Freigeben über

Verwenden eines SAML 2.0-Identitätsanbieters (IdP, Identity Provider) für einmaliges Anmelden

  • Artikel

Dieses Dokument enthält Informationen zur Verwendung des mit dem SP-Lite-Profil kompatiblen SAML 2.0-Identitätsanbieters als bevorzugter Sicherheitstokendienst (STS) bzw. Identitätsanbieter. Dieses Szenario ist hilfreich, wenn Sie bereits lokal über einen Speicher für das Benutzerverzeichnis und Kennwort verfügen, auf den mithilfe von SAML 2.0 zugegriffen werden kann. Dieses vorhandene Benutzerverzeichnis kann für die Anmeldung bei Microsoft 365 und anderen mit Microsoft Entra ID gesicherten Ressourcen verwendet werden. Das SAML 2.0-SP-Lite-Profil basiert auf dem häufig verwendeten Verbund-Identitätsstandard Security Assertion Markup Language (SAML), um das einmalige Anmelden zu ermöglichen und ein Framework für den Austausch von Attributen bereitzustellen.

Hinweis

Eine Liste der Drittanbieter-IdPs, die für die Verwendung mit Microsoft Entra ID getestet wurden, finden Sie in der Microsoft Entra-Verbund – Kompatibilitätsliste.

Microsoft unterstützt diese Anmeldung als Integration von Microsoft-Clouddiensten, z. B. Microsoft 365, mit Ihrem ordnungsgemäß konfigurierten, auf dem SAML 2.0-Profil basierten IdP. Es handelt sich bei SAML 2.0-Identitätsanbieter um Drittanbieterprodukte, und Microsoft bietet deshalb keinen Support für die Bereitstellung, Konfiguration und Problembehandlung sowie keine bewährten Methoden dafür. Sobald die Integration mit dem SAML 2.0-Identitätsanbieter ordnungsgemäß konfiguriert ist, kann dieser für die Konfiguration mithilfe des Microsoft-Verbindungsuntersuchungstools verwendet werden, wie weiter unten ausführlicher beschrieben wird. Weitere Informationen zu Ihrem auf dem SAML 2.0 SP-Lite-Profil basierten Identitätsanbieter erhalten Sie bei der Organisation, die ihn bereitgestellt hat.

Wichtig

In diesem Anmeldeszenario mit SAML 2.0-Identitätsanbietern ist nur eine begrenzte Anzahl von Clients verfügbar, einschließlich:

  • Webbasierte Clients wie Outlook Web Access und SharePoint Online
  • E-Mail-Clients, die die Standardauthentifizierung sowie eine unterstützte Exchange-Zugriffsmethode verwenden, wie IMAP, POP, Active Sync, MAPI usw. (Der Endpunkt des erweiterten Clientprotokolls muss bereitgestellt werden). Dazu zählen:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (verschiedene iOS-Versionen)
    • Verschiedene Google Android-Geräte
    • Windows Phone 7, Windows Phone 7.8 und Windows Phone 8.0
    • E-Mail-Client für Windows 8 und Windows 8.1
    • E-Mail-Client für Windows 10

Alle anderen Clients sind nicht in diesem Anmeldeszenario mit Ihrem SAML 2.0-Identitätsanbieter verfügbar. Beispielsweise kann sich der Lync 2010-Desktopclient nicht beim Dienst mit Ihrem SAML 2.0-Identitätsanbieter anmelden, der für einmaliges Anmelden konfiguriert ist.

Microsoft Entra SAML 2.0-Protokollanforderungen

Dieses Dokument enthält detaillierte Anforderungen hinsichtlich der Protokoll- und Benachrichtigungsformatierung, die Ihr SAML 2.0-Identitätsanbieter implementieren muss, um einen Verbund mit Microsoft Entra ID zu bilden, damit die Anmeldung bei mehr als einem Microsoft-Clouddienst (wie Microsoft 365) aktiviert werden kann. Die vertrauende SAML 2.0-Seite (SP-STS) für einen Microsoft-Clouddienst, die in diesem Szenario verwendet wird, ist Microsoft Entra ID.

Sie sollten sicherstellen, dass die ausgehenden Nachrichten Ihres SAML 2.0-Identitätsanbieters den bereitgestellten Beispielablaufverfolgungen so ähnlich wie möglich sind. Verwenden Sie wo möglich auch die spezifischen Attributwerte aus den bereitgestellten Microsoft Entra-Metadaten. Wenn Sie mit den Ausgabenachrichten zufrieden sind, können Sie mit der Microsoft-Verbindungsuntersuchung wie unten beschrieben Tests durchführen.

Die Microsoft Entra-Metadaten können unter dieser URL heruntergeladen werden: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Für Kunden in China, die die für China bestimmte Instanz von Microsoft 365 nutzen, sollte der folgende Verbundendpunkt verwendet werden: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

SAML-Protokollanforderungen

In diesem Abschnitt wird beschrieben, wie die Anforderungs- und Anwortbenachrichtigungspaare zusammengefügt werden, damit Sie Ihre Benachrichtigungen richtig formatieren können.

Microsoft Entra ID kann für die Arbeit mit Identitätsanbietern konfiguriert werden, die dasselbe SAML 2.0-SP Lite-Profil mit einigen bestimmten Anforderungen verwenden, so wie nachstehend aufgeführt. Mithilfe der Anforderungs- und Antwortbeispielbenachrichtigungen von SAML sowie mit automatischen und manuellen Tests können Sie Interoperabilität mit Microsoft Entra ID erreichen.

Signaturblockanforderungen

In der SAML-Antwortnachricht enthält der Signaturknoten Informationen über die digitale Signatur für die Benachrichtigung selbst. Der Signaturblock besitzt folgende Anforderungen:

  1. Der Assertionsknoten selbst muss signiert sein
  2. Der RSA-sha1-Algorithmus muss als DigestMethod verwendet werden. Andere Algorithmen für digitale Signaturen werden nicht akzeptiert. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. Sie können auch das XML-Dokument signieren.
  4. Der Transformationsalgorithmus muss den Werten im folgenden Beispiel entsprechen: <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
  5. Der SignatureMethod-Algorithmus muss mit folgendem Beispiel übereinstimmen: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Hinweis

Um die Sicherheit zu verbessern, wird der SHA-1-Algorithmus nicht mehr verwendet. Stellen Sie sicher, dass Sie einen sichereren Algorithmus wie SHA-256 verwenden. Weitere Informationen finden Sie hier.

Unterstützte Bindungen

Bindungen sind die transportbezogenen Kommunikationsparameter, die erforderlich sind. Die folgenden Anforderungen gelten für die Bindungen

  1. HTTPS ist der erforderliche Transport.
  2. Microsoft Entra ID erfordert HTTP POST für die Tokenübermittlung während der Anmeldung.
  3. Microsoft Entra ID verwendet HTTP POST für die Authentifizierungsanforderung an den Identitätsanbieter und REDIRECT für die Abmeldenachricht an den Identitätsanbieter.

Erforderliche Attribute

Diese Tabelle zeigt die Anforderungen für bestimmte Attribute in der SAML 2.0-Benachrichtigung.

attribute BESCHREIBUNG
NameID Der Wert dieser Assertion muss mit der ImmutableID des Microsoft Entra-Benutzers identisch sein. Er kann bis zu 64 alphanumerische Zeichen lang sein. Alle sicheren Nicht-HTML-Zeichen müssen codiert werden, z.B. wird ein „+“-Zeichen als „.2B“ angezeigt.
IDPEmail Der Benutzerprinzipalname (User Principal Name, UPN) ist in der SAML-Antwort als Element mit dem Namen „IDPEmail“ aufgeführt. Dieser ist der UPN des Benutzers in Microsoft Entra ID / Microsoft 365. Der UPN ist im E-Mail-Adressformat. UPN-Wert in Windows Microsoft 365 (Microsoft Entra ID).
Issuer (Aussteller) Dies muss ein URI des Identitätsanbieters sein. Der Aussteller aus der Beispielbenachrichtigung sollte nicht wiederverwendet werden. Wenn Sie mehrere Domänen der obersten Ebene in Ihrem Microsoft Entra-Mandanten verfügen, muss der Aussteller mit der pro Domäne konfigurierten URI-Einstellung übereinstimmen.

Wichtig

Microsoft Entra ID unterstützt aktuell den folgenden NameID-Format-URI für SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

SAML-Anforderungs- und Antwortbeispielbenachrichtigungen

Ein Anforderungs- und Antwortbenachrichtigungspaar wird für den Nachrichtenaustausch bei der Anmeldung angezeigt. Dies ist eine Beispielanforderungsnachricht, die von Microsoft Entra ID an einen SAML 2.0-Beispielidentitätsanbieter gesendet wird. Der SAML 2.0-Beispielidentitätsanbieter ist mit AD FS zur Verwendung des SAML-P-Protokolls konfiguriert. Interoperabilitätstests wurden auch mit anderen SAML 2.0-Identitätsanbietern ausgeführt.

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" 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>

Wenn isSignedAuthenticationRequestRequired wie in internaldomainfederation-updateerläutert aktiviert ist, würde die Anforderung wie in diesem Beispiel aussehen:

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Dies ist eine Beispielantwortnachricht, die von dem mit SAML 2.0 kompatiblen Beispielidentitätsanbieter an Microsoft Entra ID/Microsoft 365 gesendet wird.

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

Konfigurieren Ihres mit SAML 2.0 kompatiblen Identitätsanbieters

Dieser Abschnitt enthält Richtlinien zum Konfigurieren Ihres SAML 2.0-Identitätsanbieters für einen Verbund mit Microsoft Entra ID für die Aktivierung des einmaligen Anmeldens für den Zugriff auf einen oder mehrere Microsoft-Clouddienste (z. B. Microsoft 365) mithilfe des SAML 2.0-Protokolls. Die vertrauende SAML 2.0-Seite für einen Microsoft-Clouddienst, die in diesem Szenario verwendet wird, ist Microsoft Entra ID.

Hinzufügen von Microsoft Entra-Metadaten

Ihr SAML 2.0-Identitätsanbieter muss sich nach Informationen über die vertrauende Microsoft Entra-Seite richten. Microsoft Entra ID veröffentlicht Metadaten unter https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Es wird empfohlen, beim Konfigurieren Ihres SAML 2.0-Identitätsanbieters immer die aktuellen Microsoft Entra-Metadaten zu importieren.

Hinweis

Microsoft Entra ID liest keine Metadaten vom Identitätsanbieter.

Hinzufügen von Microsoft Entra ID als vertrauende Seite

Sie müssen die Kommunikation zwischen Ihrem SAML 2.0-Identitätsanbieter und Microsoft Entra ID aktivieren. Diese Konfiguration ist abhängig von Ihrem spezifischen Identitätsanbieter. Informationen hierzu entnehmen Sie bitte der Dokumentation. Sie würden die ID der vertrauenden Seite in der Regel auf den gleichen Wert wie die EntityID aus den Microsoft Entra-Metadaten festlegen.

Hinweis

Stellen Sie sicher, dass die Uhr auf dem Server Ihres SAML 2.0-Identitätsanbieters mit einer genauen Zeitquelle synchronisiert ist. Eine ungenaue Zeitangabe kann zu Fehlern bei Verbundanmeldungen führen.

Installieren von PowerShell für die Anmeldung mit SAML 2.0-Identitätsanbieter

Nachdem Sie Ihren SAML 2.0-Identitätsanbieter für die Verwendung mit der Microsoft Entra-Anmeldung konfigurieren haben, besteht der nächste Schritt darin, das Microsoft Graph PowerShell-Modul herunterzuladen und zu installieren. Nach Abschluss der Installation verwenden Sie diese Cmdlets zum Konfigurieren Ihrer Microsoft Entra-Domänen als Verbunddomänen.

Das Microsoft Graph PowerShell-Modul ist ein Download für die Verwaltung Ihrer Organisationsdaten in Microsoft Entra ID. Dieses Modul installiert eine Reihe von Cmdlets in PowerShell. Sie führen diese Cmdlets zum Einrichten des einmaligen Anmeldens für den Zugriff auf Microsoft Entra ID aus, und somit auch auf alle Cloud-Dienste, die Sie abonniert haben. Anweisungen zum Herunterladen und Installieren dieser Cmdlets finden Sie unter Installieren des Microsoft Graph PowerShell-SDK.

Einrichten einer Vertrauensstellung zwischen Ihrem SAML-Identitätsanbieter und Microsoft Entra ID

Bevor ein Verbund für eine Microsoft Entra-Domäne konfiguriert wird, muss zuerst eine benutzerdefinierte Domäne konfiguriert werden. Sie können keinen Verbund für die Standarddomäne erstellen, die von Microsoft bereitgestellt wird. Die Standarddomäne von Microsoft endet mit onmicrosoft.com. Sie werden eine Reihe von PowerShell-Cmdlets ausführen, um Domänen für einmaliges Anmelden hinzuzufügen oder zu konvertieren.

Jede Microsoft Entra-Domäne, für die Sie einen Verbund mithilfe Ihres SAML 2.0-Identitätsanbieters erstellen möchten, muss entweder als eine Domäne für einmaliges Anmelden hinzugefügt oder als Domäne für einmaliges Anmelden von einer Standarddomäne konvertiert werden. Durch das Hinzufügen oder Konvertieren einer Domäne wird eine Vertrauensstellung zwischen Ihrem SAML 2.0-Identitätsanbieter und Microsoft Entra ID eingerichtet.

Das folgende Verfahren führt Sie durch das Konvertieren einer vorhandenen Standarddomäne zu einer Verbunddomäne mithilfe von SAML 2.0 SP-Lite.

Hinweis

Nach Ausführung dieses Schritts kommt es in Ihrer Domäne möglicherweise zu einem Ausfall, der Benutzer bis zu zwei Stunden lang betreffen kann.

Konfigurieren einer Domäne im Microsoft Entra-Verzeichnis für den Verbund

  1. Stellen Sie in der Rolle eines Mandantenadministrators eine Verbindung mit Ihrem Microsoft Entra-Verzeichnis her:

    Connect-MgGraph -Scopes "Domain.ReadWrite.All"

  2. Konfigurieren Sie Ihre gewünschte Microsoft 365-Domäne zur Verwendung eines Verbunds mit SAML 2.0:

    $Domain = "contoso.com"  
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
$MyUri = "urn:uri:MySamlp2IDP"
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
$MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
$Protocol = "saml"

New-MgDomainFederationConfiguration `
  -DomainId $Domain `
  -ActiveSignInUri $ecpUrl `
  -IssuerUri $MyUri `
  -PassiveSignInUri $LogOnUrl `
  -PreferredAuthenticationProtocol $Protocol `
  -SignOutUri $LogOffUrl `
  -SigningCertificate $MySigningCert

  3. Sie können die base64-codierte Zeichenfolge des Signaturzertifikats aus Ihrer IDP-Metadatendatei abrufen. Ein Beispiel für diesen Speicherort finden Sie unten. Dies kann jedoch abhängig von Ihrer Implementierung variieren.

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="signing">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
     <X509Data>
       <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
</IDPSSODescriptor>

Weitere Informationen finden Sie unter New-MgDomainFederationConfiguration.

Hinweis

Sie müssen $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" nur verwenden, wenn Sie eine ECP-Erweiterung für Ihren Identitätsanbieter einrichten. Exchange Online-Clients mit Ausnahme von Outlook Web Application (OWA) basieren auf einem auf POST basierenden aktiven Endpunkt. Wenn Ihr SAML 2.0-STS einen aktiven Endpunkt implementiert, der der ECP-Implementierung von Shibboleth von einem aktiven Endpunkt ähnelt, können diese Rich Clients möglicherweise mit dem Exchange Online-Dienst interagieren.

Nachdem der Verbund konfiguriert wurde, können Sie zurück zu „ohne Verbund“ (oder „verwaltet“) wechseln. Diese Änderungen benötigen jedoch bis zu zwei Stunden und erfordern die Zuweisung neuer zufälliger Kennwörter für die cloudbasierte Anmeldung für jede*n Benutzer*in. Das Zurückwechseln zu „verwaltet“ ist in einigen Szenarios möglicherweise erforderlich, um einen Fehler in Ihren Einstellungen zurückzusetzen. Weitere Informationen zum Domänenwechsel finden Sie unter Remove-MgDomainFederationConfiguration.

Bereitstellen von Benutzerprinzipalen für Microsoft Entra ID/Microsoft 365

Bevor Sie Ihre Benutzer mit Microsoft 365 authentifizieren können, müssen Sie Microsoft Entra ID mit Benutzerprinzipalen bereitstellen, die mit der Assertion im SAML 2.0-Anspruch übereinstimmen. Wenn Microsoft Entra ID diese Benutzerprinzipale nicht im Voraus kennt, können sie nicht für die Verbundanmeldung verwendet werden. Microsoft Entra Connect oder PowerShell kann verwendet werden, um Benutzerprinzipale bereitzustellen.

Microsoft Entra Connect kann zum Bereitstellen von Prinzipalen für Ihre Domänen in Ihrem Microsoft Entra-Verzeichnis aus dem lokalen Active Directory verwendet werden. Ausführlichere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in Microsoft Entra ID.

PowerShell kann auch zum Automatisieren des Hinzufügens neuer Benutzer zu Microsoft Entra ID und zum Synchronisieren von Änderungen aus dem lokalen Verzeichnis verwendet werden. Um die PowerShell-Cmdlets zu verwenden, müssen Sie das Microsoft Graph PowerShell-Modul herunterladen.

Diese Prozedur zeigt, wie Microsoft Entra ID ein einzelner Benutzer hinzugefügt wird.

  1. Stellen Sie mithilfe von Connect-MgGraph als Mandantenadministrator*in eine Verbindung mit Ihrem Microsoft Entra-Verzeichnis her.

  2. Erstellen Sie einen neuen Benutzerprinzipal:

    $Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$PasswordProfile = @{ Password = "$Password" }

New-MgUser `
  -UserPrincipalName "elwoodf1@contoso.com" `
  -DisplayName "Elwood Folk" `
  -GivenName "Elwood" `
  -Surname "Folk" `
  -AccountEnabled `
  -MailNickName 'ElwoodFolk' `
  -OnPremisesImmutableId ABCDEFG1234567890 `
  -OtherMails "Elwood.Folk@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -UsageLocation "US"

Weitere Informationen finden Sie unter New-MgUser.

Hinweis

Der Wert „UserPrincipalName“ muss mit dem Wert übereinstimmen, den Sie für „IDPEmail“ in Ihrem SAML 2.0-Anspruch senden, und der Wert „OnPremisesImmutableId“ muss mit dem Wert übereinstimmen, der in Ihrer „NameID“-Assertion gesendet wurde.

Überprüfen des einmaligen Anmeldens mit Ihrem SAML 2.0-IdP

Bevor Sie als Administrator das einmalige Anmelden (auch als Identitätsverbund bekannt) überprüfen und verwalten, überprüfen Sie die Informationen, und führen Sie die Schritte in den folgenden Artikeln aus, um das einmalige Anmelden mit Ihrem auf SAML 2.0 SP-Lite basierenden Identitätsanbieter einzurichten.

  1. Sie haben die Microsoft Entra-SAML 2.0-Protokollanforderungen überprüft.
  2. Sie haben Ihren SAML 2.0-Identitätsanbieter konfiguriert.
  3. Installieren von PowerShell für einmaliges Anmelden (SSO) mit dem SAML 2.0-Identitätsanbieter
  4. Einrichten einer Vertrauensstellung zwischen einem SAML 2.0-Identitätsanbieter und Microsoft Entra ID
  5. Es wurde ein bekannter Testbenutzerprinzipal über PowerShell oder Microsoft Entra Connect an Microsoft Entra ID (Microsoft 365) bereitgestellt.
  6. Konfigurieren Sie die Verzeichnissynchronisierung mithilfe von Microsoft Entra Connect.

Nach dem Einrichten des SSO mit Ihrem auf SAML 2.0 SP-Lite basierenden Identitätsanbieter müssen Sie überprüfen, ob dieser ordnungsgemäß funktioniert. Weitere Informationen zum Testen von SAML-basierten SSO finden Sie unter Testen von SAML-basiertem einmaligen Anmelden.

Hinweis

Wenn Sie eine Domäne konvertiert haben, statt eine hinzuzufügen, kann die Einrichtung des einmaligen Anmeldens bis zu 24 Stunden dauern. Bevor Sie das einmalige Anmelden überprüfen, müssen Sie die Einrichtung der Active Directory-Synchronisierung abgeschlossen, Ihre Verzeichnisse synchronisiert und Ihre synchronisierten Benutzer aktiviert haben.

Manuelle Bestätigung, dass einmaliges Anmelden ordnungsgemäß eingerichtet wurde

Die manuelle Überprüfung bietet zusätzliche Schritte, die Sie vornehmen können, um sicherzustellen, dass Ihr SAML 2.0-Identitätsanbieter in vielen Szenarios korrekt ausgeführt wird. Um zu überprüfen, dass einmaliges Anmelden ordnungsgemäß eingerichtet ist, führen Sie die folgenden Schritte aus:

  1. Melden Sie sich auf einem mit einer Domäne verbundenen Computer bei Ihrem Clouddienst an. Nutzen Sie dafür den Anmeldenamen, den Sie für Ihre Unternehmensanmeldeinformationen verwenden.
  2. Wählen Sie das Kennwortfeld aus. Wenn das einmalige Anmelden eingerichtet wird, ist das Anmeldefeld ausgegraut, und Ihnen wird die folgende Meldung angezeigt: „Sie müssen sich nun bei <Ihrem Unternehmen> anmelden.“
  3. Klicken Sie auf den Link zum Anmelden bei <Ihrem Unternehmen>. Wenn Sie sich anmelden können, wurde das einmalige Anmelden eingerichtet.

Nächste Schritte