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 diagnostisering 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:s 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 endast en specifik lokal plats domänkontrollant (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 anslutningsapp för att spara tid. Lägg till fler anslutningsappar 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 anslutningsapp direkt till domänkontrollanterna och serverdelsprogrammet.

Det bästa stället att placera anslutningsappar är så nära målen som möjligt. En brandvägg som är infogad när du testar lägger till onödig komplexitet och kan förlänga dina undersökningar.

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 de tre stegen.

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. Programproxytjänsten tillhandahålls ett giltigt användar-ID som används för att hämta 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änstloggar Microsoft>Microsoft Entra privat nätverksanslutningsadministratör>>>.

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 att Använd alla autentiseringsprotokoll har valts. Mer information finns i artikeln om SSO-konfiguration.
3. Kontrollera att det bara finns en instans av SPN i Microsoft Entra-ID: t. Problem setspn -x från en kommandotolk på alla domänmedlemsvärdar.
4. Kontrollera att en domänprincip tillämpas som begränsar den maximala storleken på 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. Mer information finns i felsökningsdokumentet för djupdykning.

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 ditt ärende. Gå till nästa steg.

Målprogram

Konsumenten av Kerberos-biljetten som anslutningsappen har angett. I det här skedet förväntar du dig att anslutningsappen skickade en Kerberos-tjänstbiljett till serverdelen. Biljetten är ett huvud i den första programbegä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å anslutningsvärden. Sedan kan du logga in. Information finns på sidan Felsökning av anslutningsprogram.

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 anslutningsvä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 de 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.

     Kommentar

     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å anslutningsvärden. 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. Kontrollera att Negotiate visas överst, med NTLM precis under. Om du ser Inte förhandla, Kerberos eller Förhandla eller PKU2U fortsätter du 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 serverdelsprogrammet, inte KCD.

   • Återaktivera förautentisering i portalen. Autentisera via Azure genom att försöka ansluta till programmet via dess externa URL. Om enkel inloggning misslyckas visas ett förbjudet felmeddelande i webbläsaren och händelse 13022 i loggen:

     Det går inte att autentisera användaren eftersom serverdelsservern 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.

     

   • Kontrollera det SPN som definierats mot programmets 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 Konfigurationsredigerare för programmet. Navigera till system.webServer/security/authentication/windowsAuthentication. Kontrollera att värdet UseAppPoolCredentials är Sant.

     

     Ändra värdet till Sant. Ta bort alla cachelagrade Kerberos-biljetter från serverdelsservern 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. Ställ in det här värdet på Sant för att bryta KCD när programmet finns på mer än en server i en servergrupp.

• Som en annan kontroll inaktiverar du utökat skydd också. I vissa scenarier bröt utökat skydd 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 nedtonade, vilket tyder på att underordnade objekt 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 aktiverat, där det är möjligt.

  Den här extra kontrollen gör att du kan använda det publicerade programmet. Du kan skapa fler anslutningsappar som också är konfigurerade att delegeras. Mer information finns i den mer djupgående tekniska genomgången, Felsökning av 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 innehåller en serverdel och en klientdel. 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.