Felsöka Kerberos-konfigurationer för begränsad delegering (KCD) med Microsoft Entra-programproxy

Metoderna för enkel inloggning varierar från ett program till ett annat. Microsoft Entra-programproxy tillhandahåller Kerberos-begränsad delegering (KCD) som standard. Användare autentiserar till privata program med Kerberos.

Den här artikeln innehåller en referenspunkt för att felsöka de vanligaste problemen. Den omfattar även diagnos av mer komplexa implementeringsproblem.

I den här artikeln görs följande antaganden.

• Distribution av Microsoft Entra-programproxy och allmän åtkomst till icke-KCD-program. Mer information finns i Komma igång med programproxy.
• Det publicerade programmet baseras på IIS (Internet Information Services) och Microsofts implementering av Kerberos.
• Server- och programvärdar finns i en enda Microsoft Entra-domän. Mer information om scenarier mellan domäner och skogar finns i KCD vitbok .
• Programmet publiceras i en Microsoft Entra-klientorganisation med förautentisering aktiverat. Användarna förväntas autentisera med hjälp av formulärbaserad autentisering. Omfattande klientautentiseringsscenarier omfattas inte av den här artikeln.

Förutsättningar

Enkla felkonfigurationer eller allmänna misstag orsakar de flesta problem. Kontrollera alla krav i Använda enkel inloggning med KCD med programproxyn innan du felsöker.

Anslutningsvärdar är inte begränsade till kommunikation med bara en specifik domänkontrollant på en lokal plats (DC). Kontrollera vilken domänkontrollant som används eftersom den kan ändras.

Scenarier mellan domäner förlitar sig på hänvisningar som dirigerar en anslutningsvärd till domänkontrollanter som kan ligga utanför den lokala nätverksperimetern. I dessa fall är det lika viktigt att även skicka trafik vidare till domänkontrollanter som representerar andra domäner. Annars misslyckas delegeringen.

Undvik aktiva IPS- eller IDS-enheter (Intrusion Detection System) mellan anslutningsvärdar och domänkontrollanter. Dessa enheter är för påträngande och stör RPC-trafiken (Remote Procedure Call).

Testa delegering i enkla scenarier. Ju fler variabler du introducerar, desto mer kan du behöva kämpa med. Begränsa testningen till en enda kontakt för att spara tid. Lägg till fler anslutningar när problemet har lösts.

Vissa miljöfaktorer kan också bidra till ett problem. Minimera arkitekturen så mycket som möjligt under testningen för att undvika dessa faktorer. Till exempel är felkonfigurerade interna åtkomstkontrollistor (ACL: er) vanliga. Skicka om möjligt all trafik från en konnektor direkt genom till domänkontrollanterna och serverdelsprogrammet.

Den bästa platsen att placera kontakter är så nära deras mål som möjligt. En brandvägg som är placerad i linje vid testning lägger till onödig komplexitet och kan förlänga dina analyser.

Vad visar ett KCD-problem? Det finns flera vanliga tecken på att KCD-enkel inloggning misslyckas. De första tecknen på ett problem visas i webbläsaren.

Båda bilderna visar samma symptom: fel med enkel inloggning. Användaråtkomst till programmet nekas.

Felsökning

Separera felsökningen i tre steg.

Klientförautentisering

Den externa användaren autentiserar via en webbläsare. Möjligheten att i förväg autentisera till Microsoft Entra-ID är nödvändig för att KCD-enkel inloggning (SSO) ska fungera. Testa och åtgärda den här möjligheten om det finns några problem. Förautentiseringssteget är inte relaterat till KCD eller det publicerade programmet. Det är enkelt att korrigera eventuella avvikelser genom att kontrollera att ämneskontot finns i Microsoft Entra-ID. Kontrollera att programmet inte har inaktiverats eller blockerats. Felsvaret i webbläsaren är tillräckligt beskrivande för att förklara orsaken.

Delegeringstjänst

Den privata nätverksanslutningen som hämtar en Kerberos-tjänstbiljett för användare från ett Kerberos Key Distribution Center (KCD).

Den externa kommunikationen mellan klienten och Azure-klientdelen har ingen betydelse för KCD. Dessa meddelanden ser bara till att KCD fungerar. Applikationsproxytjänsten får ett giltigt användar-ID som används för att erhålla en Kerberos-biljett. Utan det här ID:t är KCD inte möjligt och misslyckas.

Webbläsarens felmeddelanden ger några bra ledtrådar om varför saker misslyckas. Registrera fälten activity ID och timestamp i svaret. Informationen hjälper till att korrelera beteendet med faktiska händelser i programproxyhändelseloggen.

Motsvarande poster som visas i händelseloggen visas som händelser 13019 eller 12027. Hitta anslutningshändelseloggarna i program- och tjänstehändelselogg>Microsoft>privata Microsoft Entra-nätverket>Connector>Admin.

1. Använd en A-post i ditt interna DNS (Domain Name System) för programmets adress, inte en CName.
2. Bekräfta att anslutningsvärden har rätt att delegera till det avsedda målkontots tjänsthuvudnamn (SPN). Bekräfta på nytt att Använd valfritt autentiseringsprotokoll har valts. Mer information finns i artikeln SSO-konfiguration.
3. Kontrollera att det bara finns en instans av SPN i Microsoft Entra-ID: t. Utfärda kommandot setspn -x från en kommandotolk på en domänmedlemsvärd.
4. Kontrollera att en domänprincip tillämpas som begränsar maximal storlek för utfärdade Kerberos-token. Principen hindrar anslutningsappen från att hämta en token om den är överdriven.

En nätverksspårning som samlar in utbyten mellan anslutningsvärden och en domän för Kerberos-begränsad delegering (KDC) är det näst bästa steget för att få mer information på låg nivå om problemen. För mer information, se felsökningsdokumentet.

Om biljetten ser bra ut ser du en händelse i loggarna som anger att autentiseringen misslyckades eftersom programmet returnerade 401. Den här händelsen anger att målprogrammet avvisade din biljett. Gå till nästa steg.

Målapplikation

Konsumenten av Kerberos-biljetten som anslutningen tillhandahåller. I det här skedet förväntar du dig att anslutningsappen skickade en Kerberos-tjänstbiljett till serverdelen. Biljetten är en rubrik i den första ansökningsbegäran.

1. Genom att använda programmets interna URL som definierats i portalen kontrollerar du att programmet är tillgängligt direkt från webbläsaren på värddatorn för anslutningen. Sedan kan du logga in. Du hittar information på sidan Felsökning.

2. Bekräfta att autentiseringen mellan webbläsaren och programmet använder Kerberos.

3. Kör DevTools (F12) i Internet Explorer eller använd Fiddler från navvärden. Gå till programmet med hjälp av den interna URL:en. Kontrollera att antingen negotiate eller Kerberos finns i de webbauktoriseringshuvuden som erbjuds som returneras i svaret från programmet.

   • Nästa Kerberos-blob som returneras i svaret från webbläsaren till programmet börjar med YII-. De här bokstäverna visar att Kerberos körs. Microsoft NT LAN Manager (NTLM) börjar å andra sidan alltid med TlRMTVNTUAAB, som läser NTLM Security Support Provider (NTLMSSP) när den avkodas från Base64. Om du ser TlRMTVNTUAAB i början av blobben är Kerberos inte tillgängligt. Om du inte ser TlRMTVNTUAABär Kerberos sannolikt tillgängligt.

     Anteckning

     Om du använder Fiddler kräver den här metoden att du tillfälligt inaktiverar utökat skydd i programmets konfiguration i IIS.

     

   • Blobben i den här bilden börjar inte med TIRMTVNTUAAB. Så i det här exemplet är Kerberos tillgängligt och Kerberos-bloben börjar inte med YII-.

4. Ta tillfälligt bort NTLM från leverantörslistan på IIS-webbplatsen. Få åtkomst till appen direkt från Internet Explorer på värddatorn. NTLM finns inte längre i leverantörslistan. Du kan bara komma åt programmet med hjälp av Kerberos. Om åtkomsten misslyckas kan det uppstå ett problem med programmets konfiguration. Kerberos-autentisering fungerar inte.

   • Om Kerberos inte är tillgängligt kontrollerar du programmets autentiseringsinställningar i IIS. Se till att Negotiate visas överst, med NTLM precis under. Om du ser Förhandla inte, Kerberos eller Negotiate, eller PKU2U, fortsätt endast om Kerberos fungerar.

     

   • Med Kerberos och NTLM på plats inaktiverar du tillfälligt förautentisering för programmet i portalen. Försök att komma åt den från Internet med hjälp av den externa URL:en. Du uppmanas att autentisera. Du kan göra det med samma konto som användes i föregående steg. Annars är det problem med back-end-applikationen, inte KCD.

   • Återaktivera förautentisering i portalen. Autentisera via Azure genom att försöka ansluta till programmet via dess externa URL. Om Single Sign-On (SSO) misslyckas visas ett felmeddelande om åtkomst nekad i webbläsaren och händelse 13022 i loggen.

     Användaren kan inte autentiseras i Microsoft Entra-anslutningsprogrammet eftersom backend-servern svarar på Kerberos-autentiseringsförsök med ett HTTP 401-fel.

     

   • Kontrollera IIS-programmet. Kontrollera att den konfigurerade programpoolen och SPN är konfigurerade för att använda samma konto i Microsoft Entra-ID. Navigera i IIS enligt följande bild.

     

     När du känner till identiteten kontrollerar du att det här kontot har konfigurerats med spn i fråga. Ett exempel är setspn –q http/spn.wacketywack.com. Ange följande text i en kommandotolk.

     

   • Jämför SPN med applikationens inställningar i portalen. Kontrollera att samma SPN som konfigurerats mot Microsoft Entra-målkontot används av programmets apppool.

   • Gå till IIS och välj alternativet Configuration Editor för programmet. Gå till system.webServer/security/authentication/windowsAuthentication. Kontrollera att värdet UseAppPoolCredentials är True.

     

     Ändra värdet till True. Ta bort alla cachelagrade Kerberos-biljetter från backendservern genom att köra kommandot.

     Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
     

Om du låter kernelläget vara aktiverat förbättrar det prestandan för Kerberos-åtgärder. Men det gör också att biljetten för den begärda tjänsten dekrypteras med hjälp av datorkontot. Det här kontot kallas även det lokala systemet. Ange det här värdet till True för att bryta KCD när programmet finns på fler än en server i en servergrupp.

• Som en annan kontroll inaktiverar du även utökat skydd. I vissa scenarier orsakade utökat skydd en störning i KCD när det aktiverades i specifika konfigurationer. I dessa fall publicerades ett program som en undermapp till standardwebbplatsen. Det här programmet är endast konfigurerat för anonym autentisering. Alla dialogrutor är inaktiverade, vilket tyder på att barnobjekt inte ärver några aktiva inställningar. Vi rekommenderar att du testar, men glöm inte att återställa det här värdet till aktiverad, där det är möjligt.

  Den här extra kontrollen håller dig på rätt spår för att använda ditt publicerade program. Du kan skapa fler anslutningar som också är konfigurerade att delegera. Mer information finns i den mer djupgående tekniska genomgången Felsöka Microsoft Entra-programproxyn.

Om du fortfarande inte kan göra några framsteg kan Microsofts support hjälpa dig. Skapa en supportbegäran direkt i portalen.

Andra scenarier

Microsoft Entra-programproxy begär en Kerberos-biljett innan den skickar sin begäran till ett program. Vissa program gillar inte den här metoden för autentisering. Dessa ansökningar förväntar sig att de mer konventionella förhandlingarna ska äga rum. Den första begäran är anonym, vilket gör att programmet kan svara med de autentiseringstyper som det stöder via en 401. Den här typen av Kerberos-förhandling kan aktiveras med hjälp av stegen i det här dokumentet: Kerberos-begränsad delegering för enkel inloggning.

Multi-hop-autentisering används ofta i scenarier där ett program är nivåindelat. Nivåerna består av en backend och en frontend. Båda nivåerna kräver autentisering. Till exempel SQL Server Reporting Services. Mer information finns i Konfigurera Kerberos-begränsad delegering för webbregistreringsproxysidor.

Nästa steg

Konfigurera KCD på en hanterad domän.