Häufig gestellte Fragen zu den Active Directory-Verbunddiensten (Active Directory Federation Services, AD FS) (2024)

Sie können ein Upgrade bzw. eine Migration für ADFS durchführen, indem Sie die Schritte in einem der folgenden verknüpften Artikel ausführen:

• Windows Server2012 R2 ADFS zu Windows Server2016 ADFS oder höher. (Der Vorgang ist identisch, wenn Sie ein Upgrade von Windows Server2016 ADFS auf Windows Server2019 ADFS ausführen.)
  • Aktualisieren auf ADFS unter WindowsServer2016 unter Verwendung einer WID-Datenbank
  • Aktualisieren auf ADFS unter WindowsServer2016 unter Verwendung einer SQL-Datenbank
• Windows Server2012 ADFS zu Windows Server2012 R2 ADFS:
  • Migrieren zu ADFS unter Windows Server2012 R2
• ADFS2.0 zu Windows Server2012 ADFS:
  • Migrieren zu ADFS unter Windows Server2012
• ADFS1.x zu ADFS2.0:
  • Upgrade von ADFS1.x auf ADFS2.0

Wenn ein Upgrade von ADFS 2.0 oder 2.1 (Windows Server2008 R2 oder Windows Server2012) erforderlich ist, verwenden Sie die mitgelieferten Skripts (in „C:\Windows\ADFS“).

Ja, aber folgende Nebeneffekte treten auf:

• Sie müssen die Aktualisierung von Tokensignaturzertifikaten manuell verwalten, weil AzureAD auf die Verbundmetadaten nicht zugreifen kann. Weitere Informationen zum manuellen Aktualisieren von Tokensignaturzertifikaten finden Sie unter Erneuern von Verbundzertifikaten für Office365 und Azure Active Directory.
• Sie können keine Legacyauthentifizierungsflows verwenden (z.B. den ExO-Proxyauthentifizierungsflow).

ADFS ist ein zustandsloses System, sodass der Lastenausgleich für Anmeldungen relativ einfach ist. Im Folgenden finden Sie einige wichtige Empfehlungen für Lastenausgleichssysteme:

• Lastenausgleichsmodule sollten nicht mit IP-Affinität konfiguriert werden. Durch IP-Affinität kann eine Teilmenge Ihrer Server in bestimmten Exchange Online-Szenarien überlastet werden.
• Lastenausgleichsmodule dürfen die HTTPS-Verbindungen nicht beenden und keine neue Verbindung mit dem ADFS-Server starten.
• Lastenausgleichsmodule sollten sicherstellen, dass die IP-Adresse zum Herstellen einer Verbindung im HTTP-Paket beim Senden an ADFS als IP-Quelladresse übersetzt wird. Wenn ein Lastenausgleichsmodul die IP-Quelladresse nicht im HTTP-Paket senden kann, muss das Lastenausgleichsmodul die IP-Adresse dem Header „X-Forwarded-For“ hinzufügen. Dieser Schritt ist erforderlich, um bestimmte IP-bezogene Features (z.B. gesperrte IP-Adressen und intelligente Extranetsperre) ordnungsgemäß zu behandeln. Wenn diese Konfiguration nicht ordnungsgemäß implementiert ist, kann die Sicherheit reduziert werden.
• Lastenausgleichsmodule sollten SNI unterstützen. Wenn dies nicht der Fall ist, stellen Sie sicher, dass AD FS so konfiguriert ist, dass HTTPS-Bindungen erstellt werden, um Clients zu verarbeiten, die SNI nicht unterstützen.
• Lastenausgleichsmodule sollten den HTTP-Integritätstestendpunkt von ADFS verwenden, um zu ermitteln, ob die AD FS- oder Webanwendungsproxy-Server ausgeführt werden. Sie sollten ausgeschlossen werden, wenn „200OK“ nicht zurückgegeben wird.

ADFS unterstützt mehrere Konfigurationen mit mehreren Gesamtstrukturen. ADFS verwendet das zugrunde liegende ADDS-Vertrauensstellungsnetzwerk, um Benutzer über mehrere vertrauenswürdige Bereiche hinweg zu authentifizieren. Es wird dringend empfohlen, bidirektionale Gesamtstruktur-Vertrauensstellungen einzurichten, da sie einfacher einzurichten sind, wodurch sichergestellt wird, dass das Vertrauenssystem ordnungsgemäß funktioniert.

Außerdem zu beachten:

• Wenn Sie über eine unidirektionale Gesamtstruktur-Vertrauensstellung verfügen, z.B. eine Umkreisnetzwerk-Gesamtstruktur (auch als DMZ bezeichnet), die Partneridentitäten enthält, empfiehlt es sich, AD FS in der Unternehmensgesamtstruktur bereitzustellen. Behandeln Sie die Umkreisnetzwerk-Gesamtstruktur als eine weitere Vertrauensstellung mit lokalem Anspruchsanbieter, die über LDAP verbunden ist. In diesem Fall funktioniert integrierte Windows-Authentifizierung für Benutzer der Umkreisnetzwerk-Gesamtstruktur nicht. Sie müssen Kennwortauthentifizierung verwenden, da dies der einzige unterstützte Mechanismus für LDAP ist.

  Wenn Sie diese Option nicht verwenden können, müssen Sie einen weiteren ADFS-Server in der Umkreisnetzwerk-Gesamtstruktur einrichten. Fügen Sie ihn als Anspruchsanbieter-Vertrauensstellung im ADFS-Server in der Unternehmensgesamtstruktur hinzu. Benutzer müssen eine Startbereichsermittlung durchführen, aber sowohl integrierte Windows-Authentifizierung als auch Kennwortauthentifizierung funktionieren. Nehmen Sie geeignete Änderungen an den Ausstellungsregeln in ADFS in der Umkreisnetzwerk-Gesamtstruktur vor, da ADFS in der Unternehmensgesamtstruktur keine weiteren Informationen zu Benutzern aus der Umkreisnetzwerk-Gesamtstruktur abrufen kann.

• Vertrauensstellungen auf Domänenebene werden unterstützt und können funktionieren. Es wird jedoch dringend empfohlen, zu einem Vertrauensstellungsmodell auf Gesamtstrukturebene zu wechseln. Außerdem müssen Sie sicherstellen, dass UPN-Routing und NetBIOS-Namensauflösung ordnungsgemäß funktionieren.

ADFS bietet einen erweiterbaren Mechanismus zum Integrieren von MFA-Drittanbietern. Hierfür gibt es kein festgelegtes Zertifizierungsprogramm. Es wird davon ausgegangen, dass der Hersteller die erforderlichen Überprüfungen vor der Freigabe durchgeführt hat.

Die Liste der Anbieter, die Microsoft benachrichtigt haben, finden Sie hier: Anbieter für mehrstufige Authentifizierung für ADFS. Möglicherweise sind Anbieter verfügbar, die wir nicht kennen. Wir aktualisieren die Liste, wenn wir neue Anbieter ermitteln.

Ja, Proxys von Drittanbietern können vor AD FS eingefügt werden, aber jeder Drittanbieter-Proxy muss das MS-ADFSPIP-Protokoll unterstützen, das anstelle des Webanwendungsproxys zu verwenden ist.

Derzeit sind uns die folgenden Drittanbieter bekannt. Möglicherweise sind Anbieter verfügbar, die wir nicht kennen. Wir aktualisieren diese Liste, wenn wir neue Anbieter ermitteln.

• F5-Zugriffsrichtlinien-Manager
• Citrix Application Delivery Controller (ADC)

Sie können die ADFS2016-Version des Arbeitsblatts herunterladen.Sie können dieses Arbeitsblatt auch für ADFS in Windows Server2012 R2 verwenden.

Apple hat eine Reihe von Anforderungen herausgegeben, die als „App-Transportsicherheit“ (App Transport Security, ATS) bezeichnet werden und sich auf Aufrufe aus iOS-Apps auswirken können, die sich bei ADFS authentifizieren. Sie können dafür sorgen, dass Ihre ADFS- und Webanwendungsproxy-Server diesen Anforderungen genügen, indem Sie sicherstellen, dass die Server die Anforderungen zum Herstellen einer Verbindung mithilfe von ATS unterstützen.Insbesondere sollten Sie Folgendes sicherstellen:

• Ihre AD FS- und Webanwendungsproxy-Server unterstützen TLS1.2.
• Die ausgehandelte Verschlüsselungssammlung der TLS-Verbindung unterstützt perfekte Weiterleitungssicherheit.

Informationen zum Aktivieren und Deaktivieren von SSL2.0 und 3.0 sowie TLS1.0, 1.1 und 1.2 finden Sie unter Verwalten von SSL-Protokollen in ADFS.

Um sicherzustellen, dass Ihre ADFS- und Webanwendungsproxy-Server nur TLS-Verschlüsselungssammlungen aushandeln, die ATP unterstützen, können Sie alle Verschlüsselungssammlungen deaktivieren, die nicht in der Liste der ATP-kompatiblen Verschlüsselungssammlungen enthalten sind. Verwenden Sie zum Deaktivieren die WindowsTLS PowerShell-Cmdlets.

Sie können ein angepasstes ID-Token (id_token) verwenden, um relevante Informationen im id_token selbst hinzuzufügen. Weitere Informationen finden Sie unter Anpassen von Ansprüchen, die in id-token ausgegeben werden müssen.

Für dieses Szenario wurden ein spezieller ValueType (http://www.w3.org/2001/XMLSchema#json) und ein Escapezeichen (\x22) in ADFS2016 hinzugefügt. Verwenden Sie die folgenden Beispiele, die die Ausstellungsregel und auch die endgültige Ausgabe aus dem Zugriffstoken zeigen.

Beispiel für eine Ausstellungsregel:

=> 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}");

Im Zugriffstoken ausgegebener Anspruch:

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

Unterstützt:

• aza. Wenn Sie OAuth2.0 Protocol Extensions for Broker Clients verwenden und der Bereichsparameter den Bereich „aza“ enthält, gibt der Server ein neues primäres Aktualisierungstoken aus und legt es im Feld refresh_token der Antwort fest. Außerdem wird das Feld refresh_token_expires_in auf die Lebensdauer des neuen primären Aktualisierungstokens festgelegt, sofern eines erzwungen wird.
• openid. Ermöglicht es einer Anwendung, die Verwendung des OpenID Connect-Autorisierungsprotokolls anzufordern.
• logon_cert. Ermöglicht einer Anwendung das Anfordern von Anmeldezertifikaten, die für die interaktive Anmeldung authentifizierter Benutzer verwendet werden können. Der ADFS-Server lässt den Parameter access_token in der Antwort aus und stellt stattdessen eine Base64-codierte CMS-Zertifikatkette oder eine CMC-vollständige PKI-Antwort bereit. Weitere Informationen finden Sie unter Verarbeitungsandetails.
• user_impersonation. Erforderlich, wenn Sie ein Im-Auftrag-von-Zugriffstoken von ADFS anfordern möchten. Weitere Informationen zur Verwendung dieses Bereichs finden Sie unter Erstellen einer Anwendung mit mehreren Ebenen mithilfe von „On-Behalf-Of“ (OBO) unter Verwendung von OAuth mit ADFS2016.

Nicht unterstützt:

• vpn_cert. Ermöglicht einer Anwendung das Anfordern von VPN-Zertifikaten, die verwendet werden können, um VPN-Verbindungen mithilfe von EAP-TLS-Authentifizierung herzustellen. Dieser Bereich wird nicht mehr unterstützt.
• email. Ermöglicht es einer Anwendung, einen E-Mail-Anspruch für den angemeldeten Benutzer anzufordern. Dieser Bereich wird nicht mehr unterstützt.
• profile. Ermöglicht es einer Anwendung, profilbezogene Ansprüche für den angemeldeten Benutzer anzufordern. Dieser Bereich wird nicht mehr unterstützt.

• Wenn der Proxy für ADFS-Anforderungen eingesetzt wird, die die integrierte Windows-Authentifizierung verwenden, muss das Proxy-SSL-Zertifikat denselben Schlüssel wie das SSL-Zertifikat des Verbundservers verwenden.
• Wenn die ADFS-Eigenschaft ExtendedProtectionTokenCheck aktiviert ist (die Standardeinstellung in ADFS), muss das Proxy-SSL-Zertifikat denselben Schlüssel wie das SSL-Zertifikat des Verbundservers verwenden.
• Andernfalls kann das Proxy-SSL-Zertifikat einen anderen Schlüssel als das ADFS SSL-Zertifikat haben. Es muss die gleichen Anforderungen erfüllen.

ADFS zeigt auf dem Anmeldebildschirm nur eine einzige Authentifizierungsmethode an, wenn die Anwendung explizit einen bestimmten Authentifizierungs-URI erfordert, der einer konfigurierten und aktivierten Authentifizierungsmethode zugeordnet ist. Die Methode wird im wauth-Parameter in WS-Verbund-Anforderungen übermittelt. Sie wird im RequestedAuthnCtxRef-Parameter in SAML-Protokollanforderungen übermittelt. Nur die angeforderte Authentifizierungsmethode wird angezeigt. (Beispielsweise Kennwortanmeldung.)

Wenn ADFS mit AzureAD verwendet wird, senden Anwendungen normalerweise den Parameter prompt=login an AzureAD. Azure AD übersetzt diesen Parameter standardmäßig, um eine neue kennwortbasierte Anmeldung bei ADFS anzufordern. Dieses Szenario ist der häufigste Grund dafür, dass eine Kennwortanmeldung für ADFS in Ihrem Netzwerk angezeigt oder eine Option zur Anmeldung mit Ihrem Zertifikat nicht angezeigt wird. Dieses Problem kann leicht behoben werden, indem Sie in AzureAD eine Änderung an den Einstellungen der Verbunddomäne vornehmen.

Weitere Informationen finden Sie unter Unterstützung für den Parameter „prompt=login“ in den Active Directory-Verbunddiensten.

Weitere Informationen dazu finden Sie unter Konfigurieren von Browsers für die Verwendung der integrierten Windows-Authentifizierung.

Administratoren fragen sich häufig, wie lange Benutzer einmaliges Anmelden (Single Sign-On, SSO) nutzen können, ohne neue Anmeldeinformationen eingeben zu müssen, und wie Administratoren dieses Verhalten steuern können. Dieses Verhalten und die Konfigurationseinstellungen zur entsprechenden Steuerung werden unter ADFS: Einstellungen für einmaliges Anmelden beschrieben.

Die Standardlebensdauer der verschiedenen Cookies und Token wird unten aufgeführt (zusammen mit den Parametern, die die Lebensdauer bestimmen):

Registrierte Geräte

• PRT- und SSO-Cookies: Maximal 90Tage, gesteuert durch PSSOLifeTimeMins. (Vorausgesetzt, das Gerät wird mindestens alle 14Tage verwendet. Dieses Zeitfenster wird über DeviceUsageWindow gesteuert.)

• Aktualisierungstoken: Wird basierend auf den Parametern oben berechnet, um ein einheitliches Verhalten zu bieten.

• access_token: Standardmäßig eine Stunde, basierend auf der vertrauenden Seite.

• id_token: Identisch mit access_token.

Nicht registrierte Geräte

• SSO-Cookies: Standardmäßig acht Stunden, gesteuert durch SSOLifetimeMins. Wenn KMSI (Keep me signed in, Angemeldet bleiben) aktiviert ist, beträgt der Standardwert24 Stunden. Dieser Standardwert kann über KMSILifetimeMins konfiguriert werden.

• Aktualisierungstoken: Standardmäßig acht Stunden. 24Stunden, wenn KMSI aktiviert ist.

• access_token: Standardmäßig eine Stunde, basierend auf der vertrauenden Seite.

• id_token: Identisch mit access_token.

  See Also

  Teil 28b: Active Directory Federation Services konfigurieren

HSTS ist ein Mechanismus für Websicherheitsrichtlinien. Mit seiner Hilfe werden Angriffe zur Herabstufung des Protokolls und Cookieübernahme für Dienste reduziert, die sowohl über HTTP- als auch über HTTPS-Endpunkte verfügen. Auf diese Weise können Webserver deklarieren, dass Webbrowser (oder andere entsprechende Benutzer-Agents) mit ihnen nur mit HTTPS und niemals über das HTTP-Protokoll interagieren sollen.

Alle ADFS-Endpunkte für den Webauthentifizierungsdatenverkehr werden ausschließlich über HTTPS geöffnet. Daher mindert ADFS die Bedrohungen, die durch den HSTS-Richtlinienmechanismus entstehen. (Entwurfsbedingt erfolgt keine Herabstufung auf HTTP, da es keine Listener in HTTP gibt.) ADFS verhindert auch, dass Cookies an einen anderen Server mit HTTP-Protokollendpunkten gesendet werden, indem alle Cookies mit dem Sicherheitsflag gekennzeichnet werden.

Daher benötigen Sie HSTS nicht auf einem ADFS-Server, da HSTS nicht herabgestuft werden kann. ADFS-Server erfüllen Complianceanforderungen, weil sie kein HTTP verwenden können und weil Cookies als sicher gekennzeichnet sind.

Schließlich unterstützen ADFS2016 (mit den neuesten Patches) und ADFS2019 die Ausgabe des HSTS-Headers. Informationen zur Konfiguration dieses Verhaltens finden Sie unter Anpassen der HTTP-Sicherheitsantwortheader mit ADFS.

Es wird nicht empfohlen, die SSL-Beendigung vor dem Webanwendungsproxy-Server zu vorzunehmen. Wenn dies vor dem Webanwendungsproxy-Server erfolgt, enthält X-MS-Forwarded-Client-IP die IP-Adresse des Netzwerkgeräts vor dem Webanwendungsproxy-Server. Im Folgenden finden Sie eine kurze Beschreibung der verschiedenen IP-bezogenen Ansprüche, die von ADFS unterstützt werden:

• X-MS-Client-IP. Netzwerk-IP-Adresse des Geräts, das mit dem STS verbunden ist. Bei Extranetanforderungen enthält dieser Anspruch immer die IP-Adresse des Webanwendungsproxy-Servers.
• X-MS-Forwarded-Client-IP. Mehrwertiger Anspruch, der alle Werte enthält, die von Exchange Online an ADFS weitergeleitet werden. Er enthält auch die IP-Adresse des Geräts, das mit dem Webanwendungsproxy-Server verbunden ist.
• Userip. Bei Extranetanforderungen enthält dieser Anspruch den Wert von X-MS-Forwarded-Client-IP. Bei Intranetanforderungen enthält dieser Anspruch denselben Wert wie X-MS-Client-IP.

In ADFS2016 (mit den neuesten Patches) und höheren Versionen wird auch das Erfassen des Headers X-Forwarded-For unterstützt. Ein Lastenausgleichsmodul oder Netzwerkgerät, das nicht auf Ebene3 weitergeleitet wird (IP-Adresse wird beibehalten), sollte die eingehende Client-IP-Adresse dem Header nach Branchenstandard X-Forwarded-For hinzufügen.

Diese Gruppe wird nur erstellt, wenn ein Windows Server2016-Domänencontroller mit der FSMO-PDC-Rolle in der Domäne vorhanden ist. Um den Fehler zu beheben, können Sie die Gruppe manuell erstellen. Führen Sie die folgenden Schritte aus, um die erforderlichen Berechtigungen hinzuzufügen, nachdem Sie das Dienstkonto als Mitglied der Gruppe hinzugefügt haben:

1. Öffnen Sie Active Directory-Benutzer und -Computer.
2. Klicken Sie im linken Bereich mit der rechten Maustaste auf Ihren Domänennamen, und wählen Sie Eigenschaften aus.
3. Wählen Sie Sicherheit aus. (Wenn die Registerkarte Sicherheit nicht vorhanden ist, aktivieren Sie über das Menü Ansicht die Option Erweiterte Funktionen.)
4. Wählen Sie Erweitert, Hinzufügen und dann Prinzipal auswählen aus.
5. Das Dialogfeld Benutzer, Computer, Dienstkonto oder Gruppe auswählen wird geöffnet. Geben Sie im Textfeld Geben Sie den auszuwählenden Objektnamen ein den Namen Key Admin-Gruppe ein. Klicken Sie auf OK.
6. Wählen Sie im Listenfeld Gilt für die Option Nachgeordnete Benutzerobjekte aus.
7. Scrollen Sie zum Ende der Seite, und wählen Sie Alle löschen aus.
8. Wählen Sie im Abschnitt Eigenschaften die Optionen msDS-KeyCredentialLink lesen und msDS-KeyCredentialLink schreiben aus.

Bei Anwendungen, die die ADAL-Bibliothek von Android verwenden, schlägt die Authentifizierung bei AzureAD für Verbundbenutzer möglicherweise fehl. Bei der App tritt ein AuthenticationException-Fehler auf, wenn sie die Anmeldeseite anzuzeigen versucht. Im Chrome-Browser wird die ADFS-Anmeldeseite möglicherweise als unsicher bezeichnet.

Android unterstützt (in allen Versionen und auf allen Geräten) nicht das Herunterladen zusätzlicher Zertifikate über das Feld authorityInformationAccess des Zertifikats. Diese Einschränkung gilt auch für den Chrome-Browser. Bei jedem Serverauthentifizierungszertifikat, bei dem Zwischenzertifikate fehlen, tritt dieser Fehler auf, wenn die gesamte Zertifikatkette nicht von ADFS übergeben wird.

Sie können dieses Problem beheben, indem Sie die ADFS- und Webanwendungsproxy-Server so konfigurieren, dass die erforderlichen Zwischenzertifikate zusammen mit dem SSL-Zertifikat gesendet werden.

Wenn Sie das SSL-Zertifikat von einem Computer exportieren, um es in den persönlichen Speicher des ADFS- und Webanwendungsproxy-Servers zu importieren, stellen Sie sicher, dass Sie den privaten Schlüssel exportieren und Personal Information Exchange - PKCS #12 auswählen.

Stellen Sie außerdem sicher, dass Sie Nach Möglichkeit alle Zertifikate in den Zertifikatpfad einschließen und Alle erweiterten Eigenschaften exportieren auswählen.

Führen Sie „certlm.msc“ auf den Windows-Servern aus, und importieren Sie die PFX-Datei in den persönlichen Zertifikatspeicher des Computers. Dies bewirkt, dass der Server die gesamte Zertifikatkette an die ADAL-Bibliothek übergibt.

ADFS-Farmen im gemischten Modus sind für vorübergehende Nutzung gedacht. Es wird empfohlen, dass Sie während Ihrer Planung entweder ein Rollover des SSL-Zertifikats vor dem Upgradevorgang ausführen oder den Vorgang beenden und die Ebene des Farmverhaltens erhöhen, bevor Sie das SSL-Zertifikat aktualisieren. Wenn diese Empfehlung nicht befolgt wurde, verwenden Sie die folgenden Anweisungen, um das SSL-Zertifikat zu aktualisieren.

Auf Webanwendungsproxy-Servern können Sie weiterhin Set-WebApplicationProxySslCertificate verwenden. Auf den ADFS-Servern müssen Sie Netsh verwenden. Führen Sie die folgenden Schritte aus:

1. Wählen Sie eine Teilmenge der ADFS2016-Server für die Verwaltung aus.

2. Importieren Sie auf den im vorherigen Schritt ausgewählten Servern das neue Zertifikat über MMC.

3. Löschen der vorhandenen Zertifikate:

   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. Hinzufügen der neuen Zertifikate:

   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. Starten Sie den ADFS-Dienst auf dem ausgewählten Server neu.

6. Entfernen Sie eine Teilmenge der Webanwendungsproxy-Server zur Verwaltung.

7. Importieren Sie das neue Zertifikat auf den ausgewählten Webanwendungsproxy-Servern über MMC.

8. Legen Sie das neue Zertifikat auf dem Webanwendungsproxy-Server mithilfe dieses Cmdlets fest:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Starten Sie den Dienst auf den ausgewählten Webanwendungsproxy-Servern neu.

10. Platzieren Sie die ausgewählten Webanwendungsproxy- und ADFS-Server erneut in der Produktionsumgebung.

Aktualisieren Sie die restlichen ADFS- und Webanwendungsproxy-Server auf die gleiche Weise.

ADFS- und Webanwendungsserver unterstützen jede Firewall, die keine SSL-Beendigung für den Endpunkt ausführt. Außerdem verfügen ADFS- und Webanwendungsproxy-Server über integrierte Mechanismen für Folgendes:

• Verhindern häufiger Webangriffe wie Cross-Site Scripting.
• Ausführen von ADFS-Proxyfunktionen.
• Erfüllen aller Anforderungen, die durch das MS-ADFSPIP-Protokoll definiert werden.

In ADFS2016 wird die Tokenbindung automatisch aktiviert. Das verursacht mehrere bekannte Probleme bei Proxy- und Verbundszenarien. Diese Probleme verursachen dieses Ereignis. Führen Sie zum Auflösen dieses Ereignisses den folgenden PowerShell-Befehl aus, um Unterstützung für Tokenbindungen zu entfernen:

Set-AdfsProperties -IgnoreTokenBinding $true

Wenn ESL aktiviert ist, verfolgt ADFS die Kontoaktivität und die bekannten Speicherorte für Benutzer in der ADFSArtifactStore-Datenbank nach. Diese Datenbank wird relativ zur Anzahl der nachverfolgten Benutzer und bekannten Standorte skaliert. Beim Planen der Aktivierung von ESL können Sie die Größenzunahme für die ADFSArtifactStore-Datenbank auf eine Rate von bis zu 1GB pro 100.000Benutzer schätzen.

Wenn die ADFS-Farm die interne Windows-Datenbank verwendet, ist der Standardspeicherort für die Datenbankdateien „C:\Windows\WID\Data“. Um zu verhindern, dass dieses Laufwerk überlastet wird, stellen Sie sicher, dass Sie über mindestens 5GB freien Speicherplatz verfügen, bevor Sie ESL aktivieren. Planen Sie zusätzlich zum Datenspeicher ein, dass der gesamte Prozessspeicher nach der Aktivierung von ESL um bis zu 1GB RAM für Benutzerpopulationen von 500.000 oder weniger anwächst.

Dies ist der Text des Ereignisses:

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.

Dieses Ereignis tritt auf, wenn Gesamtstrukturen nicht vertrauenswürdig sind und ADFS versucht, alle Gesamtstrukturen in einer Kette vertrauenswürdiger Gesamtstrukturen zu durchlaufen und Verbindungen über alle Gesamtstrukturen hinweg herzustellen. Angenommen, ADFS-GesamtstrukturA und GesamtstrukturB sind vertrauenswürdig, und GesamtstrukturB und GesamtstrukturC sind vertrauenswürdig. ADFS listet alle drei Gesamtstrukturen auf und versucht, eine Vertrauensstellung zwischen GesamtstrukturA und GesamtstrukturC zu finden. Wenn Benutzer aus der nicht erfolgreichen Gesamtstruktur durch ADFS authentifiziert werden sollen, sollten Sie eine Vertrauensstellung zwischen der ADFS-Gesamtstruktur und der nicht erfolgreichen Gesamtstruktur einrichten. Wenn Benutzer aus nicht erfolgreichen Gesamtstruktur nicht durch ADFS authentifiziert werden sollen, können Sie diesen Fehler ignorieren.

Dies ist der Text des Ereignisses:

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

In ADFS2016 wird die Tokenbindung automatisch aktiviert. Das verursacht mehrere bekannte Probleme bei Proxy- und Verbundszenarien. Diese Probleme verursachen dieses Ereignis. Führen Sie zum Auflösen dieses Ereignisses den folgenden PowerShell-Befehl aus, um Unterstützung für Tokenbindungen zu entfernen:

Set-AdfsProperties -IgnoreTokenBinding $true

Dies ist der Text des Ereignisses:

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.

Dieses Ereignis wird erwartet, wenn diese Anweisungen beide zutreffen:

• Sie verwenden eine Farm im gemischten Modus.
• AD FS 2019 stellt dem primären Verbundserver Informationen zur maximalen Verhaltensebene der Farm zur Verfügung und wird vom Verbundserver mit Version2016 nicht erkannt.

ADFS2019 versucht weiterhin, den MaxBehaviorLevel-Wert Win2019 in der Farm zu teilen, bis er nach zwei Monaten veraltet und automatisch aus der Farm entfernt wird. Um dieses Ereignis zu vermeiden, migrieren Sie die primäre Verbundrolle zum Verbundserver mit der neuesten Version. Befolgen Sie die Anweisungen unter So aktualisieren Sie Ihre ADFS-Farm auf die Ebene „Windows Server2019-Farmverhalten“.