Neuerungen in Active Directory-Verbunddienste

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

Geschützte Anmeldungen

Es folgt eine kurze Zusammenfassung der Aktualisierungen geschützter Anmeldungen, die in AD FS 2019 verfügbar sind:

  • Externe Authentifizierungsanbieter als primäre Authentifizierung: Kunden 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: Kunden verfügen über eine vollständig unterstützte Eingangsoption, um das Kennwort nur für den zusätzlichen Faktor zu verwenden, nachdem eine Option ohne Kennwort als erster Faktor verwendet wurde. Dies verbessert die Benutzerfreundlichkeit von AD FS 2016. Bei dieser Komponente mussten Kunden einen GitHub-Adapter herunterladen, der unverändert unterstützt wird.
  • Austauschbares Risikobewertungsmodul: Kunden können jetzt eigene Plug-In-Module erstellen, um bestimmte Anforderungstypen während der Vorauthentifizierung zu blockieren. Dadurch können Kunden Cloud Intelligence-Lösungen wie Identity Protection (Identitätsschutz) einfacher verwenden, um Anmeldungen für riskante Benutzer oder riskante Transaktionen zu blockieren. Weitere Informationen findest du unter Erstellen von Plug-Ins mit dem Risikobewertungsmodell von AD FS 2019.
  • ESL-Verbesserungen: Durch Hinzufügen der folgenden Funktionen wird das ESL-QFE in 2016 verbessert.
    • Ermöglicht es Kunden, 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. Dadurch können mehrere Instanzen von Apps, die mit einem gemeinsamen Dienstkonto ausgeführt werden, einen Rollover für Kennwörter mit minimalen Auswirkungen durchführen.

Zusätzliche Sicherheitsverbesserungen

In AD FS 2019 sind die folgenden zusätzlichen Sicherheitsverbesserungen verfügbar:

  • Remote PowerShell (PSH) mithilfe von SmartCard-Anmeldung: Kunden können jetzt mithilfe von Smartcards über PSH eine Remoteverbindung mit AD FS herstellen und diese zum Verwalten aller PSH-Funktionen verwenden, einschließlich PSH-Cmdlets mit mehreren Knoten.
  • Anpassung von HTTP-Headern: Kunden können jetzt HTTP-Header anpassen, die bei AD FS-Antworten ausgegeben werden. Dies schließt die folgenden Header ein:
    • HSTS: Dadurch wird vermittelt, dass AD FS-Endpunkte nur für HTTPS-Endpunkte verwendet werden können, damit ein kompatibler Browser erzwungen wird.
    • x-frame-options: Ermöglicht es AD FS-Administratoren, bestimmten vertrauenden Seiten das Einbetten von iFrames für interaktive AD FS-Anmeldeseiten zu gestatten. Dies sollte mit Bedacht und nur auf HTTPS-Hosts erfolgen.
    • Zukünftige Header: Es können auch weitere zukünftige Header konfiguriert werden.

Weitere Informationen findest du unter Anpassen der HTTP-Sicherheitsantwortheader mit AD FS 2019.

Authentifizierungs-/Richtlinienfunktionen

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

  • Authentifizierungsmethode für zusätzliche Authentifizierung pro RP angeben: Kunden können jetzt Anspruchsregeln verwenden, um zu entscheiden, welcher weitere Authentifizierungsanbieter als zusätzlicher Authentifizierungsanbieter aufgerufen werden soll. Dies ist in zwei Anwendungsfällen nützlich.
    • Kunden wechseln von einem zusätzlichen Authentifizierungsanbieter zu einem anderen. Wenn diese Kunden Benutzer in einen neueren Authentifizierungsanbieter integrieren, können sie Gruppen verwenden, um zu steuern, welcher zusätzliche Authentifizierungsanbieter aufgerufen wird.
    • Kunden müssen für bestimmte Anwendungen einen bestimmten zusätzlichen Authentifizierungsanbieter (z. B. ein Zertifikat) verwenden.
  • TLS-basierte Geräteauthentifizierung nur auf Anwendungen beschränken, die sie erfordern: Kunden können jetzt clientseitige TLS-basierte Geräteauthentifizierungen auf Anwendungen beschränken, die gerätebasierten bedingten Zugriff ausführen. Dadurch werden unerwünschte Eingabeaufforderungen zur Geräteauthentifizierung (oder Fehler, wenn die Clientanwendung diese nicht verarbeiten kann) für Anwendungen verhindert, die keine TLS-basierte Geräteauthentifizierung erfordern.
  • Unterstützung der MFA-Aktualität: AD FS unterstützt jetzt die Möglichkeit, 2. Faktor-Anmeldeinformationen basierend auf der Aktualität der Anmeldeinformationen des zweiten Faktors erneut zu verwenden. Dadurch können Kunden eine erste Transaktion mit zwei Faktoren ausführen und nur in regelmäßigen Abständen den zweiten Faktor anfordern. Dies ist nur für Anwendungen verfügbar, die einen zusätzlichen Parameter in der Anforderung bereitstellen können. Dies ist keine konfigurierbare Einstellung in AD FS. Dieser Parameter wird von Azure AD unterstützt, wenn „Meine MFA für X Tage speichern“ konfiguriert ist und in Azure AD das Flag „supportsMFA“ in den Vertrauenseinstellungen der Verbunddomäne auf „true“ festgelegt ist.

Verbesserungen beim einmaligen Anmelden

In AD FS 2019 wurden die folgenden Verbesserungen beim einmaligen Anmelden vorgenommen:

  • Paginierte Benutzeroberfläche mit zentriertem Design: In AD FS wurde die Benutzeroberfläche zu einem paginierten UX-Flow umgestaltet, sodass AD FS eine optimierte Anmeldeoberfläche validieren und bereitstellen kann. In AD FS wird jetzt eine zentrierte Benutzeroberfläche (anstelle der rechten Seite des Bildschirms) verwendet. Möglicherweise benötigst du ein neueres Logo und neuere Hintergrundbilder, die an diese Oberfläche angepasst sind. Dadurch wird auch die in Azure AD angebotene Funktionalität widergespiegelt.
  • Fehlerbehebung: Persistenter SSO-Status für Win10-Geräte bei der PRT-Authentifizierung Dadurch wird ein Problem behoben, bei dem der MFA-Status nicht beibehalten wurde, wenn die PRT-Authentifizierung für Windows 10 wurde. 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 das Erstellen von modernen branchenspezifischen Apps hinzugefügt:

  • OAuth-Geräteflow/-Profil: AD FS unterstützt jetzt das OAuth-Geräteflowprofil zum Ausführen von Anmeldungen auf Geräten, die nicht über einen Benutzeroberflächenbereich verfügen, der umfangreiche Anmeldefunktionen unterstützt. Dadurch können Benutzer 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, der mit den aktuellen OAuth-Spezifikationen übereinstimmt. Clients können jetzt zusätzlich zu den angeforderten Berechtigungen den Bezeichner der Vertrauensstellung der vertrauenden Seite als Bereichsparameter angeben.
  • CORS-Header in AD FS-Antworten: Kunden können jetzt Single-Page-Anwendungen erstellen, mit denen clientseitige JS-Bibliotheken die Signatur des ID-Tokens (id_token) überprüfen können, indem sie die Signaturschlüssel aus dem OIDC-Discovery-Dokument in AD FS abfragen.
  • PKCE-Unterstützung: AD FS pkce-Unterstützung hinzu, um einen sicheren Authentifizierungscodefluss in OAuth zu ermöglichen. Dadurch wird diesem Flow eine zusätzliche Sicherheitsebene hinzugefügt, um den Code vor Hijacking zu schützen und zu verhindern, dass er von einem anderen Client wiedergegeben werden kann.
  • Programmfehlerbehebung: „x5t“- und „kid“-Anspruch senden: 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 hat AD FS dies nur als „x5t“-Anspruch gesendet.

Verbesserungen der Unterstützbarkeit

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

  • Fehlerdetails an AD FS-Administratoren senden: Dadurch können Administratoren Endbenutzer so konfigurieren, dass Debugprotokolle zu einem Fehler bei der Endbenutzerauthentifizierung gesendet werden, die zur einfachen Nutzung als ZIP-Datei gespeichert werden. Administratoren können auch eine SMTP-Verbindung konfigurieren, um die ZIP-Datei automatisch an ein Triage-E-Mail-Konto zu senden oder ein Ticket auf der Grundlage der E-Mail automatisch zu erstellen.

Bereitstellungsaktualisierungen

Die folgenden Bereitstellungsaktualisierungen sind jetzt in AD FS 2019 enthalten:

  • Farmverhaltensebene 2019: Wie in AD FS 2016 gibt es eine neue Version der Farmverhaltensebene, die zum Aktivieren von neuen Funktionen erforderlich ist, die oben erläutert werden. Dies ermöglicht einen Wechsel von:
    • 2012 R2– > 2019
    • 2016 – > 2019

SAML-Updates

In AD FS 2019 ist das folgende SAML-Update enthalten:

  • Programmfehlerbehebung: Beheben von Fehlern im aggregierten Verbund: Es gibt zahlreiche Fehlerbehebungen für die Unterstützung des aggregierten Verbunds (z. B. „InCommon“). Die Fehlerbehebungen beziehen sich auf die folgenden Punkte:
    • Verbesserte Skalierung für eine große Anzahl von Entitäten im Dokument für aggregierte Verbundmetadaten. Zuvor ist dabei der Fehler „ADMIN0017“ aufgetreten.
    • Abfragen mit dem Parameter „ScopeGroupID“ über das PSH-Cmdlet „Get-AdfsRelyingPartyTrustsGroup PSH“ (PowerShell).
    • 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. Eine typische oauth-Anforderung würde beispielsweise wie folgt aussehen: 7
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. Dies entspricht auch der Art und Weise, wie eine Authentifizierung bei Azure AD durchgeführt werden kann.

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 kann nicht erfolgreich ausgeführt werden.

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 zusätzliche Parameter hinzu.

Proofkey

A. Der Client erstellt und zeichnet ein Geheimnis namens "code_verifier" auf und leitet eine transformierte Version "t(code_verifier)" (als "code_challenge" bezeichnet) ab, die in der OAuth 2.0-Autorisierungsanforderung zusammen mit der Transformationsmethode "t_m" gesendet wird.

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 den unter (A) generierten geheimen Schlüssel „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 gleich sind, 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 einen bestimmten RP können mithilfe des Cmdlets Set-AdfsRelyingPartyTrust (AD FS) | Microsoft-Dokumentation durch Übergeben des Parameters „AdditionalAuthenticationRules“ oder des Parameters „AdditionalAuthenticationRulesFile“ festgelegt werden. Um sie global festzulegen, kann der Administrator das Cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft-Dokumentation verwenden.

Beispielsweise kann der Administrator ab 2012 R2 bereits die folgende Regel schreiben, um eine zusätzliche Authentifizierung anzufordern, wenn die Anforderung aus dem Extranet kommt.

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 Kunden jetzt Anspruchsregeln verwenden, um zu entscheiden, welcher weitere Authentifizierungsanbieter für die zusätzliche Authentifizierung aufgerufen werden soll. Dies ist in zwei Szenarien nützlich:

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

Kunden benötigen einen bestimmten zusätzlichen Authentifizierungsanbieter (z. B. ein Zertifikat) für bestimmte Anwendungen, aber eine andere Methode (AzureMFA) für andere Anwendungen.

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

In 2019 kann die oben genannte Anspruchsregel jetzt geändert werden, um Authentifizierungsanbieter basierend auf bestimmten Szenarien auszuwählen.

Übergang von einem zusätzlichen Authentifizierungsanbieter zu einem anderen: Wir ändern die oben genannte Regel, um AzureMFA für Benutzer in der Gruppe SID S-1-5-21-608905689-872870963-3921916988-12345 auszuwählen (z. B. eine vom Unternehmen verwaltete Gruppe, die die für AzureMFA registrierten Benutzer verfolgt). Für die übrigen Benutzer möchte der Administrator die Zertifikatauthentifizierung verwenden.

'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");’ 

Beispiel zum Festlegen von 2 verschiedenen Authentifizierungsanbietern für 2 verschiedene Anwendungen

Anwendung A soll „Azure MFA“ als zusätzlichen Authentifizierungsanbieter verwenden:

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");' 

Anwendung B soll „Zertifikat“ als zusätzlichen Authentifizierungsanbieter verwenden:

Set- 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");' 

Administratoren können auch Regeln festlegen, um mehr als einen zusätzlichen Authentifizierungsanbieter zuzulassen. In diesem Fall zeigt AD FS alle ausgestellten Authentifizierungsmethodenanbieter an, und der Benutzer kann einen beliebigen Authentifizierungsanbieter auswählen. Um mehrere zusätzliche Authentifizierungsanbieter zuzulassen, sollten sie mehrere Ansprüche ausstellen. https://schemas.microsoft.com/claims/authnmethodsproviders

Wenn keiner der Authentifizierungsanbieter von der Anspruchsauswertung zurückgegeben wird, geht AD FS zurück und zeigt alle zusätzlichen Authentifizierungsanbieter an, die vom Administrator in AD FS konfiguriert wurden, und der Benutzer muss den entsprechenden Authentifizierungsanbieter auswählen.

Um alle zulässigen zusätzlichen Authentifizierungsanbieter abzurufen, kann der Administrator das Cmdlet „(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider“ verwenden. Der Wert des Anspruchs https://schemas.microsoft.com/claims/authnmethodsproviders sollte einer der Anbieternamen sein, die vom obigen Cmdlet zurückgegeben werden.

Es gibt keine Unterstützung zum Auslösen bestimmter zusätzlicher Authentifizierungsanbieter, wenn der RP Zugriffskontrollrichtlinien in AD FS Windows Server 2016 | Microsoft-Dokumentation verwendet. Beim Verschieben einer Anwendung weg von der Zugriffssteuerungsrichtlinie kopiert AD FS die entsprechende Richtlinie aus der Zugriffssteuerungsrichtlinie in den Parameter „AdditionalAuthenticationRules“ und den Parameter „IssuanceAuthorizationRules“. Wenn ein Administrator also einen bestimmten Authentifizierungsanbieter verwenden möchte, kann er die Verwendung der Zugriffskontrollrichtlinie aussetzen und den Parameter „AdditionalAuthenticationRules“ ändern, um einen bestimmten zusätzlichen Authentifizierungsanbieter auszulösen.

Häufig gestellte Fragen

Hinweis

Dieser Fehler kann in den Ereignisprotokollen von AD FS Admin auftreten: Es wurde eine ungültige OAuth-Anforderung empfangen. Dem Client „NAME“ ist der Zugriff auf die Ressource mit dem Bereich „ugs“ untersagt. So behebst du diesen Fehler

  1. Starte die AD FS-Verwaltungskonsole. Navigieren Sie zu > "Beschreibungen des Dienstbereichs".
  2. Klicke mit der rechten Maustaste auf „Bereichsbeschreibungen“ und wähle „Bereichsbeschreibung hinzufügen“ aus.
  3. Geben Sie unter name den Namen "ugs" ein, und klicken Sie auf OK anwenden. >
  4. Führen Sie PowerShell als Administrator aus.
  5. Führe den Befehl „Get-AdfsApplicationPermission“ aus. Suche nach „ScopeNames :{openid, aza}“, die „ClientRoleIdentifier“ aufweisen. Notiere den „ObjectIdentifier“.
  6. Führen Sie den Befehl "Set-AdfsApplicationPermission -TargetIdentifier < ObjectIdentifier" aus Schritt 5 > -AddScope 'ugs' aus.
  7. Starten Sie den AD FS-Dienst neu.
  8. Auf dem Client: Starte den Client neu. Der Benutzer sollte zur Bereitstellung von WHFB aufgefordert werden.
  9. Wenn das Bereitstellungsfenster nicht angezeigt wird, musst du Protokolle zur NGC-Nachverfolgung sammeln und eine weitere Problembehandlung durchführen.

Q. Kann ich den Ressourcenwert als Teil des Bereichswerts übergeben, z. B. wie Anforderungen für Azure AD ausgeführt werden?

Mit AD FS auf Server 2019 können Sie nun den im Scope-Parameter eingebetteten Ressourcenwert übergeben. Der Bereichsparameter kann jetzt als eine durch Leerzeichen getrennte Liste organisiert werden, wobei jeder Eintrag als Ressource/Bereich strukturiert ist. Erstellen Sie beispielsweise eine > gültige Beispielanforderung.

Q. Unterstützt AD FS die PKCE-Erweiterung?

AD FS in Server 2019 unterstützt den Flow Proof Key for Code Exchange (PKCE) for OAuth Authorization Code Grant.)

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

Active Directory-Verbunddienste (AD FS) ermöglicht die 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 der Anmeldung und Zugriffssteuerung sowohl für moderne als auch für ältere Anwendungen, lokal und in der Cloud, basierend auf demselben Satz von Anmeldeinformationen und Richtlinien.
  • Dem Benutzer ermöglicht AD FS eine nahtlose Anmeldung mit denselben, 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.

In diesem Artikel werden die Neuerungen in AD FS für Windows Server 2016 (AD FS 2016) beschrieben.

Vermeiden von Kennwörtern im 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 Azure Multi-Factor Authentication

AD FS 2016 basiert auf den Funktionen für die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) von AD FS unter Windows Server 2012 R2, wobei die Anmeldung nur mit einem Azure MFA-Code zugelassen wird, ohne zuvor einen Benutzernamen und ein Kennwort einzugeben.

  • Wenn Azure MFA die primäre Authentifizierungsmethode ist, wird der Benutzer zur Eingabe seines Benutzernamens und des OTP-Codes aus der Microsoft Authenticator-App aufgefordert.
  • Wenn Azure MFA als sekundäre oder zusätzliche Authentifizierungsmethode verwendet wird, stellt der Benutzer Anmeldeinformationen für die primäre Authentifizierung bereit (mittels integrierter Windows-Authentifizierung, Benutzername und Kennwort, Smartcard oder Benutzer- oder Gerätezertifikat). Und dann wird dem Benutzer eine Eingabeaufforderung für die text-, sprach- oder OTP-basierte Azure MFA-Anmeldung angezeigt.
  • Dank des neuen integrierten Azure MFA-Adapters ist die Einrichtung und Konfiguration von Azure MFA mit AD FS einfacher als jemals zuvor.
  • Organisationen können Azure MFA nutzen, ohne einen lokalen Azure MFA-Server verwenden zu müssen.
  • Azure MFA kann für das Intranet oder Extranet oder als Teil einer Zugriffssteuerungsrichtlinie konfiguriert werden.

Weitere Informationen zu Azure MFA mit AD FS:

Kennwortloser Zugriff über kompatible 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 können sich mit den Geräteanmeldeinformationen anmelden, und die Konformität wird bei Änderungen der Geräteattribute erneut ausgewertet, sodass immer sichergestellt wird, dass Richtlinien erzwungen werden. Dadurch können beispielsweise die folgenden Richtlinien angewendet werden:

  • Zugriff nur von verwalteten und/oder kompatiblen Geräten zulassen
  • Extranetzugriff nur von verwalteten und/oder kompatiblen Geräten zulassen
  • Mehrstufige Authentifizierung für nicht verwaltete oder nicht kompatible Computer erforderlich

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.

whats new

Weitere Informationen zum Verwenden des gerätebasierten bedingten Zugriffs in der Cloud:

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 Microsoft 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 sich Benutzer sich über das Intranet oder Extranet bei AD FS-Anwendungen anmelden können, ohne ein Kennwort angeben zu müssen.

Weitere Informationen zum Verwenden von Microsoft Windows Hello for Business in der Organisation:

Sicherer Zugriff auf Anwendungen

Moderne Authentifizierung

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

Weitere Informationen findest du unter AD FS-Szenarien für Entwickler.

Konfigurieren von Zugriffssteuerungsrichtlinien ohne Kenntnis der Anspruchsregelsprache

Bisher mussten AD FS-Administratoren 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
  • Jedem Einzelnen Zugriff gewähren und MFA für Extranetzugriffe verlangen
  • Jedem Einzelnen Zugriff gewähren und MFA für bestimmte Gruppe verlangen

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

Weitere Informationen findest du unter Zugriffssteuerungsrichtlinien in 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 das Authentifizieren von Benutzern, die in LDAP v3-kompatiblen Verzeichnissen gespeichert sind, kann AD FS jetzt für Folgendes verwendet werden:

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

Weitere Informationen findest du unter Konfigurieren von AD FS zum Authentifizieren von Benutzern, die in LDAP-Verzeichnissen gespeichert sind.

Bessere Anmeldeoberfläche

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

Wir haben gehört, dass die Möglichkeit, die Anmeldeoberfläche für jede Anwendung anzupassen, eine erhebliche Verbesserung der Benutzerfreundlichkeit darstellen würde, insbesondere für Organisationen, die Anmeldungen für Anwendungen bereitstellen, die mehrere verschiedene Unternehmen oder Marken umfassen.

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 kannst du neue, benutzerdefinierte Webdesigns erstellen und diese pro vertrauende Seite anwenden.

Weitere Informationen findest du 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 einzige Anforderung generiert, und die relevanten Informationen zu einer Anmelde- oder Tokenausstellungsaktivität sind entweder nicht vorhanden (in einigen Versionen von AD FS) 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 findest du unter Überwachen 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 umfasst zusätzliche Unterstützung für das SAML-Protokoll, einschließlich der Unterstützung für das Importieren von Vertrauensstellungen basierend auf Metadaten, die mehrere Entitäten enthalten. Dadurch 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 findest du unter Verbesserte Interoperabilität mit SAML 2.0.

Vereinfachte Kennwortverwaltung für Office 365-Verbundbenutzer

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 findest du unter 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 für Windows Server 2012 R2 auf AD FS für Windows Server 2016 gestaltet sich jetzt viel einfacher. Füge einfach einer Windows Server 2012 R2-Farm einen neuen Windows Server 2016-Server hinzu. Die Farm verhält sich dann auf der Verhaltensebene der Windows Server 2012 R2-Farm, sodass sie das Aussehen und Verhalten einer Windows Server 2012 R2-Farm aufweist.

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 alle Farmknoten unter Windows Server 2016 ausgeführt werden, kannst du die Farmverhaltensebene auf 2016 aktualisieren und die neuen Features verwenden.

Weitere Informationen findest du unter Aktualisieren auf AD FS unter Windows Server 2016.