Häufig gestellte Fragen (FAQ) zu AD FS

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

• Windows Server 2012 R2 AD FS zu Windows Server 2016 AD FS oder höher. (Der Vorgang ist identisch, wenn Sie ein Upgrade von Windows Server 2016 AD FS auf Windows Server 2019 AD FS ausführen.)
  • Aktualisieren auf AD FS unter Windows Server 2016 unter Verwendung einer WID-Datenbank
  • Aktualisieren auf AD FS unter Windows Server 2016 unter Verwendung einer SQL-Datenbank
• Windows Server 2012 AD FS zu Windows Server 2012 R2 AD FS:
  • Migrieren zu AD FS unter Windows Server 2012 R2
• AD FS 2.0 zu Windows Server 2012 AD FS:
  • Migrieren zu AD FS unter Windows Server 2012
• AD FS 1.x zu AD FS 2.0:
  • Upgrade von AD FS 1.x auf AD FS 2.0

Wenn ein Upgrade von AD FS 2.0 oder 2.1 (Windows Server 2008 R2 oder Windows Server 2012) erforderlich ist, verwenden Sie die mitgelieferten Skripts (in „C:\Windows\ADFS“).

Die HTTP/2-Unterstützung wurde in Windows Server 2016 hinzugefügt, aber HTTP/2 kann nicht für die Authentifizierung mit Clientzertifikat verwendet werden. Viele AD FS-Szenarien verwenden Clientzertifikatauthentifizierung. Und viele Clients unterstützen das Wiederholen von Anforderungen mit HTTP/1.1 nicht. Daher konfiguriert die AD FS-Farmkonfiguration die HTTP-Einstellungen des lokalen Servers für HTTP/1.1 neu. Diese Neukonfiguration erfordert einen Neustart des Servers.

Diese Konfiguration wird unterstützt, allerdings würden in ihr keine neuen AD FS 2016-Features unterstützt. Diese Konfiguration wird nur vorübergehend während der Migration von AD FS 2012 R2 zu AD FS 2016 verwendet. Es sollte nicht über einen längeren Zeitraum hinweg verwendet werden.

Ja, aber folgende Nebeneffekte treten auf:

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

AD FS 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 AD FS-Server starten.
• Lastenausgleichsmodule sollten sicherstellen, dass die IP-Adresse zum Herstellen einer Verbindung im HTTP-Paket beim Senden an AD FS 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 AD FS verwenden, um zu ermitteln, ob die AD FS- oder Webanwendungsproxy-Server ausgeführt werden. Sie sollten ausgeschlossen werden, wenn „200 OK“ nicht zurückgegeben wird.

AD FS unterstützt mehrere Konfigurationen mit mehreren Gesamtstrukturen. AD FS verwendet das zugrunde liegende AD DS-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 AD FS-Server in der Umkreisnetzwerk-Gesamtstruktur einrichten. Fügen Sie ihn als Anspruchsanbieter-Vertrauensstellung im AD FS-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 AD FS in der Umkreisnetzwerk-Gesamtstruktur vor, da AD FS 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.

Ja, IPv6-Adressen werden als vertraute und unbekannte Standorte berücksichtigt.

AD FS 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 AD FS. 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 AD FS 2016-Version des Arbeitsblatts herunterladen. Sie können dieses Arbeitsblatt auch für AD FS in Windows Server 2012 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 AD FS authentifizieren. Sie können dafür sorgen, dass Ihre AD FS- 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 TLS 1.2.
• Die ausgehandelte Verschlüsselungssammlung der TLS-Verbindung unterstützt perfekte Weiterleitungssicherheit.

Informationen zum Aktivieren und Deaktivieren von SSL 2.0 und 3.0 sowie TLS 1.0, 1.1 und 1.2 finden Sie unter Verwalten von SSL-Protokollen in AD FS.

Um sicherzustellen, dass Ihre AD FS- 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 Windows TLS PowerShell-Cmdlets.

Der Wert des „sub“-Anspruchs ist der Hash aus der Client-ID und dem Ankeranspruchswert.

Die Lebensdauer des Aktualisierungstokens ist die Lebensdauer des Tokens, das AD FS von der Remoteanspruchsanbieter-Vertrauensstellung erhalten hat. Die Lebensdauer des Zugriffstokens ist die Tokenlebensdauer der vertrauenden Seite, für die das Zugriffstoken ausgestellt wird.

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 AD FS 2016 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"}

Mit AD FS unter Windows Server 2019 können Sie jetzt den im Bereichsparameter eingebetteten Ressourcenwert übergeben. Der Bereichsparameter kann als eine durch Leerzeichen getrennte Liste organisiert werden, wobei jeder Eintrag als Ressource/Bereich strukturiert ist.

AD FS unter Windows Server 2019 unterstützt die Erweiterung „Proof Key for Code Exchange“ (PKCE) für den OAuth Authorization Code Grant-Datenfluss.

Unterstützt:

• aza. Wenn Sie OAuth 2.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 AD FS-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 AD FS 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 AD FS 2016.

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.

Das AD FS SSL-Zertifikat ist nicht identisch mit dem Zertifikat für die AD FS-Dienstkommunikation, das im Snap-In „AD FS-Verwaltung“ enthalten ist. Zum Ändern des SSL-Zertifikats von AD FS müssen Sie PowerShell verwenden. Befolgen Sie die Anleitungen unter Verwalten von SSL-Zertifikaten in AD FS und WAP 2016.

Informationen zum Deaktivieren und Aktivieren von SSL-Protokollen und Verschlüsselungssammlungen finden Sie unter Verwalten von SSL-Protokollen in AD FS.

• Wenn der Proxy für AD FS-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 AD FS-Eigenschaft ExtendedProtectionTokenCheck aktiviert ist (die Standardeinstellung in AD FS), 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 AD FS SSL-Zertifikat haben. Es muss die gleichen Anforderungen erfüllen.

AD FS 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 AD FS mit Azure AD verwendet wird, senden Anwendungen normalerweise den Parameter prompt=login an Azure AD. Azure AD übersetzt diesen Parameter standardmäßig, um eine neue kennwortbasierte Anmeldung bei AD FS anzufordern. Dieses Szenario ist der häufigste Grund dafür, dass eine Kennwortanmeldung für AD FS in Ihrem Netzwerk angezeigt oder eine Option zur Anmeldung mit Ihrem Zertifikat nicht angezeigt wird. Dieses Problem kann leicht behoben werden, indem Sie in Azure AD 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.

Verwenden Sie zum Ändern des AD FS-Dienstkontos das PowerShell-Modul „Dienstkonto“ der AD FS-Toolbox. Anweisungen dazu finden Sie unter Ändern des AD FS-Dienstkontos.

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

Wenn Sie über keine Zugriffssteuerungsrichtlinien, die auf dem Gerät in AD FS basieren, oder über keine Windows Hello for Business-Zertifikatregistrierung mithilfe von AD FS verfügen, können Sie BrowserSsoEnabled deaktivieren. BrowserSsoEnabled ermöglicht es AD FS, ein PRT (Primary Refresh Token, Primäres Aktualisierungstoken) vom Client zu erfassen, das Geräteinformationen enthält. Ohne dieses Token funktioniert Geräteauthentifizierung von AD FS nicht auf Windows 10-Geräten.

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 AD FS: 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 90 Tage, gesteuert durch PSSOLifeTimeMins. (Vorausgesetzt, das Gerät wird mindestens alle 14 Tage 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 Standardwert 24 Stunden. Dieser Standardwert kann über KMSILifetimeMins konfiguriert werden.

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

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

• id_token: Identisch mit access_token.

AD FS unterstützt keine impliziten Flows für vertrauliche Clients. Clientauthentifizierung ist nur für den Tokenendpunkt aktiviert, und AD FS stellt ohne Clientauthentifizierung kein Zugriffstoken aus. Wenn ein vertraulicher Client ein Zugriffstoken und auch eine Benutzerauthentifizierung erfordert, muss der Autorisierungscodeflow verwendet werden.

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 AD FS-Endpunkte für den Webauthentifizierungsdatenverkehr werden ausschließlich über HTTPS geöffnet. Daher mindert AD FS die Bedrohungen, die durch den HSTS-Richtlinienmechanismus entstehen. (Entwurfsbedingt erfolgt keine Herabstufung auf HTTP, da es keine Listener in HTTP gibt.) AD FS 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 AD FS-Server, da HSTS nicht herabgestuft werden kann. AD FS-Server erfüllen Complianceanforderungen, weil sie kein HTTP verwenden können und weil Cookies als sicher gekennzeichnet sind.

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

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 AD FS 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 AD FS 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 AD FS 2016 (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 Ebene 3 weitergeleitet wird (IP-Adresse wird beibehalten), sollte die eingehende Client-IP-Adresse dem Header nach Branchenstandard X-Forwarded-For hinzufügen.

Der AD FS-Benutzerinformationsendpunkt gibt – wie in den OpenID-Standards festgelegt – immer den Antragstelleranspruch zurück. AD FS unterstützt keine zusätzlichen Ansprüche, die über den UserInfo-Endpunkt angefordert werden. Wenn Sie weitere Ansprüche in einem ID-Token benötigen, finden Sie weitere Informationen unter Benutzerdefinierte ID-Token in AD FS.

Diese Gruppe wird nur erstellt, wenn ein Windows Server 2016-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 Azure AD 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 AD FS-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 AD FS übergeben wird.

Sie können dieses Problem beheben, indem Sie die AD FS- 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 AD FS- 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.

AD FS unterstützt keine HEAD-Anforderungen. Anwendungen sollten keine HEAD-Anforderungen für AD FS-Endpunkte verwenden. Die Verwendung dieser Anforderungen kann zu HTTP-Fehlerantworten führen, die unerwartet oder verzögert sind. Außerdem werden möglicherweise im AD FS-Ereignisprotokoll unerwartete Fehlerereignisse angezeigt.

Es wird kein Aktualisierungstoken ausgestellt, wenn das von IdP ausgegebene Token weniger als eine Stunde gültig ist. Wenn Sie sicherstellen möchten, dass ein Aktualisierungstoken ausgestellt wird, verlängern Sie die Gültigkeit des vom IdP ausgestellten Tokens auf mehr als eine Stunde.

Die RP-Tokenverschlüsselung ist auf AES256 festgelegt. Sie können sie nicht in einen anderen Wert ändern.

AD FS-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 AD FS-Servern müssen Sie Netsh verwenden. Führen Sie die folgenden Schritte aus:

1. Wählen Sie eine Teilmenge der AD FS 2016-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 AD FS-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 AD FS-Server erneut in der Produktionsumgebung.

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

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

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

In AD FS 2016 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

Nach einem Upgrade auf Windows Server 2019 wird die Konfigurationsversion des Webanwendungsproxys weiterhin als Windows Server 2016 angezeigt. Der Webanwendungsproxy verfügt nicht über neue versionsspezifische Features für Windows Server 2019. Wenn die Ebene des Farmverhaltens für AD FS erhöht wurde, wird der Webanwendungsproxy weiterhin als Windows Server 2016 angezeigt. Dieses Verhalten ist beabsichtigt.

Wenn ESL aktiviert ist, verfolgt AD FS 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 1 GB pro 100.000 Benutzer schätzen.

Wenn die AD FS-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 5 GB 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 1 GB 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 AD FS versucht, alle Gesamtstrukturen in einer Kette vertrauenswürdiger Gesamtstrukturen zu durchlaufen und Verbindungen über alle Gesamtstrukturen hinweg herzustellen. Angenommen, AD FS-Gesamtstruktur A und Gesamtstruktur B sind vertrauenswürdig, und Gesamtstruktur B und Gesamtstruktur C sind vertrauenswürdig. AD FS listet alle drei Gesamtstrukturen auf und versucht, eine Vertrauensstellung zwischen Gesamtstruktur A und Gesamtstruktur C zu finden. Wenn Benutzer aus der nicht erfolgreichen Gesamtstruktur durch AD FS authentifiziert werden sollen, sollten Sie eine Vertrauensstellung zwischen der AD FS-Gesamtstruktur und der nicht erfolgreichen Gesamtstruktur einrichten. Wenn Benutzer aus nicht erfolgreichen Gesamtstruktur nicht durch AD FS 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 AD FS 2016 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 Version 2016 nicht erkannt.

AD FS 2019 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 AD FS-Farm auf die Ebene „Windows Server 2019-Farmverhalten“.