Felmeddelandet "E-typ som inte stöds" visas när du öppnar en resurs i en betrodd domän

Artikel
03/31/2022
6 minuter för att läsa

Gäller för: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Ursprungligt KB-nummer: 4492348

Symptom

En dator i en underordnad domän i en AD DS-skog (Active Directory Domain Services) kan inte komma åt en tjänst som finns i en annan domän i samma skog. Om du kör en nätverksspårning för kommunikation till och från klientdatorn innehåller spårningen följande Kerberos-meddelanden:

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}

I domänkontrollanten för den underordnade domänen registrerar Händelsevisaren följande händelse 14-post:

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.

Orsak

Det här problemet uppstår när du konfigurerar den underordnade domänen (eller bara klienten) enligt följande:

Du inaktiverar RC4_HMAC-MD5-krypteringstypen och lämnar AES128-CTS-HMAC-SHA1-96 och AES256-CTS-HMAC-SHA1-96-krypteringstyperna aktiverade.
Du inaktiverar NTLM-autentisering.

Kerberos-krypteringstyper

RC4-kryptering anses vara mindre säker än de nyare krypteringstyperna, AES128-CTS-HMAC-SHA1-96 och AES256-CTS-HMAC-SHA1-96. Säkerhetsguider som teknisk implementeringsguide för Windows 10 Security ger instruktioner för hur du förbättrar säkerheten på en dator genom att konfigurera den till att bara använda AES128- och/eller AES256-kryptering (se Kerberos-krypteringstyper måste konfigureras för att förhindra användning av DES- och RC4-krypterings paket).

En sådan klient kan fortsätta att ansluta till tjänster inom en egen domän som använder AES128- eller AES256-kryptering. Men andra faktorer kan förhindra att klienten ansluter till liknande tjänster i en annan betrodd domän, även om de tjänsterna också använder AES128- eller AES256-kryptering.

På en mycket hög nivå ansvarar en domänkontrollant för att hantera åtkomstförfrågningar inom sin egen domän. Som en del av Kerberos-autentiseringsprocessen kontrollerar DC att både klienten och tjänsten kan använda samma Kerberos-krypteringstyp. Men när en klient begär åtkomst till en tjänst i en annan betrodd domän måste klientens DC "referera" klienten till en dc i tjänstens domän. När DC skapar hänvisningsbegäran jämförs krypteringstyperna för klienten och tjänsten i stället för att jämföra klientens och tjänstens krypteringstyper.

Problemet uppstår på grund av själva förtroendekonfigurationen. I Active Directory har ett domänobjekt tillhörande betrodda domänobjekt (TDOs) som representerar varje domän som den litar på. Attributen i en TDO beskriver förtroenderelationen, inklusive vilka Kerberos-krypteringstyper som lita på. Standardrelationen mellan en underordnad domän och en överordnad domän är ett tvåvägs transitivt förtroende som stöder RC4-krypteringstypen. Både den överordnade och den underordnade domänen har TDOs som beskriver den här relationen, inklusive krypteringstyp.

När klienten kontaktar dc för child.contoso.com att begära åtkomst till tjänsten, avgör dc att tjänsten finns i den betrodda domänen contoso.com. Dc kontrollerar förtroendekonfigurationen för att identifiera den krypteringstyp som förtroende stöder. Som standard stöder förtroende RC4-kryptering men inte AES128- eller AES256-kryptering. Å andra sidan kan klienten inte använda RC4-kryptering. Dc kan inte identifiera en vanlig krypteringstyp, så den kan inte skapa hänvisningsbegäran, och begäran misslyckas.

NTLM-autentisering

När Kerberos-autentiseringen misslyckas försöker klienten att gå tillbaka till NTLM-autentisering. Men om NTLM-autentisering är inaktiverad har klienten inga andra alternativ. Därför går det inte att ansluta.

Lösning

Lös problemet med någon av följande metoder:

Metod 1: Konfigurera förtroende för att stödja AES128- och AES 256-kryptering utöver RC4-kryptering.
Metod 2: Konfigurera klienten för att stödja RC4-kryptering utöver AES128- och AES256-kryptering.
Metod 3: Konfigurera förtroende för att stödja AES128- och AES 256-kryptering i stället för RC4-kryptering.

Valet beror på dina säkerhetsbehov och du behöver minimera avbrottet eller bibehålla bakåtkompatibilitet.

Metod 1: Konfigurera förtroende för att stödja AES128- och AES 256-kryptering utöver RC4-kryptering

Den här metoden lägger till de nyare krypteringstyperna till förtroendekonfigurationen och kräver inga ändringar av klienten eller tjänsten. I den här metoden använder du kommandoradsverktyget ksetup för att konfigurera förtroende.

Om du vill konfigurera kerberos-krypteringstypen för ett förtroende öppnar du kommandotolken i ett DC i den betrodda domänen och anger sedan följande kommando:

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

Anteckning

I det här kommandot <trustingdomain> representerar det fullständiga kvalificerade domännamnet (FQDN) för den betrodda domänen.

I exemplet contoso.com där är rotdomänen (där tjänsten finns) och är den underordnade domänen (contoso.comdär klienten finns) child.contoso.com öppnar du ett kommandotolkfönster i ett DC och anger sedan följande kommando:

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

När det här kommandot har avslutats kan child.contoso.com DC:et skapa hänvisningsbegäran som klienten kan använda för att nå DC contoso.com .

Eftersom relationen mellan de två domänerna är ett tvåvägs transitivt child.contoso.com förtroende konfigurerar du den andra sidan av förtroende genom att öppna kommandotolken i ett dc-fönster och ange sedan följande kommando:

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

När det här kommandot har avslutats kan ett contoso.com DC contoso.com skapa hänvisningsärenden för alla klienter som inte kan använda RC4-kryptering men som måste använda resurser i child.contoso.com.

Mer information om ksetupverktyget finns i ksetup.

Metod 2: Konfigurera klienten för att stödja RC4-kryptering utöver AES128- och AES256-kryptering

Den här metoden innebär att du ändrar konfigurationen av klienten i stället för att lita på den. Du kan ändra konfigurationen av en enskild klient eller använda Grupprincip om du vill ändra konfigurationen av flera klienter i en domän. Den största nackdelen med den här konfigurationsändringen är att om du inaktiverar RC4-kryptering för att förbättra säkerheten är det inte möjligt att distribuera den här ändringen.

Fullständiga instruktioner om hur du ändrar krypteringstyperna som klienter kan använda finns i Windows Konfigurationer för krypteringstyp som stöds av Kerberos.

Metod 3: Konfigurera förtroende för att stödja AES128- och AES 256-kryptering i stället för RC4-kryptering

Den här metoden liknar metod 1 på så sätt att du konfigurerar förtroendeattributen.

När det gäller Windows förtroenden för skogen stöder båda sidorna av förtroende-AES. Därför använder alla begäran om biljett för förtroende AES. Men en Kerberos-klient från tredje part som inspekterar hänvisningsbegäran kan meddela dig att biljetten använder en krypteringstyp som klienten inte stöder. För att fortsätta att tillåta en sådan klient att kontrollera biljetten, uppdatera den till stöd för AES.

När du använder den här metoden konfigurerar du förtroende med hjälp av snapin-modulen MMC-snapin-modulen Active Directory Domains and Trusts MMC. Följ de här stegen om du vill använda den här metoden:

Gå till det betrodda domänobjektet (i exemplet) i Active Directory - domäner och förtroendencontoso.com. Högerklicka på objektet, välj Egenskaper och välj sedan Förtroenden.
I rutan Domäner som litar på den här domänen (inkommande förtroenden) markerar du den betrodda domänen (i exemplet child.domain.com).
Välj Egenskaper, välj Den andra domänen har stöd för Kerberos AES-kryptering och välj sedan OK.

Anteckning

Om du vill verifiera förtroendekonfigurationen väljer du Verifiera i dialogrutan Betrodd domän.

Viktigt

Om du litar på en envägsförtroende visas den betrodda domänen som ett inkommande förtroende och den betrodda domänen visas som ett utgående förtroende.

Om relationen är tvåvägsförtroende visas den andra domänen som både ett inkommande och utgående förtroende. I den här konfigurationen ska du kontrollera domänkonfigurationen i både Domäner som litar på den här domänen (inkommande förtroenden) och Domäner som är betrodda av den här domänen (utgående förtroenden). I båda fallen måste kryssrutan vara markerad.
Klicka på OK på fliken Förtroenden.
Navigera till domänobjektet för den betrodda domänen (child.contoso.com).
Upprepa steg 1–4 för att säkerställa att förtroendekonfigurationen för den här domänen speglar förtroendekonfigurationen för den andra domänen (i det här fallet innehåller listorna för inkommande och utgående förtroende contoso.com).

Mer information

Mer information om TDOS finns i följande artiklar:

Mer information om Kerberos-krypteringstyper finns i följande artiklar: