Neuerungen in Active Directory-Verbunddienste

Neuerungen in Active Directory-Verbunddienste für Windows Server 2019

In diesem Artikel werden die neuen Änderungen beschrieben, die an Active Directory-Verbunddienste (AD FS) vorgenommen wurden.

Geschützte Anmeldungen

Die folgenden Punkte sind eine kurze Zusammenfassung der Updates für geschützte Anmeldungen, die in Active Directory-Verbunddienste (AD FS) 2019 verfügbar sind:

  • Externe Authentifizierungsanbieter als primäre Authentifizierung: Kund*innen können jetzt Authentifizierungsprodukte von Drittanbietern als ersten Faktor verwenden und müssen Kennwörter nicht als ersten Faktor verfügbar machen. In Fällen, in denen ein externer Authentifizierungsanbieter zwei Faktoren nachweisen kann, besteht MFA-Anspruch.
  • Kennwortauthentifizierung als zusätzliche Authentifizierung: Kund*innen verfügen über eine vollständig unterstützte integrierte Option, um Kennwörter nur als zusätzlichen Faktor zu verwenden, nachdem eine Option ohne Kennwort als erster Faktor verwendet wurde. Diese Option verbessert die Benutzerfreundlichkeit im Vergleich zu AD FS 2016. Dort mussten Kund*innen einen GitHub-Adapter herunterladen, der ohne Anpassungen unterstützt wird.
  • Austauschbares Risikobewertungsmodul: Kund*innen können jetzt eigene Plug-In-Module erstellen, um bestimmte Anforderungstypen während der Vorauthentifizierung zu blockieren. Dieses Features erleichtert die Nutzung von Cloudintelligenz wie etwa Identitätsschutz, um Anmeldungen für riskante Benutzer*innen oder riskante Transaktionen zu blockieren. Weitere Informationen finden Sie unter Erstellen von Plug-Ins mit dem Risikobewertungsmodell von AD FS 2019.
  • ESL-Verbesserungen: Verbessert das ESL-QFE (Quick Fix Engineering) der Version 2016 durch Hinzufügen folgender Funktionen:
    • Ermöglicht es Kund*innen, sich im Überwachungsmodus zu befinden und gleichzeitig durch die „klassische“ Extranetsperrfunktion geschützt zu sein, die ab AD FS 2012R2 verfügbar ist. Derzeit sind 2016-Kunden im Überwachungsmodus nicht geschützt.
    • Aktiviert einen unabhängigen Sperrschwellenwert für bekannte Orte. Dank dieses Features können mehrere Instanzen von Apps, die mit einem gemeinsamen Dienstkonto ausgeführt werden, mit minimalen Auswirkungen einen Rollover für Kennwörter durchführen.

Weitere Sicherheitsverbesserungen

In AD FS 2019 sind folgende Sicherheitsverbesserungen verfügbar:

  • Remote-PowerShell mit Smartcard-Anmeldung: Kund*innen können jetzt mithilfe von Smartcards über PowerShell eine Remoteverbindung mit AD FS herstellen und dies zum Verwalten aller PowerShell-Funktionen verwenden – einschließlich Cmdlets mit mehreren Knoten.
  • Anpassung von HTTP-Headern: Kund*innen können jetzt HTTP-Header anpassen, die im Rahmen von AD FS-Antworten ausgegeben werden – einschließlich folgender Header:
    • HSTS: Dieser Header gibt an, dass AD FS-Endpunkte nur für HTTPS-Endpunkte verwendet werden können (für die Erzwingung durch einen konformen Browser).
    • x-frame-options: Ermöglicht es AD FS-Administrator*innen, bestimmten vertrauenden Seiten das Einbetten von iFrames für interaktive AD FS-Anmeldeseiten zu gestatten. Dieser Header sollte mit Bedacht und nur auf HTTPS-Hosts verwendet werden.
    • Zukünftiger Header: Es können auch andere zukünftige Header konfiguriert werden.

Weitere Informationen finden Sie unter Anpassen der HTTP-Sicherheitsantwortheader mit AD FS 2019.

Authentifizierungs-/Richtlinienfunktionen

In AD FS 2019 sind die folgenden Authentifizierungs-/Richtlinienfunktionen verfügbar:

  • Angeben der Authentifizierungsmethode für andere Authentifizierung pro vertrauender Seite: Kund*innen können jetzt Anspruchsregeln verwenden, um zu entscheiden, welcher andere Authentifizierungsanbieter für die zusätzliche Authentifizierung aufgerufen werden soll. Dieses Feature ist in zwei Anwendungsfällen nützlich:
    • Kund*innen wechseln zu einem anderen Authentifizierungsanbieter. Wenn diese Kund*innen Benutzer*innen in einen neueren Authentifizierungsanbieter integrieren, können sie Gruppen verwenden, um zu steuern, welcher zusätzliche Authentifizierungsanbieter aufgerufen wird.
    • Kund*innen müssen für bestimmte Anwendungen einen bestimmten zusätzlichen Authentifizierungsanbieter (z. B. ein Zertifikat) verwenden.
  • Beschränken der auf Transport Layer Security (TLS) basierenden Geräteauthentifizierung auf Anwendungen, die sie erfordern: Kunden können jetzt clientseitige TLS-basierte Geräteauthentifizierungen auf Anwendungen beschränken, die gerätebasierten bedingten Zugriff verwenden. Diese Option verhindert unerwünschte Eingabeaufforderungen für die Geräteauthentifizierung (oder Fehler, wenn die Clientanwendung diese nicht verarbeiten kann) für Anwendungen, die keine TLS-basierte Geräteauthentifizierung erfordern.
  • Unterstützung von MFA-Aktualität (Multi-Faktor-Authentifizierung): AD FS unterstützt jetzt die Wiederholung der Anmeldeinformationen des zweiten Faktors auf der Grundlage der Aktualität dieser Anmeldeinformationen. Dank dieses Features können Kund*innen eine erste Transaktion mit zwei Faktoren ausführen und in regelmäßigen Abständen nur den zweiten Faktor anfordern. Dieses Feature ist nur für Anwendungen verfügbar, die einen zusätzlichen Parameter in der Anforderung bereitstellen können, und ist keine konfigurierbare Einstellung in AD FS. Azure AD unterstützt diesen Parameter, wenn Sie „Meine MFA für X Tage speichern“ konfigurieren und in den Vertrauenseinstellungen der Verbunddomäne von Azure AD das Flag „supportsMFA“ auf „true“ festlegen.

Verbesserungen für einmaliges Anmelden

In AD FS 2019 wurden folgende Verbesserungen für das einmalige Anmelden vorgenommen:

  • Paginierte Benutzerumgebung mit zentriertem Design: In AD FS wird jetzt eine paginierte Anmeldeseite verwendet, sodass AD FS eine Überprüfung durchführen und eine reibungslosere Anmeldung bieten kann. In AD FS wird jetzt eine zentrierte Benutzeroberfläche (anstelle der rechten Seite des Bildschirms) verwendet. Möglicherweise benötigen Sie ein neueres Logo und neuere Hintergrundbilder, die an diese Umgebung angepasst sind. Diese Änderung spiegelt auch die in Azure AD gebotene Funktionalität wider.
  • Fehlerkorrektur: Persistenter SSO-Zustand für Windows 10-Geräte bei der Authentifizierung mit primärem Aktualisierungstoken (Primary Refresh Token, PRT): Durch diese Änderung wird ein Problem behoben, das dazu führte, dass der MFA-Zustand bei Verwendung der PRT-Authentifizierung für Windows 10-Geräte nicht persistent war. Dieses Problem führte dazu, dass Endbenutzer häufig zur Eingabe von Anmeldeinformationen des zweiten Faktors (MFA) aufgefordert wurden. Durch die Fehlerbehebung wird auch die Benutzererfahrung konsistent, wenn die Geräteauthentifizierung erfolgreich über Client-TLS und über den PRT-Mechanismus durchgeführt wird.

Unterstützung für das Erstellen von modernen branchenspezifischen Apps

In AD FS 2019 wurde die folgende Unterstützung für die Erstellung moderner branchenspezifischer Apps hinzugefügt:

  • OAuth-Geräteflow/-Profil: AD FS unterstützt jetzt das OAuth-Geräteflowprofil für die Anmeldung auf Geräten, die nicht über einen Benutzeroberflächenbereich verfügen, der umfangreiche Anmeldefunktionen unterstützt. Dank dieses Features können Benutzer*innen die Anmeldung auf einem anderen Gerät durchführen. Diese Funktion ist für Azure CLI in Azure Stack erforderlich und kann auch in anderen Fällen verwendet werden.
  • Entfernung des Ressourcenparameters: In AD FS muss jetzt kein Ressourcenparameter mehr angegeben werden. Dies steht mit den aktuellen OAuth-Spezifikationen im Einklang. Clients können jetzt zusätzlich zu den angeforderten Berechtigungen den Bezeichner der Vertrauensstellung der vertrauenden Seite als Bereichsparameter angeben.
  • CORS-Header (Cross-Origin Resource Sharing) in AD FS-Antworten: Kund*innen können jetzt Single-Page-Anwendungen erstellen, mit denen clientseitige JavaScript-Bibliotheken die Signatur des ID-Tokens (id_token) überprüfen können, indem sie die Signaturschlüssel aus dem OIDC-Discovery-Dokument (OpenID Connect) in AD FS abfragen.
  • PKCE-Unterstützung (Proof Key for Code Exchange): AD FS bietet jetzt PKCE-Unterstützung, um einen sicheren Authentifizierungscodeflow in OAuth zu ermöglichen. Dieses Feature fügt dem Flow eine zusätzliche Sicherheitsebene hinzu, um den Code vor Hijacking zu schützen und zu verhindern, dass er von einem anderen Client wiedergegeben werden kann.
  • Programmfehlerbehebung: Senden von x5t- und kid-Anspruch: Hierbei handelt es sich um eine kleinere Programmfehlerbehebung. AD FS sendet jetzt zusätzlich den kid-Anspruch, um den Schlüssel-ID-Hinweis zum Überprüfen der Signatur anzugeben. Zuvor wurde von AD FS nur der x5t-Anspruch gesendet.

Verbesserungen der Unterstützbarkeit

Die folgenden Verbesserungen bei der Unterstützbarkeit sind jetzt Teil von AD FS 2019:

  • Senden von Fehlerdetails an AD FS-Administrator*innen: Dadurch können Administrator*innen Endbenutzer*innen so konfigurieren, dass Debugprotokolle zu einem Fehler bei der Endbenutzerauthentifizierung gesendet werden, die zur einfachen Nutzung als ZIP-Datei gespeichert werden. Administrator*innen können auch eine SMTP-Verbindung (Simple Mail Transfer-Protokoll) konfigurieren, um die ZIP-Datei automatisch an ein E-Mail-Konto für die Selektierung zu senden oder automatisch ein Ticket auf der Grundlage der E-Mail zu erstellen.

Bereitstellungsaktualisierungen

Die folgenden Bereitstellungsaktualisierungen sind jetzt in AD FS 2019 enthalten:

  • Farmverhaltensebene 2019: Genau wie in AD FS 2016 gibt es eine neue Version der Farmverhaltensebene, die zum Aktivieren von neuen Funktionen erforderlich ist, die weiter unten in diesem Artikel erläutert werden. Dieses Update ermöglicht einen Wechsel von:
    • AD FS unter Windows Server 2012 R2 zu AD FS unter Windows Server 2016
    • AD FS unter Windows Server 2016 zu AD FS unter Windows Server 2019

SAML-Updates

Das folgende SAML-Update (Security Assertion Markup Language) ist in AD FS 2019 enthalten:

  • Programmfehlerbehebung: Beheben von Fehlern im aggregierten Verbund: Es gibt zahlreiche Fehlerbehebungen für die Unterstützung des aggregierten Verbunds (z. B. InCommon). In folgenden Bereichen wurden Korrekturen vorgenommen:
    • Verbesserte Skalierung für eine große Anzahl von Entitäten im Dokument für aggregierte Verbundmetadaten. Zuvor ist bei der Skalierung ein Fehler vom Typ „ADMIN0017“ aufgetreten.
    • Abfragen mit dem ScopeGroupID-Parameter über das PowerShell-Cmdlet Get-AdfsRelyingPartyTrustsGroup
    • Behandeln von Fehlerbedingungen im Zusammenhang mit einer doppelten Entitäts-ID (entityID)

Azure AD-Stilressourcenspezifikation im Bereichsparameter

Zuvor war es in AD FS erforderlich, dass die gewünschte Ressource und der gewünschte Bereich in einem separaten Parameter in jeder Authentifizierungsanforderung enthalten waren. Die folgende OAuth-Anforderung zeigt eine typische Anforderung, die von Benutzer*innen gesendet wird:

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Bei AD FS unter Windows Server 2019 kann jetzt der im Bereichsparameter eingebettete Ressourcenwert übergeben werden. Diese Änderung ist konsistent mit einer Authentifizierung über Azure AD.

Der Bereichsparameter kann jetzt als eine durch Leerzeichen getrennte Liste organisiert werden, wobei jeder Eintrag als Ressource/Bereich strukturiert ist.

Hinweis

In der Authentifizierungsanforderung kann nur eine Ressource angegeben werden. Wenn in der Anforderung mehrere Ressourcen enthalten sind, gibt AD FS einen Fehler zurück, und die Authentifizierung ist nicht erfolgreich.

Proof Key for Code Exchange-Unterstützung (PKCE-Unterstützung) für OAuth

Öffentliche OAuth-Clients die den Authorization Code Grant-Typ verwenden, sind anfällig für den Angriff zum Abfangen des Autorisierungscodes. Der Angriff ist in RFC 7636 gut beschrieben. Um diesen Angriff zu entschärfen, unterstützt AD FS unter Windows Server 2019 die Erweiterung „Proof Key for Code Exchange“ (PKCE) für den OAuth Authorization Code Grant-Datenfluss.

Um die PKCE-Unterstützung zu nutzen, fügt diese Spezifikation den OAuth 2.0-Autorisierungs- und Zugriffstokenanforderungen weitere Parameter hinzu.

Diagram of the PKCE relationship between the client and AD FS 2019.

A. Der Client erstellt ein Geheimnis mit dem Namen „code_verifier“, zeichnet es auf und leitet eine transformierte Version ab: t(code_verifier). Diese wird auch als „code_challenge“ bezeichnet. Das Geheimnis wird zusammen mit der Transformationsmethode „t_m“ in der OAuth 2.0-Autorisierungsanforderung gesendet.

B. Der Autorisierungsendpunkt antwortet wie gewohnt, zeichnet jedoch „t(code_verifier)“ und die Transformationsmethode auf.

C. Der Client sendet dann den Autorisierungscode in der Zugriffstokenanforderung wie gewohnt, schließt jedoch das unter (A) generierte Geheimnis „code_verifier“ ein.

D. AD FS transformiert den geheimen Schlüssel „code_verifier“ und vergleicht ihn mit „t(code_verifier)“ aus (B). Wenn sie nicht übereinstimmen, wird der Zugriff verweigert.

Auswählen zusätzlicher Authentifizierungsanbieter in 2019

AD FS unterstützt bereits das Auslösen einer zusätzlichen Authentifizierung basierend auf einer Anspruchsregelrichtlinie. Diese Richtlinien können für einen bestimmten RP oder auf globaler Ebene festgelegt werden. Zusätzliche Authentifizierungsrichtlinien für eine bestimmte vertrauende Seite können mithilfe des Cmdlets Set-AdfsRelyingPartyTrust durch Übergeben des Parameters AdditionalAuthenticationRules oder des Parameters AdditionalAuthenticationRulesFile festgelegt werden. Um sie global festzulegen, können Administrator*innen das Cmdlet Set-AdfsAdditionalAuthenticationRule verwenden.

Beispielsweise können Administrator*innen ab 2012 R2 bereits die folgende Regel schreiben, um eine zusätzliche Authentifizierung anzufordern, wenn die Anforderung aus dem Extranet stammt:

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );' 

In 2019 können Kund*innen jetzt Anspruchsregeln verwenden, um zu entscheiden, welcher andere Authentifizierungsanbieter für die zusätzliche Authentifizierung aufgerufen werden soll. Dieses Feature ist in zwei Szenarien nützlich:

Kund*innen wechseln zu einem anderen Authentifizierungsanbieter. Wenn diese Kund*innen Benutzer*innen in einen neueren Authentifizierungsanbieter integrieren, können sie Gruppen verwenden, um zu steuern, welcher zusätzliche Authentifizierungsanbieter aufgerufen wird.

Kund*innen benötigen einen bestimmten zusätzlichen Authentifizierungsanbieter (z. B. ein Zertifikat) für bestimmte Anwendungen, aber eine andere Methode (Multi-Faktor-Authentifizierung von Azure AD) für andere Anwendungen.

Diese Konfiguration kann erreicht werden, indem der Anspruch https://schemas.microsoft.com/claims/authnmethodsproviders von anderen Authentifizierungsrichtlinien ausgegeben wird. Der Wert dieses Anspruchs sollte der Name des Authentifizierungsanbieters sein.

In 2019 kann die vorherige Anspruchsregel jetzt geändert werden, um Authentifizierungsanbieter basierend auf ihren Szenarien auszuwählen.

Wechseln zu einem anderen Authentifizierungsanbieter: Sie können die oben erwähnte Regel ändern, um die Multi-Faktor-Authentifizierung von Azure AD für Benutzer*innen auszuwählen, die der Gruppen-SID S-1-5-21-608905689-872870963-3921916988-12345 angehören. Diese Änderung kann beispielsweise für eine nach Unternehmen verwaltete Gruppe genutzt werden, die die Benutzer*innen nachverfolgt, die sich für die Multi-Faktor-Authentifizierung von Azure AD registriert haben. Diese Änderung funktioniert auch für die restlichen Benutzer*innen, für die ein Administrator oder eine Administratorin die Verwendung der Zertifikatauthentifizierung vorschreiben möchte.

'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); 

not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’ 

Das folgende Beispiel zeigt, wie zwei verschiedene Authentifizierungsanbieter für zwei verschiedene Anwendungen festgelegt werden:

Konfigurieren Sie Anwendung A so, dass sie die Multi-Faktor-Authentifizierung von Azure AD als zusätzlichen Authentifizierungsanbieter verwendet:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

Konfigurieren Sie Anwendung B so, dass sie ein Zertifikat als zusätzlichen Authentifizierungsanbieter verwendet:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

Administrator*innen können mithilfe von Regeln auch mehr als einen zusätzlichen Authentifizierungsanbieter zulassen. In diesem Fall zeigt AD FS die ausgegebenen Authentifizierungsmethodenanbieter an, und Benutzer*innen können beliebige davon auswählen. Um mehrere zusätzliche Authentifizierungsanbieter zuzulassen, müssen mehrere Ansprüche ausgegeben werden: https://schemas.microsoft.com/claims/authnmethodsproviders.

Wenn die Anspruchsauswertung keinen der Authentifizierungsanbieter zurückgibt, werden von AD FS wieder alle zusätzlichen Authentifizierungsanbieter angezeigt, die vom Administrator bzw. von der Administratorin in AD FS konfiguriert wurden. Die Benutzer*innen müssen dann den entsprechenden Authentifizierungsanbieter auswählen.

Um alle zulässigen zusätzlichen Authentifizierungsanbieter abzurufen, können Administrator*innen das Cmdlet „(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider“ verwenden. Der Wert des Anspruchs https://schemas.microsoft.com/claims/authnmethodsproviders muss einer der Anbieternamen sein, die vom zuvor erwähnten Cmdlet zurückgegeben werden.

Es gibt keine Unterstützung für das Auslösen bestimmter zusätzlicher Authentifizierungsanbieter, wenn die vertrauende Seite Zugriffssteuerungsrichtlinien in Windows Server 2016 AD FS verwendet. Wenn für eine Anwendung keine Zugriffssteuerungsrichtlinie mehr verwendet werden soll, kopiert AD FS die entsprechende Richtlinie aus der Zugriffssteuerungsrichtlinie in „AdditionalAuthenticationRules“ und „IssuanceAuthorizationRules“. Wenn also ein Administrator oder eine Administratorin einen bestimmten Authentifizierungsanbieter verwenden möchte, kann er bzw. sie sich dazu entscheiden, keine Zugriffssteuerungsrichtlinie mehr zu verwenden, und „AdditionalAuthenticationRules“ so ändern, dass ein spezifischer Authentifizierungsanbieter verwendet wird.

Häufig gestellte Fragen

Wie behebe ich den folgenden Fehler in den AD FS-Administratorereignisprotokollen: „Es wurde eine ungültige OAuth-Anforderung empfangen. Dem Client „NAME“ ist der Zugriff auf die Ressource mit dem Bereich „ugs“ untersagt.“?

Führen Sie die folgenden Schritte aus, um das Problem zu behandeln:

  1. Starte die AD FS-Verwaltungskonsole. Navigieren Sie zu Dienste > Bereichsbeschreibungen.
  2. Wählen Sie unter Bereichsbeschreibungen weitere Optionen und anschließend Bereichsbeschreibung hinzufügen aus.
  3. Geben Sie unter „Name“ den Namen „ugs“ ein, und wählen Sie Anwenden > OK aus.
  4. Starten Sie PowerShell als Administrator*in.
  5. Führen Sie den Befehl Get-AdfsApplicationPermission aus. Suchen Sie nach ScopeNames :{openid, aza} mit ClientRoleIdentifier. Notieren Sie sich den Namen in ObjectIdentifier.
  6. Führen Sie den Befehl Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' aus.
  7. Starten Sie den AD FS-Dienst neu.
  8. Führen Sie auf dem Client einen Neustart des Clients durch. Sie sollten dazu aufgefordert werden, Windows Hello for Business (WHFB) zu konfigurieren.
  9. Wird das Konfigurationsfenster nicht angezeigt, müssen Sie Ablaufverfolgungsprotokolle sammeln und weitere Problembehandlungsschritte ausführen.

Kann ich einen Ressourcenwert als Teil des Bereichswerts übergeben (wie bei Anforderungen für Azure AD)?

Bei AD FS unter Windows Server 2019 kann jetzt der im Bereichsparameter eingebettete Ressourcenwert übergeben werden. Der Bereichsparameter kann jetzt als eine durch Leerzeichen getrennte Liste organisiert werden, wobei jeder Eintrag als Ressource/Bereich strukturiert ist. Beispiel: <create a valid sample request>

Unterstützt AD FS die PKCE-Erweiterung?

AD FS unter Windows Server 2019 unterstützt PKCE (Proof Key for Code Exchange) für den Flow zur Gewährung von OAuth-Autorisierungscodes.

Neuerungen in Active Directory-Verbunddienste für Windows Server 2016

Informationen zu früheren Versionen von AD FS finden Sie in den folgenden Artikeln: AD FS in Windows Server 2012 oder 2012 R2 und AD FS 2.0

AD FS bietet Zugriffssteuerung und einmaliges Anmelden für eine Vielzahl von Anwendungen – einschließlich Office 365, cloudbasierter SaaS-Anwendungen und Anwendungen im Unternehmensnetzwerk.

  • Der IT-Organisation ermöglicht AD FS das Bereitstellen von Anmeldung und Zugriffssteuerung sowohl für moderne Anwendungen als auch für Legacyanwendungen auf beliebigen Computern basierend auf den gleichen Anmeldeinformationen und Richtlinien.
  • Benutzer*innen ermöglicht AD FS eine nahtlose Anmeldung mit den gleichen vertrauten Kontoanmeldeinformationen.
  • Dem Entwickler bietet AD FS eine einfache Möglichkeit zum Authentifizieren von Benutzern, deren Identitäten im Organisationsverzeichnis gespeichert sind, sodass du dich auf die Anwendung konzentrieren kannst und dich nicht mit der Authentifizierung oder Identität befassen musst.

Beseitigen von Kennwörtern aus dem Extranet

AD FS 2016 bietet drei neue Optionen für die Anmeldung ohne Kennwörter, sodass Organisationen das Risiko einer Netzwerkgefährdung durch über Phishing erlangte, kompromittierte oder gestohlene Kennwörter vermeiden können.

Anmelden mit Multi-Faktor-Authentifizierung von Azure Active Directory

AD FS 2016 basiert auf den MFA-Funktionen (Multi-Faktor-Authentifizierung) von AD FS unter Windows Server 2012 R2. Sie haben jetzt die Möglichkeit, eine Anmeldung mit lediglich einem Code der Multi-Faktor-Authentifizierung von Azure AD zuzulassen – ohne vorherige Eingabe eines Benutzernamens und eines Kennworts.

  • Wenn die Multi-Faktor-Authentifizierung von Azure AD die primäre Authentifizierungsmethode ist, werden Benutzer*innen zur Eingabe des Benutzernamens und des OTP-Codes aus der Azure Authenticator-App aufgefordert.
  • Wenn die Multi-Faktor-Authentifizierung von Azure AD als sekundäre oder zusätzliche Authentifizierungsmethode verwendet wird, geben Benutzer*innen Anmeldeinformationen für die primäre Authentifizierung an. Sie können sich per integrierter Windows-Authentifizierung, mit Benutzername und Kennwort, per Smartcard oder mit einem Benutzer- oder Gerätezertifikat anmelden. Anschließend wird eine Aufforderung zur text-, sprach- oder OTP-basierten Anmeldung per Multi-Faktor-Authentifizierung von Azure AD angezeigt.
  • Mit dem neuen integrierten Adapter für die Multi-Faktor-Authentifizierung von Azure AD ist die Einrichtung und Konfiguration der Multi-Faktor-Authentifizierung von Azure AD mit AD FS so einfach wie nie.
  • Organisationen können die Multi-Faktor-Authentifizierung von Azure AD nutzen, ohne dass dafür ein entsprechender lokaler Server erforderlich ist.
  • Die Multi-Faktor-Authentifizierung von Azure AD kann für das Intranet oder Extranet oder als Teil einer beliebigen Zugriffssteuerungsrichtlinie konfiguriert werden.

Weitere Informationen zur Multi-Faktor-Authentifizierung von Azure AD mit AD FS finden Sie unter Konfigurieren der Azure AD-Multi-Faktor-Authentifizierung als Authentifizierungsanbieter mithilfe von AD FS.

Kennwortloser Zugriff über konforme Geräte

AD FS 2016 baut auf früheren Geräteregistrierungsfunktionen auf, um die Anmeldung und Zugriffssteuerung basierend auf dem Konformitätsstatus der Geräte zu ermöglichen. Benutzer*innen können sich mit den Geräteanmeldeinformationen anmelden, und die Konformität wird bei Änderungen der Geräteattribute erneut ausgewertet, sodass die Erzwingung von Richtlinien stets sichergestellt ist. Dank dieses Features können Richtlinien wie die folgenden angewendet werden:

  • Zugriff nur von verwalteten und/oder konformen Geräten zulassen
  • Extranetzugriff nur von verwalteten und/oder konformen Geräten zulassen
  • Multi-Faktor-Authentifizierung für nicht verwaltete oder nicht konforme Computer erforderlich machen

AD FS bietet die lokale Komponente der Richtlinien für bedingten Zugriff in einem Hybridszenario. Wenn du Geräte bei Azure AD für den bedingten Zugriff auf Cloudressourcen registrierst, kann die Geräteidentität auch für AD FS-Richtlinien verwendet werden.

Diagram of a hybrid solution and the relationships between users and on-premises active directory.

Weitere Informationen zur Verwendung von gerätebasiertem bedingtem Zugriff in der Cloud finden Sie unter Was ist bedingter Zugriff?.

Weitere Informationen zum Verwenden des gerätebasierten bedingten Zugriffs mit AD FS:

Anmelden mit Windows Hello for Business

Hinweis

Derzeit werden Google Chrome und die neuen Chromium-basierten Microsoft Edge-Open-Source-Projektbrowser nicht für browserbasiertes einmaliges Anmelden (Single-Sign On, SSO) mit Windows Hello for Business unterstützt. Verwende Internet Explorer oder eine ältere Version von Microsoft Edge.

Auf Windows 10-Geräten werden Windows Hello und Windows Hello for Business eingeführt, wobei Benutzerkennwörter durch sichere gerätegebundene Benutzeranmeldeinformationen ersetzt werden, die durch eine Benutzergeste (eine PIN, eine biometrische Geste wie ein Fingerabdruck oder Gesichtserkennung) geschützt sind. AD FS 2016 unterstützt diese neuen Windows 10-Funktionen, sodass Benutzer*innen sich über ein Intranet oder Extranet bei AD FS-Anwendungen anmelden können, ohne ein Kennwort anzugeben.

Weitere Informationen zur Verwendung von Windows Hello for Business in Ihrer Organisation finden Sie in der Übersicht über die Voraussetzungen für die Windows Hello for Business-Bereitstellung.

Sicherer Zugriff auf Anwendungen

Die folgenden Änderungen wirken sich auf den sicheren Zugriff auf Anwendungen in AD FS aus:

Moderne Authentifizierung

AD FS 2016 unterstützt die neuesten modernen Protokolle, die mehr Benutzerfreundlichkeit für Windows 10-Geräte und -Apps sowie für die neuesten iOS- und Android-Geräte und -Apps bieten.

Weitere Informationen finden Sie unter AD FS OpenID Connect-/OAuth-Flows und Anwendungsszenarien.

Konfigurieren von Zugriffssteuerungsrichtlinien ohne Kenntnis der Anspruchsregelsprache

Bislang mussten AD FS-Administrator*innen Richtlinien mithilfe der AD FS-Anspruchsregelsprache konfigurieren, wodurch das Konfigurieren und Verwalten von Richtlinien erschwert wurde. Bei Zugriffssteuerungsrichtlinien können Administratoren integrierte Vorlagen verwenden, um allgemeine Richtlinien anzuwenden, wie beispielsweise:

  • Nur Intranetzugriff zulassen
  • Alle Benutzer*innen zulassen und Verwendung von MFA für Extranet erforderlich machen
  • Alle Benutzer*innen zulassen und Verwendung von MFA für eine bestimmte Gruppe erforderlich machen

Die Vorlagen können mithilfe eines assistentengesteuerten Prozesses problemlos angepasst werden, um Ausnahmen oder zusätzliche Richtlinienregeln hinzuzufügen. Außerdem können sie auf eine oder mehrere Anwendungen angewendet werden, um eine konsistente Richtlinienerzwingung zu erreichen.

Weitere Informationen finden Sie unter Zugriffssteuerungsrichtlinien in Windows Server 2016 AD FS.

Aktivieren der Anmeldung mit Nicht-AD-LDAP-Verzeichnissen

Viele Organisationen verwenden eine Kombination aus Active Directory-Verzeichnissen und Verzeichnissen von Drittanbietern. Durch die hinzugefügte AD FS-Unterstützung für die Authentifizierung von Benutzer*innen, die in LDAP v3-konformen Verzeichnissen gespeichert sind, kann AD FS jetzt für Folgendes verwendet werden:

  • Benutzer*innen in LDAP v3-konformen Verzeichnissen von Drittanbietern
  • Benutzer*innen in Active Directory-Gesamtstrukturen, für die keine bidirektionale Active Directory-Vertrauensstellung konfiguriert ist
  • Benutzer*innen in Active Directory Lightweight Directory Services (AD LDS)

Weitere Informationen finden Sie unter Configure AD FS to authenticate users stored in LDAP directories.

Bessere Anmeldeoberfläche

Die folgenden Änderungen verbessern die Anmeldung für AD FS:

Anpassen der Anmeldeoberfläche für AD FS-Anwendungen

In AD FS für Windows Server 2012 R2 wurde zuvor eine gemeinsame Anmeldeoberfläche für alle Anwendungen der vertrauenden Seite bereitgestellt, mit der Möglichkeit, eine Teilmenge von textbasierten Inhalten pro Anwendung anzupassen. Unter Windows Server 2016 kannst du nicht nur die Meldungen, sondern auch die Bilder, das Logo und das Webdesign pro Anwendung anpassen. Darüber hinaus können Sie neue, benutzerdefinierte Webdesigns erstellen und diese pro vertrauender Seite anwenden.

Weitere Informationen finden Sie unter AD FS: Anpassung der Benutzeranmeldung.

Verwaltbarkeit und operative Erweiterungen

Im folgenden Abschnitt werden die verbesserten operativen Szenarien beschrieben, die in Active Directory-Verbunddienste (AD FS) für Windows Server 2016 eingeführt werden.

Optimierte Überwachung für eine einfachere administrative Verwaltung

In AD FS für Windows Server 2012 R2 wurden zahlreiche Überwachungsereignisse für eine einzelne Anforderung generiert, und die relevanten Informationen zu einer Anmelde- oder Tokenausstellungsaktivität waren entweder nicht vorhanden oder auf mehrere Überwachungsereignisse verteilt. Die AD FS-Überwachungsereignisse sind aufgrund ihrer Ausführlichkeit standardmäßig deaktiviert. Mit der Veröffentlichung von AD FS 2016 ist die Überwachung optimiert und weniger ausführlich.

Weitere Informationen finden Sie unter Überwachung von Erweiterungen für AD FS unter Windows Server 2016.

Verbesserte Interoperabilität mit SAML 2.0 für die Teilnahme an Verbünden

AD FS 2016 bietet eine bessere Unterstützung des SAML-Protokolls – einschließlich Unterstützung für das Importieren von Vertrauensstellungen basierend auf Metadaten, die mehrere Entitäten enthalten. Dank dieser Änderung kann AD FS für die Teilnahme an Verbünden wie der InCommon Federation und anderen Implementierungen konfiguriert werden, die dem eGov 2.0-Standard entsprechen.

Weitere Informationen finden Sie unter Verbesserte Interoperabilität mit SAML 2.0.

Vereinfachte Kennwortverwaltung für Microsoft 365-Verbundbenutzer*innen

Du kannst Active Directory Federation Services (AD FS) so konfigurieren, dass Ansprüche beim Kennwortablauf an die Vertrauensstellungen der vertrauenden Seite (Anwendungen) gesendet werden, die durch AD FS geschützt sind. Wie diese Ansprüche verwendet werden, hängt von der jeweiligen Anwendung ab. Beispiel: Bei Office 365 als vertrauende Seite werden Updates in Exchange und Outlook implementiert, damit Verbundbenutzer über ihre bald ablaufenden Kennwörter benachrichtigt werden.

Weitere Informationen finden Sie unter Configure AD FS to Send Password Expiry Claims (Konfigurieren von AD FS zum Senden von Ansprüchen beim Kennwortablauf).

Einfachere Umstellung von AD FS für Windows Server 2012 R2 auf AD FS für Windows Server 2016

Bisher erforderte die Migration zu einer neuen Version von AD FS das Exportieren der Konfiguration aus der alten Farm und das Importieren in eine ganz neue parallele Farm.

Die Umstellung von AD FS unter Windows Server 2012 R2 auf AD FS unter Windows Server 2016 ist jetzt einfacher. Fügen Sie einer Windows Server 2012 R2-Farm einen neuen Windows Server 2016-Server hinzu. Die Farm agiert dann auf der Verhaltensebene der Windows Server 2012 R2-Farm. Ihr Server sieht jetzt wie eine Windows Server 2012 R2-Farm aus und verhält sich auch so.

Füge der Farm dann neue Windows Server 2016-Server hinzu, überprüfe die Funktionalität, und entferne die älteren Server aus dem Lastenausgleich. Sobald auf allen Farmknoten Windows Server 2016 ausgeführt wird, können Sie für die Farmverhaltensebene ein Upgrade auf 2016 durchführen und die neuen Features nutzen.

Weitere Informationen finden Sie unter Durchführen eines Upgrades für eine vorhandene AD FS-Farm mithilfe der internen Windows-Datenbank.