Problemen met KCD-configuraties (Beperkte Kerberos-delegering) oplossen met de Microsoft Entra-toepassingsproxy
Methoden voor eenmalige aanmelding variëren van de ene toepassing naar de andere. Microsoft Entra-toepassingsproxy biedt standaard KCD (Beperkte Kerberos-delegering). Gebruikers verifiëren zich bij privétoepassingen met behulp van Kerberos.
Dit artikel bevat één referentiepunt voor het oplossen van de meest voorkomende problemen. Het bevat ook informatie over de diagnose van complexere implementatieproblemen.
In dit artikel worden de volgende veronderstellingen weergegeven.
- Implementatie van Microsoft Entra-toepassingsproxy en algemene toegang tot niet-KCD-toepassingen. Zie Aan de slag met de toepassingsproxy voor meer informatie.
- De gepubliceerde toepassing is gebaseerd op IIS (Internet Information Services) en de Microsoft-implementatie van Kerberos.
- Server- en toepassingshosts bevinden zich in één Microsoft Entra-domein. Zie KCD whitepaper voor meer informatie over scenario's tussen domeinen en forests.
- De toepassing wordt gepubliceerd in een Microsoft Entra ID-tenant waarvoor verificatie vooraf is ingeschakeld. Gebruikers worden naar verwachting geverifieerd met verificatie op basis van formulieren. In dit artikel worden geen uitgebreide scenario's voor clientverificatie behandeld.
Vereisten
Eenvoudige verkeerde configuraties of algemene fouten veroorzaken de meeste problemen. Controleer alle vereisten in KCD-eenmalige aanmelding gebruiken met de toepassingsproxy voordat u problemen kunt oplossen.
Verbinding maken orhosts zijn niet beperkt tot communicatie met alleen een specifieke lokale sitedomeincontroller (DC). Controleer de domeincontroller die wordt gebruikt, omdat deze kan worden gewijzigd.
Scenario's voor meerdere domeinen zijn afhankelijk van verwijzingen die een connectorhost naar DC's leiden die zich mogelijk buiten de perimeter van het lokale netwerk bevinden. In deze gevallen is het even belangrijk om ook verkeer te verzenden naar DC's die andere respectieve domeinen vertegenwoordigen. Als dit niet gebeurt, mislukt delegering.
Vermijd actieve IPS-apparaten (Inbraakpreventiesysteem) of IDS-apparaten (Inbraakdetectiesysteem) tussen connectorhosts en DC's. Deze apparaten zijn te intrusief en verstoren het belangrijkste RPC-verkeer (Remote Procedure Call).
Test delegering in eenvoudige scenario's. Als u meer variabelen introduceert, zijn er waarschijnlijk ook meer factoren in het spel. Bespaar tijd door het testen tot één connector te beperken. Voeg meer connectors toe nadat het probleem is opgelost.
Sommige omgevingsfactoren kunnen ook bijdragen aan een probleem. Om deze factoren te vermijden minimaliseert u de architectuur zoveel mogelijk tijdens het testen. Zo zijn onjuist geconfigureerde interne toegangsbeheerlijsten (ACL's) voor interne firewalls gebruikelijk. Verzend indien mogelijk al het verkeer van een connector rechtstreeks naar de DC's en back-endtoepassing.
De beste plaats om connectors te plaatsen is zo dicht mogelijk bij hun doelen. Een firewall die zich bij het testen inline bevindt, voegt onnodige complexiteit toe en kan uw onderzoeken verlengen.
Wat duidt op een KCD-probleem? Er zijn verschillende veelvoorkomende aanwijzingen dat eenmalige aanmelding van KCD mislukt. De eerste tekenen van een probleem verschijnen in de browser.
Beide afbeeldingen geven hetzelfde symptoom weer: eenmalige aanmeldingsfout. Gebruikerstoegang tot de toepassing wordt geweigerd.
Probleemoplossing
Los problemen op in de drie fasen.
Verificatie van client vooraf
De externe gebruiker die via een browser wordt geverifieerd. De mogelijkheid om vooraf te verifiëren bij Microsoft Entra ID is nodig om KCD-eenmalige aanmelding (SSO) te laten functioneren. Test deze mogelijkheid en los eventuele problemen op. De fase voor verificatie vooraf is niet gerelateerd aan KCD of de gepubliceerde toepassing. Het is eenvoudig om eventuele verschillen te corrigeren door te controleren of het onderwerpaccount bestaat in Microsoft Entra-id. Controleer of de toepassing niet is uitgeschakeld of geblokkeerd. De foutreactie in de browser is beschrijvend genoeg om de oorzaak uit te leggen.
Delegatieservice
De privénetwerkconnector die een Kerberos-serviceticket voor gebruikers ophaalt vanuit een Kerberos Key Distribution Center (KCD).
De externe communicatie tussen de client en de Azure-front-end heeft geen invloed op KCD. Deze communicatie zorgt er alleen voor dat KCD werkt. De toepassingsproxyservice krijgt een geldige gebruikers-id die wordt gebruikt om een Kerberos-ticket op te halen. Zonder deze id is KCD niet mogelijk en mislukt KCD.
De foutberichten van de browser geven een aantal goede aanwijzingen over waarom dingen mislukken. Noteer de activity ID en timestamp velden in het antwoord. De informatie helpt het gedrag te correleren met werkelijke gebeurtenissen in het gebeurtenislogboek van de toepassingsproxy.
De bijbehorende vermeldingen in het gebeurtenislogboek worden weergegeven als gebeurtenis 13019 of 12027. Zoek de gebeurtenislogboeken van de connector in toepassingen en serviceslogboeken>microsoft>Entra-privénetwerk> Verbinding maken or> Beheer.
- Gebruik een A-record in uw interne DNS (Domain Name System) voor het adres van de toepassing, niet een
CName. - Bevestig opnieuw dat de connectorhost het recht heeft om te delegeren aan de Service Principal Name (SPN) van het aangewezen doelaccount. Bevestig opnieuw dat Elk willekeurig verificatieprotocol gebruiken is ingeschakeld. Zie het artikel over configuratie van eenmalige aanmelding voor meer informatie.
- Controleer of er slechts één exemplaar van de SPN aanwezig is in Microsoft Entra ID. Geef
setspn -xuit met een opdrachtprompt op een domeinlidhost. - Controleer of een domeinbeleid wordt afgedwongen waarmee de maximale grootte van uitgegeven Kerberos-tokens wordt beperkt. Het beleid voorkomt dat de connector een token krijgt als dit te veel is.
Een netwerktracering die uitwisselingen tussen de connectorhost en een domein beperkte kerberos-delegering (KDC) vastlegt, is de volgende beste stap om meer details op laag niveau te krijgen over de problemen. Zie het artikel met diepgaande informatie over het oplossen van problemen voor meer informatie.
Als het ticketsysteem goed werkt, ziet u een gebeurtenis in de logboeken waarin staat dat de verificatie is mislukt omdat de toepassing een 401 heeft geretourneerd. Met deze gebeurtenis wordt aangegeven dat de doeltoepassing uw ticket heeft geweigerd. Ga naar de volgende fase.
Doeltoepassing
De consument van het Kerberos-ticket dat door de connector is opgegeven. In deze fase verwacht u dat de connector een Kerberos-serviceticket naar de back-end heeft verzonden. Het ticket is een header in de eerste aanvraag van de toepassing.
Door de interne URL van de toepassing te gebruiken die is gedefinieerd in de portal, controleert u of de toepassing rechtstreeks vanuit de browser op de connectorhost toegankelijk is. Vervolgens kunt u zich aanmelden. Details vindt u op de pagina Problemen oplossen van de connector.
Controleer of voor verificatie tussen de browser en de toepassing Kerberos wordt gebruikt.
Voer DevTools (F12) uit in Internet Explorer of gebruik Fiddler vanaf de connectorhost. Ga naar de toepassing met behulp van de interne URL. Controleer de aangeboden webautorisatieheaders die zijn geretourneerd in het antwoord van de toepassing om ervoor te zorgen dat er onderhandeld of Kerberos aanwezig is.
De volgende Kerberos-blob die wordt geretourneerd in het antwoord van de browser naar de toepassing begint met YII. Deze letters geven aan dat Kerberos wordt uitgevoerd. Microsoft NT LAN Manager (NTLM) begint daarentegen altijd met TlRMTVNTUAAB, dat NTLM Security Support Provider (NTLMSSP) leest wanneer deze wordt gedecodeerd vanuit Base64. Als u TlRMTVNTUAAB aan het begin van de blob ziet, is Kerberos niet beschikbaar. Als u TlRMTVNTUAAB niet ziet, is Kerberos waarschijnlijk beschikbaar.
Notitie
Als u Fiddler gebruikt, moet u voor deze methode uitgebreide beveiliging tijdelijk uitschakelen voor de configuratie van de toepassing in IIS.
De blob in deze afbeelding begint niet met TIRMTVNTUAAB. In dit voorbeeld is Kerberos dus beschikbaar en begint de Kerberos-blob niet met YII.
Verwijder NTLM tijdelijk uit de lijst met providers op de IIS-site. Open de app rechtstreeks vanuit Internet Explorer op de connectorhost. NTLM staat niet meer in de lijst met providers. U hebt alleen toegang tot de toepassing met gebruikmaking van Kerberos. Als de toegang mislukt, kan er een probleem zijn met de configuratie van de toepassing. Kerberos-verificatie werkt niet.
Als Kerberos niet beschikbaar is, controleert u de verificatie-instellingen van de toepassing in IIS. Zorg ervoor dat Onderhandelen bovenaan wordt weergegeven, met NTLM eronder. Als u Niet onderhandelen, Kerberos of onderhandelen of PKU2U ziet, gaat u alleen door als Kerberos functioneel is.
Als Kerberos en NTLM zijn ingesteld, schakelt u de verificatie vooraf uit voor de toepassing in de portal. Probeer toegang te krijgen via internet met behulp van de externe URL. U wordt gevraagd om te verifiëren. U kunt dit doen met hetzelfde account dat in de vorige stap is gebruikt. Zo niet, dan is er een probleem met de back-endtoepassing, niet met KCD.
Schakel verificatie vooraf opnieuw in in de portal. Verifieer via Azure door verbinding te maken met de toepassing via de externe URL. Als eenmalige aanmelding mislukt, wordt in het foutbericht in de browser vermeld dat dit niet is toegestaan en ziet u gebeurtenis 13022 in het logboek:
Microsoft Entra private network connector kan de gebruiker niet verifiëren omdat de back-endserver reageert op Kerberos-verificatiepogingen met een HTTP 401-fout.
Controleer de IIS-toepassing. Zorg ervoor dat de geconfigureerde groep van toepassingen en de SPN zijn geconfigureerd voor het gebruik van hetzelfde account in Microsoft Entra-id. Navigeer in IIS, zoals wordt weergegeven in de volgende afbeelding.
Als u de identiteit weet, controleert u of dit account is geconfigureerd met de betreffende SPN. Een voorbeeld is
setspn –q http/spn.wacketywack.com. Voer de volgende tekst in een opdrachtprompt in.
Controleer de gedefinieerde SPN op basis van de instellingen van de toepassing in de portal. Zorg ervoor dat dezelfde SPN die is geconfigureerd voor het Microsoft Entra-doelaccount, wordt gebruikt door de app-groep van de toepassing.
Ga naar IIS en selecteer de optie Configuratie-editor voor de toepassing. Navigeer naar system.webServer/security/authentication/windowsAuthentication. Zorg ervoor dat de waarde UseAppPoolCredentialswaar is.
Wijzig de waarde in Waar. Verwijder alle Kerberos-tickets in de cache van de back-endserver door de opdracht uit te voeren.
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Als u de kernelmodus ingeschakeld laat, worden de prestaties van Kerberos-bewerkingen verbeterd. Maar het zorgt er ook voor dat het ticket voor de aangevraagde service wordt ontsleuteld met behulp van het computeraccount. Dit account wordt ook wel het lokale systeem genoemd. Stel deze waarde in op Waar om KCD te verbreken wanneer de toepassing wordt gehost op meer dan een server in een farm.
Als een andere controle schakelt u uitgebreide beveiliging ook uit. In sommige scenario's heeft de uitgebreide beveiliging KCD verbroken toen deze werd ingeschakeld in specifieke configuraties. In die gevallen is een toepassing gepubliceerd als submap van de standaardwebsite. Deze toepassing is alleen geconfigureerd voor anonieme verificatie. Alle dialoogvensters worden grijs weergegeven, wat aangeeft dat onderliggende objecten geen actieve instellingen overnemen. We raden u aan te testen, maar vergeet niet deze waarde waar mogelijk te herstellen naar ingeschakeld.
Met deze extra controle bent u op schema om uw gepubliceerde toepassing te gebruiken. U kunt meer connectors instellen die ook zijn geconfigureerd om te delegeren. Lees de uitgebreidere technische procedure voor het oplossen van problemen met de Microsoft Entra-toepassingsproxy voor meer informatie.
Als u nog steeds geen voortgang kunt boeken, kan Microsoft-ondersteuning u helpen. Maak rechtstreeks in de portal een ondersteuningsticket.
Andere scenario's
Microsoft Entra-toepassingsproxy vraagt een Kerberos-ticket aan voordat de aanvraag naar een toepassing wordt verzonden. Sommige toepassingen vinden deze verificatiemethode niet leuk. Deze toepassingen verwachten dat de conventionelere onderhandelingen plaatsvinden. De eerste aanvraag is anoniem, waardoor de toepassing kan reageren met de verificatietypen die worden ondersteund via een 401. Dit type Kerberos-onderhandeling kan worden ingeschakeld met behulp van de stappen in dit document: Beperkte Kerberos-delegering voor eenmalige aanmelding.
Meervoudige verificatie wordt vaak gebruikt in scenario's waarin een toepassing gelaagd is. De lagen bevatten een back-end en front-end. Voor beide lagen is verificatie vereist. Bijvoorbeeld SQL Server Reporting Services. Zie Kerberos-beperkte delegering configureren voor proxypagina's voor webinschrijvingen voor meer informatie.