MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Entra ID und Domain Federation

Benutzer in Entra ID per Provisioning anlegen, die UPN-Domain per Federation mit einem externen IDP verbinden und alles ohne ADSync. Wenn Sie die Hintergründe kennen und damit die Vorgaben erfüllen, können Sie Microsoft 365 ganz ohne den Microsoft Verzeichnisabgleich und ohne PHS oder PTA betreiben.

IDP Szenario ohne ADSync

Seht kleine Firmen brauchen keinen Entra ID Connect, denn sie pflegen ihre Benutzer einfach direkt mit dem Microsoft 365 Admin Portal (https://admin.microsoft.com) und vergeben eigene Kennworte in der Cloud. Wenn eine Firma aber ein lokales Active Directory hat, dann kommt ein Microsoft Verzeichnisabgleich mit Entra ID Connect (ADSync / AADConnect) oder EntraID Cloud Sync mit Password Hash Sync (PHS) oder Pass Through Authentifizierung (PTA) zum Einsatz. Früher wurde die Authentifizierung manchmal mit ADFS bereitgestellt.

Es gibt aber noch eine Konfiguration bei der ein zentrale Identity-Service die Verwaltung der Benutzer und Gruppen sowohl im lokale Active Directory als auch in Entra ID, OpenLDAP und vielen anderen Verzeichnisdiensten übernimmt. Wenn das Identity Management nicht auch gleich noch die Kennworte synchron hält, dann kommt meist ein Authentication Service als Bestandteil des Identity Service Providers (IDP) zum Einsatz. In Entra ID wird die Domain dann per "Federation" angebunden und in der Microsoft Welt ist der ADFS-Service so ein Authentifizierungsdienst.

Gerade bei XXL-Firmen, Forschungseinrichtungen, Schulen, Universitäten ist das Active Directory nicht das führende System. Die Identitäten werden in einem separaten System verwaltet, welches dann die Objekte im lokalen AD per LDAP, im Entra ID per Graph und weiteren Systemen anlegt. ADSync kommt hier nicht zum Einsatz und damit fehlt auch die Replikation der ObjectGUID im AD in das Feld "ms-ds-consistencyGUID" in Entra ID. Das IDP muss sicherstellt, dass der SAML-Server, z.B. Shibboleth, die NameID mit einem Wert füllt, den EntraID im Feld "OnPremisesImmutableID" wiederfindet.

Wenn das nun zu schnell war, dann finden Sie in den folgenden Kapiteln jede Menge Details zu den Zusammenhängen.

Anmeldung per Federation

Wenn ein Anwender auf einen Microsoft 365 Service zugreifen will, muss er sich mit einem SAML-Token authentifizieren, welches von Entra ID (login.microsoftonline.com) ausgestellt wurde. Beim Einsatz von Federation prüft aber nicht der Entra ID Service die Legitimierung sondern verweist den Client zu einem dritten Authentifizierungsdienst. Für den Anwender stellt sich die Anmeldung wie folgt dar:

 

  • Der Anwender wird von Zugriff auf einen Microsoft 365 Dienste, z.B. "https://outlook.office.com" weiterhin auf https://login.microsoftonline.com umgeleitet.
  • Nach der Übermittlung des Anmeldnamens sendet Entra ID den Client mit einem HTTP-POST zum lokalen IDP
  • Hier meldet sich der Anwender dann an und wird dann wieder zu Entra ID zurückgesendet
  • Der Client sendet per POST die Information über seinen Benutzernamen als signiertes Paket an Entra ID. Entra ID prüft die Signatur und den Vertrauensstatus und übernimmt dann die Information über die Identität. (OnPremisesImmutableID) und stellt ein Ticket für den angeforderten Dienst aus
  • Der Client kann dann endlich auf den eigentlichen Dienst zugreifen.

Die Sicherheit ist durch den Einsatz von "Signing-Zertifikaten" gewährleistet, welche bei der Einrichtung eingetragen werden. Die Konfiguration kann deutlich vereinfacht werden, denn die Services die relevanten Informationen als "Federation Metadata" bereitstellen. So kann ein Server sich alleine die Zertifikate per HTTPS holen und auch automatisch aktualisieren. Ansonsten müssen Sie ab und an die Konfiguration aktualisieren.

Federation zwischen Welten

Entra ID ist ein AUTH-Service, der SAML/OAUTH unterstützt. Das machen aber andere 3rd-Party Service auch und manchmal werden die Dienste noch kaskadiert. Das passiert auch, wenn ich eine Domain mit einem externen Federation-Service verbinde. Ein Microsoft 365 Service sendet mich nie direkt zum eigenen Federation-Service, sondern immer über EntraID.

Ein Anwender greift z.B. auf Exchange Online zu und wird immer auf login.microsoftonline.com umgeleitet. Wenn der Client nicht schon angemeldet ist, dann sendet er den UPN des Benutzers und anhand der UPN-Domain und des Benutzers entscheidet Entra ID, ob die Anmeldung mit dem in die Cloud synchronisierten Hashwert (2) oder über einen PTA-Agenten (3)  gegen den lokalen DC erfolgt, oder ob der Client zu nächsten Federation-Server (4) umgeleitet wird.

Für 3rd-Party Dienste gibt es in Verbindung mit Entra ID und einem lokalen Federation-Server nun sogar zwei Wege.

  • Direkte Federation (5)
    d.h. Sie binden den 3rd Party Service direkt in ihren eigenen AUTH-Service an. Das ist möglich aber hat für den Anbieter den Nachteil, dass er zu jedem Kunden eine eigene Federation einrichten und aktuell halten muss. Ein SAML-Signing-Zertifikat läuft aber regelmäßig ab und nicht alle Firmen stellen auch Federation-Metadaten bereit. Hier ist also ein gewisses Risiko und manuelle Nacharbeit vorhanden.
  • Federation über Entra ID (6)
    Für Anbieter ist es daher viel einfacher, eine Federation zu Entra ID aufrecht zu erhalten und kann damit seinen Kunden auch direkt die Wahl lassen, ob diese dann wieder per PHS, PTA oder Federation die Anmeldung umsetzen. Auch MFA und Conditional Access ist so ganz einfach möglich.

Auf dem Bild ist nun nicht weiter abgebildet, dass Sie von ihrem OnPremises Federation Server natürlich wieder weiter zu einem anderen Federation Service verzweigen könnten. Das könnte z.B. in Universitäten passieren, wenn Sie vom Federation Service der Universität über das DFN dann weiter zum Federation-Service ihrer Heimatuniversität geleitet werden. Das ist dann ähnlich wie die Kaskadierung von Radius-Servern, die z.B. Eduroam (How Does eduroam Work? - eduroam.org) nutzt. Das ist aber keine Federation.

Federation in Entra ID konfigurieren

In Entra ID müssen Sie pro UPN-Domain die Federation einrichten. Dazu müssen Sie Entra ID mitteilen, an welchen Service er die Clients umleiten soll und mit welchem Zertifikat der Authentifizierungsservice die Rückantworten signiert. Wenn Sie einen Windows ADFS-Service nutzen, dann hat kann das Entra ID Connect -Setup die Konfiguration für sie übernehmen. Wenn Sie aber einen eigenen Service nutzen, dann müssen Sie die Konfiguration per Microsoft Graph umsetzen. Viele Anleitungen im Internet beschreiben immer noch MSOnline und AzureAD PowerShell, welche aber seit  30. März 2024 nicht mehr genutzt werden können. Heute ist die MGGraph-PowerShell der einfachste Weg, diese Konfigurationsänderung vorzunehmen.

Achtung:
Stellen Sie sicher, dass Sie ein Admin-Konto z.B.: mit einem "@<tenantname>.onmicrosoft.com"-UPN haben. Mit Aktivierung der Federation werden anmelden an die Domain nicht mehr gegen Entra ID ausgeführt. Sie wollen sich doch nicht aussperren?

Hinweis:
Laut Anleitung für "New-MgDomainFederationConfiguration" benötigen Sie nur "Domain.ReadWrite.All". Dies ist nicht korrekt. "Directory.AccessAsUser.All" ist ebenfalls erforderlich. Ggfls. müssen Sie sich den Consent erteilen.

Der lokale OAUTH/SAML-Server ist per HTTPS unter verschiedenen URLs erreichbar. Diese unterscheiden sich nach Produkt, SAML-Version und Anmeldeverfahren. Hier ein Beispiel mit URLs eines NetIQ Access Manager mit SAML-Anmeldung:

# Installation von Microsoft Graph
Install-Module MGGraph

# Anmelden als Administrator mit zusätzlichen Berechtigungen. Eine Constent-Abfrage muss bestätigt werden
# Allein das Recht "Domain.ReadWrite.All" reicht aktuell nicht.
Connect-MgGraph `
   -Scopes "Domain.ReadWrite.All","Directory.AccessAsUser.All"

# Definition der URLS
$Domain =            "msxfaq.de"
$PassiveSignInUri =  "https://login.msxfaq.de/nidp/saml2/sso" 
$SignOutUri =        "https://login.msxfaq.de/nidp/jsp/o365Logout.jsp" 
$ActiveSignInUri =   "https://login.msxfaq.de/nidp/saml2/soap" 
$IssuerUri =         "https://login.msxfaq.de/nidp/saml2/metadata"
$Protocol =          "saml"

# Hier benötigen wir das Token Signing Zertifikat
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\tokensign.cer")
$MySigningCert       = [system.convert]::tobase64string($idptokensigningcert.rawdata) 

# Umtellung der Domain auf Federated
New-MgDomainFederationConfiguration `
   -DomainId $Domain `
   -PreferredAuthenticationProtocol $Protocol `
   -ActiveSignInUri $ActiveSignInUri `
   -PassiveSignInUri $PassiveSignInUri `
   -IssuerUri $IssuerUri `
   -SignOutUri $SignOutUri `
   -SigningCertificate $MySigningCert `
   -FederatedIdpMfaBehavior "acceptIfMfaDoneByFederatedIdp"

Achtung:
Es kann passieren, dass bei der Einrichtung ein Fehler kommt. Entra ID setzt anscheinend zuerst die Domain auf "Federated" und speichert dann die Federationconfiguration. Wenn hier ein Fehler kommt, dann müssen Sie erst die Domain wieder mit "update-MgDomain -DomainId <domain> -AuthenticationType managed" auf "Managed" stellen und es dann erneut versuchen.

Der Wert für "$IssuerUri" muss weltweit eindeutig sein. Ansonsten bekommen Sie einen Fehler "New-MgDomainFederationConfiguration_CreateExpanded: Resource already exists". Sie bekommen aber keinen Hinweis, in welchem fremden Tenant oder welcher ihrer Domains der gleiche Wert schon verwendet wird.

Wenn alles fehlerfrei ausgeführt wurde, dann sehen Sie die Domain im Entra ID als "Federated".

Wenn die Änderung unerwartete Effekte hat, dann können Sie dies wie folgt wieder rückgängig machen. Sie müssen sich sich dazu zuerst die "ID" der aktuellen Federation holen und dann als Parameter "InternalDomainFederationId" übergeben.

$Domain = "msxfaq.de" 
$federation = get-MgDomainFederationConfiguration -DomainId $Domain
Remove-MGDomainFederationConfiguration `
   -DomainId $domain `
   -InternalDomainFederationId $federation.id

Die Änderung wurde bei mir quasi innerhalb von Sekunden aktiv. Alternativ können Sie auch die Domain von "Federated" auf "Managed" umstellen.

Update-MgDomain `
   -DomainId msxfaq.net `
   -AuthenticationType managed 

Federation mit mehreren Domains

Wenn Sie nicht nur eine UPN-Domain in ihrem Tenant per Federation verbinden wollen, dann müssen Sie für jede Domain eine eigene Federation Konfiguration hinterlegen. So können Sie sogar mehrere Firmen mit mehreren lokalen SAML-Servern in einem Tenant zusammenführen, was bei Merger&Aquisitions sehr nützlich sein kann. Aber schon bei der Nutzung von ADFS mussten Sie hier bei der Einrichtung aufpassen. Früher haben wir bei der ADFS-Einrichtung folgenden Aufruf genutzt:

Update-MsolFederatedDomain `
   -DomainName <domain> `
   -SupportMultipleDomain

Allerdings ist die MSOL-PowerShell nicht mehr verfügbar und der "-SupportMultipleDomain" Parameter gibt es weder in der MGGraph PowerShell noch Entra ID PowerShell. Wir müssen pro Domain den vorherigen Schritt einfach wiederholen.

Denken Sie daran, dass die IssuerUri eindeutig sein muss.


Quelle: Multiple Domain Support for Federating with Microsoft Entra ID - Microsoft Entra ID
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-multiple-domains

Der Wert für "$IssuerUri" muss weltweit eindeutig sein. Ansonsten bekommen Sie einen Fehler "New-MgDomainFederationConfiguration_CreateExpanded: Resource already exists". Sie bekommen aber keinen Hinweis, in welchem fremden Tenant oder welcher ihrer Domains der gleiche Wert schon verwendet wird. Ansonsten könnten Sie folgenden Fehler sehen:

The error Request_MultipleObjectsWithSameKeyValue typically indicates that the IssuerURI provided in the command is already in use, either in another domain within your tenant or in a different tenant. IssuerURIs must be globally unique.

Federation und "Primary Domain"

Ehe Sie ihre Domain für Federation aktivieren, sollten Sie prüfen, ob es die primäre Domain ist. Das geht einfach per Entra ID/AzureAD Portal:

In meinem Fall unterscheiden sich die federierte Domain und die primäre Domain. Bei den meisten Firmen wird die "<tenantname>.onmicrosoft.com" noch die primäre Domain sein. Ich habe eine Stelle gefunden, an der Microsoft etwas zu einem Zusammenhang schreibt.

You can change the primary domain name for your organization to be any verified custom domain that isn't federated.
https://learn.microsoft.com/en-us/entra/identity/users/domains-manage

Daraus könnten wir ableiten, das die primäre Domain keine federierte Domain sein darf. Der Versuch dies per Entra ID zu ändern, liefert auch einen Fehler:

 

Allerdings ohne weitere Begründung oder Beschreibung. Im Chromium Debugger sehe ich aber den Request

Request URL 
https://graph.windows.net/myorganization/domains('msxfaqdev.de')?api-version=1.6
Request Method PATCH
Status Code 400 Bad Request

Payload: {"isDefault":true}

Und dem JSON Ergebniscode:

{
    "odata.error": {
        "code": "Request_BadRequest",
        "message": {
            "lang": "en",
            "value": "SetDomain. domain authentication type must be Managed to become default domain. 
                        paramName: LiveType,SetAsDefault, 
                        paramValue: Federated, 
                        objectType: Microsoft.Online.DirectoryServices.CompanyDomain"
        },
        "requestId": "fd85f27b-ae24-4b6d-922a-792483d1b2ae",
        "date": "2025-11-14T15:30:41",
        "values": [
            {
                "item": "PropertyName",
                "value": "authenticationType"
            },
            {
                "item": "PropertyErrorCode",
                "value": "DefaultDomainInvalidAuthentication"
            }
        ]
    }
}

Interessant ist aber im Umkehrschluss, dass ich die Default Domain durchaus für Federation aktivieren kann.

Hinweis: Als ich die primäre Domain als zweite Domain addieren wollte, bekam ich folgenden Fehler:

New-MgDomainFederationConfiguration_CreateExpanded: Resource already exists.

Status: 409 (Conflict)
ErrorCode: Request_MultipleObjectsWithSameKeyValue

Die $IssuerUri muss wohl pro Tenant einmalig sein. Allerdings hat Entra ID dann die Domain auf "Federated" umgestellt aber die DomainFederationConfiguration nicht angelegt. Ich konnte also mit Get-MGDomainFederationConfiguration -DomainId <domain> keinen Eintrag erhalten und damit auch nicht mit Remove-MGDomainFederationConfiguration entfernen. Ich konnte aber die Domain mit "Update-MgDomain -DomainId msxfaq.net -AuthenticationType managed" wieder auf Managed zurückstellen und einen zweiten Versuch starten.

Beachten Sie noch eine weitere Besonderheit, wenn es um die Anlage von Shared Mailboxen in der Cloud und der Primary Domain geht. Siehe shared_mailbox_mit_federated_domain

Post zu Anmeldung

Mit der Aktivierung von Federated ändert sich auch das Anmeldeverhalten am Client. Starten Sie einen privaten Browser und gehen Sie auf einen Microsoft 365 Service, z.B. https://outlook.office.com. Sie werden auf login.microsoftonline.com umgeleitet und geben dort ihren Benutzernamen ein. Genaugenommen können Sie einen beliebigen Benutzernamen eingeben, denn EntraID prüft nicht, ob der Benutzer gültig ist. Allein anhand der Domain erkennt Microsoft, dass der Client zu einem Authentifizierungsserver der Organisation umzuleiten ist. Die URL ist Wert aus "$PassiveSignInUri" der Konfiguration und die Methode ist ein POST. Für den Webserver sieht dies wie ein ausgefülltes Formular aus, welches drei Felder hat:

Feld

Beschreibung und Beispiel

SAMLRequest

Das ist eine BASE64-codierte XML-Struktur, die decodiert den "Issuer" mit "urn:federation:MicrosoftOnline" angibt und dass er gerne eine NameID zurück braucht.

<samlp:AuthnRequest ID="_cd8ff3d0-fe42-4ac3-bff9-9b9139a864f6"
                    Version="2.0"
                    IssueInstant="2025-11-06T18:34:42.968Z"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
	<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer>
	<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>

Was genau in dem Feld stehen muss, wird hier nicht angegeben. Bei Microsoft habe ich gefunden, dass es die ImmutableID sein müsste

RelayState

Enthält die Information für Micosoft 365, zu welcher Ressource der Client nach der Rückkehr wieder gehen soll. Das kann eine URL sein, wenn das IDP dies vorgibt oder der von Microsoft gesendet Wert, damit Entra ID die Rückantwort zuordnen kann.

Username

Der vom Anwender eingegebene Username. Den könnte der eigene Authentication Server z.B. ins Feld "Username" übernehmen

Diese Information wird über ein "FORM POST" an das eigene IDP gesendet

Postback zu Entra ID

Das IDP hat dann die Aufgabe, eine Anmeldung durch den Anwender durchführen zu lassen. Hier können Sie die Funktionen des IDP nutzen, z.B. MFA oder Zertifikate o.ä. Wenn das IDP den Benutzer erfolgreich authentifiziert hat, sendet es wieder eine HTML-Seite mit einem Formular an den Client und ein eingebettetes JavaScript drücken für den Anwender den "Absenden"-Button. Die URL für das POST verweist auf Entra ID zurück und enthält ebenfalls wieder einige Felder: (gekürzt)

<samlp:Response ID="_<GUID>" 
                Version="2.0" 
                IssueInstant="2024-01-31T15:36:31.357Z" 
                Destination="https://login.microsoftonline.com/login.srf" 
                Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" 
                InResponseTo="_<GUID>" 
                xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://login.msxfaq.de/nidp/saml2/metadata</Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  </samlp:Status>
  <Assertion ID="_<GUID>" IssueInstant="2025-10-25T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>login.msxfaq.de/nidp/saml2/metadata</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>......</ds:SignedInfo>
      <ds:SignatureValue>TciWMy....:........6dA==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data><ds:X509Certificate>MIIC7.........Dg9A==</ds:X509Certificate></ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">BASE64codierteImmutableID</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_<GUID>" NotOnOrAfter="2025-10-25T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2025-10-25T15:36:31.263Z" NotOnOrAfter="2025-10-25T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>user1@msxfaq.de</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2025-10-25T15:36:30.200Z" SessionIndex="_<GUID>">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
  </Assertion>
</samlp:Response>

Wichtig ist hier das Feld "NameID".

      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">BASE64codierteImmutableID</NameID> 

Hier steht die eindeutige ID des authentifizierten Benutzers, anhand der Entra ID das Objekt in seinem Verzeichnis findet.

Mal eben schnell so eine XML-Struktur fälschen oder verändern ist nicht möglich, das Entra ID zwingend eine digitale Signatur durch das IDP erzwingt.

NameID und ImmutableID

Wenn der Client mit dem vom IDP ausgestellten Token zu Entra ID zurückkehrt, muss im Token auch die Information enthalten sein, welcher Benutzer sich authentifiziert hat. Maßgeblich ist dabei das Feld "NameID" aus der XML-Struktur, die der Client zurück an login.microsoftonline.com sendet.

      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">BASE64codierteImmutableID</NameID>

Dies ist ein eindeutiges und unveränderlichen Feld, welches das Benutzerobjekt eindeutig identifiziert. Laut Microsoft ist dies die "OnPremisesImmutableID", welche durch ADSync / AADConnect anhand der lokalen ObjectGUID gesetzt wird. So kann ADFS auch die ID aus dem lokalen AD auslesen.


Quelle: Microsoft Entra Connect: Use a SAML 2.0 Identity Provider for Single Sign On - Azure - Microsoft Entra ID
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-saml-idp#required-attributes

SAML_SUBJECT to guid (guid should map to your attribute holding the Microsoft 365 user objectID and be in Base64 binary format)
Quelle: Configuring SAML SSO with Microsoft 365 and PingFederate | Configuration Guides https://docs.pingidentity.com/configuration_guides/microsoft_365/config_saml_o365_pf.html

"..If you have an existing user, ensure that the Immutable ID matches with the GUID of the Access Manager user. .."
Quelle: SAML NameID Format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
https://support.pingidentity.com/s/article/SAML-Name-ID-urn-oasis-names-tc-SAML-2-0-nameid-format-persistent

Azure AD is using the attribute ImmutableID as the source anchor to link the users between IdP and SP.
Quelle: https://www.ruianding.com/blog/single-sign-on-microsoft-365-azure-ad-via-google-idp/

This error arises when a Microsoft Office 365 user has an ImmutableID in Entra ID that does not match the ImmutableID configured in Okta.
Quelle: https://support.okta.com/help/s/article/error-during-microsoft-office-365-single-sign-on-aadsts51004-the-user-account-does-not-exist-in-the-directory
Quelle: Okta: https://support.okta.com/help/s/article/ms-o365-federation-immutableid-missing-issue-with-o365-federation

Step 1: Configure ImmutableID
Office 365 uses the ImmutableID attribute to uniquely identify users. For SSO between Google and Office 365 to work, each Office 365 user must have an ImmutableId, and the SAML Name ID attribute sent to Office 365 during SSO must be the same as the ImmutableId.
Quelle: Set up SSO via SAML for Microsoft Office 365 -  https://support.google.com/a/answer/6363817  

Werden die Benutzer nicht durch ADSync verwaltet und sind damit "Cloud Managed", dann ist das Feld normalerweise leer und muss durch ihr IDM gesetzt werden, z.B. mit:

# ImmutableID der aktuellenUser ausgehen
Get-MgUser `
   -UserId <user@domain.tld> `
   -Property OnPremisesImmutableId `
| Format-List OnPremisesImmutableId

# Feld setzen, wenn User nicht durch EntraID gesetzt wird
Update-MgUser `
   -UserId user1@msxfaqdev.de `
   -OnPremisesImmutableId <ImmutableId>

Zusätzlich gibt es noch das Feld "IDPEmail", welches jedes Token mit enthalten hat.

    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>user1@msxfaq.de</AttributeValue>
      </Attribute>
    </AttributeStatement>

Laut Federationmetadata ist dieses Feld aber nicht für die Anmeldung erforderlich.

MFA - federatedIdpMfaBehavior und multipleauthn

Eine Anmeldung mit Benutzername und Kennwort ist definitiv nicht sicher. Sie können weiterhin in Entra ID mit MFA und Conditional Access den Zugriff weiter kontrollieren. Sie können aber auch zumindest die MFA-Funktion an ihren eigenen Authentifizierungsserver übertragen. Bei POST zum IDP ist dies noch nicht ersichtlich aber wenn der Anwender sich an ihrem IDP per MFA authentifiziert hat, dann kann beim POST zurück zu Entra eine MFA-Anmeldung mit folgender Information mitgeliefert werden: (SAML 2.0)

<AuthnStatement AuthnInstant="2024-11-12T08:43:17.537Z">
    <AuthnContext>
        <AuthnContextClassRef>http://schemas.microsoft.com/claims/multipleauthn</AuthnContextClassRef>
    </AuthnContext>
</AuthnStatement>

Beí einer SAML 1.1/WS-Fed-Konfiguration beachtet Entra ID die folgenden Claims

http://schemas.microsoft.com/claims/multipleauthn
http://schemas.microsoft.com/claims/wiaormultiauthn

Entra ID geht dann davon aus, dass die Anmeldung am lokalen IDP per MFA erfolgt ist, was Sie in Conditional Access Regeln weiter verwenden können.

Sie sollten schon aus Eigeninteresse diese Claims natürlich nur dann addieren, wenn die Anmeldung auch per MFA abgesichert war,

Zudem müssen Sie bei der Federation noch "federatedIdpMfaBehavior" entsprechend aktivieren, wenn dies nicht schon bei der Einrichtung erfolgt ist.

$feddomain = "msxfaqdev.de"
$fedsettings = get-mgdomainFederationConfiguration -domainId $feddomain
Update-MgDomainFederationConfiguration `
   -InternalDomainFederationId $fedsettings.Id `
   -DomainId msxfaqdev.de `
   -FederatedIdpMfaBehavior enforceMfaByFederatedIdp

Entsprechend wertet Entra ID die im Post übermittelten Claims aus.

  • acceptIfMfaDoneByFederatedIdp
    Wenn das IDP eine MFA-Anmeldung meldet, dann übernimmt dies Entra ID und macht keine eigene Anmeldung. Das IDP muss aber kein MFA senden
  • enforceMfaByFederatedIdp
    Wenn das IDP kein MFA meldet, dann macht Entra ID immer das eigene MFA
  • rejectMfaByFederatedIdp
    Entra ID ignoriert den Claim zu MFA und behandelt die Antwort, als hätte MFA noch nicht stattgefunden.

Sie müssen eine für ihre Umgebung passende Einstellung bestimmen.

Wenn ich mir schon die Mühe mache, ein eigenes IDP zu betreiben, dann würde ich auch dort die MFA-Prüfung machen. So profitieren dann alle an diesem IDP angebundenen Dienste von der MFA Funktion und nicht nur über Entra ID verbundene Anwendungen. Andererseits können Sie in Entra mit Conditional Access natürlich auch den Device-Status sehr einfach mit integrieren.

Federated User im Adminportal anlegen - Nein

Die meisten Firmen nutzen ADSync/EntraID Connect zur Verwaltung der Benutzer in der Cloud anhand der lokalen AD-Identitäten. Es gibt aber auch Firmen, die auf ADSync/EntraID-Connect verzichten und mit einer eigenen Identity-Lösung die Benutzer in ihren verschiedenen Systemen verwalten. Sobald eine Domain für Federation aktiviert ist, können Sie über die Weboberflächen aber keine Benutzer mehr in dieser Domain anlegen.

Im Microsoft 36 Admin Center wird die federierte Domain einfach nicht mehr angeboten:

Federated User im Entra ID Portal anlegen - Nein

In Entra-ID/Azure-AD Admin Center kann ich die Domain noch auswählen aber beim "Create" liefert mit das Admin Center dann den Fehler, dass der "SourceAnchor" nicht gefüllt aber für federierte Benutzer zwingend erforderlich ist.

 

Der Link "Help me Troubletshoot" liefert mit Copilot gar nicht mal so schlechte Ergebnisse.

 

Allerdings passen die Hinweise zu Entra ID Connect natürlich nicht zum Prozess einer manuellen Anlage.

Federated User mit Graph anlegen

Ein eigene Identity-Verwaltung wird heute solche Benutzer per Graph-API anlegen. Ich habe mit MGUser diesen Prozess für eine solche Domain versucht und natürlich den gleichen Fehler bekommen:

 

New-MgUser_CreateExpanded: SourceAnchor is a required property for creation of a federated user. 

Der Benutzer konnte aber angelegt, werden, wenn ich direkt auch das Feld "OnPremisesImmutableId" mit einem Wert versehen habe:

New-MgUser `
   -DisplayName 'IDPUser1' `
   -AccountEnabled  `
   -MailNickname "IDPUser1" `
   -UserPrincipalName "idpuser1@msxfaqdev.de" `
   -OnPremisesImmutableId "idpuser1@msxfaqdev.de"

Sie müssen bei einer Anlagen eines Benutzers kein Kennwort angeben. Sie können aber schon ein Kennwort wie folgt mitgeben, z.B. wenn Sie die Federation später mal abschalten

   -PasswordProfile @{Password = "HiereinsicheresStartkennwort2025!" } `

Denken Sie daran, dass der Wert für "OnPremisesImmutableID" auf jeden Fall "eindeutig" und unveränderlich sein soll. Am besten ist es also eine GUID oder Nummer und nicht gerade ein UPN oder Mailadresse, die sich bei einer Heirat auch mal ändern. Die ID muss weltweit eindeutig sein!

Der Wert muss vom lokalen IDP-System als NameID mit gesendet werden und wird daher idealerweise auch von diesem Identity Management System verwaltet und gesetzt.

Federated User mit New-Mailbox anlegen

Die Exchange Online PowerShell ist durchaus leistungsfähig und sie können mit New-Mailbox direkt "Cloud Only"Postfächer anlegen. Die Exchange PowerShell legt dazu im Hintergrund auch einen Benutzer in Entra ID an. New-Mailbox in Exchange Online kennt leider den Parameter "UserPrincipalName" nicht. Stattdessen müssen Sie "MicrosoftOnlineServicesID" nutzen. Dennoch haben meine ersten drei Versuche nur Fehler geliefert:

Die Fehlermeldung war teils deutsch und teils englisch. Einmal haben die Parameter nicht zusammengepasst und zweimal gab es einen deutlichen Hinweis, dass es sich um ein verwaltetes Konto mi Federation (Verbund) handelt. Daher habe ich weitere Konstellationen getestet und es ist mir tatsächlich gelungen, per PowerShell einen Benutzer mit Postfach für eine federierte Domain anzulegen. Die Mindestparameter sind dabei:

New-Mailbox `
   -Name                      "feduser2name" `
   -MicrosoftOnlineServicesID "feduser2a@msxfaqdev.de" `
   -ImmutableId               "feduser2immutable" `
   -FederatedIdentity         "feduser2fed@msxfaqdev.de" 

Als Ergebnis sind folgende Felder mit den davon abgeleiteten Werten gefüllt:

UserPrincipalName               : feduser2a@msxfaqdev.de
WindowsLiveID                   : feduser2a@msxfaqdev.de
MicrosoftOnlineServicesID       : feduser2a@msxfaqdev.de
ImmutableId                     : feduser2immutable
Alias                           : feduser2a
DisplayName                     : feduser2name
EmailAddresses                  : {smtp:feduser2a@msxfaqdev.onmicrosoft.com,
                                   SMTP:feduser2a@msxfaqdev.de}
PrimarySmtpAddress              : feduser2a@msxfaqdev.de
RecipientTypeDetails            : UserMailbox
WindowsEmailAddress             : feduser2a@msxfaqdev.de
Identity                        : feduser2name
Id                              : feduser2name
Name                            : feduser2name

Sie sehen gut, dass z.B. der Alias aus dem Userpart der "MicrosoftOnlineServicesID" abgeleitet wird.

Es gibt aber auch anderen gültige Aufrufe, die nach meinem Wissen aber funktionsunfähige Benutzer anlegen, z.B.

New-Mailbox `
   -Name                      "feduser4" `
   -MicrosoftOnlineServicesID "feduser4a@msxfaqdev.de" `
   -FederatedIdentity         "feduser4b@msxfaqdev.de"

Wenn Sie keine ImmutableID angeben, dann ist das Feld leer. Damit dürfte eine Anmeldung per Federation und NameID nicht möglich sind

UserPrincipalName               : feduser4a@msxfaqdev.de
WindowsLiveID                   : feduser4a@msxfaqdev.de
MicrosoftOnlineServicesID       : feduser4a@msxfaqdev.de
ImmutableId                     :                <-----------------leer !
Alias                           : feduser4a
DisplayName                     : feduser4
EmailAddresses                  : {SMTP:feduser4a@msxfaqdev.de}
PrimarySmtpAddress              : feduser4a@msxfaqdev.de
RecipientTypeDetails            : UserMailbox
WindowsEmailAddress             : feduser4a@msxfaqdev.de
Identity                        : feduser4
Id                              : feduser4
Name                            : feduser4

Sie können natürlich auch noch weitere optionale Werte mit angeben, die dann in die entsprechenden Felder übernommen werden

New-Mailbox `
   -Name                        "feduser1name" `
   -MicrosoftOnlineServicesID   "feduser1a@msxfaqdev.de" `
   -Alias                       "feduser1alias" `
   -DisplayName                 "Feduser1display" `
   -ImmutableId                 "feduser1immutable" `
   -FederatedIdentity           "feduser1fed@msxfaqdev.de" `
   -PrimarySmtpAddress          "feduser1mail@msxfaqdev.de"

Die Inhalte finden sich dann in den Feldern:

PS C:\> get-mailbox feduser1alias | fl *

IsMailboxEnabled                : True
IsLinked : False
LinkedMasterAccount             :
SamAccountName                  : $C2R052-O01PE454PHHH
UserPrincipalName               : feduser1a@msxfaqdev.de
WindowsLiveID                   : feduser1a@msxfaqdev.de
MicrosoftOnlineServicesID       : feduser1a@msxfaqdev.de
ImmutableId                     : feduser1immutable
Alias                           : feduser1alias
DisplayName                     : Feduser1display
EmailAddresses                  : {smtp:feduser1alias@msxfaqdev.onmicrosoft.com,
                                  smtp:feduser1a@msxfaqdev.de,
                                  SMTP:feduser1mail@msxfaqdev.de}
LegacyExchangeDN                : /o=ExchangeLabs/ou=Exchange
                                  Administrative Group (FYDIBOHF23SPDLT)
                                  /cn=Recipients/cn=8e3.....-feduser1nam
PrimarySmtpAddress              : feduser1mail@msxfaqdev.de
RecipientTypeDetails            : UserMailbox
WindowsEmailAddress             : feduser1mail@msxfaqdev.de
Identity :feduser1name
Id       :feduser1name
Name     :feduser1name

Es gibt also einen Weg, auch über die Exchange Online PowerShell eine Mailbox samt Entra ID mit einer federierten Domain anzulegen. Allerdings müssen Sie die richtigen Parameter setzen und insbesondere die ImmutableID sollten Sie immer setzen.

Mir hat sich noch nicht erschlossen, welche Funktion das Feld "FederatedIdentity" in dem Umfeld hat.

Federated User im EAC anlegen - nur Shared Mailbox

Zuletzt habe ich noch versucht eine Mailbox im Exchange Online Admin Center für eine federierte Domain anzulegen. Auf den ersten Block fällt schon einmal auf, dass Sie im Exchange Online Admin Center gar keine Benutzer-Postfächer anlegen können. Ich kann in meinem Tenant nur eine "Shared Mailbox" anlegen.

Das gelingt aber auch mit federierten Domain und folgende Felder werden so gesetzt:

ExchangeUserAccountControl      : AccountDisabled
UserPrincipalName               : fedshared1@msxfaq.net
WindowsLiveID                   : fedshared1@msxfaq.net
MicrosoftOnlineServicesID       : fedshared1@msxfaq.net
ImmutableId                     : feduser1immutable
AccountDisabled                 : True
IsDirSynced                     : False
Alias                           : fedshared1
DisplayName                     : fedshared1
EmailAddresses                  : {smtp:fedshared1@msxfaq.net, 
                                   SMTP:fedshared1@msxfaqdev.de}
PrimarySmtpAddress              : fedshared1@msxfaqdev.de
RecipientTypeDetails            : SharedMailbox
WindowsEmailAddress             : fedshared1@msxfaqdev.de
Maentity                        : fedshared1
Id                              : fedshared1
Name                            : fedshared1

Die Shared Mailbox ist natürlich dein deaktiviertes Konto, an dem ich mich nicht direkt anmelden kann und damit muss auch keine ImmutableID nicht für eine Federation vorhanden sein. Das Exchange Online Admin Center erlaubt aber auch nur die Eingabe von Displayname, Mailadresse und Alias. Wenn Sie die Details genau anschauen, dann sehen Sie die korrekte primäre Mailadresse "fedshared1@msxfaqdev.de" aber der UserPrincipalName lautet auf eine andere Domain "fedshared1@msxfaq.net". Das ist die "Primäre Domain" in meinem Tenant. Wenn Sie weiter oben noch mal lesen, dann wissen Sie um die Besonderheit der "Primären Domain" und einer federierten Domain.

Shared Mailbox mit Federated Domain

Also wollte ich wissen, was hier per PowerShell möglich ist. Ich habe verschiedene Kombinationen von "New-Mailbox" aus probiert, Sobald ich den Parameter "-Shared" addiert habe, konnte ich die nur noch eine Teilmenge der Parameter angeben.

((get-command new-mailbox -ShowCommandInfo).parametersets `
    | where {$_.name -eq "Shared"} `
).parameters | ft name,IsMandatory

Name                        IsMandatory
----                        -----------
ActiveSyncMailboxPolicy           False
Alias                             False
Archive                           False
DisplayName                       False
FirstName                         False
Force                             False
ImmutableId                       False
Initials                          False
LastName                          False
MailboxRegion                     False
ModeratedBy                       False
ModerationEnabled                 False
Name                               True
Password                          False
PrimarySmtpAddress                False
RemotePowerShellEnabled           False
ResetPasswordOnNextLogon          False
RoleAssignmentPolicy              False
SendModerationNotifications       False
Shared                             True
TargetAllMDBs                     False

Sie finden hier keine Option, einen "UserPrincipalName" bzw. "MicrosoftOnlineServicesID" oder eine "FederatedIdentity" anzugeben. Die Parameter entfallen, sobald Sie den Parameter "Shared" anlegen. Knifflig wird es nun, wenn die "Primary Domain" entgegen den Empfehlungen von Microsoft auch noch mittels Federation verbunden ist. Die Neuanlage mittels New-Mailbox funktioniert nicht, da die Parameter nicht mit:

Allerdings geht der umgekehrte Weg. Sie können eine Mailbox mit Federation der primären Domain anlegen und diese nachträglich dann zu einer Shared Mailbox konvertieren.

Damit können Sie dann auch mit der Exchange Online PowerShell direkt eine ShareMailbox anlegen und den UPN "richtig " setzen. Also haben wir nun drei Optionen:

  • "New-Mailbox -shared" mit managed Primary Domain
    Wenn die primäre Domains nicht zugleich federiert ist, dann können Sie einfach eine Shared Mailbox anlegen. Der UPN der Mailbox wird dann anhand der primären Domain gebildet und einen fehlende ImmutableID stört nicht
  • "New-Mailbox" und dann "Set-Mailbox -type shared"
    Da ein "Set-Mailbox -Shared" nicht die Angabe eines UPN erlaubt, können Sie eine reguläre Mailbox mit "Set-Mailbox" auch für eine federierte Domain anlegen und diese in einem zweiten Schritt dann zu einer Shared Mailbox konvertieren
  • New-MGUser und "Enable-mailbox -shared"
    Der aus meiner Sicht sauberste Weg ist aber die Anlage des Entra ID-Kontos mittels Graph mit den gewünschten Eigenschaften um dieses Konto danach als Shared Mailbox zu aktivieren.

 

Ich würde generell überlegen, ob Sie "New-*"-Commandlets in Exchange Online verwenden wollen und damit quasi "durch die Hintertür" Objekte in Entra ID anlegen.
Es dürfte nur eine Frage der Zeit sein bis Microsoft dieses Privileg der Exchange Online Administratoren irgendwann auf die Entra ID User Management Rolle beschränkt. Bei Kontakten ist schon
Updates to Get-Contact and Set-Contact Cmdlets for “Contacts” Recipient Type in Exchange Online
https://techcommunity.microsoft.com/blog/exchange/updates-to-get-contact-and-set-contact-cmdlets-for-%E2%80%9Ccontacts%E2%80%9D-recipient-type-in-/4459678

Dokumente und Links

Download Office 365 SAML 2.0 Federation Implementers Guide from Official Microsoft Download Center
https://www.microsoft.com/en-us/download/details.aspx?id=42041&msockid=080bdba6505368b91cc6cd3a51176988

Microsoft 365 FederationMetadata
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

NetIQ Configuring Single Sign-On For Office 365 Services
https://www.netiq.com/documentation/netiqaccessmanager4/resources/office365.pdf

Weitere Links