Dela via

Felsökning av diagnostiksidor för Windows-integrerad autentisering

  • Artikel

Det kan vara svårt att felsöka felscenarier med Windows-integrerad autentisering, särskilt när du hanterar Kerberos-delegering av autentiseringsuppgifter. Även om det finns en detaljerad checklista för hur du ser till att du har rätt konfiguration för IIS (Internet Information Services) för att arbeta med Windows-integrerad autentisering och eventuellt använda delegering av autentiseringsuppgifter, riktar den här artikeln specifikt in sig på följande scenarier:

  • Du kan logga in på målwebbplatsen från klientdatorn, men du är osäker på om du använder NTLM eller Kerberos som autentiseringsmekanism.
  • Du kan logga in på målwebbplatsen, men du uppmanas att logga in först när du har angett en kombination av användarnamn och lösenord.
  • Du kan komma åt målwebbplatsen på klientdelsservern, men den misslyckas när du initierar en åtgärd som kräver att klientdelsservern anropar en HTTP-slutpunkt för serverdelen med den autentiserade användarens autentiseringsuppgifter.

I den här artikeln bör du tänka på följande layout:

  • Klient 1 är den domänanslutna arbetsstationen eller bärbara datorn från vilken den hypotetiska användaren initierar alla anslutningsförsök.

  • Web-serv1 är klientdelens IIS-server som är värd för en webbplats för ASP.NET (på .NET Framework) som använder Windows-integrerad autentisering och körs med identiteten för ett tjänstkonto: domain\serviceaccount.

  • Web-serv2 är serverdelswebbservern som också är värd för en ASP.NET -webbplats (på .NET Framework) som exponerar API-slutpunkter för klientdelsprogrammet. Den är också konfigurerad för att tillåta begäranden som använder Windows-integrerad autentisering och körs i en programpool som använder domän\serviceapiaccount som en programpoolsidentitet.

Skärmbild som visar layouten för arbetsstation, Web-serv1 och Web-serv2.

För att underlätta datainsamlingen för dessa scenarier och inte förlita dig på externa datainsamlingsverktyg som Fiddler eller WireShark (eftersom anslutningar mellan de tre datorerna kan använda HTTPS och därför kommer alla utbyten mellan dem att krypteras), använder du de två fristående diagnostiksidorna i ASP.NET fristående sidor för felsökning av problem med Windows-integrerad autentisering på IIS.

Felsökningssidor

De två sidorna är kodade i ASP.NET Web Forms. De är avsedda att paketeras koden och pålägget för sidan i en fil som kan kopieras till roten i webbprogrammet som du försöker felsöka, utan att behöva kompileras eller distribueras. Sidorna är:

  • WhoAmI.aspx – På den här sidan kan autentiseringsrelaterad information dumpas, till exempel:

    • Den autentiseringsmetod som används för att komma åt målplatsen. Om metoden baseras på Negotiate-providern för Windows-integrerad autentisering visar sidan om Kerberos eller NTLM används för att autentisera användaren.

    • Identiteten för det konto som kör programpoolen som är värd för webbplatsen.

    • Personifieringsnivån för den autentiserade användaren. Om Kerberos används för autentisering och obegränsad delegering av autentiseringsuppgifter tillåts markeras personifieringsnivån som ombud. Annars markeras den som personifierad i händelse av begränsad delegering eller enkel personifiering.

    • Identiteten för den autentiserade användaren och de grupper som användaren tillhör.

    • Identiteten för det konto som kör sidans kod (det kan vara en autentiserad användare eller en programpoolsanvändare, beroende på personifieringsinställningarna ).

    • Alla värden för begärandehuvudena för begäranden som kommer till WhoAmI.aspx sidan som återställts från IIS-servervariablerna.

      Skärmbild som visar sidan Vem är jag med autentiseringsinformation och identitet.

  • ScrapperTest.aspx – Den här sidan är gjord för att fungera med sidan WhoAmI.aspx , vilket gör att begäranden från klientdelsservern kan dirigeras till url:er på serverdelsservern. Sidan visar ett gränssnitt för användargränssnittet som gör att en användare kan:

    • Ange önskad URL för serverdelsserverresursen som sidan ska försöka läsa in.

    • Kontrollera om de autentiseras när ScrapperTest.aspx-sidan läses in, och om de autentiseras, vilka användare de autentiseras som.

    • I scenariot där användaren verkligen autentiseras tillåter en kryssruta försök att återanvända användarens autentiseringsuppgifter när du försöker läsa in den serverdelsresurs som anges i url-textrutan.

      Skärmbild som visar sidan ScrapperTest.

Så här distribuerar du

Eftersom båda sidorna är självständiga är det enda som behövs att:

  1. Ladda ned sidorna från GitHub-lagringsplatsen.
  2. Kopiera WhoAmI.aspx-sidan eller båda sidorna till roten för dina målwebbprogram som körs i IIS.
  3. Skicka en begäran till url:en för din webbplats som lägger till /WhoAmI.aspx eller /ScrapperTest.aspx, beroende på vilken sida du vill komma åt.

Användning

Det första användningsscenariot är att försöka avgöra vilken autentiseringsmetod som används för att komma åt en viss webbplats eller ett visst webbprogram som finns på IIS. För den här kan du göra begäranden till den WhoAmI.aspx sidan som du tidigare har distribuerat till webbplatsen.

  • På den första begäran visas autentiseringsinformationen på sidan. Om negotiate-providern för Windows-integrerad autentisering används visas även det autentiseringsprotokoll som används: Kerberos eller NTLM.

  • Efterföljande begäranden i ett scenario där Negotiate används som provider för Windows-integrerad autentisering visar endast etiketten Sessionsbaserad bredvid autentiseringstypen. Mer information finns i Request-based versus Session-based Kerberos Authentication (eller parametern AuthPersistNonNTLM).

  • All annan autentiseringsinformation, till exempel programpoolsanvändare, autentiserad användare, körningsanvändarinformation och huvuden för inkommande begäran, visas på varje begäran.

På sidan WhoAmI.aspx visas också ett litet formulär längst ned. Med det här formuläret kan du utfärda POST begäranden till servern för att testa hur webbläsaren beter sig när du utfärdar dessa typer av begäranden. Om sidan är inaktiv i mer än 60 sekunder avbryts TCP-anslutningen (Transmission Control Protocol) som används för att ladda ned sidan till webbläsaren och autentiseras av servern på grund av inaktivitet. När du gör en POST begäran öppnas därför en ny TCP-anslutning och du måste autentisera igen. Det finns en subtilitet med POST begäranden:

  1. Webbläsaren skickar först HTTP-begärandehuvudena POST .
  2. Den utfärdar sedan brödtexten i POST begäran, som innehåller den information som hämtas från de olika indatafälten i HTTP-formuläret som visas på sidan.

Om webbläsaren inte väntar efter att ha skickat begärandehuvuden POST , utan i stället skickar brödtexten direkt på en oautentiserad anslutning, kan följande problem uppstå:

  • Servern tar emot begärandehuvudena POST och eftersom anslutningen inte autentiseras (förutsatt att Windows-integrerad autentisering eller annan utmaningsbaserad autentisering används) utfärdar den ett 401-svar med rätt HTTP-huvud för autentiseringssvar (WWW-Authenticate).
  • Under den här tiden har webbläsaren redan skickat begärandetexten POST innan 401-svaret tas emot från servern.
  • Servern tar sedan emot en oautentiserad begärandetext POST på en anslutning som den tidigare har angett för klienten att autentisering krävs.
  • Detta resulterar i att servern bryter den underliggande TCP-anslutningen och att webbläsaren eventuellt visar meddelandet "Webbsidan är inte tillgänglig".

Sidan ScrapperTest.aspx används för att testa delegeringen av scenarier med autentiseringsuppgifter från klientdelsservern till serverdelsserverns slutpunkt. När sidan har begärts från klientwebbläsaren kommer den att erbjuda ett användargränssnitt som tillåter:

  • Ange den url för serverdelsslutpunkten som klientdelsservern ska ansluta till.
  • Kontrollera att användaren är autentiserad i klientdelen och vilket användarnamn som används för att ansluta till klientdelsservern.
  • Avgör (om autentisering används för att komma åt ScrapperTest.aspx sidan) om autentiseringsuppgifterna för den autentiserade användaren ska skickas vidare med begäran till serverdelen (om personifiering och delegering är möjliga).

När knappen Klipp sida har valts skickar koden för ScrapperTest.aspx-sidan en begäran om den angivna mål-URL:en GET . Om kryssrutan Använd autentiseringsuppgifter är markerad och autentisering krävs för att få åtkomst till den angivna serverdelsslutpunkten används även den autentiserade användarens autentiseringsuppgifter för att göra begäran. Om en begäran lyckas visas resultatet i textområdeskontrollen på sidan som http-råutdata för det mottagna svaret.

Ett användningsscenario som vi föreställer oss är att placera ScrapperTest.aspx-sidan och den WhoAmI.aspx sidan i det ASP.NET program som skulle kontaktas på serverdelsservern. Http-svaret som återställs av ScrapperTest.aspx-sidan är därför HTML-utdata för WhoAmI.aspx-sidan när det körs på serverdelen. Dessa utdata kan sedan utvärderas för att förstå hur begäran autentiserades på serverdelen och vilka konton som användes.

Mer information

Mer information om hur du konfigurerar Windows-integrerad autentisering med Kerberos finns i: