信頼されたドメイン内のリソースにアクセスするときの "サポートされていない etype" エラー
適用対象: Windows Server 2019、Windows Server 2016、Windows Server 2012 R2
元の KB 番号: 4492348
現象
Active Directory Domain 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 では、ドメイン オブジェクトに、信頼される各ドメインを表す信頼されたドメイン オブジェクト (TTO) が関連付けられています。 TDO の属性は、信頼がサポートする Kerberos 暗号化の種類など、信頼関係を記述します。 子ドメインと親ドメインの既定の関係は、RC4 暗号化の種類をサポートする双方向の推移的信頼です。 親ドメインと子ドメインの両方に、暗号化の種類を含め、この関係を記述する TTO があります。
クライアントが DC に接続 child.contoso.com してサービスへのアクセスを要求すると、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
注:
このコマンドでは、 <trustingdomain> は、信頼するドメインの完全修飾ドメイン名 (FQDN) を表します。
ルート ドメイン (サービスが存在する場所) とchild.contoso.com子ドメイン (クライアントが存在する場所) の例contoso.comでは、DC でコマンド プロンプト ウィンドウをcontoso.com開き、次のコマンドを入力します。
ksetup /setenctypeattr child.contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
このコマンドが完了すると、 child.contoso.com DC は、クライアントが DC に到達するために使用できる紹介チケットを正常に contoso.com 構築できます。
2 つのドメイン間の関係は双方向の推移的な信頼であるため、DC のコマンド プロンプト ウィンドウ child.contoso.com を開いて信頼の反対側を構成し、次のコマンドを入力します。
ksetup /setenctypeattr contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96
このコマンドが完了すると、contoso.comDC は RC4 暗号化を使用できないが、 child.contoso.comでリソースを使用する必要があるクライアントのcontoso.com紹介チケットを構築できます。
ksetup ツールの詳細については、「 ksetup」を参照してください。
方法 2: AES128 および AES256 暗号化に加えて RC4 暗号化をサポートするようにクライアントを構成する
この方法では、信頼ではなくクライアントの構成を変更する必要があります。 1 つのクライアントの構成を変更することも、グループ ポリシーを使用してドメイン内の複数のクライアントの構成を変更することもできます。 ただし、この構成変更のメイン欠点は、セキュリティを向上させるために RC4 暗号化を無効にした場合、その変更をロールバックできない可能性があるということです。
クライアントが使用できる暗号化の種類を変更する完全な手順については、「 Kerberos でサポートされる暗号化の種類の Windows 構成」を参照してください。
方法 3: RC4 暗号化ではなく AES128 および AES 256 暗号化をサポートするように信頼を構成する
このメソッドは、信頼属性を構成する方法 1 のようになります。
Windows フォレスト信頼の場合、信頼の両側で AES がサポートされます。 したがって、信頼に対するすべてのチケット要求では AES が使用されます。 ただし、紹介チケットを検査するサード パーティの Kerberos クライアントは、チケットでクライアントがサポートしていない暗号化の種類を使用していることを通知する場合があります。 このようなクライアントが引き続きチケットを検査できるようにするには、AES をサポートするように更新します。
この方法を使用する場合は、Active Directory ドメインと信頼 MMC スナップインを使用して信頼を構成します。 このメソッドを使用するには、次の手順に従います。
[Active Directory ドメインと信頼] で、信頼されたドメイン オブジェクト (例では)
contoso.comに移動します。 オブジェクトを右クリックし、[ プロパティ] を選択し、[ 信頼] を選択します。[ このドメインを信頼するドメイン (受信信頼)] ボックスで、信頼するドメイン (例では
child.domain.com) を選択します。[ プロパティ] を選択し、[ 他のドメインは Kerberos AES Encryption をサポートしています] を選択し、[ OK] を選択します。
注:
信頼構成を検証するには、[信頼ドメイン] ダイアログ ボックスで [ 検証 ] を選択します。
重要
一方向の信頼の場合、信頼されたドメインは信頼ドメインを受信信頼として一覧表示し、信頼ドメインは信頼されたドメインを送信信頼として一覧表示します。
リレーションシップが双方向の信頼である場合、各ドメインは、他のドメインを受信信頼と送信信頼の両方として一覧表示します。 この構成では、このドメインを信頼するドメイン (受信信頼) とこのドメインによって信頼されたドメイン (送信信頼) の両方でドメイン構成をチェックしてください。 どちらの場合も、チェック ボックスをオンにする必要があります。
[信頼] タブ で 、[ OK] をクリックします。
信頼するドメイン (
child.contoso.com) のドメイン オブジェクトに移動します。手順 1 ~ 4 を繰り返して、このドメインの信頼構成が他のドメインの信頼構成を反映していることを確認します (この場合、受信および送信の信頼リストには が含まれます
contoso.com)。
詳細
TTO の詳細については、次の記事を参照してください。
Kerberos 暗号化の種類の詳細については、次の記事を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示