Błąd "Nieobsługiwany typ etype" podczas uzyskiwania dostępu do zasobu w zaufanej domenie

2025-01-15

Oryginalny numer KB: 4492348

Symptomy

Komputer w domenie podrzędnej lasu usług domena usługi Active Directory (AD DS) nie może uzyskać dostępu do usługi, która znajduje się w innej domenie w tym samym lesie. W przypadku uruchomienia śledzenia sieci w komunikacji z komputerem klienckim i z komputera klienckiego ślad zawiera następujące komunikaty Protokołu 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}

Na kontrolerze domeny podrzędnej Podgląd zdarzeń rejestruje następujący wpis zdarzenia 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.

Przyczyna

Ten problem występuje podczas konfigurowania domeny podrzędnej (lub tylko klienta) w następujący sposób:

Należy wyłączyć typ szyfrowania RC4_HMAC-MD5, pozostawiając włączone typy szyfrowania AES128-CTS-HMAC-SHA1-96 i AES256-CTS-HMAC-SHA1-96.
Należy wyłączyć uwierzytelnianie NTLM.

Typy szyfrowania Kerberos

Szyfrowanie RC4 jest uważane za mniej bezpieczne niż nowsze typy szyfrowania, AES128-CTS-HMAC-SHA1-96 i AES256-CTS-HMAC-SHA1-96. Przewodniki zabezpieczeń, takie jak Przewodnik implementacji technicznej zabezpieczeń systemu Windows 10, zawierają instrukcje dotyczące poprawy bezpieczeństwa komputera przez skonfigurowanie go do używania tylko szyfrowania AES128 i/lub AES256 (zobacz Typy szyfrowania Kerberos muszą być skonfigurowane w celu zapobiegania używaniu pakietów szyfrowania DES i RC4).

Taki klient może nadal łączyć się z usługami w ramach własnej domeny korzystającej z szyfrowania AES128 lub AES256. Jednak inne czynniki mogą uniemożliwić klientowi nawiązanie połączenia z podobnymi usługami w innej zaufanej domenie, nawet jeśli te usługi również używają szyfrowania AES128 lub AES256.

Na bardzo wysokim poziomie kontroler domeny jest odpowiedzialny za zarządzanie żądaniami dostępu w ramach własnej domeny. W ramach procesu uwierzytelniania Kerberos kontroler domeny sprawdza, czy zarówno klient, jak i usługa mogą używać tego samego typu szyfrowania Kerberos. Jeśli jednak klient żąda dostępu do usługi w innej, zaufanej domenie, kontroler domeny klienta musi "odwoływać się" do kontrolera domeny usługi. Gdy kontroler domeny kompiluje bilet poleceń, zamiast porównywać typy szyfrowania klienta i usługi, porównuje typy szyfrowania klienta i zaufania.

Problem występuje z powodu konfiguracji samego zaufania. W usłudze Active Directory obiekt domeny ma skojarzone zaufane obiekty domeny (TDOS), które reprezentują każdą zaufaną domenę. Atrybuty obiektu TDO opisują relację zaufania, w tym typy szyfrowania Kerberos obsługiwane przez zaufanie. Domyślna relacja między domeną podrzędną a domeną nadrzędną jest dwukierunkowym zaufaniem przechodnim obsługującym typ szyfrowania RC4. Zarówno nadrzędna, jak i domena podrzędna mają obiekty TDOs opisujące tę relację, w tym typ szyfrowania.

Gdy klient kontaktuje się z kontrolerem child.contoso.com domeny w celu żądania dostępu do usługi, kontroler domeny określa, że usługa znajduje się w zaufanej domenie contoso.com. Kontroler domeny sprawdza konfigurację zaufania, aby zidentyfikować typ szyfrowania, który obsługuje zaufanie. Domyślnie zaufanie obsługuje szyfrowanie RC4, ale nie szyfrowanie AES128 lub AES256. Z drugiej strony klient nie może używać szyfrowania RC4. Kontroler domeny nie może zidentyfikować wspólnego typu szyfrowania, więc nie może skompilować biletu odwołania i żądanie kończy się niepowodzeniem.

Uwierzytelnianie NTLM

Po niepomyślnie uwierzytelnieniu protokołu Kerberos klient próbuje wrócić do uwierzytelniania NTLM. Jeśli jednak uwierzytelnianie NTLM jest wyłączone, klient nie ma innych alternatyw. W związku z tym próba połączenia kończy się niepowodzeniem.

Rozwiązanie

Aby rozwiązać ten problem, skorzystaj z jednej z następujących metod:

Metoda 1. Skonfiguruj zaufanie do obsługi szyfrowania AES128 i AES 256 oprócz szyfrowania RC4.
Metoda 2. Skonfiguruj klienta do obsługi szyfrowania RC4 oprócz szyfrowania AES128 i AES256.
Metoda 3. Skonfiguruj zaufanie do obsługi szyfrowania AES128 i AES 256 zamiast szyfrowania RC4.

Wybór zależy od potrzeb związanych z zabezpieczeniami i konieczności zminimalizowania zakłóceń lub zachowania zgodności z poprzednimi wersjami.

Metoda 1. Konfigurowanie zaufania w celu obsługi szyfrowania AES128 i AES 256 oprócz szyfrowania RC4

Ta metoda dodaje nowsze typy szyfrowania do konfiguracji zaufania i nie wymaga żadnych zmian w kliencie ani usłudze. W tej metodzie użyjesz ksetup narzędzia wiersza polecenia, aby skonfigurować zaufanie.

Aby skonfigurować typ szyfrowania Kerberos zaufania, otwórz okno wiersza polecenia na kontrolerze domeny w zaufanej domenie, a następnie wprowadź następujące polecenie:

ksetup /setenctypeattr <trustingdomain> RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Uwaga 16.

W tym poleceniu <trustingdomain> reprezentuje w pełni kwalifikowaną nazwę domeny (FQDN) domeny zaufania.

W przykładzie, w którym contoso.com jest domena główna (gdzie znajduje się usługa) i child.contoso.com jest domeną podrzędną (gdzie znajduje się klient), otwórz okno wiersza polecenia na kontrolerze contoso.com domeny, a następnie wprowadź następujące polecenie:

ksetup /setenctypeattr child.contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Po zakończeniu tego polecenia kontroler child.contoso.com domeny może pomyślnie skompilować bilet odwołania, którego klient może użyć do nawiązania połączenia z kontrolerem contoso.com domeny.

Ponieważ relacja między dwiema domenami jest dwukierunkowym zaufaniem przechodnim, skonfiguruj drugą stronę zaufania, otwierając okno wiersza polecenia na kontrolerze child.contoso.com domeny, a następnie wprowadź następujące polecenie:

ksetup /setenctypeattr contoso.com RC4-HMAC-MD5 AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Po zakończeniu tego polecenia kontroler domeny może tworzyć bilety poleceń dla wszystkich klientów, którzy contoso.com nie mogą używać szyfrowania RC4, contoso.com ale muszą używać zasobów w programie child.contoso.com.

Aby uzyskać więcej informacji na temat narzędzia ksetup, zobacz ksetup.

Metoda 2. Konfigurowanie klienta do obsługi szyfrowania RC4 oprócz szyfrowania AES128 i AES256

Ta metoda obejmuje zmianę konfiguracji klienta zamiast zaufania. Możesz zmienić konfigurację pojedynczego klienta lub użyć zasad grupy, aby zmienić konfigurację wielu klientów w domenie. Jednak główną wadą tej zmiany konfiguracji jest to, że jeśli wyłączono szyfrowanie RC4 w celu zwiększenia bezpieczeństwa, wycofywanie tej zmiany może nie być możliwe.

Aby uzyskać pełne instrukcje dotyczące zmiany typów szyfrowania, których mogą używać klienci, zobacz Konfiguracje systemu Windows dla obsługiwanego typu szyfrowania Kerberos.

Metoda 3. Konfigurowanie zaufania w celu obsługi szyfrowania AES128 i AES 256 zamiast szyfrowania RC4

Ta metoda przypomina metodę 1 w tej metodzie, w której konfigurujesz atrybuty zaufania.

W przypadku zaufania lasu systemu Windows obie strony zaufania obsługują usługę AES. W związku z tym wszystkie żądania biletów dotyczące zaufania używają AES. Jednak klient protokołu Kerberos innej firmy, który sprawdza bilet poleceń, może powiadomić Cię, że bilet używa typu szyfrowania, którego klient nie obsługuje. Aby umożliwić takiemu klientowi sprawdzenie biletu, zaktualizuj go, aby obsługiwał usługę AES.

Jeśli używasz tej metody, skonfiguruj zaufanie przy użyciu przystawki MMC domena usługi Active Directory s i zaufania. Aby użyć tej metody, wykonaj następujące kroki:

W domena usługi Active Directory i zaufania przejdź do obiektu zaufanej domeny (w przykładziecontoso.com). Kliknij prawym przyciskiem myszy obiekt, wybierz pozycję Właściwości, a następnie wybierz pozycję Zaufania.
W polu Domeny, które ufają tej domenie (przychodzące relacje zaufania) wybierz domenę zaufania (w przykładzie child.domain.com).
Wybierz pozycję Właściwości, wybierz pozycję Inna domena obsługuje szyfrowanie Kerberos AES, a następnie wybierz przycisk OK.

Uwaga 16.

Aby zweryfikować konfigurację zaufania, wybierz pozycję Zweryfikuj w oknie dialogowym ufającej domeny.

Ważne

W przypadku zaufania jednokierunkowego zaufana domena wyświetla domenę zaufania jako relację zaufania przychodzącego, a domena zaufania wyświetla zaufaną domenę jako relację zaufania wychodzącego.

Jeśli relacja jest relacją dwukierunkową, każda domena wyświetla drugą domenę jako relację zaufania przychodzącego i wychodzącego. W tej konfiguracji upewnij się, że konfiguracja domeny jest sprawdzana w obu domenach, które ufają tej domenie (przychodzącym relacjom zaufania) i Domenom zaufanym przez tę domenę (relacje zaufania wychodzące). W obu przypadkach należy zaznaczyć pole wyboru.
Na karcie Zaufania kliknij przycisk OK.
Przejdź do obiektu domeny dla domeny zaufania (child.contoso.com).
Powtórz kroki 1– 4, aby upewnić się, że konfiguracja zaufania dla tej domeny dubluje konfigurację zaufania dla innej domeny (w tym przypadku listy zaufania przychodzące i wychodzące zawierają contoso.com).

Więcej informacji

Aby uzyskać więcej informacji na temat obiektów TDOS, zobacz następujące artykuły:

Aby uzyskać więcej informacji na temat typów szyfrowania Kerberos, zobacz następujące artykuły: