インストール時に使用した管理者アカウントが前提条件チェック中にロックアウトされたために、ソフトウェア アプリケーションをインストールできない状況が発生しています。調査の結果、原因が判明しました。前提条件チェックでは、サーバーの FQDN ではなく IP アドレスへの RPC 呼び出しによって他のサーバーのリモート レジストリ設定が調べられますが、何らかの理由で認証が失敗し、アカウントがロックアウトされます。
私たちは次のことを実行してこれを検証しました。
- regedit を使用して、サーバーの FQDN を使用して別の AD サーバーのレジストリに接続しようとすると、問題なく接続されます。
- サーバーの IP アドレスを使用して同じ接続を試みると、新しい資格情報の入力を求められます。
- すべての AD 資格情報は失敗し、最終的には使用中のアカウントがロックアウトされますが、ローカル管理者アカウントを使用すると問題はありません。
環境内の他のサーバーからもこのテストを実行しましたが、IP による接続と認証に問題はありませんでした。NIC/DNS/WINS 設定を比較しましたが、目立った違いはありませんでした。GPO 設定をクロスチェックする段階ですが、何も見つからないと思います。
もちろんローカル管理者アカウントを使用することもできますが、なぜFQDN ではなく IP アドレスを使用した RPC 呼び出しにより、AD 認証が失敗し、AD アカウントがロックアウトされます。何かアイデアはありますか?
答え1
アカウントがロックアウトされた場合、パスワードに問題があることは間違いありません。そうでない場合は、Kerberos が使用されず、NTLM が無効になっているか、何かが原因の可能性があります。ソース サーバーとターゲット サーバーのセキュリティ ログを確認し、認証の問題に関連する可能性のあるログ エントリを提供する必要があります。
これも試すことができます。ただし、何かが機能しない理由がわからないときに変更するのはあまり効率的ではなく、他のものを壊してしまう可能性があります。
Windows 10 バージョン 1507 および Windows Server 2016 以降では、Kerberos クライアントは SPN で IPv4 および IPv6 ホスト名をサポートするように構成できます。
デフォルトでは、ホスト名が IP アドレスの場合、Windows はホストに対して Kerberos 認証を試行しません。NTLM などの他の有効な認証プロトコルにフォールバックします。ただし、アプリケーションが IP アドレスを使用するようにハードコードされている場合、アプリケーションは Kerberos を使用せずに NTLM にフォールバックします。これにより、環境が NTLM を無効にすると互換性の問題が発生する可能性があります。
NTLM を無効にした場合の影響を軽減するために、管理者がサービス プリンシパル名のホスト名として IP アドレスを使用できる新しい機能が導入されました。
詳しくはこちら
https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip