Best Practices zum Sichern von Active Directory-Verbunddiensten (AD FS)

• Gilt für::

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Dieses Dokument enthält bewährte Methoden für die sichere Planung und Bereitstellung von Active Directory-Verbunddiensten (AD FS) und Webanwendungsproxy (WAP). Es enthält Empfehlungen für zusätzliche Sicherheitskonfigurationen, spezifische Anwendungsfälle und Sicherheitsanforderungen.

Dieses Dokument gilt für AD FS und WAP in Windows Server 2012 R2, 2016 und 2019. Diese Empfehlungen können entweder für ein lokales Netzwerk oder in einer in der Cloud gehosteten Umgebung wie Microsoft Azure verwendet werden.

Standardbereitstellungstopologie

Für die Bereitstellung in lokalen Umgebungen wird eine Standardbereitstellungstopologie empfohlen, die aus folgenden Elementen besteht:

• Mindestens ein AD FS-Server im internen Unternehmensnetzwerk.
• Mindestens ein WAP-Server (Webanwendungsproxy) in einer DMZ oder einem Extranetnetzwerk.

Auf jeder Ebene, AD FS und WAP, wird ein Hardware- oder Softwarelastenausgleich vor der Serverfarm platziert, der das Datenverkehrsrouting übernimmt. Firewalls werden nach Bedarf vor der externen IP-Adresse des Lastenausgleichs platziert.

Hinweis

AD FS erfordert einen vollständig beschreibbaren Domänencontroller; ein schreibgeschützter Domänencontroller reicht nicht aus. Wenn die geplante Topologie einen schreibgeschützten Domänencontroller umfasst, kann er für die Authentifizierung genutzt werden. Für die LDAP-Anspruchsverarbeitung ist eine Verbindung mit dem beschreibbaren Domänencontroller erforderlich.

Härten Ihrer AD FS-Server

Im Folgenden finden Sie eine Liste bewährter Methoden und Empfehlungen zum Härten und Sichern Ihrer AD FS-Bereitstellung:

• Stellen Sie sicher, dass nur Active Directory-Administratoren und AD FS-Administratoren über Administratorrechte für das AD FS-System verfügen.
• Verkleinern Sie die Mitgliedschaft in der Gruppe „Lokale Administratoren“ auf allen AD FS-Servern.
• Verlangen Sie, dass alle Cloudadministratoren Multi-Faktor-Authentifizierung verwenden müssen.
• Minimale Verwaltungsfunktionen über Agents.
• Beschränken Sie den Zugriff auf das Netzwerk über die Hostfirewall.
• Stellen Sie sicher, dass AD FS-Administratoren Admininstratorarbeitsstationen verwenden, um ihre Anmeldeinformationen zu schützen.
• Platzieren Sie AD FS-Servercomputerobjekte in einer Organisationseinheit der obersten Ebene, in der nicht auch noch andere Server gehostet werden.
• Alle Gruppenrichtlinienobjekte, die für AD FS-Server gelten, sollten nur für diese und nicht auch für andere Server gelten. Dies schränkt eine potenzielle Rechteausweitung durch Änderungen an Gruppenrichtlinienobjekten (GPO) ein.
• Stellen Sie sicher, dass die installierten Zertifikate vor Diebstahl geschützt sind (speichern Sie diese nicht auf einer Freigabe im Netzwerk), und legen Sie eine Kalendererinnerung fest, um sicherzustellen, dass sie vor Ablauf verlängert werden (abgelaufene Zertifikate verletzen die Verbundauthentifizierung). Darüber hinaus wird empfohlen, Signaturschlüssel/-zertifikate in einem Hardwaresicherheitsmodul (HSM) zu schützen, das an AD FS angefügt ist.
• Legen Sie die Protokollierung auf den höchsten Grad fest, und senden Sie die AD FS (und Sicherheits)-Protokolle an ein SIEM, um mit der AD-Authentifizierung sowie mit AzureAD (oder ähnlich) zu korrelieren.
• Entfernen Sie unnötige Protokolle und Windows-Features.
• Verwenden Sie ein langes (>25 Zeichen) komplexes Kennwort für das AD FS-Dienstkonto. Es wird empfohlen, ein gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) als Dienstkonto zu verwenden, da dadurch die Verwaltung des Dienstkontokennworts im Laufe der Zeit entfällt, da es automatisch verwaltet wird.
• Aktualisieren Sie auf die neueste AD FS-Version, um Sicherheits- und Protokollierungsverbesserungen zu erzielen (wie immer zuerst testen).

Ports erforderlich

Das folgende Diagramm zeigt die Firewallports, die zwischen den Komponenten der AD FS- und WAP-Bereitstellung sowie untereinander aktiviert werden müssen. Wenn die Bereitstellung weder Microsoft Entra ID noch Office 365 enthält, können die Synchronisierungsanforderungen ignoriert werden.

Hinweis

Port 49443 ist nur erforderlich, wenn die Benutzerzertifikatauthentifizierung verwendet wird, was für Microsoft Entra ID und Office 365 optional ist.

Hinweis

Port 808 (Windows Server 2012R2) oder Port 1501 (Windows Server 2016 und höher) ist das Netz. Der TCP-Port, den AD FS für den lokalen WCF-Endpunkt verwendet, um Konfigurationsdaten an den Dienstprozess und an PowerShell zu übertragen. Dieser Port kann durch Ausführen von „Get-AdfsProperties | select NetTcpPort“ angezeigt werden. Dies ist ein lokaler Port, der nicht in der Firewall geöffnet werden muss, sondern bei einer Portüberprüfung angezeigt wird.

Kommunikation zwischen Verbundservern

Verbundserver in einer AD FS-Farm kommunizieren für die Konfigurationssynchronisierung über HTTP-Port 80 mit anderen Servern in der Farm und den WAP-Servern (Webanwendungsproxy). Stellen Sie sicher, dass nur diese Server miteinander kommunizieren können und kein anderer eine Maßnahme der tiefgreifenden Verteidigung (Defense in Depth) ist.

Organisationen können diesen Zustand erreichen, indem sie Firewallregeln auf jedem Server einrichten. Die Regeln sollten nur eingehende Kommunikation von den IP-Adressen der Server in der Farm und von WAP-Servern zulassen. Einige Netzwerklastenausgleichs-Module (NLB) verwenden HTTP-Port 80, um die Integrität auf einzelnen Verbundservern zu testen. Stellen Sie sicher, dass Sie die IP-Adressen der NLB in die konfigurierten Firewallregeln einschließen.

Microsoft Entra Connect und AD FS-Verbund-Server/WAP

Diese Tabelle beschreibt die Ports und Protokolle, die für die Kommunikation zwischen dem Microsoft Entra Connect-Server und Verbund-/WAP-Servern erforderlich sind.

Protokoll	Ports	BESCHREIBUNG
HTTP	80 (TCP/UDP)	Wird zum Herunterladen von Zertifikatsperrlisten zur Überprüfung von SSL-Zertifikaten verwendet
HTTPS	443 (TCP/UDP)	Wird für die Synchronisierung mit Microsoft Entra ID verwendet.
WinRM	5985	WinRM-Listener

WAP- und Verbundserver

In dieser Tabelle werden die Ports und Protokolle beschrieben, die für die Kommunikation zwischen den Verbundservern und WAP-Servern erforderlich sind.

Protokoll	Ports	BESCHREIBUNG
HTTPS	443 (TCP/UDP)	Wird für die Authentifizierung verwendet

WAP und Benutzer

In dieser Tabelle werden die Ports und Protokolle beschrieben, die für die Kommunikation zwischen Benutzern und den WAP-Servern erforderlich sind.

Protokoll	Ports	BESCHREIBUNG
HTTPS	443 (TCP/UDP)	Wird für die Geräteauthentifizierung verwendet
TCP	49443 (TCP)	Wird für die Zertifikatauthentifizierung verwendet

Informationen zu erforderlichen Ports und Protokollen, die für Hybridbereitstellungen erforderlich sind, finden Sie unter Hybridreferenz-Verbindungsports.

Informationen zu Ports und Protokollen, die für eine Microsoft Entra ID- und Office 365-Bereitstellung erforderlich sind, finden Sie im Dokument Office 365-URL- und IP-Adressbereiche.

Endpunkte aktiviert

Wenn AD FS und WAP installiert sind, wird ein Standardsatz von AD FS-Endpunkten für den Verbunddienst und den Proxy aktiviert. Diese Standardwerte wurden basierend auf den am häufigsten benötigten und verwendeten Szenarien ausgewählt und müssen nicht geändert werden.

Minimaler Satz von Endpunktproxys, der für Microsoft Entra ID/Office 365 aktiviert ist (optional)

Organisationen, die AD FS und WAP nur für Microsoft Entra ID- und Office 365-Szenarien bereitstellen, können die Anzahl der auf dem Proxy aktivierten AD FS-Endpunkte noch weiter einschränken, um eine noch geringere Angriffsfläche zu erzielen. Im Folgenden finden Sie eine Liste der Endpunkte, die für den Proxy in diesen Szenarien aktiviert sein müssen:

Endpunkt	Zweck
/adfs/ls/	Browserbasierte Authentifizierungsflows und aktuelle Versionen von Microsoft Office verwenden diesen Endpunkt für Microsoft Entra ID- und Office 365-Authentifizierung.
/adfs/services/trust/2005/usernamemixed	Wird für Exchange Online mit Office-Clients verwendet, die älter als das Office 2013-Update vom Mai 2015 sind. Spätere Clients verwenden den passiven Endpunkt „\adfs\ls“.
/adfs/services/trust/13/usernamemixed	Wird für Exchange Online mit Office-Clients verwendet, die älter als das Office 2013-Update vom Mai 2015 sind. Spätere Clients verwenden den passiven Endpunkt „\adfs\ls“.
/adfs/oauth2/	Wird für alle modernen Apps (lokal oder in der Cloud) verwendet, die Sie für die direkte Authentifizierung bei AD FS konfiguriert haben (d. h. nicht über Microsoft Entra ID).
/adfs/services/trust/mex	Wird für Exchange Online mit Office-Clients verwendet, die älter als das Office 2013-Update vom Mai 2015 sind. Spätere Clients verwenden den passiven Endpunkt „\adfs\ls“.
/federationmetadata/2007-06/federationmetadata.xml	Anforderung für alle passiven Flows, und wird von Office 365/Microsoft Entra ID verwendet, um AD FS-Zertifikate zu überprüfen.

AD FS-Endpunkte können mithilfe des folgenden PowerShell-Cmdlets auf dem Proxy deaktiviert werden:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Erweiterter Schutz für die Authentifizierung

Erweiterter Schutz für die Authentifizierung ist ein Feature, das „Man in the Middle“-Angriffe (MITM) entschärft und standardmäßig mit AD FS aktiviert ist. Die Einstellung kann mithilfe des folgenden PowerShell-Cmdlets überprüft werden:

Get-ADFSProperties

Die Eigenschaft ist ExtendedProtectionTokenCheck. Die Standardeinstellung ist „Zulassen“, sodass die Sicherheitsvorteile ohne Kompatibilitätsbedenken hinsichtlich Browsern erreicht werden können, die die Funktion nicht unterstützen.

Überlastungssteuerung zum Schutz des Verbunddiensts

Der Verbunddienstproxy (Teil der WAP) bietet eine Überlastungssteuerung, um den AD FS-Dienst vor einer Überflutung durch Anforderungen zu schützen. Der Webanwendungsproxy lehnt externe Clientauthentifizierungsanforderungen ab, wenn der Verbundserver überlastet ist. Die Überlastung wird anhand der Latenz zwischen dem Webanwendungsproxy und dem Verbundserver erkannt. Dieses Feature ist standardmäßig mit einem empfohlenen Schwellenwert für die Latenz konfiguriert. Um die Einstellungen zu überprüfen, können Sie wie folgt vorgehen:

1. Öffnen Sie auf dem Webanwendungsproxy-Computer ein Befehlsfenster mit erhöhten Rechten.
2. Navigieren Sie zum AD FS-Verzeichnis unter „%WINDIR%\adfs\config“.
3. Ändern Sie die Standardwerte der Überlastungssteuerungseinstellungen in <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
4. Speichern und schließen Sie die Datei.
5. Starten Sie den AD FS-Dienst erneut, indem Sie net stop adfssrv und danach net start adfssrv ausführen.

Anleitungen zu dieser Funktion finden Sie unter Konfigurieren des Extranetzugriffs für AD FS unter Windows Server 2012 R2.

Standardüberprüfungen von HTTP-Anforderungen am Proxy

Der Proxy führt auch die folgenden Standardüberprüfungen für den gesamten Datenverkehr durch:

• Der FS-P selbst authentifiziert sich über ein kurzlebiges Zertifikat bei AD FS. In einem Szenario mit vermuteter Kompromittierung von DMZ-Servern kann AD FS die „Proxyvertrauensstellung widerrufen“, sodass eingehende Anforderungen von potenziell kompromittierten Proxys nicht mehr als vertrauenswürdig eingestuft werden. Durch das Widerrufen der Proxyvertrauensstellung wird das eigene Zertifikat jedes Proxys widerrufen, sodass diese sich für keinen Zweck mehr erfolgreich beim AD FS-Server authentifizieren können.
• Der FS-P beendet alle Verbindungen und erstellt eine neue HTTP-Verbindung mit dem AD FS-Dienst im internen Netzwerk. Dadurch wird ein Puffer auf Sitzungsebene zwischen externen Geräten und dem AD FS-Dienst hergestellt. Das externe Gerät stellt nie eine direkte Verbindung mit dem AD FS-Dienst her.
• Der FS-P führt eine HTTP-Anforderungsüberprüfung durch, die speziell HTTP-Header herausfiltert, die für den AD FS-Dienst nicht erforderlich sind.

Empfohlene Sicherheitskonfigurationen

Stellen Sie sicher, dass alle AD FS- und WAP-Server die neuesten Updates erhalten. Die wichtigste Sicherheitsempfehlung für Ihre AD FS-Infrastruktur besteht darin, sicherzustellen, dass Sie über eine Möglichkeit verfügen, Ihre AD FS- und WAP-Server mit allen Sicherheitsupdates sowie den optionalen Updates, die für AD FS auf dieser Seite als wichtig angegeben werden, auf dem neuesten Stand zu halten.

Die empfohlene Möglichkeit für Microsoft Entra-Kunden, ihre Infrastruktur zu überwachen und auf dem Laufenden zu halten, ist über Microsoft Entra Connect Health for AD FS, ein Feature von Microsoft Entra ID P1 oder P2. Microsoft Entra Connect Health umfasst Monitore und Warnungen, die ausgelöst werden, wenn auf einem AD FS- oder WAP-Computer eins der wichtigen Updates speziell für AD FS und WAP fehlt.

Weitere Informationen zur Integritätsüberwachung für AD FS finden Sie unter Installation des Microsoft Entra Connect Health-Agents.

Bewährte Methode zum Sichern und Überwachen der AD FS-Vertrauensstellung mit Microsoft Entra

Wenn Sie AD FS und Microsoft Entra ID verbinden, muss die Verbundkonfiguration (die konfigurierte Vertrauensstellung zwischen AD FS und Microsoft Entra ID) eng überwacht werden, um alle ungewöhnlichen oder verdächtigen Aktivitäten zu erfassen. Dazu wird empfohlen, entsprechende Benachrichtigungen zu einrichten, damit Sie benachrichtigt werden, wenn Änderungen an der Verbundkonfiguration vorgenommen werden. Informationen zum Einrichten von Warnungen finden Sie unter Überwachen von Änderungen an der Verbundkonfiguration.

Zusätzliche Sicherheitskonfigurationen

Die folgenden zusätzlichen Funktionen können konfiguriert werden, um mehr Schutz zu bieten.

„Weicher“ Schutz vor Extranetsperrung für Konten

Mit der Extranetsperrfunktion in Windows Server 2012 R2 kann ein AD FS-Administrator eine maximal zulässige Anzahl fehlerhafter Authentifizierungsanforderungen (ExtranetLockoutThreshold) und einen observation window-Zeitraum (ExtranetObservationWindow) festlegen. Wenn diese maximale Anzahl (ExtranetLockoutThreshold) von Authentifizierungsanforderungen erreicht wird, beendet AD FS den Versuch, die angegebenen Kontoanmeldeinformationen bei AD FS zu authentifizieren, für den festgelegten Zeitraum (ExtranetObservationWindow). Mit dieser Aktion wird dieses Konto vor einer AD-Kontosperrung geschützt, d. h., es wird vor dem Verlust des Zugriffs auf Unternehmensressourcen geschützt, die AD FS für die Authentifizierung des Benutzers benötigen. Diese Einstellungen gelten für alle Domänen, die der AD FS-Dienst authentifizieren kann.

Sie können den folgenden Windows PowerShell-Befehl verwenden, um die AD FS-Extranetsperre festzulegen (Beispiel):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Weitere Informationen zu diesem Feature finden Sie unter Konfigurieren der AD FS-Extranetsperre.

Deaktivieren von WS-Trust Windows-Endpunkten im Proxy aus dem Extranet

WS-Trust Windows-Endpunkte (/adfs/services/trust/2005/windowstransport und /adfs/services/trust/13/windowstransport) sind nur als intranetseitige Endpunkte gedacht, die WIA-Bindung unter HTTPS verwenden. Wenn Sie sie für das Extranet verfügbar machen, können Anforderungen an diese Endpunkte eventuell den Sperrschutz umgehen. Diese Endpunkte sollten mit folgenden PowerShell-Befehlen auf dem Proxy (d. h. für das Extranet) deaktiviert werden, um die Sperrung des AD-Kontos zu schützen. Es gibt keine bekannten Auswirkungen auf Endbenutzer, wenn diese Endpunkte auf dem Proxy deaktiviert werden.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Hinweis

Wenn Ihre AD FS-Farm unter WID (interne Windows-Datenbank) ausgeführt wird und über einen sekundären AD FS-Server verfügt, warten Sie nach dem Deaktivieren der Endpunkte auf dem primären Server, bis die SYNCHRONISIERUNG auf sekundären Knoten erfolgt, bevor Sie den AD FS-Dienst auf diesen neu starten. Verwenden Sie den PowerShell-Befehl Get-AdfsSyncProperties auf dem sekundären Knoten, um den letzten SYNC-Prozess nachzuverfolgen.

Differenzieren von Zugriffsrichtlinien für den Intranet- und Extranetzugriff

AD FS hat die Möglichkeit, Zugriffsrichtlinien hinsichtlich Anforderungen, die aus dem lokalen Unternehmensnetzwerk stammen, gegenüber Anforderungen, die über den Proxy aus dem Internet eingehen, zu unterscheiden. Diese Differenzierung kann pro Anwendung oder global erfolgen. Erwägen Sie bei Anwendungen mit hohem Geschäftswert oder Anwendungen mit vertraulichen Informationen die Anforderung der Multi-Faktor-Authentifizierung. Multi-Faktor-Authentifizierung kann über das AD FS-Verwaltungs-Snap-In eingerichtet werden.

Verlangen von mehrstufiger Authentifizierung (MFA)

AD FS kann so konfiguriert werden, dass eine starke Authentifizierung (z. B. Multi-Faktor-Authentifizierung) speziell für Anforderungen angefordert wird, die über den Proxy eingehen, für einzelne Anwendungen und für bedingten Zugriff auf Microsoft Entra ID/Office 365- sowie lokale Ressourcen. Unterstützte MFA-Methoden umfassen sowohl Microsoft Azure MF als auch Drittanbieter. Der Benutzer wird aufgefordert, die zusätzlichen Informationen (z. B. einen SMS-Text mit einem Einmalcode) anzugeben, und AD FS arbeitet mit dem anbieterspezifischen Plug-In zusammen, um den Zugriff zuzulassen.

Zu den unterstützten externen MFA-Anbietern gehören die auf der Seite Konfigurieren zusätzlicher Authentifizierungsmethoden für AD FS aufgeführten Anbieter.

Aktivieren Sie den Schutz, um die Umgehung von cloudbasierter Azure AD-Multi-Faktor-Authentifizierung zu verhindern, wenn sie mit Azure AD im Verbund erfolgt.

Aktivieren Sie den Schutz, um die Umgehung von cloudbasierter Azure AD-Multi-Faktor-Authentifizierung zu verhindern, wenn sie mit Azure AD im Verbund erfolgt und Sie Microsoft Entra-Multi-Faktor-Authentifizierung als Multi-Faktor-Authentifizierung für Ihre Verbundbenutzer verwenden.

Durch Aktivieren des Schutzes für eine Verbunddomäne in Ihrem Microsoft Entra-Mandanten wird sichergestellt, dass Microsoft Entra-Multi-Faktor-Authentifizierung immer durchgeführt wird, wenn ein Verbundbenutzer auf eine Anwendung zugreift, die durch eine Richtlinie für bedingten Zugriff gesteuert wird, die MFA erfordert. Dazu gehört, dass die Microsoft Entra-Multi-Faktor-Authentifizierung auch dann ausgeführt wird, wenn ein Verbundidentitätsanbieter Verbundtokenansprüche ausgestellt hat, dass die lokale MFA ausgeführt wurde. Das konsequente Erzwingen von Microsoft Entra-Multi-Faktor-Authentifizierung stellt sicher, dass ein kompromittiertes lokales Konto Microsoft Entra-Multi-Faktor-Authentifizierung nicht umgehen kann, indem nachgeahmt wird, dass bereits eine Multi-Faktor-Authentifizierung vom Identitätsanbieter ausgeführt wurde, und es wird dringend empfohlen, es sei denn, Sie führen MFA für Ihre Verbundbenutzer mit einem MFA-Drittanbieter durch.

Der Schutz kann mithilfe der neuen Sicherheitseinstellung federatedIdpMfaBehavior aktiviert werden, die als Teil der Internen Verbund-API von MS Graph oder mit den PowerShell-Cmdlets von MS Graph verfügbar gemacht wird. Die federatedIdpMfaBehavior-Einstellung bestimmt, ob Microsoft Entra ID die MFA akzeptiert, die vom Verbundidentitätsanbieter ausgeführt wird, wenn ein Verbundbenutzer auf eine Anwendung zugreift, die einer Richtlinie für bedingten Zugriff unterliegt, die MFA erfordert.

Administratoren können einen der folgenden Werte auswählen:

Eigenschaft	BESCHREIBUNG
acceptIfMfaDoneByFederatedIdp	Microsoft Entra ID akzeptiert die MFA, wenn sie vom Verbundidentitätsanbieter ausgeführt wird. Falls nicht, können Benutzer*innen eine Microsoft Entra-Multi-Faktor-Authentifizierung durchführen.
enforceMfaByFederatedIdp	Microsoft Entra ID akzeptiert die MFA, wenn sie vom Verbundidentitätsanbieter ausgeführt wird. Andernfalls wird die Anforderung an den Identitätsanbieter zur Durchführung der MFA umgeleitet.
rejectMfaByFederatedIdp	Microsoft Entra ID führt immer die Microsoft Entra-Multi-Faktor-Authentifizierung aus und lehnt MFA ab, wenn sie vom Identitätsanbieter ausgeführt wird.

Sie können den Schutz aktivieren, indem Sie mit dem folgenden Befehl federatedIdpMfaBehavior auf rejectMfaByFederatedIdp festlegen.

MS GRAPH-API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

Beispiel:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

Beispiel:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Beispiel:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

Hardwaresicherheitsmodul (HSM)

In der Standardkonfiguration verlassen die Schlüssel, die AD FS zum Signieren von Token verwendet, niemals die Verbundserver im Intranet. Sie sind nie in der DMZ oder auf den Proxycomputern vorhanden. Optional wird empfohlen, diese Schlüssel in einem Hardwaresicherheitsmodul (HSM) zu schützen, das an AD FS angefügt ist, um mehr Schutz zu bieten. Microsoft stellt kein HSM-Produkt her, es gibt jedoch mehrere auf dem Markt, die AD FS unterstützen. Um diese Empfehlung zu implementieren, befolgen Sie die Richtlinien des Herstellers, um die X509-Zertifikate zum Signieren und Verschlüsseln zu erstellen, und verwenden Sie dann die PowerShell-Cmdlets für die AD FS-Installation, und geben Sie dabei Ihre benutzerdefinierten Zertifikate wie folgt an:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

Dabei gilt Folgendes:

• CertificateThumbprint ist Ihr SSL-Zertifikat.
• SigningCertificateThumbprint ist Ihr Signaturzertifikat (mit HSM-geschütztem Schlüssel).
• DecryptionCertificateThumbprint ist Ihr Verschlüsselungszertifikat (mit HSM-geschütztem Schlüssel).