Aufbau einer Identitätsföderation mit SAML und Azure AD
Überblick
Identitätsföderation ermöglicht es Benutzern, die von einem Identitätsanbieter authentifiziert wurden, auf Ressourcen eines anderen Anbieters zuzugreifen, ohne separate Anmeldeinformationen verwalten zu müssen. Diese Anleitung beschreibt die Einrichtung einer SAML 2.0-Föderation zwischen dem lokalen Active Directory einer Organisation (über AD FS oder einen Drittanbieter-IdP) und Microsoft Entra ID (ehemals Azure AD) sowie die Konfiguration von föderiertem SSO für SaaS-Anwendungen von Drittanbietern. Die Föderation vermeidet Bedenken hinsichtlich der Passwortsynchronisation und behält die Authentifizierungsautorität vor Ort, während sie SSO auf Cloud-Ressourcen ausweitet.
Wann verwenden
- Beim Bereitstellen oder Konfigurieren von Identitätsföderation mit SAML und Azure AD in Ihrer Umgebung
- Bei der Einrichtung von Sicherheitskontrollen gemäß Compliance-Anforderungen
- Beim Aufbau oder der Verbesserung der Sicherheitsarchitektur für diesen Bereich
- Bei der Durchführung von Sicherheitsbewertungen, die diese Implementierung erfordern
Voraussetzungen
- Lokale Active Directory-Domäne
- AD FS 2019+ oder SAML-IdP eines Drittanbieters (Okta, Ping, usw.)
- Microsoft Entra ID-Mandant (P1- oder P2-Lizenz empfohlen)
- Azure AD Connect (bei Verwendung einer hybriden Identität mit Passwort-Hash-Synchronisierung als Fallback)
- Öffentliches TLS-Zertifikat für den Föderationsendpunkt
- DNS-Einträge für den Föderationsdienstnamen
Kernkonzepte
Föderationsmodelle
| Modell | Authentifizierungsautorität | Anwendungsfall |
|---|---|---|
| Föderiert (AD FS) | Lokales AD FS | Regulatorische Anforderung, Authentifizierung vor Ort zu behalten |
| Verwaltet (PHS) | Azure AD mit Passwort-Hash-Synchronisierung | Einfachste Cloud-Authentifizierung, AD FS nicht erforderlich |
| Verwaltet (PTA) | Lokal über Pass-Through-Agent | Cloud-Authentifizierung, die gegen lokales AD validiert wird |
| Drittanbieter-Föderation | Externer IdP (Okta, Ping) | Multi-IdP-Umgebung |
SAML-Föderationsarchitektur
Benutzer → Cloud-App (SP)
│
└── Weiterleitung zu Azure AD
│
├── Azure AD prüft die föderierte Domäne
│
└── Weiterleitung zum lokalen AD FS
│
├── AD FS authentifiziert gegen Active Directory
│
├── AD FS stellt SAML-Token aus
│
└── Token wird zurück an Azure AD gesendet
│
├── Azure AD validiert das Föderationsvertrauen
│
├── Azure AD stellt eigenes Token aus
│
└── Benutzer erhält Zugriffstoken für die Cloud-App
Komponenten des Föderationsvertrauens
| Komponente | Beschreibung |
|---|---|
| Token-Signaturzertifikat | X.509-Zertifikat, das vom IdP zum Signieren von SAML-Assertionen verwendet wird |
| Föderationsmetadaten | XML-Dokument, das IdP-Endpunkte und -Fähigkeiten beschreibt |
| Vertrauen der vertrauenden Seite | Konfiguration in AD FS für jeden SP (Azure AD) |
| Anspruchsregeln | Wandelt AD-Attribute in SAML-Ansprüche um |
| Aussteller-URI | Eindeutige Kennung für den IdP (Entitäts-ID) |
Arbeitsablauf
Schritt 1: AD FS-Infrastruktur vorbereiten
# AD FS-Rolle installieren
Install-WindowsFeature ADFS-Federation -IncludeManagementTools
# AD FS-Farm konfigurieren
Install-AdfsFarm `
-CertificateThumbprint $certThumbprint `
-FederationServiceDisplayName "Corp Federation Service" `
-FederationServiceName "fs.corp.example.com" `
-ServiceAccountCredential $gmsaCredential
# Überprüfen, ob AD FS betriebsbereit ist
Get-AdfsProperties | Select-Object HostName, Identifier, FederationPassiveAddress
Schritt 2: Azure AD-föderierte Domäne konfigurieren
# Microsoft Graph PowerShell-Modul installieren
Install-Module Microsoft.Graph -Scope CurrentUser
# Mit Microsoft Graph verbinden
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# Verwaltete Domäne in föderierte Domäne umwandeln
# Verwendung der AD FS-Föderationsmetadaten-URL
$domainId = "corp.example.com"
$federationConfig = @{
issuerUri = "http://fs.corp.example.com/adfs/services/trust"
metadataExchangeUri = "https://fs.corp.example.com/adfs/services/trust/mex"
passiveSignInUri = "https://fs.corp.example.com/adfs/ls/"
signOutUri = "https://fs.corp.example.com/adfs/ls/?wa=wsignout1.0"
signingCertificate = $base64Cert
preferredAuthenticationProtocol = "saml"
}
# Föderationseinstellungen auf Domäne anwenden
New-MgDomainFederationConfiguration -DomainId $domainId -BodyParameter $federationConfig
Schritt 3: AD FS-Anspruchsregeln konfigurieren
# Vertrauen der vertrauenden Seite für Azure AD hinzufügen
Add-AdfsRelyingPartyTrust `
-Name "Microsoft Office 365 Identity Platform" `
-MetadataUrl "https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml"
# Anspruchsregeln konfigurieren
$rules = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract AD Attributes"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory",
types = ("http://schemas.xmlsoap.org/claims/UPN",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"),
query = ";userPrincipalName,mail,givenName,sn;{0}",
param = c.Value);
@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass Through UPN as NameID"
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,
Value = c.Value,
ValueType = c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]
= "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");
"@
Set-AdfsRelyingPartyTrust `
-TargetName "Microsoft Office 365 Identity Platform" `
-IssuanceTransformRules $rules
Schritt 4: Drittanbieter-SaaS-Föderation konfigurieren
Führen Sie für jede SaaS-Anwendung, die SAML SSO über Azure AD unterstützt, Folgendes aus:
- Navigieren Sie zum Microsoft Entra Admin Center > Unternehmensanwendungen
- Fügen Sie die Anwendung aus dem Katalog hinzu (oder erstellen Sie eine benutzerdefinierte SAML-Anwendung)
- Konfigurieren Sie Einmaliges Anmelden > SAML:
- Bezeichner (Entitäts-ID): Entitäts-ID der Anwendung
- Antwort-URL (ACS): Assertion Consumer Service-URL der Anwendung
- Anmelde-URL: Anmelde-URL der Anwendung
- Ordnen Sie Benutzerattribute/-ansprüche zu:
- NameID: user.userprincipalname (E-Mail-Format)
- Zusätzliche Ansprüche gemäß den Anforderungen der Anwendung
- Laden Sie die Föderationsmetadaten-XML oder das Zertifikat herunter
- Konfigurieren Sie die SaaS-App mit den Föderationsdetails von Azure AD
Schritt 5: Zertifikatslebenszyklus-Management
AD FS-Token-Signaturzertifikate laufen ab und müssen erneuert werden:
# Aktuelles Zertifikat-Ablaufdatum prüfen
Get-AdfsCertificate -CertificateType Token-Signing | Select-Object Thumbprint, NotAfter
# AD FS unterstützt automatischen Rollover (standardmäßig aktiviert)
Get-AdfsProperties | Select-Object AutoCertificateRollover
# Falls manuelle Rotation erforderlich ist:
# 1. Neues Zertifikat als sekundäres hinzufügen
Set-AdfsCertificate -CertificateType Token-Signing -Thumbprint $newThumbprint -IsPrimary $false
# 2. Azure AD mit dem neuen Zertifikat aktualisieren
# 3. Zum primären Zertifikat hochstufen
Set-AdfsCertificate -CertificateType Token-Signing -Thumbprint $newThumbprint -IsPrimary $true
# 4. Altes Zertifikat entfernen
Remove-AdfsCertificate -CertificateType Token-Signing -Thumbprint $oldThumbprint
Validierungs-Checkliste
- AD FS-Farm betriebsbereit mit gültigen TLS- und Token-Signaturzertifikaten
- Azure AD-Domäne als föderiert mit korrekten Metadaten konfiguriert
- Anspruchsregeln wandeln AD-Attribute korrekt in SAML-Assertionen um
- Testbenutzer kann sich über den gesamten Föderationsablauf authentifizieren
- MFA auf AD FS- oder Azure AD-Bedingungszugriffsebene erzwungen
- Automatischer Zertifikats-Rollover aktiviert oder manuelle Rotation geplant
- Föderationsmetadaten-Endpunkt öffentlich zugänglich
- Smart Lockout konfiguriert, um Brute-Force-Angriffe zu verhindern
- Externetsperrrichtlinien auf AD FS konfiguriert
- Überwachung für AD FS-Integrität und Zertifikatsablauf eingerichtet
- Notfallwiederherstellung: Verwalteter Authentifizierungsfallback dokumentiert