Vanliga frågor och svar om AD FS

Du kan uppgradera/migrera AD FS genom att slutföra stegen i någon av följande länkade artiklar:

• Windows Server 2012 R2 AD FS till Windows Server 2016 AD FS eller senare. (Processen är densamma om du uppgraderar från Windows Server 2016 AD FS till Windows Server 2019 AD FS.)
  • Uppgradera till AD FS i Windows Server 2016 med hjälp av en WID-databas
  • Uppgradera till AD FS i Windows Server 2016 med hjälp av en SQL-databas
• Windows Server 2012 AD FS till Windows Server 2012 R2 AD FS:
  • Migrera till AD FS på Windows Server 2012 R2
• AD FS 2.0 till Windows Server 2012 AD FS:
  • Migrera till AD FS på Windows Server 2012
• AD FS 1. x till AD FS 2.0:
  • Uppgradera från AD FS 1. x till AD FS 2.0

Om du behöver uppgradera från AD FS 2.0 eller 2.1 (Windows Server 2008 R2 eller Windows Server 2012) använder du inkorgsskripten i C:\Windows\ADFS.

HTTP/2-stöd lades till i Windows Server 2016, men HTTP/2 kan inte användas för klientcertifikatautentisering. Många AD FS-scenarier använder klientcertifikatautentisering. Och många klienter stöder inte återförsök av begäranden med hjälp av HTTP/1.1. Ad FS-servergruppskonfigurationen konfigurerar om den lokala serverns HTTP-inställningar till HTTP/1.1. Den här omkonfigurationen kräver en omstart av servern.

Den här konfigurationen stöds, men inga nya AD FS 2016-funktioner stöds i den. Den här konfigurationen är avsedd att vara tillfällig under migreringen från AD FS 2012 R2 till AD FS 2016. Den bör inte användas under långa tidsperioder.

Ja, men som en bieffekt:

• Du måste hantera uppdateringar av tokensigneringscertifikat manuellt eftersom Microsoft Entra-ID inte kommer att kunna komma åt federationsmetadata. Mer information om hur du uppdaterar tokensigneringscertifikat manuellt finns i Förnya federationscertifikat för Office 365 och Microsoft Entra-ID.
• Du kommer inte att kunna använda äldre autentiseringsflöden (till exempel ExO-proxyautentiseringsflödet).

AD FS är ett tillståndslöst system, så belastningsutjämning är ganska enkelt för inloggningar. Här följer några viktiga rekommendationer för belastningsutjämningssystem:

• Lastbalanserare bör inte konfigureras med IP-tillhörighet. IP-tillhörighet kan medföra onödig belastning på en delmängd av servrarna i vissa Exchange Online-scenarier.
• Lastbalanserare får inte avsluta HTTPS-anslutningarna och starta en ny anslutning till AD FS-servern.
• Lastbalanserare bör se till att den anslutande IP-adressen ska översättas som käll-IP i HTTP-paketet när den skickas till AD FS. Om en lastbalanserare inte kan skicka käll-IP-adressen i HTTP-paketet måste lastbalanseraren lägga till IP-adressen i X-Forwarded-For-huvudet. Det här steget krävs för korrekt hantering av vissa IP-relaterade funktioner (till exempel förbjuden IP- och Extranet Smart Lockout). Om den här konfigurationen inte implementeras korrekt kan säkerheten minskas.
• Lastbalanserare bör ha stöd för SNI. Om de inte gör det kontrollerar du att AD FS är konfigurerat för att skapa HTTPS-bindningar för att hantera klienter som inte stöder SNI.
• Lastbalanserare bör använda AD FS HTTP-hälsoavsökningens slutpunkt för att identifiera om AD FS- eller webbprogramproxyservrarna körs. De bör undantas om 200 OK inte returneras.

AD FS har stöd för flera konfigurationer med flera förskogningar. Det förlitar sig på det underliggande AD DS-förtroendenätverket för att autentisera användare över flera betrodda områden. Vi rekommenderar starkt dubbelriktade skogsförtroenden eftersom de är enklare att konfigurera, vilket hjälper till att säkerställa att förtroendesystemet fungerar korrekt.

Additionally:

• Om du har ett envägsskogsförtroende, till exempel en perimeternätverksskog (även kallad DMZ) som innehåller partneridentiteter, rekommenderar vi att du distribuerar AD FS i företagsskogen. Behandla perimeternätverksskogen som ett annat lokalt anspråksproviderförtroende som är anslutet via LDAP. I det här fallet fungerar inte Windows-integrerad autentisering för användare av perimeternätverksskogen. De måste använda lösenordsautentisering eftersom det är den enda mekanism som stöds för LDAP.

  Om du inte kan använda det här alternativet måste du konfigurera en annan AD FS-server i perimeternätverksskogen. Lägg till den som ett anspråksproviderförtroende på AD FS-servern i företagsskogen. Användarna måste göra identifiering av hemsfären, men både Windows-integrerad autentisering och lösenordsautentisering fungerar. Gör lämpliga ändringar i utfärdandereglerna i AD FS i perimeternätverksskogen eftersom AD FS i företagsskogen inte kan få mer information om användare från perimeternätverksskogen.

• Förtroenden på domännivå stöds och kan fungera. Men vi rekommenderar starkt att du går över till en förtroendemodell på skogsnivå. Du måste också se till att UPN-routning och NetBIOS-namnmatchning fungerar korrekt.

Ja, IPv6-adresser beaktas för välbekanta och okända platser.

AD FS tillhandahåller en utökningsbar mekanism för tredjepartsleverantörer av multifaktorautentisering att integrera. Det finns inget angivet certifieringsprogram för detta. Det förutsätts att leverantören har utfört nödvändiga valideringar före lanseringen.

Listan över leverantörer som har meddelat Microsoft finns här: Multifaktorautentiseringsprovidrar för AD FS. Det kan finnas tillgängliga leverantörer som vi inte känner till. Vi uppdaterar listan när vi upptäcker nya.

Ja, proxyservrar från tredje part kan placeras framför AD FS, men alla proxyservrar från tredje part måste ha stöd för detMS-ADFSPIP protokollet som ska användas i stället för Proxy för webbprogram.

Vi är för närvarande medvetna om följande tredjepartsleverantörer. Det kan finnas tillgängliga leverantörer som vi inte känner till. Vi uppdaterar den här listan när vi upptäcker nya.

• F5 Principhanterare för åtkomst
• Citrix Application Delivery Controller (ADC)

Du kan ladda ned AD FS 2016-versionen av kalkylbladet. Du kan också använda det här kalkylbladet för AD FS i Windows Server 2012 R2.

Apple har släppt en uppsättning krav som kallas App Transport Security (ATS) som kan påverka anrop från iOS-appar som autentiserar till AD FS. Du kan se till att ad FS- och webbprogramproxyservrarna uppfyller kraven för anslutning med hjälp av ATS. I synnerhet bör du kontrollera att:

• Ad FS- och webbprogramproxyservrarna stöder TLS 1.2.
• TLS-anslutningens förhandlade chiffersvit stöder perfekt framåtsekretess.

Information om hur du aktiverar och inaktiverar SSL 2.0 och 3.0 och TLS 1.0, 1.1 och 1.2 finns i Hantera SSL-protokoll i AD FS.

För att säkerställa att ad FS- och webbprogramproxyservrar endast förhandlar om TLS-chiffersviter som stöder ATP kan du inaktivera alla chiffersviter som inte finns med i listan över ATP-kompatibla chiffersviter. Om du vill inaktivera dem använder du Windows TLS PowerShell-cmdletar.

Värdet för anspråket "sub" är hashen för klient-ID:t och ankaranspråksvärdet.

Livslängden för uppdateringstoken är livslängden för den token som AD FS fick från fjärranspråksproviderns förtroende. Livslängden för åtkomsttoken är tokens livslängd för den förlitande part som åtkomsttoken utfärdas för.

Du kan använda en anpassad id_token för att lägga till relevant information i själva id_token. Mer information finns i Anpassa anspråk som ska genereras i id_token.

Ett särskilt ValueType-tecken (http://www.w3.org/2001/XMLSchema#json) och escape-tecken (\x22) lades till för det här scenariot i AD FS 2016. Använd följande exempel för utfärdanderegeln och för de slutliga utdata från åtkomsttoken.

Exempel på utfärdanderegel:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Anspråk utfärdat i åtkomsttoken:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Med AD FS på Windows Server 2019 kan du nu skicka det inbäddade resursvärdet i omfångsparametern. Omfångsparametern kan ordnas som en utrymmesavgränsad lista där varje post är strukturerad som resurs/omfång.

AD FS i Windows Server 2019 stöder Proof Key for Code Exchange (PKCE) för OAuth Authorization Code Grant-flödet.

Supported:

• aza. Om du använder OAuth 2.0 Protocol Extensions for Broker Clients och omfångsparametern innehåller omfångs-aza, utfärdar servern en ny primär uppdateringstoken och anger den i fältet refresh_token i svaret. Det anger också fältet refresh_token_expires_in till livslängden för den nya primära uppdateringstoken, om en tillämpas.
• openid. Tillåter att ett program begär användning av OpenID Connect-auktoriseringsprotokollet.
• logon_cert. Tillåter att ett program begär inloggningscertifikat, som kan användas för att interaktivt logga in autentiserade användare. AD FS-servern utelämnar parametern access_token från svaret och tillhandahåller i stället en Base64-kodad CMS-certifikatkedja eller ett FULLSTÄNDIGT CMC-PKI-svar. Mer information finns i Bearbetningsinformation.
• user_impersonation. Krävs om du vill begära en on-behalf-of-åtkomsttoken från AD FS. Mer information om hur du använder det här omfånget finns i Skapa ett program med flera nivåer med on-Behalf-Of (OBO) med OAuth med AD FS 2016.

Not supported:

• vpn_cert. Tillåter att ett program begär VPN-certifikat, som kan användas för att upprätta VPN-anslutningar med hjälp av EAP-TLS autentisering. Det här omfånget stöds inte längre.
• email. Tillåter att ett program begär ett e-postanspråk för den inloggade användaren. Det här omfånget stöds inte längre.
• profile. Tillåter att ett program begär profilrelaterade anspråk för den inloggade användaren. Det här omfånget stöds inte längre.

AD FS SSL-certifikatet är inte detsamma som AD FS Service Communications Certificate i snapin-modulen AD FS Management. Om du vill ändra AD FS SSL-certifikatet måste du använda PowerShell. Följ riktlinjerna i Hantera SSL-certifikat i AD FS och WAP 2016.

Information om hur du inaktiverar och aktiverar SSL-protokoll och chiffersviter finns i Hantera SSL-protokoll i AD FS.

• Om proxyn används för ad FS-proxybegäranden som använder Windows-integrerad autentisering måste proxy-SSL-certifikatet använda samma nyckel som federationsserverns SSL-certifikat.
• Om egenskapen AD FS ExtendedProtectionTokenCheck är aktiverad (standardinställningen i AD FS) måste SSL-proxycertifikatet använda samma nyckel som SSL-certifikatet för federationsservern.
• Annars kan proxy-SSL-certifikatet ha en annan nyckel än AD FS SSL-certifikatet. Den måste uppfylla samma krav.

AD FS visar bara en autentiseringsmetod på inloggningsskärmen när ett program uttryckligen kräver en specifik autentiserings-URI som mappar till en konfigurerad och aktiverad autentiseringsmetod. Metoden förmedlas i wauth parametern i WS-Federation begäranden. Den förmedlas i parametern RequestedAuthnCtxRef i SAML-protokollbegäranden. Endast den begärda autentiseringsmetoden visas. (Till exempel lösenordsinloggning.)

När du använder AD FS med Microsoft Entra-ID är det vanligt att program skickar parametern prompt=login till Microsoft Entra-ID. Microsoft Entra-ID översätter som standard den här parametern till att begära en ny lösenordsbaserad inloggning till AD FS. Det här scenariot är den vanligaste anledningen till att du kan se en lösenordsinloggning på AD FS i nätverket eller inte se ett alternativ för att logga in med certifikatet. Du kan enkelt lösa det här problemet genom att ändra de federerade domäninställningarna i Microsoft Entra-ID.

Mer information finns i Active Directory Federation Services prompt=login parameter support.

Om du vill ändra AD FS-tjänstkontot använder du POWERShell-modulen AD FS Toolbox Service Account. Anvisningar finns i Ändra AD FS-tjänstkonto.

Se Konfigurera webbläsare för att använda Windows-integrerad autentisering (WIA) med AD FS.

Om du inte har principer för åtkomstkontroll baserat på enheten vid AD FS- eller Windows Hello för företag-certifikatregistrering via AD FS kan du inaktivera BrowserSsoEnabled. Med BrowserSsoEnabled kan AD FS samla in en primär uppdateringstoken (PRT) från klienten som innehåller enhetsinformation. Utan den token fungerar inte enhetsautentisering av AD FS på Windows 10-enheter.

Administratörer undrar ofta hur länge användare får enkel inloggning (SSO) utan att behöva ange nya autentiseringsuppgifter och hur administratörer kan styra det beteendet. Det beteendet och de konfigurationsinställningar som styr det beskrivs i inställningarna för enkel inloggning med AD FS.

Standardlivslängden för de olika cookies och token visas här (tillsammans med de parametrar som styr livslängden):

Registered devices

• PRT- och SSO-cookies: Högst 90 dagar, styrs av PSSOLifeTimeMins. (Om enheten används minst var 14:e dag. Det här tidsfönstret styrs av DeviceUsageWindow.)

• Uppdateringstoken: Beräknas baserat på föregående parametrar för att ge konsekvent beteende.

• access_token: En timme som standard, baserat på den förlitande parten.

• id_token: Samma som access_token.

Unregistered devices

• SSO-cookies: Åtta timmar som standard, styrs av SSOLifetimeMins. När Håll mig inloggad (KMSI) är aktiverat är standardvärdet 24 timmar. Den här standardinställningen kan konfigureras via KMSILifetimeMins.

• Uppdateringstoken: Åtta timmar som standard. 24 timmar om KMSI är aktiverat.

• access_token: En timme som standard, baserat på den förlitande parten.

• id_token: Samma som access_token.

AD FS stöder inte implicita flöden för konfidentiell klient. Klientautentisering är endast aktiverat för tokenslutpunkt och AD FS utfärdar inte en åtkomsttoken utan klientautentisering. Om den konfidentiella klienten behöver en åtkomsttoken och även kräver användarautentisering måste den använda auktoriseringskodflödet.

HSTS är en mekanism för webbsäkerhetsprinciper. Det hjälper till att minimera protokollnedgraderingsattacker och cookiekapning för tjänster som har både HTTP- och HTTPS-slutpunkter. Det gör att webbservrar kan deklarera att webbläsare (eller andra kompatibla användaragenter) endast ska interagera med dem med hjälp av HTTPS och aldrig via HTTP-protokollet.

Alla AD FS-slutpunkter för webbautentiseringstrafik öppnas exklusivt via HTTPS. AD FS minimerar därför de hot som HSTS-principmekanismen skapar. (Det finns ingen nedgradering till HTTP eftersom det inte finns några lyssnare i HTTP.) AD FS förhindrar också att cookies skickas till en annan server som har HTTP-protokollslutpunkter genom att markera alla cookies med den säkra flaggan.

Därför behöver du inte HSTS på en AD FS-server eftersom HSTS inte kan nedgraderas. AD FS-servrar uppfyller efterlevnadskraven eftersom de inte kan använda HTTP och eftersom cookies är markerade som säkra.

Slutligen stöder AD FS 2016 (med flest up-to-datumkorrigeringar) och AD FS 2019 stöd som genererar HSTS-huvudet. Information om hur du konfigurerar det här beteendet finns i Anpassa HTTP-säkerhetssvarshuvuden med AD FS.

Vi rekommenderar inte att du avslutar SSL före webbprogramproxyservern. Om det görs framför webbprogramproxyservern innehåller X-MS-Forwarded-Client-IP IP-adressen för nätverksenheterna framför webbprogramproxyservern. Här är en kort beskrivning av de olika IP-relaterade anspråk som stöds av AD FS:

• X-MS-Client-IP. Nätverks-IP för enheten som är ansluten till STS. För extranätsbegäranden innehåller det här anspråket alltid IP-adressen för webbprogramproxyservern.
• X-MS-Forwarded-Client-IP. Flervärdesanspråk som innehåller alla värden som vidarebefordras till AD FS av Exchange Online. Den innehåller också IP-adressen för den enhet som är ansluten till webbprogramproxyservern.
• Userip. För extranätsbegäranden innehåller det här anspråket värdet X-MS-Forwarded-Client-IP. För intranätbegäranden innehåller det här anspråket samma värde som X-MS-Client-IP.

AD FS 2016 (med flest up-to-datumkorrigeringar) och senare versioner stöder också insamling av X-Forwarded-For-huvudet. Alla lastbalanserare eller nätverksenheter som inte vidarebefordras på lager 3 (IP bevaras) bör lägga till den inkommande klient-IP-adressen till branschstandard-X-Forwarded-For-huvudet.

AD FS UserInfo-slutpunkten returnerar alltid ämnesanspråket enligt OpenID-standarderna. AD FS stöder inte ytterligare anspråk som begärs via UserInfo-slutpunkten. Om du behöver fler anspråk i en ID-token kan du läsa Anpassade ID-token i AD FS.

Den här gruppen skapas bara när en Windows Server 2016-domänkontrollant med FSMO PDC-rollen finns i domänen. Du kan lösa felet genom att skapa gruppen manuellt. Gör så här för att lägga till de behörigheter som krävs när du har lagt till tjänstkontot som medlem i gruppen:

1. Öppna Användare och datorer i Active Directory.
2. Högerklicka på ditt domännamn i den vänstra rutan och välj sedan Egenskaper.
3. Select Security. (Om fliken Säkerhet saknas aktiverar du Avancerade funktioner på Visa-menyn .)
4. Välj Avancerat, Lägg till och sedan Välj ett huvudkonto.
5. Dialogrutan Välj användare, dator, tjänstkonto eller grupp visas. I rutan Ange det objektnamn som ska väljas anger du Nyckeladministratörsgrupp. Select OK.
6. I rutan Gäller för väljer du Underordnade användarobjekt.
7. Bläddra längst ned på sidan och välj Rensa alla.
8. I avsnittet Egenskaper väljer du Läs msDS-KeyCredentialLink och Skriv msDS-KeyCredentialLink.

För appar som använder Android ADAL-biblioteket kan autentisering till Microsoft Entra-ID misslyckas för federerade användare. Appen får en AuthenticationException när den försöker visa inloggningssidan. I Webbläsaren Chrome kan inloggningssidan för AD FS beskrivas som osäker.

För alla versioner och alla enheter har Android inte stöd för att ladda ned ytterligare certifikat från fältet authorityInformationAccess i certifikatet. Den här begränsningen gäller även webbläsaren Chrome. Alla serverautentiseringscertifikat som saknar mellanliggande certifikat orsakar det här felet om hela certifikatkedjan inte skickas från AD FS.

Du kan lösa det här problemet genom att konfigurera AD FS- och webbprogramproxyservrarna för att skicka nödvändiga mellanliggande certifikat tillsammans med SSL-certifikatet.

När du exporterar SSL-certifikatet från en dator som ska importeras till datorns personliga arkiv för AD FS- och webbprogramproxyservrarna ska du exportera den privata nyckeln och välja Personligt informationsutbyte – PKCS #12.

Se också till att välja Inkludera alla certifikat i certifikatsökvägen om möjligt och Exportera alla utökade egenskaper.

Kör certlm.msc på Windows-servrarna och importera *.pfx till datorns personliga certifikatarkiv. Detta gör att servern skickar hela certifikatkedjan till ADAL-biblioteket.

AD FS stöder inte HEAD-begäranden. Program bör inte använda HEAD-begäranden mot AD FS-slutpunkter. Om du använder dessa begäranden kan det orsaka HTTP-felsvar som är oväntade eller fördröjda. Du kan också se oväntade felhändelser i AD FS-händelseloggen.

En uppdateringstoken utfärdas inte om token som utfärdats av IdP har en giltighet på mindre än en timme. För att säkerställa att en uppdateringstoken utfärdas ökar du giltigheten för token som utfärdats av IdP till mer än en timme.

RP-tokenkryptering är inställt på AES256. Du kan inte ändra det till något annat värde.

AD FS-gårdar i blandat läge är avsedda att vara tillfälliga. Vi rekommenderar att du under planeringen antingen rullar över SSL-certifikatet före uppgraderingsprocessen eller slutför processen och ökar servergruppens beteendenivå innan du uppdaterar SSL-certifikatet. Om rekommendationen inte följdes använder du följande instruktioner för att uppdatera SSL-certifikatet.

På webbprogramproxyservrar kan du fortfarande använda Set-WebApplicationProxySslCertificate. På AD FS-servrarna måste du använda netsh. Slutför följande steg:

1. Välj en delmängd av AD FS 2016-servrar för underhåll.

2. På de servrar som valdes i föregående steg importerar du det nya certifikatet via MMC.

3. Ta bort de befintliga certifikaten:

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Lägg till de nya certifikaten:

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Starta om AD FS-tjänsten på den valda servern.

6. Ta bort en delmängd av webbprogramproxyservrar för underhåll.

7. På de valda webbprogramproxyservrarna importerar du det nya certifikatet via MMC.

8. Ange det nya certifikatet på webbprogramproxyservern med hjälp av den här cmdleten:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Starta om tjänsten på de valda webbprogramproxyservrarna.

10. Sätt tillbaka den valda webbprogramproxyn och AD FS-servrarna i produktionsmiljön.

Uppdatera resten av AD FS- och webbprogramproxyservrarna på samma sätt.

AD FS- och webbprogramservrar stöder alla brandväggar som inte utför SSL-avslutning på slutpunkten. Ad FS-/webbprogramproxyservrar har dessutom inbyggda mekanismer för att:

• Förhindra vanliga webbattacker som skript mellan webbplatser.
• Utför AD FS-proxy.
• Uppfyll alla krav som definieras av MS-ADFSPIP-protokollet.

I AD FS 2016 aktiveras tokenbindningen automatiskt och orsakar flera kända problem med proxy- och federationsscenarier. Dessa problem orsakar den här händelsen. Lös den här händelsen genom att köra följande PowerShell-kommando för att ta bort stöd för tokenbindning:

Set-AdfsProperties -IgnoreTokenBinding $true

Efter en uppgradering till Windows Server 2019 fortsätter konfigurationsversionen av webbprogramproxyn att visas som Windows Server 2016. Webbprogramproxyn har inte nya versionsspecifika funktioner för Windows Server 2019. Om servergruppens beteendenivå har höjts på AD FS fortsätter webbprogramproxyn att visas som Windows Server 2016. Det här beteendet är avsiktligt.

När ESL är aktiverat spårar AD FS kontoaktiviteten och kända platser för användare i databasen ADFSArtifactStore. Den här databasen skalas i förhållande till antalet användare och kända platser som spåras. När du planerar att aktivera ESL kan du uppskatta att databasen ADFSArtifactStore växer med en hastighet av upp till 1 GB per 100 000 användare.

Om AD FS-servergruppen använder den interna Windows-databasen är standardplatsen för databasfilerna C:\Windows\WID\Data. För att förhindra att enheten fylls måste du ha minst 5 GB ledigt lagringsutrymme innan du aktiverar ESL. Utöver disklagring planerar du att det totala processminnet ska växa efter att du har aktiverat ESL med upp till ytterligare 1 GB RAM-minne för användarpopulationer på 500 000 eller mindre.

Här är texten i händelsen:

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Den här händelsen inträffar när skogar inte är betrodda när AD FS försöker räkna upp alla skogar i en kedja av betrodda skogar och ansluta över alla skogar. Anta till exempel att AD FS Forest A och Forest B är betrodda och att och Skog B och Skog C är betrodda. AD FS räknar upp alla tre skogarna och försöker hitta ett förtroende mellan skog A och skog C. Om användare från den misslyckade skogen ska autentiseras av AD FS konfigurerar du ett förtroende mellan AD FS-skogen och den misslyckade skogen. Om användare från den misslyckade skogen inte ska autentiseras av AD FS ignorerar du den här händelsen.

Här är texten i händelsen:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

I AD FS 2016 aktiveras tokenbindningen automatiskt och orsakar flera kända problem med proxy- och federationsscenarier. Dessa problem orsakar den här händelsen. Lös händelsen genom att köra följande PowerShell-kommando för att ta bort stöd för tokenbindning:

Set-AdfsProperties -IgnoreTokenBinding $true

Här är texten i händelsen:

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Den här händelsen förväntas när båda dessa instruktioner är sanna:

• Du har en servergrupp i blandat läge.
• AD FS 2019 tillhandahåller information om servergruppens högsta beteendenivå till den primära federationsservern och identifieras inte av federationsserverversionen 2016.

AD FS 2019 försöker dela värdet Win2019 MaxBehaviorLevel i servergruppen tills det blir inaktuellt efter två månader och tas bort automatiskt från servergruppen. Om du vill undvika att hämta den här händelsen migrerar du den primära federationsrollen till federationsservern med den senaste versionen. Följ anvisningarna i Uppgradera AD FS-servergruppen till Beteendenivå för Windows Server 2019-servergrupp.

Följ dessa anvisningar för att lösa problemet:

1. Starta AD FS-hanteringskonsolen.
2. Gå till Beskrivningar av tjänstomfång>.
3. I "Omfattningsbeskrivningar" väljer du Fler alternativ och sedan Lägg till omfångsbeskrivning.
4. Under Namn anger du ugs och väljer sedan Tillämpa>OK.
5. Starta PowerShell som administratör.
6. Kör kommandot Get-AdfsApplicationPermission. Leta efter värdet ScopeNames :{openid, aza} som har värdet ClientRoleIdentifier . Anteckna värdet ObjectIdentifier .
7. Kör kommandot Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
8. Starta om AD FS-tjänsten.
9. Starta om klienten på klienten. Du bör uppmanas att konfigurera Windows Hello för företag.
10. Om konfigurationsfönstret inte visas måste du samla in spårningsloggar och felsöka ytterligare.

Ja, men bara i Windows Server 2019 eller senare. Du kan ordna omfångsparametern som en blankstegsavgränsad lista där varje post är strukturerad som en resurs eller ett omfång, till exempel <create a valid sample request>.

Ja, men bara i Windows Server 2019 eller senare. AD FS stöder Proof Key for Code Exchange (PKCE) för OAuth Authorization Code Grant-flödet.

AD FS registreras för inloggningscertifikat för autentiserade konton under vissa Windows Hello för företag-scenarier, enligt beskrivningen i Konfigurera enkel inloggning för Azure Virtual Desktop med AD FS. Som standard innehåller dessa certifikat inte SID-tillägg och nekas av KDC. Mer information om KDC-kraven finns i KB5014754: Certifikatbaserade autentiseringsändringar på Windows-domänkontrollanter. Uppdateringar är tillgängliga för AD FS på Windows Server 2019, Windows Server 2022 och Windows Server 2025 för att säkerställa att utfärdade certifikat innehåller SID-tillägget för att uppfylla starka mappningskrav. Om du vill aktivera det här beteendet installerar du de senaste Windows-uppdateringarna på alla AD FS-servrar i servergruppen och kör följande cmdlet på den primära AD FS-servern:

• Set-AdfsCertificateAuthority -EnrollmentAgent -AddSIDCertificateExtension $true