元の KB 番号: 4492348
現象
Active Directory ドメイン Services (AD DS) フォレストの子ドメイン内のコンピューターは、同じフォレスト内の別のドメインにあるサービスにアクセスできません。 クライアント コンピューターとの間の通信でネットワーク トレースを実行する場合、トレースには次の Kerberos メッセージが含まれます。
6 9:35:19 AM 8/14/2018 17.8417442 192.168.1.101 192.168.1.2 KerberosV5 KerberosV5:AS Request Cname: Administrator Realm: contoso.com Sname: krbtgt/contoso.com {TCP:4, IPv4:1}
7 9:35:19 AM 8/14/2018 17.8452544 192.168.1.2 192.168.1.101 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14) {TCP:4, IPv4:1}
子ドメインのドメイン コントローラーで、イベント ビューアーは次のイベント 14 エントリを記録します。
Log Name: System
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID: 14
Task Category: None
Level: Error
Keywords: Classic
Description:
While processing an AS request for target service krbtgt, the account Administrator did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23 -133 -128. Changing or resetting the password of Administrator will generate a proper key.
原因
この問題は、次のように子ドメイン (またはクライアントのみ) を構成するときに発生します。
- RC4_HMAC-MD5 暗号化の種類は無効にし、AES128-CTS-HMAC-SHA1-96 と AES256-CTS-HMAC-SHA1-96 暗号化の種類は有効のままにします。
- NTLM 認証を無効にします。
Kerberos 暗号化の種類
RC4 暗号化は、新しい暗号化の種類である AES128-CTS-HMAC-SHA1-96 および AES256-CTS-HMAC-SHA1-96 よりも安全性が低いと見なされます。 Windows 10 セキュリティ技術実装ガイドなどのセキュリティ ガイドではAES128 暗号化または AES256 暗号化のみを使用するようにコンピューターを構成することで、コンピューターのセキュリティを向上させる手順を示します (「 DES および RC4 暗号化スイートの使用を防ぐために、Kerberos 暗号化の種類を構成する必要がありますを参照してください)。
このようなクライアントは、AES128 または AES256 暗号化を使用する独自のドメイン内のサービスに引き続き接続できます。 ただし、他の要因により、クライアントが別の信頼されたドメイン内の同様のサービスに接続できなくなる可能性があります。ただし、それらのサービスで AES128 または AES256 暗号化も使用されている場合でも同様です。
非常に高いレベルでは、ドメイン コントローラー (DC) は、独自のドメイン内でアクセス要求を管理する役割を担います。 Kerberos 認証プロセスの一環として、DC は、クライアントとサービスの両方で同じ Kerberos 暗号化の種類を使用できることを確認します。 ただし、クライアントが別の信頼されたドメイン内のサービスへのアクセスを要求する場合、クライアントの DC は、サービスのドメイン内の DC にクライアントを "参照" する必要があります。 DC は、クライアントとサービスの暗号化の種類を比較するのではなく、紹介チケットを構築するときに、クライアントの暗号化の種類と信頼を比較します。
この問題は、信頼自体の構成が原因で発生します。 Active Directory では、ドメイン オブジェクトには、信頼する各ドメインを表す信頼されたドメイン オブジェクト (TDO) が関連付けられています。 TDO の属性は、信頼がサポートする Kerberos 暗号化の種類など、信頼関係を表します。 子ドメインと親ドメインの間の既定の関係は、RC4 暗号化の種類をサポートする双方向の推移的信頼です。 親ドメインと子ドメインの両方に、暗号化の種類を含め、このリレーションシップを記述する TTO があります。
クライアントが child.contoso.com DC に接続してサービスへのアクセスを要求すると、DC はサービスが信頼されたドメイン contoso.com内にあると判断します。 DC は信頼構成をチェックして、信頼がサポートする暗号化の種類を識別します。 既定では、信頼は RC4 暗号化をサポートしますが、AES128 または AES256 暗号化はサポートしません。 一方、クライアントは RC4 暗号化を使用できません。 DC は共通の暗号化の種類を識別できないため、紹介チケットを作成できず、要求は失敗します。
NTLM 認証
Kerberos 認証が失敗した後、クライアントは NTLM 認証にフォールバックしようとします。 ただし、NTLM 認証が無効になっている場合、クライアントには他の方法はありません。 そのため、接続の試行は失敗します。
解決方法
この問題を解決するには、次のいずれかの方法を使用します。
- 方法 1: RC4 暗号化に加えて、AES128 および AES 256 暗号化をサポートするように信頼を構成します。
- 方法 2: AES128 および AES256 暗号化に加えて RC4 暗号化をサポートするようにクライアントを構成します。
- 方法 3: RC4 暗号化ではなく AES128 および AES 256 暗号化をサポートするように信頼を構成します。
選択は、セキュリティのニーズと、中断を最小限に抑えるか、下位互換性を維持する必要性によって異なります。
方法 1: RC4 暗号化に加えて、AES128 および AES 256 暗号化をサポートするように信頼を構成する
この方法では、信頼構成に新しい暗号化の種類が追加され、クライアントまたはサービスに変更を加える必要はありません。 この方法では、 ksetup コマンド ライン ツールを使用して信頼を構成します。
信頼の Kerberos 暗号化の種類を構成するには、信頼されたドメインの DC でコマンド プロンプト ウィンドウを開き、次のコマンドを入力します。
ksetup /setenctypeattr <trustingdomain> RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
Note
このコマンドでは、 <trustingdomain> は、信頼するドメインの完全修飾ドメイン名 (FQDN) を表します。
contoso.comがルート ドメイン (サービスが存在する場所) であり、child.contoso.comが子ドメイン (クライアントが存在する) である例では、contoso.com DC でコマンド プロンプト ウィンドウを開き、次のコマンドを入力します。
ksetup /setenctypeattr child.contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
このコマンドが完了すると、 child.contoso.com DC は、クライアントが contoso.com DC に到達するために使用できる紹介チケットを正常に構築できます。
2 つのドメイン間の関係は双方向の推移的信頼であるため、 child.contoso.com DC でコマンド プロンプト ウィンドウを開いて信頼のもう一方の側を構成し、次のコマンドを入力します。
ksetup /setenctypeattr contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
このコマンドが完了すると、contoso.com DC は、RC4 暗号化を使用できないが、child.contoso.com内のリソースを使用する必要があるcontoso.com内のすべてのクライアントの紹介チケットを作成できます。
ksetup ツールの詳細については、「 ksetupを参照してください。
方法 2: AES128 および AES256 暗号化に加えて RC4 暗号化をサポートするようにクライアントを構成する
この方法では、信頼ではなくクライアントの構成を変更する必要があります。 1 つのクライアントの構成を変更することも、グループ ポリシーを使用してドメイン内の複数のクライアントの構成を変更することもできます。 ただし、この構成変更の主な欠点は、セキュリティを向上させるために RC4 暗号化を無効にした場合、その変更をロールバックできない可能性があるということです。
クライアントが使用できる暗号化の種類を変更する完全な手順については、「 Windows Configurations for Kerberos Supported Encryption Type(Kerberos でサポートされる暗号化の種類の Windows 構成)」を参照してください。
方法 3: RC4 暗号化ではなく AES128 および AES 256 暗号化をサポートするように信頼を構成する
このメソッドは、信頼属性を構成する方法 1 に似ています。
Windows フォレストの信頼の場合、信頼の両側で AES がサポートされます。 したがって、信頼に関するすべてのチケット要求では AES が使用されます。 ただし、紹介チケットを検査するサード パーティの Kerberos クライアントは、クライアントがサポートしていない暗号化の種類をチケットが使用していることを通知する場合があります。 このようなクライアントが引き続きチケットを検査できるようにするには、AES をサポートするように更新します。
この方法を使用する場合は、Active Directory ドメインと信頼 MMC スナップインを使用して信頼を構成します。 このメソッドを使用するには、次の手順に従います。
Active Directory ドメインと信頼で、信頼されたドメイン オブジェクト (例では
contoso.com) に移動します。 オブジェクトを右クリックし、 Properties を選択し、 Trusts を選択します。[このドメインを信頼する ドメイン (受信信頼)] ボックスで、信頼するドメイン (例では
child.domain.com) を選択します。Propertiesを選択し、 Kerberos AES 暗号化をサポートする他のドメインを選択し、OK を選択します。
Note
信頼構成を検証するには、信頼するドメイン ダイアログ ボックスで Validate を選択します。
重要
一方向の信頼の場合、信頼されたドメインは信頼するドメインを受信信頼として一覧表示し、信頼するドメインは信頼されたドメインを送信信頼として一覧表示します。
リレーションシップが双方向の信頼である場合、各ドメインは、他のドメインを受信信頼と送信信頼の両方として一覧表示します。 この構成では、 このドメインを信頼するドメイン (受信信頼) と ドメインによって信頼されているドメイン (送信信頼)) の両方でドメイン構成を確認してください。 どちらの場合も、チェック ボックスをオンにする必要があります。
[ Trusts タブで、 OKをクリックします。
信頼するドメイン (
child.contoso.com) のドメイン オブジェクトに移動します。手順 1 ~ 4 を繰り返して、このドメインの信頼構成が他のドメインの信頼構成を反映していることを確認します (この場合、受信および送信の信頼リストには
contoso.comが含まれます)。
詳細
TTO の詳細については、次の記事を参照してください。
Kerberos 暗号化の種類の詳細については、次の記事を参照してください。