信頼されたドメイン内のリソースにアクセスするときの "サポートされていない 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 では、ドメイン オブジェクトには、信頼する各ドメインを表す信頼されたドメイン オブジェクト (TDO) が関連付けられます。 TDO の属性は、信頼がサポートする Kerberos 暗号化の種類を含む信頼関係を記述します。 子ドメインと親ドメインの間の既定のリレーションシップは、RC4 暗号化の種類をサポートする双方向推移的信頼です。 親ドメインと子ドメインの両方に、暗号化の種類を含め、このリレーションシップを記述する TDO があります。

クライアントが 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 ドメインと Trusts MMC スナップインを使用して信頼を構成します。 このメソッドを使用するには、次の手順に従います。

  1. Active Directory のドメインと信頼で、信頼されたドメイン オブジェクトに移動します (例では)。contoso.com オブジェクトを右クリックし、[ プロパティ] を選択し、[ 信頼] を選択します。

  2. [このドメインを信頼するドメイン (受信信頼)] ボックスで、信頼するドメインを選択します (例では)。 child.domain.com

  3. [プロパティ] を選択し、他のドメインが Kerberos AES 暗号化をサポートしている場合は [OK] を選択します

    子ドメインのプロパティのスクリーンショット。プロパティ ウィンドウには、他のドメインが Kerberos AES Encryption チェックボックスをサポートしています。

    注:

    信頼の構成を検証するには、[信頼するドメイン] ダイアログ ボックスで [検証 ] を選択します。

    重要

    一方向信頼の場合、信頼されたドメインは信頼するドメインを受信信頼として一覧表示し、信頼するドメインには信頼されたドメインが送信信頼として一覧表示されます。

    リレーションシップが双方向信頼の場合、各ドメインは他のドメインを受信信頼と送信信頼の両方として一覧表示します。 この構成では、このドメインを信頼するドメイン (受信信頼) と、このドメインによって信頼されているドメイン (送信信頼) の両方でドメイン構成を確認してください。 どちらの場合も、チェック ボックスをオンにする必要があります。

  4. [信頼] タブ 、[OK] をクリック します

  5. 信頼するドメイン (child.contoso.com) のドメイン オブジェクトに移動します。

  6. 手順 1 ~ 4 を繰り返して、このドメインの信頼構成が他のドメインの信頼構成を反映していることを確認します (この場合は、受信信頼リストと送信信頼リストに含まれます contoso.com)。

詳細情報

TDO の詳細については、次の記事を参照してください。

Kerberos 暗号化の種類の詳細については、次の記事を参照してください。