Verwenden eines SAML 2.0-Identitätsanbieters zum Implementieren eines einmaligen Anmeldens

Gilt für: Azure, Office 365, Power BI, Windows Intune

Dieses Thema enthält Hinweise für Lösungsimplementierer eines Microsoft Cloud-Diensts, die ihren Azure Active Directory-Benutzern (AD) die Möglichkeit zum einmaligen Anmelden mithilfe eines mit SAML 2.0 kompatiblen Identitätsanbieters, der auf dem SP-Lite-Profil basiert, als bevorzugtem Sicherheitstokendienst (STS)/Identitätsanbieter bieten möchten. Dies ist sinnvoll, wenn der Lösungsimplementierer bereits ein Benutzerverzeichnis und einen Kennwortspeicher lokal eingerichtet hat, auf das bzw. den mithilfe von SAML 2.0 zugegriffen werden kann. Dieses vorhandene Benutzerverzeichnis kann für die Anmeldung bei Office 365 und anderen mit Azure AD 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.

Microsoft unterstützt diese Anmeldeerfahrung als die Integration eines Microsoft Cloud-Diensts (z. B. Office 365) in Ihren ordnungsgemäß konfigurierten Identitätsanbieter, der auf dem SAML 2.0-Profil basiert. Dieser wird im Folgenden als SAML 2.0-Identitätsanbieter bezeichnet. 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

Drittanbieter von SAML-Anbietern werden mit Modern Auth Office 365 Clients unterstützt, ohne dass sie mit dem Works with Office 365-Programm überprüft werden müssen.  Weitere Informationen finden Sie in Office 365 SAML 2.0 Federation Implementer's Guide.

Die folgenden Clients stehen auch in diesem Anmeldeszenario mit SAML 2.0-Identitätsanbietern zur Verfügung:

• Webbasierte Clients wie Outlook Web Access und SharePoint Online
  
  
• E-Mail-Clients, die die Standardauthentifizierung sowie eine unterstützte Exchange-Zugriffsmethode wie IMAP, POP, Aktive Sync, MAPI usw. verwenden (der Endpunkt des erweiterten Clientprotokolls muss bereitgestellt werden), einschließlich:
  
  
  1. Microsoft Outlook 2010, Microsoft Outlook 2013, Word 2013, Excel 2013, PowerPoint 2013, Skype for Business 2013, Publisher 2013, Viso 2013, Access 2013, Project 2013 und OneDrive for Business Synchronisierungsclient.
     
     
  2. Apple iPhone (verschiedene iOS Versionen)
     
     
  3. Verschiedene Google Android-Geräte
     
     
  4. Windows Phone 7, Windows Phone 7.8 und Windows Phone 8.0
     
     
  5. E-Mail-Client für Windows 8 und Windows 8.1
     
     

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 mehr beim Dienst mit Ihrem SAML 2.0-Identitätsanbieter anmelden, der für einmaliges Anmelden konfiguriert ist.

Wichtig

Als Voraussetzung für das Starten der nachstehenden Schritte überprüfen Sie die Vorteile, Die Benutzerfreundlichkeit und die Anforderungen der einmaligen Anmeldung in Vorbereitung auf einmaliges Anmelden.

Azure AD SAML 2.0-Protokollanforderungen

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

Es wird empfohlen, sicherzustellen, dass die Ausgabenachrichten Ihres SAML 2.0-Identitätsanbieters den bereitgestellten Beispielablaufverfolgungen so ähnlich wie möglich sind. Verwenden Sie auch wenn möglich die bestimmten Attributwerte aus den bereitgestellten Azure AD-Metadaten. Wenn Sie mit den Ausgabenachrichten zufrieden sind, können Sie mit der Microsoft-Verbindungsuntersuchung wie unten beschrieben Tests durchführen.

Die Azure AD-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 Office 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.

Azure AD 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, zusammen mit automatischen und manuellen Tests, können Sie Interoperabilität mit Azure AD erreichen.

Signaturblockanforderungen

In der SAML-Anforderungsbenachrichtigung 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="http://www.w3.org/2000/09/xmldsig#sha1"/>
   

3. Sie können auch das XML-Dokument signieren.

4. Der Transformationsalgorithmus muss mit den Werten im folgenden Beispiel übereinstimmen:

   <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   

5. Der SignatureMethod-Algorithmus muss mit dem folgenden Beispiel übereinstimmen:

   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
   

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. Azure AD erfordert HTTP POST für die Tokenübermittlung während der Anmeldung

3. Azure AD 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.

NameID	Der Wert dieser Assertion muss mit der ImmutableID des Azure AD-Benutzers identisch sein. Er kann bis zu 64 alphanumerische Zeichen lang sein. Alle Zeichen, die nicht HTML-sicher sind, müssen codiert werden. Das Zeichen "+" wird z. B. 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 Benutzerprinzipalname des Benutzers in Azure AD/Office 365. Der UPN ist im E-Mail-Adressformat. Der UPN-Wert in Windows Office 365 (Azure Active Directory)
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 Azure AD-Mandanten verfügen, muss der Aussteller mit der pro Domäne konfigurierten URI-Einstellung übereinstimmen.

Warnung

Azure AD unterstützt zurzeit den folgenden NameID-Format-URI für SAML 2.0: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

SAML-Anforderungs und -Antwortbeispielnachrichten

Ein Anforderungs- und Antwortbenachrichtigungspaar wird für den Nachrichtenaustausch bei der Anmeldung angezeigt.

Dies ist eine Anforderungsbeispielbenachrichtigung, die von Azure AD zu einem 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 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_7171b0b2-19f2-4ba2-8f94-24b5e56b7f1e" IssueInstant="2014-01-30T16:18:35Z" Version="2.0" AssertionConsumerServiceIndex="0" >
  <saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>

Dies ist eine Beispielantwortbenachrichtigung, die von dem mit SAML 2.0 kompatiblen Beispielidentitätsanbieter an Azure AD/Office 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="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/5YqbheaJP425c0pHva9PhNY=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>TciWMyHW2ZODrh/2xrvp5ggmcHBFEd9vrp6DYXp+hZWJzmXMmzwmwS8KNRJKy8H7XqBsdELA1Msqi8I3TmWdnoIRfM/ZAyUppo8suMu6Zw+boE32hoQRnX9EWN/f0vH6zA/YKTzrjca6JQ8gAV1ErwvRWDpyMcwdYCiWALv9ScbkAcebOE1s1JctZ5RBXggdZWrYi72X+I4i6WgyZcIGai/rZ4v2otoWAEHS0y1yh1qT7NDPpl/McDaTGkNU6C+8VfjD78DrUXEcAfKvPgKlKrOMZnD1lCGsViimGY+LSuIdY45MLmyaa5UT4KWph6dA==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/+3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==</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

Dieses Thema enthält Richtlinien zum Konfigurieren Ihres SAML 2.0-Identitätsanbieters für einen Verbund mit Azure AD für die Aktivierung des einmaligen Anmeldens für den Zugriff auf einen oder mehrere Microsoft-Clouddienste (z.B. Office 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 Azure AD.

Hinzufügen von Azure AD-Metadaten

Ihr SAML 2.0-Identitätsanbieter muss Informationen zur vertrauenden Azure AD-Seite befolgen. Azure AD veröffentlicht Metadaten unter https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Es wird empfohlen, immer die aktuellen Azure AD-Metadaten zu importieren, wenn Sie Ihren SAML 2.0-Identitätsanbieter konfigurieren. Beachten Sie, dass Azure AD keine Metadaten vom Identitätsanbieter liest.

Hinzufügen von Azure AD als vertrauende Seite

Sie müssen die Kommunikation zwischen Ihrem SAML 2.0-Identitätsanbieter und Azure AD 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 Azure AD-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 Windows PowerShell für einmaliges Anmelden mit dem SAML 2.0-Identitätsanbieter

Nachdem Sie Ihren SAML 2.0-Identitätsanbieter für die Verwendung mit Azure AD-Anmeldung konfiguriert haben, besteht der nächste Schritt aus dem Herunterladen und Installieren des Azure Active Directory-Moduls für Windows PowerShell. Nach Abschluss der Installation verwenden Sie diese Cmdlets zum Konfigurieren Ihrer Azure AD-Domänen als Verbunddomänen.

Das Azure Active Directory-Modul für Windows PowerShell ist ein Download zum Verwalten Ihrer Organisationsdaten in Azure AD. Dieses Modul installiert eine Reihe von Cmdlets in Windows PowerShell; Sie führen diese Cmdlets zum Einrichten des einmaligen Anmeldens für den Zugriff auf Azure AD aus, und somit auch auf alle Cloud-Dienste, die Sie abonniert haben. Anweisungen zum Herunterladen und Installieren der Cmdlets finden Sie unter https://technet.microsoft.com/library/jj151815.aspx.

Einrichten einer Vertrauensstellung zwischen Ihrem SAML-Identitätsanbieter und Azure AD

Bevor ein Verbund für eine Azure AD-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 führen eine Reihe von Cmdlets in der Windows PowerShell-Befehlszeilenschnittstelle aus oder konvertieren Domänen für einmaliges Anmelden bzw. fügen diese hinzu.

Jede Azure Active Directory-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 Azure AD 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. Beachten Sie, dass es nach Ausführung dieses Schritts in Ihrer Domäne möglicherweise zu einem Ausfall kommen kann, der Benutzer bis zu zwei Stunden lang betreffen kann.

Konfigurieren einer Domäne in Ihrem Office 365-Mandanten für Verbund

1. Verbinden zu Ihrem Office 365 Mandanten als Mandantenadministrator: Connect-MsolService

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

   $dom = "contoso.com" $BrandName - "Sample SAML 2.0 IDP" $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" $MySigningCert = @" MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyh BREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDT E1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9yb WVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQ VcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57 sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9 T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEM b2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcC AwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9 eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+ CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvy JOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBy Sx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==" "@ $uri = "http://WS2012R2-0.contoso.com/adfs/services/trust" $Protocol = "SAMLP" Set-MsolDomainAuthentication ` -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl -SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol 
   

   HINWEIS: Sie können die signaturbasierte Zertifikatbasis64-codierte Zeichenfolge aus Ihrer IDP-Metadatendatei abrufen. Ein Beispiel für diesen Speicherort wurde bereitgestellt. Er kann jedoch abhängig von Ihrer Implementierung geringfügig abweichen.

   <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVCi2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> 
   

   Weitere Informationen zu „Set-MsolDomainAuthentication“ finden Sie unter https://technet.microsoft.com/library/dn194112.aspx.

   Hinweis

   Sie müssen „$ecpUrl = „https://WS2012R2-0.contoso.com/PAOS““ nur ausführen, 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 Änderung benötigen jedoch bis zu zwei Stunden und erfordern die Zuweisung neuer zufälliger Kennwörter für die cloudbasierte Anmeldung für jeden Benutzer. Das Zurückwechseln zu „verwaltet“ ist in einigen Szenarios möglicherweise erforderlich, um einen Fehler in Ihren Einstellungen zurückzusetzen. Weitere Informationen zur Domänenkonvertierung finden Sie unter https://msdn.microsoft.com/library/windowsazure/dn194122.aspx.

Bereitstellen von Benutzerprinzipalen für Azure AD/Office 365

Bevor Sie Ihre Benutzer mit Office 365 authentifizieren können, müssen Sie Azure AD mit Benutzerprinzipalen bereitstellen, die mit der Assertion im SAML 2.0-Anspruch übereinstimmen. Wenn Azure AD diese Benutzerprinzipale im Voraus nicht bekannt sind, können sie für die Verbundanmeldung verwendet werden. Entweder DirSync oder Windows PowerShell können verwendet werden, um Benutzerprinzipale bereitzustellen.

Das Verzeichnissynchronisierungstool kann zum Bereitstellen von Prinzipalen für Ihre Domänen in Ihrem Office 365-Mandanten aus dem lokalen Active Directory verwendet werden. Ausführlichere Informationen finden Sie unter: https://technet.microsoft.com/library/hh967642.aspx.

Windows PowerShell kann auch zum automatischen Hinzufügen neuer Benutzer zu Azure AD und zum Synchronisieren von Änderungen aus dem lokalen Verzeichnis verwendet werden. Um die Windows PowerShell Cmdlets zu verwenden, müssen Sie die Azure Active Directory Module herunterladen, die hier abgerufen werden können: https://technet.microsoft.com/library/jj151815.aspx

Diese Prozedur zeigt, wie Azure AD ein einzelner Benutzer hinzugefügt wird.

1. Verbinden Ihrem Office 365 Mandanten als Mandantenadministrator: Connect-MsolService

2. Erstellen Sie einen neuen Benutzerprinzipal:

   New-MsolUser ` 
   -UserPrincipalName elwoodf1@contoso.com
   -ImmutableId ABCDEFG1234567890
   -DisplayName "Elwood Folk"
   -FirstName Elwood 
   -LastName Folk 
   -AlternateEmailAddresses "Elwood.Folk@contoso.com" 
   -LicenseAssignment "samlp2test:ENTERPRISEPACK" 
   -UsageLocation "US" 
   

   Weitere Informationen zu "New-MsolUser" finden Sie im https://technet.microsoft.com/en-us/library/dn194096.aspxArtikel .

Hinweis

Der Wert „UserPrinciplName“ muss mit dem Wert übereinstimmen, den Sie für „IDPEmail“ in Ihrem SAML 2.0-Anspruch senden, und der Wert „ImmutableID“ 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 Azure AD-SAML 2.0-Protokollanforderungen überprüft.

2. Sie haben Ihren SAML 2.0-Identitätsanbieter konfiguriert.

3. Installieren Sie Windows PowerShell für einmaliges Anmelden mit dem SAML 2.0-Identitätsanbieter.

4. Richten Sie eine Vertrauensstellung zwischen Ihrem SAML 2.0-Identitätsanbieter und Azure AD ein.

5. Bereitstellen eines bekannten Testbenutzerprinzipals für Azure Active Directory (Office 365) über Windows PowerShell oder DirSync

6. Befolgen Sie die detaillierten Anweisungen in der Verzeichnissynchronisierungs-Roadmap , um ein Tool vorzubereiten, zu aktivieren, zu installieren und die Verzeichnissynchronisierung zu überprüfen.

Nach dem Einrichten des einmaligen Anmeldens mit Ihrem auf SAML 2.0 SP-Lite basierenden Identitätsanbieter müssen Sie überprüfen, ob dieser ordnungsgemäß arbeitet.

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. Wenn Sie DirSync verwenden, lesen Sie die Roadmap für die Verzeichnissynchronisierung.

Verwenden Sie das Tool, um sicherzustellen, dass das einmalige Anmelden ordnungsgemäß eingerichtet wurde.

Um sicherzustellen, dass das einmalige Anmelden ordnungsgemäß eingerichtet wurde, können Sie die folgenden Schritte ausführen, um zu bestätigen, dass Sie sich beim Clouddienst mit Ihren Unternehmensanmeldeinformationen anmelden können. Microsoft stellt auf TechNet Anweisungen zum Testen von AD FS unter "Testen des einmaligen Anmeldens für verschiedene Verwendungsszenarien" bereit.

Microsoft hat ein Tool bereitgestellt, das Sie verwenden können, um Ihre auf SAML 2.0 basierenden Identitätsanbieter zu testen. Bevor Sie das Testtool ausführen, müssen Sie Azure AD-Mandanten für den Verbund mit Ihrem Identitätsanbieter konfiguriert haben.

Hinweis

Die Verbindungsuntersuchung erfordert Internet Explorer 10 oder höher.

1. Laden Sie die Verbindungsuntersuchung unter https://testconnectivity.microsoft.com/?tabid=Client herunter.

2. Klicken Sie auf Jetzt installierenNow, um den Download zu starten und das Tool zu installieren. Hier sehen Sie einen Screenshot des Tools, nachdem es heruntergeladen und gestartet wurde.

   

   Wählen Sie Ich kann keinen Verbund mit Office 365, Azure oder anderen Diensten einrichten, die Azure Active Directory verwenden aus.

3. Nachdem das Tool heruntergeladen wurde und ausgeführt wird, sehen Sie das Fenster „Verbindungsdiagnose“. Das Tool führt Sie ausführlich durch das Testen Ihrer Verbundverbindung.

   

4. Die Verbindungsuntersuchung öffnet Ihren SAML 2.0-IDP für Ihre Anmeldung. Geben Sie die Anmeldeinformationen für den Benutzerprinzipal ein, den Sie testen:

   

5. Geben Sie im Anmeldefenster der Verbindungsuntersuchung einen Kontonamen und ein zugehöriges Kennwort für den Azure AD-Mandanten ein, für den mit Ihrem SAML 2.0-Identitätsanbieter ein Verbund erstellt werden soll. Das Tool versucht, sich mithilfe dieser Anmeldeinformationen anzumelden. Als Ausgabe werden ausführliche Ergebnisse von Tests, die während des Anmeldeversuchs durchgeführt wurden, bereitgestellt.

   

6. Dieses Fenster zeigt ein Fehlerergebnis des Tests an. Durch Klicken auf „Überprüfen“ werden ausführliche Informationen über die Ergebnisse der Tests, die ausgeführt wurden, angezeigt. Sie können auch die Ergebnisse auf einem Datenträger speichern, um sie freizugeben.

   Hinweis

   Die Konnektivitätsanalyse testet auch den aktiven Verbund mithilfe der WS*-basierten und ECP/PAOS-Protokolle, wenn Sie diese nicht verwenden, können Sie den folgenden Fehler ignorieren: Testen des aktiven Anmeldeflusses mithilfe des aktiven Partnerverbundendpunkts Ihres Identitätsanbieters.

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

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 wurde, 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. Klicken Sie in das Kennwortfeld. Wenn einmaliges Anmelden eingerichtet ist, wird das Kennwortfeld schattiert, und Es wird die folgende Meldung angezeigt: "Sie müssen sich jetzt bei <Ihrem Unternehmen> anmelden."

3. Klicken Sie auf den Link "Anmelden bei <Ihrem Unternehmen> ". Wenn Sie sich anmelden können, wurde das einmalige Anmelden eingerichtet.

Weitere Informationen

Konzepte

DirSync mit einmaligem Anmelden