Konfigurieren von Microsoft Entra ID zum Bereitstellen von Benutzer*innen in LDAP-Verzeichnissen
Die folgende Dokumentation enthält Konfigurations- und Tutorialinformationen zum Bereitstellen von Benutzer*innen aus Microsoft Entra ID in einem LDAP-Verzeichnis.
In diesem Dokument werden die Schritte beschrieben, die Sie durchführen müssen, um Benutzer*innen automatisch von Microsoft Entra ID in ein LDAP-Verzeichnis zu übertragen und dort zu entfernen. In diesem Dokument wird gezeigt, wie Sie Benutzer*innen in AD LDS als exemplarisches LDAP-Verzeichnis bereitstellen können. Für die Bereitstellung kann jedoch jeder der in den folgenden Abschnitten genannten unterstützten LDAP-Server verwendet werden. Über diese Lösung können keine Benutzer in Active Directory Domain Services bereitgestellt werden.
Wichtige Details zum Zweck und zur Funktionsweise dieses Diensts sowie häufig gestellte Fragen finden Sie unter Automatisieren der Bereitstellung und Bereitstellungsaufhebung von Benutzer*innen für SaaS-Anwendungen mit Microsoft Entra ID und Azure AD-Architektur für die lokale Anwendungsbereitstellung. Das folgende Video enthält eine Übersicht über die lokale Benutzerbereitstellung.
Voraussetzungen für die Bereitstellung von Benutzern in einem LDAP-Verzeichnis
Lokale Voraussetzungen
- Eine Anwendung mit einem Verzeichnisserver zum Abfragen von Benutzern
- Ein Zielverzeichnis (nicht Active Directory Domain Services), in dem Benutzer erstellt, aktualisiert und gelöscht werden können – beispielsweise Active Directory Lightweight Services (AD LDS). Diese Verzeichnisinstanz sollte kein Verzeichnis sein, das auch zum Bereitstellen von Benutzer*innen in Microsoft Entra ID verwendet wird, da sonst bei Vorhandensein beider Szenarien möglicherweise eine Schleife mit Microsoft Entra Connect entsteht.
- Ein Computer mit mindestens 3 GB RAM zum Hosten eines Bereitstellungs-Agents. Der Computer sollte unter Windows Server 2016 oder einer höheren Version von Windows Server ausgeführt werden und über eine Verbindung mit dem Zielverzeichnis sowie über ausgehende Verbindungen mit „login.microsoftonline.com“, anderen Microsoft Online Services und Azzure-Domänen verfügen. Ein Beispiel ist eine Windows Server 2016-VM, die in Azure IaaS oder hinter einem Proxy gehostet wird.
- .NET Framework 4.7.2 muss installiert sein.
- Optional: Es empfiehlt sich, Microsoft Edge für Windows Server herunterzuladen und anstelle von Internet Explorer zu verwenden. Dies ist jedoch nicht zwingend erforderlich.
Unterstützte LDAP-Verzeichnisserver
Der Connector greift zur Erkennung und Identifizierung des LDAP-Servers auf verschiedene Techniken zurück. Der Connector verwenden den Stamm-DSE und den Anbieternamen bzw. die Version und durchsucht das Schema nach eindeutigen Objekten und Attributen, die für bestimmte LDAP-Server typisch sind.
- OpenLDAP
- Microsoft Active Directory Lightweight Directory Services
- 389 Directory Server
- Apache Directory Server
- IBM Tivoli DS
- Isode Directory
- NetIQ eDirectory
- Novell eDirectory
- Open DJ
- Open DS
- Oracle (ehemals Sun ONE) Directory Server Enterprise Edition
- RadiantOne Virtual Directory Server (VDS)
Weitere Informationen finden Sie in der Referenz zum generischen LDAP-Connector.
Cloudanforderungen
Ein Microsoft Entra-Mandant mit Microsoft Entra ID P1 oder Premium P2 (oder EMS E3 oder E5).
Für die Verwendung dieses Features werden Microsoft Entra ID P1-Lizenzen benötigt. Informationen zur Ermittlung der richtigen Lizenz für Ihre Anforderungen finden Sie im Vergleich der allgemein verfügbaren Features von Microsoft Entra ID.
Die Rolle „Hybrididentitätsadministrator“ zum Konfigurieren des Bereitstellungs-Agents und die Rolle „Anwendungsadministrator“ oder „Cloudanwendungsadministrator“ zum Konfigurieren der Bereitstellung im Azure-Portal.
Die Microsoft Entra-Benutzer*innen, die in dem LDAP-Verzeichnis bereitgestellt werden sollen, müssen bereits über die Attribute verfügen, die für das Verzeichnisserverschema erforderlich und für die jeweiligen Benutzer*innen spezifisch sind. Wenn der Verzeichnisserver beispielsweise erfordert, dass jede*r Benutzer*in über eine Benutzer-ID-Nummer in Form einer eindeutigen Zahl zwischen 10000 und 30000 verfügt, um eine POSIX-Workload zu unterstützen, müssen Sie diese Nummer entweder aus einem vorhandenen Benutzerattribut generieren oder das Microsoft Entra-Schema erweitern und dieses Attribut für die Benutzer*innen im Bereich der LDAP-basierten Anwendung auffüllen. Informationen zum Erstellen zusätzlicher Verzeichniserweiterungen finden Sie unter Graph-Erweiterbarkeit.
Weitere Empfehlungen und Einschränkungen
Bei den folgenden Punkten handelt es sich um weitere Empfehlungen und Einschränkungen.
- Für die Cloudsynchronisierung und die lokale App-Bereitstellung sollte nicht der gleiche Agent verwendet werden. Microsoft empfiehlt die Verwendung separater Agents für die Cloudsynchronisierung und die lokale App-Bereitstellung.
- Für AD LDS können Benutzer derzeit nicht mit Kennwörtern bereitgestellt werden. Daher müssen Sie entweder die Kennwortrichtlinie für AD LDS deaktivieren oder die Benutzer in einem deaktivierten Zustand bereitstellen.
- Für andere Verzeichnisserver kann ein anfängliches Zufallskennwort festgelegt werden, aber es ist nicht möglich, das Kennwort von Microsoft Entra-Benutzern auf einem Verzeichnisserver bereitzustellen.
- Die Bereitstellung von Benutzern aus Microsoft Entra ID für Active Directory Domains Services wird nicht unterstützt.
- Die Bereitstellung von Benutzern aus LDAP für Microsoft Entra ID wird nicht unterstützt.
- Die Bereitstellung von Gruppen und Benutzermitgliedschaften für einen Verzeichnisserver wird nicht unterstützt.
Auswählen von Ausführungsprofilen
Wenn Sie die Konfiguration für den Connector erstellen, um mit einem Verzeichnisserver zu interagieren, konfigurieren Sie als Erstes, dass der Connector das Schema Ihres Verzeichnisses lesen soll. Anschließend gleichen Sie das Schema mit dem von Microsoft Entra ID ab und konfigurieren dann über Ausführungsprofile den Ansatz, den der Connector fortlaufend nutzen soll. Jedes Ausführungsprofil, das Sie konfigurieren, gibt an, wie der Connector LDAP-Anforderungen zum Importieren oder Exportieren von Daten vom Verzeichnisserver generiert. Bevor Sie den Connector auf einem vorhandenen Verzeichnisserver bereitstellen, müssen Sie mit den Verzeichnisserveroperator*innen in Ihrer Organisation besprechen, nach welchem Muster Vorgänge auf ihrem Verzeichnisserver ausgeführt werden.
Wenn der Bereitstellungsdienst nach der Konfiguration startet, führt er automatisch die im Ausführungsprofil Vollständiger Import konfigurierten Interaktionen aus. In diesem Ausführungsprofil liest der Connector in allen Datensätzen für Benutzer aus dem Verzeichnis unter Verwendung eines LDAP-Suchvorgangs. Dieses Ausführungsprofil ist notwendig, damit Microsoft Entra ID später, wenn es eine Änderung für eine*n Benutzer*in vornehmen muss, weiß, dass es ein bestehendes Objekt für diese*n Benutzer*in im Verzeichnis aktualisieren muss, anstatt ein neues Objekt für diese*n Benutzer*in zu erstellen.
Jedes Mal, wenn in Microsoft Entra ID Änderungen vorgenommen werden, z. B. um der Anwendung eine*n neue*n Benutzer*in zuzuweisen oder eine*n bestehende*n Benutzer*in zu aktualisieren, führt der Bereitstellungdienst die LDAP-Interaktionen im Export-Ausführungsprofil aus. Im Export-Ausführungsprofil stellt Microsoft Entra ID LDAP-Anforderungen zum Hinzufügen, Ändern, Entfernen oder Umbenennen von Objekten im Verzeichnis, um den Inhalt des Verzeichnisses mit Microsoft Entra ID zu synchronisieren.
Sofern Ihr Verzeichnis dies unterstützt, können Sie optional auch ein Ausführungsprofil vom Typ Deltaimport konfigurieren. In diesem Ausführungsprofil liest Microsoft Entra ID die Änderungen ein, die seit dem letzten Voll- oder Delta-Import in dem Verzeichnis vorgenommen wurden und nicht von Microsoft Entra ID stammen. Dieses Ausführungsprofil ist optional, da das Verzeichnis möglicherweise nicht für die Unterstützung eines Deltaimports konfiguriert wurde. Wenn Ihre Organisation beispielsweise OpenLDAP verwendet, muss OpenLDAP mit aktiviertem Zugriffsprotokoll-Überlagerungsfeature bereitgestellt worden sein.
Festlegen der Art und Weise der Interaktion des LDAP-Connectors von Microsoft Entra mit dem Verzeichnisserver
Bevor Sie den Connector auf einem vorhandenen Verzeichnisserver bereitstellen, müssen Sie mit dem Verzeichnisserveroperator in Ihrer Organisation besprechen, wie der Connector in den Verzeichnisserver integriert werden kann. Folgende Informationen werden gesammelt: Netzwerkinformationen zur Verbindung mit dem Verzeichnisserver, Art der Authentifizierung des Connectors beim Verzeichnisserver, Schemaauswahl auf dem Verzeichnisserver zum Modellieren von Benutzer*innen, der Basis-DN (Base Distinguished Name) im Namenskontext und die Verzeichnishierarchieregeln, die Art der Zuordnung von Benutzer*innen auf dem Verzeichnisserver zu Benutzer*innen in Microsoft Entra ID sowie die zu ergreifenden Maßnahmen, wenn ein*e Benutzer*in in Microsoft Entra ID den Geltungsbereich verlässt. Die Bereitstellung dieses Connectors erfordert möglicherweise Änderungen an der Konfiguration des Verzeichnisservers sowie Konfigurationsänderungen in Microsoft Entra ID. Bei Bereitstellungen, die die Integration von Microsoft Entra ID mit einem Verzeichnisserver eines Drittanbieters in einer Produktionsumgebung beinhalten, empfehlen wir Kunde*innen, mit dem Anbieter des Verzeichnisservers oder dem Bereitstellungspartner zusammenzuarbeiten, um Hilfe, Anleitungen und Unterstützung bei dieser Integration zu erhalten. In diesem Artikel werden die folgenden Beispielwerte für zwei Verzeichnisse verwendet: für AD LDS und für OpenLDAP.
Konfigurationseinstellung | Festlegen des Werts | Beispielwert |
---|---|---|
Hostname des Verzeichnisservers | Seite Konnektivität im Konfigurations-Assistenten | APP3 |
Portnummer des Verzeichnisservers | Seite Konnektivität im Konfigurations-Assistenten | 636. Verwenden Sie für LDAP über SSL oder TLS (LDAPS) Port 636. Verwenden Sie für Start TLS Port 389. |
Konto für den Connector, um sich beim Verzeichnisserver zu identifizieren | Seite Konnektivität im Konfigurations-Assistenten | Für AD LDS CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab und für OpenLDAP cn=admin,dc=contoso,dc=lab |
Kennwort für den Connector, um sich beim Verzeichnisserver zu authentifizieren | Seite Konnektivität im Konfigurations-Assistenten | |
strukturelle Objektklasse für einen Benutzer auf dem Verzeichnisserver | Seite Objekttypen im Konfigurations-Assistenten | Für AD LDS User und für OpenLDAP inetOrgPerson |
Hilfsobjektklasse für einen Benutzer auf dem Verzeichnisserver | Attributzuordnungen auf der Seite Bereitstellen im Azure-Portal | Für OpenLDAP mit dem POSIX-Schema: posixAccount und shadowAccount |
Attribute, die bei einem neuen Benutzer vorausgefüllt werden sollen | Seite Attribute auswählen im Konfigurations-Assistenten und Attributzuordnungen auf der Seite Bereitstellen im Azure-Portal | Für AD LDS msDS-UserAccountDisabled , userPrincipalName , displayName und für OpenLDAP cn , gidNumber , homeDirectory , mail , objectClass , sn , uid , uidNumber und userPassword |
Für den Verzeichnisserver erforderliche Namenshierarchie | Attributzuordnungen auf der Seite Bereitstellen im Azure-Portal | Legen Sie den DN von neu erstellten Benutzer*innen für AD LDS direkt unter CN=CloudUsers,CN=App,DC=Contoso,DC=lab und für OpenLDAP direkt unter DC=Contoso,DC=lab fest. |
Attribute zum Korrelieren von Benutzer*innen über Microsoft Entra ID und den Verzeichnisserver hinweg | Attributzuordnungen auf der Seite Bereitstellen im Azure-Portal | Für AD LDS nicht konfiguriert, da dieses Beispiel für ein anfänglich leeres Verzeichnis gilt, und für OpenLDAP, mail |
Verhalten beim Aufheben der Bereitstellung, wenn ein*e Benutzer*in in Microsoft Entra ID den Geltungsbereich verlässt | Seite Bereitstellung aufheben im Konfigurations-Assistenten | Löschen des Benutzers vom Verzeichnisserver |
Die Netzwerkadresse eines Verzeichnisservers besteht aus einem Hostnamen und einer TCP-Portnummer, in der Regel Port 389 oder 636. Wenn sich Verzeichnisserver und Connector nicht auf demselben Windows-Server befinden oder Sie keine Sicherheit auf Netzwerkebene verwenden, müssen Netzwerkverbindungen zwischen dem Connector und einem Verzeichnisserver mithilfe von SSL oder TLS geschützt werden. Der Connector unterstützt die Verbindung mit einem Verzeichnisserver an Port 389 und die Verwendung von Start TLS, um TLS innerhalb der Sitzung zu aktivieren. Der Connector unterstützt auch die Verbindung mit einem Verzeichnisserver an Port 636 für LDAPS – LDAP über TLS.
Sie benötigen ein identifiziertes Konto für den Connector, damit dieser sich bei dem Verzeichnisserver authentifizieren kann, auf dem er bereits konfiguriert ist. Dieses Konto wird in der Regel mit einem Distinguished Name identifiziert und verfügt über ein zugehöriges Kennwort oder ein Clientzertifikat. Zur Durchführung von Import- und Exportvorgängen für die Objekte im verbundenen Verzeichnis muss das Connectorkonto innerhalb des Zugriffssteuerungsmodells des Verzeichnisses über ausreichende Berechtigungen verfügen. Der Connector muss zum Exportieren über Berechtigungen vom Typ Schreiben und zum Importieren über Berechtigungen vom Typ Lesen verfügen. Die Berechtigungen werden in der Verwaltungsumgebung des Zielverzeichnisses konfiguriert.
Ein Verzeichnisschema gibt die Objektklassen und Attribute an, die eine reale Entität im Verzeichnis darstellen. Der Connector unterstützt einen Benutzer, der über eine strukturelle Objektklasse (z. B. inetOrgPerson
) und optional zusätzlichen Hilfsobjektklassen dargestellt wird. Damit der Connector Benutzer auf dem Verzeichnisserver bereitstellen kann, müssen im Rahmen der Konfiguration über das Azure-Portal Zuordnungen vom Microsoft Entra-Schema zu allen obligatorischen Attributen definiert werden. Dies schließt die obligatorischen Attribute der strukturellen Objektklasse, alle ggf. vorhandenen übergeordneten Klassen dieser strukturellen Objektklasse und die obligatorischen Attribute ggf. vorhandener Hilfsobjektklassen ein. Darüber hinaus konfigurieren Sie wahrscheinlich auch Zuordnungen für einige optionale Attribute dieser Klassen. Beispielsweise kann es bei einem OpenLDAP-Verzeichnisserver erforderlich sein, dass ein Objekt für einen neuen Benutzer über Attribute wie im folgenden Beispiel verfügt:
dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password
Die von einem Verzeichnisserver implementierten Verzeichnishierarchieregeln beschreiben, wie die Objekte für die einzelnen Benutzer miteinander und mit im Verzeichnis vorhandenen Objekten in Beziehung stehen. Bei den meisten Bereitstellungen entscheidet sich das Unternehmen für eine flache Hierarchie auf dem Verzeichnisserver, bei der sich jedes Objekt für einen Benutzer direkt unter einem gemeinsamen Basisobjekt befindet. Wenn beispielsweise der Basis-DN (Base Distinguished Name) für den Namenskontext in einem Verzeichnisserver dc=contoso,dc=com
lautet, erhält ein neuer Benutzer einen Distinguished Name in Form von cn=alice,dc=contoso,dc=com
. Manche Organisationen verwenden jedoch möglicherweise eine komplexere Verzeichnishierarchie. In diesem Fall müssen Sie bei der Angabe der Distinguished Name-Zuordnung für den Connector die Regeln implementieren. Beispiel: Ein Verzeichnisserver erwartet, dass sich die Benutzer in Organisationseinheiten, geordnet nach Abteilungen, befinden. Daher erhält ein neuer Benutzer einen Distinguished Name in Form von cn=alice,ou=London,dc=contoso,dc=com
. Da der Connector keine Zwischenobjekte für Organisationseinheiten erstellt, müssen alle von der Verzeichnisserver-Regelhierarchie erwarteten Zwischenobjekte bereits auf dem Verzeichnisserver vorhanden sein.
Als Nächstes müssen Sie die Regeln definieren, anhand derer der Connector bestimmen soll, ob sich bereits Benutzer auf dem Verzeichnisserver befinden, die Microsoft Entra-Benutzern entsprechen. Jedes LDAP-Verzeichnis verfügt über einen Distinguished Name, der für jedes Objekt auf dem Verzeichnisserver eindeutig ist. Dieser Distinguished Name ist für Benutzer*innen in Microsoft Entra ID jedoch häufig nicht vorhanden. Stattdessen verwendet eine Organisation vielleicht ein anderes Attribut wie mail
oder employeeId
in ihrem Verzeichnisserverschema, das auch bei den Benutzer*innen in Microsoft Entra ID vorhanden ist. Wenn der Connector dann einen neuen Benutzer auf einem Verzeichnisserver bereitstellt, kann er suchen, ob bereits ein Benutzer mit einem bestimmten Wert für dieses Attribut im Verzeichnis vorhanden ist. Nur wenn kein Benutzer vorhanden ist, wird ein neuer Benutzer auf dem Verzeichnisserver erstellt.
Wenn Ihr Szenario das Erstellen neuer Benutzer*innen im LDAP-Verzeichnis umfasst (nicht nur das Aktualisieren oder Löschen vorhandener Benutzer*innen), müssen Sie auch bestimmen, wie die Anwendungen, die diesen Verzeichnisserver verwenden, die Authentifizierung verarbeiten. Der empfohlene Ansatz ist, für die Anwendungen ein Verbund- oder SSO-Protokoll wie SAML, OAuth oder OpenID Connect zu verwenden, um sich bei Microsoft Entra ID zu authentifizieren, und den Verzeichnisserver ausschließlich für Attribute zu nutzen. Normalerweise können LDAP-Verzeichnisse von Anwendungen verwendet werden, um Benutzer durch Überprüfung eines Kennworts zu authentifizieren, aber dieser Anwendungsfall ist für die Multi-Faktor-Authentifizierung oder bei bereits authentifizierten Benutzer nicht möglich. Einige Anwendungen können den öffentlichen SSH-Schlüssel oder das Zertifikat von Benutzer*innen aus dem Verzeichnis abfragen, was für Benutzer*innen geeignet sein kann, die bereits über Anmeldeinformationen dieser Typen verfügen. Wenn Ihre Anwendung jedoch vom Verzeichnisserver abhängig ist und keine modernen Authentifizierungsprotokolle oder stärkeren Anmeldeinformationen unterstützt, müssen Sie beim Erstellen neuer Benutzer im Verzeichnis ein anwendungsspezifisches Kennwort festlegen, da Microsoft Entra ID die Bereitstellung des Microsoft Entra-Kennworts von Benutzer nicht unterstützt.
Schließlich müssen Sie das Verhalten beim Aufheben der Bereitstellung festlegen. Wenn der Connector konfiguriert ist und Microsoft Entra ID eine Verknüpfung zwischen einer Benutzerin/einem Benutzer in Microsoft Entra ID und einer Benutzerin/einem Benutzer im Verzeichnis eingerichtet hat, entweder für eine*n Benutzer*in, die*der sich bereits im Verzeichnis befindet, oder eine*n neue*n Benutzer*in, kann Microsoft Entra ID Attributänderungen von Microsoft Entra-Benutzer*innen im Verzeichnis bereitstellen. Wenn der Anwendung zugewiesene Benutzer*innen in Microsoft Entra ID gelöscht werden, sendet Microsoft Entra ID einen Löschvorgang an den Verzeichnisserver. Vielleicht soll Microsoft Entra ID auch das Objekt auf dem Verzeichnisserver aktualisieren, wenn ein*e Benutzer*in nicht mehr in der Lage ist, die Anwendung zu nutzen. Dieses Verhalten hängt von der Anwendung ab, die den Verzeichnisserver verwendet, da viele Verzeichnisse wie etwa OpenLDAP möglicherweise über keine Standardmethode zum Angeben der Deaktivierung eines Benutzerkontos verfügen.
Vorbereiten des LDAP-Verzeichnisses
Wenn Sie noch nicht über einen Verzeichnisserver verfügen und dieses Feature ausprobieren möchten, erfahren Sie unter Vorbereiten von Active Directory Lightweight Directory Services für die Bereitstellung aus Microsoft Entra ID, wie Sie eine AD LDS-Testumgebung erstellen. Falls Sie bereits einen anderen Verzeichnisserver bereitgestellt haben, können Sie diesen Artikel überspringen und mit der Installation und Konfiguration des ECMA-Connectorhosts fortfahren.
Installieren und Konfigurieren des Microsoft Entra Connect-Bereitstellungs-Agent-Pakets
Wenn Sie den Bereitstellungs-Agent bereits heruntergeladen und für eine andere lokale Anwendung konfiguriert haben, lesen Sie im nächsten Abschnitt weiter.
- Melden Sie sich beim Azure-Portal an.
- Navigieren Sie zu Unternehmensanwendungen, und wählen Sie Neue Anwendung aus.
- Suchen Sie nach der lokalen Ecma International-App, benennen Sie die App, und wählen Sie Erstellen aus, um sie Ihrem Mandanten hinzuzufügen.
- Navigieren Sie über das Menü zur Bereitstellungsseite Ihrer Anwendung.
- Wählen Sie Erste Schritte aus.
- Ändern Sie auf der Seite Bereitstellung den Modus in Automatisch.
- Wählen Sie unter Lokale Konnektivität die Option Herunterladen und Installieren und dann Bedingungen akzeptieren und herunterladen aus.
- Verlassen Sie das Portal und öffnen Sie das Installationsprogramm für den Bereitstellungsagenten, stimmen Sie den Nutzungsbedingungen zu und wählen Sie Installieren aus.
- Warten Sie auf den Konfigurationsassistenten für den Microsoft Entra-Bereitstellungsagenten und wählen Sie dann Weiter aus.
- Wählen Sie im Schritt Erweiterung auswählen die Option Lokale Anwendungsbereitstellung und dann Weiter aus.
- Der Bereitstellungs-Agent verwendet den Webbrowser des Betriebssystems, um ein Popupfenster anzuzeigen, in dem Sie sich bei Microsoft Entra ID und ggf. auch beim Identitätsanbieter Ihrer Organisation authentifizieren können. Wenn Sie Internet Explorer als Browser unter Windows Server verwenden, müssen Sie möglicherweise Microsoft-Websites zur Liste der vertrauenswürdigen Websites Ihres Browsers hinzufügen, damit JavaScript ordnungsgemäß ausgeführt werden kann.
- Geben Sie Anmeldeinformationen für einen Microsoft Entra-Administrator an, wenn Sie zur Autorisierung aufgefordert werden. Das Benutzerkonto muss mindestens über die Rolle Hybrididentitätsadministrator verfügen.
- Wählen Sie Bestätigen aus, um die Einstellung zu bestätigen. Nach erfolgreicher Installation können Sie Beenden auswählen und auch das Installationsprogramm für das Bereitstellungs-Agent-Paket schließen.
Konfigurieren der lokalen ECMA-App
Kehren Sie zum Portal zurück, und wählen Sie im Abschnitt Lokale Konnektivität den von Ihnen bereitgestellten Agent und dann Agent(s) zuweisen aus.
Lassen Sie dieses Browserfenster geöffnet, während Sie den nächsten Schritt der Konfiguration mit dem Konfigurations-Assistenten ausführen.
Konfigurieren des Zertifikats für den Microsoft Entra-ECMA-Connectorhost
- Klicken Sie auf dem Windows-Server, auf dem der Bereitstellungs-Agent installiert ist, im Startmenü mit der rechten Maustaste auf den Microsoft ECMA2Host-Konfigurations-Assistenten und führen Sie ihn als Administrator aus. Die Ausführung als Windows-Administrator ist erforderlich, damit der Assistent die erforderlichen Windows-Ereignisprotokolle erstellen kann.
- Wenn dies das erste Mal ist, dass Sie den Assistenten ausführen, werden Sie nach dem Starten der Konfiguration des ECMA-Connectorhosts aufgefordert, ein Zertifikat zu erstellen. Übernehmen Sie den Standardport 8585, und wählen Sie Zertifikat generieren aus, um ein Zertifikat zu generieren. Bei dem automatisch generierten Zertifikat handelt es sich um ein selbstsigniertes Zertifikat der vertrauenswürdigen Stammzertifizierungsstelle. Das SAN stimmt mit dem Hostnamen überein.
- Wählen Sie Speichern aus.
Hinweis
Wenn Sie sich für die Generierung eines neuen Zertifikats entschieden haben, erfassen Sie das Ablaufdatum des Zertifikats, um zum Konfigurations-Assistenten zurückzukehren und das Zertifikat erneut zu generieren, bevor es abläuft.
Konfigurieren eines generischen LDAP-Connectors
Je nachdem, welche Optionen Sie auswählen, sind einige Bildschirme des Assistenten möglicherweise nicht verfügbar, und die Informationen können sich geringfügig unterscheiden. Für diese Beispielkonfiguration wird die Bereitstellung von Benutzer*innen mit der User-Objektklasse für AD LDS und der inetOrgPerson-Objektklasse für OpenLDAP gezeigt. Die folgenden Informationen können Ihnen bei der Konfiguration nützlich sein.
Generieren Sie ein geheimes Token für die Authentifizierung von Microsoft Entra ID beim Connector. Es sollte mindestens 12 Zeichen umfassen und für jede Anwendung eindeutig sein. Sollten Sie noch nicht über einen Geheimnisgenerator verfügen, können Sie einen PowerShell-Befehl wie den folgenden verwenden, um eine zufällige Zeichenfolge zu generieren:
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
Wenn Sie dies noch nicht getan haben, starten Sie im Startmenü den Microsoft ECMA2Host-Konfigurations-Assistenten.
Füllen Sie auf der Seite Eigenschaften die Felder mit den Werten aus, die in der Tabelle unter dem Bild angegeben sind, und wählen Sie Weiter aus.
Eigenschaft Wert Name Der Name für den Connector. Muss für alle Connectors in Ihrer Umgebung eindeutig sein. Beispiel: LDAP
.Zeitgeber für automatische Synchronisierung (Minuten) 120 Geheimes Token Geben Sie hier Ihr geheimes Token ein. Er sollte mindestens 12 Zeichen lang sein. Erweiterungs-DLL Wählen Sie für den generischen LDAP-Connector die Option Microsoft.IAM.Connector.GenericLdap.dll aus. Auf der Seite Konnektivität wird die Kommunikation des ECMA-Connectorhosts mit dem Verzeichnisserver konfiguriert, und es werden einige der Konfigurationsoptionen festgelegt. Füllen Sie die Felder mit den Werten aus, die in der Tabelle unter dem Bild angegeben sind, und wählen Sie Weiter aus. Wenn Sie Weiter auswählen, fragt der Connector die Konfiguration des Verzeichnisservers ab.
Eigenschaft Beschreibung Host Der Hostname, auf dem sich der LDAP-Server befindet. In diesem Beispiel wird APP3
als Beispielhostname verwendet.Port Die TCP-Portnummer. Wenn der Verzeichnisserver für LDAP über SSL konfiguriert ist, verwenden Sie den Port 636. Verwenden Sie für Start TLS
oder bei Verwendung der Sicherheit auf Netzwerkebene den Port 389.Verbindungstimeout 180 Bindung Diese Eigenschaft gibt an, wie sich der Connector beim Verzeichnisserver authentifiziert. Bei der Einstellung Basic
oder der EinstellungSSL
oderTLS
ohne konfiguriertes Clientzertifikat sendet der Connector eine einfache LDAP-Bindung, um sich mit einem Distinguished Name und einem Kennwort zu authentifizieren. Mit der EinstellungSSL
oderTLS
und einem angegebenen Clientzertifikat sendet der Connector eine LDAP-SASL-Bindung vom TypEXTERNAL
, um sich mit einem Clientzertifikat zu authentifizieren.Benutzername Der Name, über den sich der ECMA-Connector beim Verzeichnisserver authentifiziert. In diesem Beispiel lautet der Beispielbenutzername für AD LDS CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab
und für OpenLDAPcn=admin,dc=contoso,dc=lab
.Kennwort Das Benutzerkennwort, über das sich der ECMA-Connector beim Verzeichnisserver authentifiziert. Bereich/Domäne Diese Einstellung ist nur erforderlich, wenn Sie Kerberos
als Bindungsoption ausgewählt haben, und dient zum Angeben des Bereichs bzw. der Domäne des Benutzers.Zertifikat Die Einstellungen in diesem Abschnitt werden nur verwendet, wenn Sie als Bindungsoption SSL
oderTLS
ausgewählt haben.Attribut-Aliase Das Textfeld für Attributaliase wird für Attribute verwendet, die im Schema mit der RFC4522-Syntax definiert sind. Diese Attribute können bei der Schemaerkennung nicht erkannt werden, und der Connector benötigt Hilfe bei der Identifizierung. Wenn der Verzeichnisserver beispielsweise userCertificate;binary
nicht veröffentlicht und Sie dieses Attribut bereitstellen möchten, muss die folgende Zeichenfolge in das Feld für Attributaliase eingegeben werden, um das Attribut „userCertificate“ ordnungsgemäß als binäres Attribut zu identifizieren:userCertificate;binary
. Wenn Sie keine speziellen Attribute benötigen, die nicht im Schema enthalten sind, können Sie diese leer lassen.Betriebsattribute einschließen Aktivieren Sie das Kontrollkästchen Include operational attributes in schema
, um auch vom Verzeichnisserver erstellte Attribute einzuschließen. Dazu zählen etwa Attribute wie der Zeitpunkt der Objekterstellung und der letzten Aktualisierung.Erweiterbare Attribute einschließen Aktivieren Sie das Kontrollkästchen Include extensible attributes in schema
, wenn auf dem Verzeichnisserver erweiterbare Objekte (RFC4512/4.3) verwendet werden. Wenn Sie diese Option aktivieren, kann jedes Attribut für alle Objekte verwendet werden. Bei Verwendung dieser Option wird das Schema ziemlich groß. Daher wird empfohlen, die Option deaktiviert zu lassen, sofern das Feature nicht vom verbundenen Dienst verwendet wird.Manuelle Ankerauswahl zulassen Lassen Sie die Option deaktiviert. Hinweis
Sollten Sie bei der Verbindungsherstellung Probleme haben und die Seite Global nicht aufrufen können, vergewissern Sie sich, dass das Dienstkonto in AD LDS oder auf dem anderen Verzeichnisserver aktiviert ist.
Auf der Seite Global werden der Distinguished Name des Delta-Änderungsprotokolls (sofern erforderlich) und weitere LDAP-Features konfiguriert. Die Seite wird vorab mit den Informationen des LDAP-Servers aufgefüllt. Überprüfen Sie die angezeigten Werte, und wählen Sie anschließend Weiter aus.
Eigenschaft BESCHREIBUNG Unterstützte SASL-Mechanismen Der obige Abschnitt enthält Informationen, die vom Server selbst bereitgestellt werden, einschließlich der Liste der SASL-Mechanismen. Details zum Serverzertifikat Wenn SSL
oderTLS
angegeben wurde, zeigt der Assistent das vom Verzeichnisserver zurückgegebene Zertifikat an. Vergewissern Sie sich, dass Aussteller, Antragsteller und Fingerabdruck für den richtigen Verzeichnisserver gelten.Obligatorische Features gefunden Der Connector überprüft außerdem, ob die erforderlichen Steuerelemente im Stamm-DSE vorhanden sind. Falls nicht, wird eine Warnung angezeigt. Einige LDAP-Verzeichnisse geben nicht alle Features im Stamm-DSE an. Es kann also sein, dass der Connector trotz vorhandener Warnung problemlos verwendet werden kann. Unterstützte Steuerelemente Die Kontrollkästchen für Unterstützte Steuerelemente steuern das Verhalten für bestimmte Vorgänge. Deltaimport Der Änderungsprotokoll-DN ist der vom Delta-Änderungsprotokoll verwendete Namenskontext (beispielsweise cn=changelog). Dieser Wert muss angegeben werden, um Deltaimporte ausführen zu können. Kennwortattribut Wenn der Verzeichnisserver ein anderes Kennwortattribut oder Kennworthashing unterstützt, können Sie das Ziel für Kennwortänderungen angeben. Partitionsnamen In der Liste mit zusätzlichen Partitionen können weitere Namespaces hinzugefügt werden, die nicht automatisch erkannt wurden. Diese Einstellung kann beispielsweise hilfreich sein, wenn mehrere Server einen logischen Cluster bilden und alle gleichzeitig importiert werden sollen. Active Directory kann mehrere Domänen in einer einzelnen Gesamtstruktur enthalten, wobei alle Domänen das gleiche Schema verwenden. Dies kann durch Eingabe zusätzlicher Namespaces in das Feld simuliert werden. Die einzelnen Namespaces können Daten von verschiedenen Servern importieren und werden auf der Seite Partitionen und Hierarchien konfigurieren weiter konfiguriert. Lassen Sie die Seite Partitionen unverändert, und wählen Sie Weiter aus.
Stellen Sie auf der Seite Ausführungsprofile sicher, dass sowohl das Kontrollkästchen Exportieren als auch das Kontrollkästchen Vollständiger Import aktiviert ist. Wählen Sie Weiteraus.
Eigenschaft BESCHREIBUNG Exportieren Ausführungsprofil zum Exportieren von Daten an den LDAP-Verzeichnisserver. Dieses Ausführungsprofil ist erforderlich. Vollständiger Import Ausführungsprofil zum Importieren aller Daten aus den zuvor angegebenen LDAP-Quellen. Dieses Ausführungsprofil ist erforderlich. Deltaimport Ausführungsprofil, das nur Änderungen aus LDAP seit dem letzten vollständigen Import oder Deltaimport importiert. Aktivieren Sie dieses Ausführungsprofil nur, wenn Sie sich vergewissert haben, dass der Verzeichnisserver die erforderlichen Anforderungen erfüllt. Weitere Informationen finden Sie in der Referenz zum generischen LDAP-Connector. Behalten Sie auf der Seite Export die Standardwerte bei, und klicken Sie auf Weiter.
Behalten Sie auf der Seite Vollständiger Import die Standardwerte bei, und klicken Sie auf Weiter.
Behalten Sie auf der Seite Deltaimport (sofern vorhanden) die Standardwerte bei, und klicken Sie auf Weiter.
Füllen Sie die Felder auf der Seite Objekttypen aus, und wählen Sie Weiter aus.
Eigenschaft BESCHREIBUNG Zielobjekt Dieser Wert ist die strukturelle Objektklasse eines Benutzers auf dem LDAP-Verzeichnisserver – beispielsweise inetOrgPerson
für OpenLDAP oderUser
für AD LDS. Geben Sie in diesem Feld keine Hilfsobjektklasse an. Wenn der Verzeichnisserver Hilfsobjektklassen benötigt, werden sie mit den Attributzuordnungen im Azure-Portal konfiguriert.Anchor Die Werte dieses Attributs müssen für jedes Objekt im Zielverzeichnis eindeutig sein. Der Microsoft Entra-Bereitstellungsdienst fragt den ECMA-Connectorhost nach dem ersten Zyklus mit diesem Attribut ab. Verwenden Sie für AD LDS den Wert ObjectGUID
, und orientieren Sie sich bei anderen Verzeichnisservern an der Tabelle weiter unten. Beachten Sie, dass als Distinguished Name-dn-
ausgewählt werden kann. Mehrwertige Attribute wie etwa das Attributuid
im OpenLDAP-Schema können nicht als Anker verwendet werden.Abfrageattribut Dieses Attribut muss mit dem Anker identisch sein, beispielsweise objectGUID
, wenn AD LDS als Verzeichnisserver verwendet wird, oder_distinguishedName
bei OpenLDAP.DN Der Distinguished Name des Zielobjekts. Behalten Sie -dn-
bei.Automatisch generiert unchecked Die folgende Tabelle enthält die LDAP-Server und die verwendeten Anker:
Verzeichnis Anchor Microsoft AD LDS und AD GC ObjectGUID. Sie müssen mindestens über die Agent-Version 1.1.846.0 verfügen, damit ObjectGUID
als Anker verwendet werden kann.389 Directory Server dn Apache Directory dn IBM Tivoli DS dn Isode Directory dn Novell/NetIQ eDirectory GUID Open DJ/DS dn Open LDAP dn Oracle ODSEE dn RadiantOne VDS dn Sun One Directory Server dn Der ECMA-Host erkennt die vom Zielverzeichnis unterstützten Attribute. Sie können wählen, welches dieser Attribute Sie für Microsoft Entra ID verfügbar machen möchten. Diese Attribute können dann im Azure-Portal zur Bereitstellung konfiguriert werden. Fügen Sie auf der Seite Attribute auswählen über die Dropdownliste nacheinander alle Attribute hinzu, die als obligatorische Attribute erforderlich sind, oder die Sie aus Microsoft Entra ID bereitstellen möchten.
In der Dropdownliste Attribut werden alle Attribute angezeigt, die im Zielverzeichnis gefunden wurden und bei der vorherigen Verwendung der Seite Attribute auswählen des Konfigurations-Assistenten nicht ausgewählt wurden.Stellen Sie sicher, dass das Kontrollkästchen
Treat as single value
für dasobjectClass
-Attribut deaktiviert ist. FallsuserPassword
festgelegt wurde, muss auch das Kontrollkästchen für dasuserPassword
-Attribut nicht aktivierbar oder deaktiviert sein.Wenn Sie OpenLDAP mit dem inetOrgPerson-Schema verwenden, konfigurieren Sie auch die Sichtbarkeit für die folgenden Attribute.
attribute Als einzelnen Wert behandeln cn J mail J objectClass sn J userPassword J Wenn Sie OpenLDAP mit dem POSIX-Schema verwenden, konfigurieren Sie die Sichtbarkeit für die folgenden Attribute.
attribute Als einzelnen Wert behandeln _distinguishedName -dn- export_password cn J gidNumber homeDirectory mail J objectClass sn J uid J uidNumber userPassword J Nachdem alle relevanten Attribute hinzugefügt wurden, wählen Sie Weiter aus.
Auf der Seite Bereitstellung aufheben können Sie angeben, ob Microsoft Entra ID Benutzer*innen aus dem Verzeichnis entfernen soll, wenn sie aus dem Bereich der Anwendung entfernt werden. Wenn ja, wählen Sie unter Flow deaktivieren die Option Löschen und unter Flow löschen die Option Löschen aus. Wenn
Set attribute value
ausgewählt wird, können die auf der vorherigen Seite ausgewählten Attribute auf der Seite „Bereitstellung aufheben“ nicht ausgewählt werden.
Hinweis
Wenn Sie Attributwert festlegen verwenden, sollten Sie beachten, dass nur boolesche Werte zulässig sind.
- Wählen Sie Fertig stellen aus.
Stellen Sie sicher, dass der ECMA2Host-Dienst ausgeführt wird und auf dem Verzeichnisserver lesen kann.
Führen Sie die folgenden Schritte aus, um zu bestätigen, dass der Connectorhost gestartet wurde und alle vorhandenen Benutzer*innen auf dem Verzeichnisserver identifiziert hat.
- Wählen Sie auf dem Server, auf dem der Microsoft Entra-ECMA-Connectorhost ausgeführt wird, Starten aus.
- Wählen Sie bei Bedarf Ausführen aus, und geben Sie dann services.msc in das Feld ein.
- Stellen Sie sicher, dass Microsoft ECMA2Host in der in der Liste Dienste enthalten ist und ausgeführt wird. Wenn der Dienst nicht ausgeführt wird, wählen Sie Start aus.
- Wenn Sie den Dienst kürzlich gestartet haben und über viele Benutzerobjekte auf dem Verzeichnisserver verfügen, warten Sie einige Minuten, bis der Connector eine Verbindung mit dem Verzeichnisserver hergestellt hat.
- Starten Sie PowerShell auf dem Server, auf dem der Microsoft Entra-ECMA-Connectorhost ausgeführt wird.
- Wechseln Sie zu dem Ordner, in dem der ECMA-Host installiert wurde, etwa
C:\Program Files\Microsoft ECMA2Host
. - Wechseln Sie zum Unterverzeichnis
Troubleshooting
. - Führen Sie im Verzeichnis, wie im Anschluss gezeigt, das Skript
TestECMA2HostConnection.ps1
aus, und geben Sie als Argumente den Connectornamen und den WertObjectTypePath
cache
an. Wenn Ihr Connectorhost nicht am TCP-Port 8585 lauscht, muss ggf. auch das Argument-Port
angegeben werden. Wenn Sie dazu aufgefordert werden, geben Sie das geheime Token ein, das für diesen Connector konfiguriert ist.PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9 Supply values for the following parameters: SecretToken: ************
- Sollte eine Fehler- oder Warnmeldung angezeigt werden, vergewissern Sie sich, dass der Dienst ausgeführt wird und dass der Connectorname und das geheime Token den Werten entsprechen, die Sie im Konfigurations-Assistenten konfiguriert haben.
- Wenn das Skript
False
ausgibt, wurden auf dem Quellverzeichnisserver keine Einträge für vorhandene Benutzer gefunden. Wenn es sich um eine neue Verzeichnisserverinstallation handelt, ist dieses Verhalten zu erwarten. Sie können dann mit dem nächsten Abschnitt fortfahren. - Wenn der Verzeichnisserver jedoch bereits eine*n oder mehrere Benutzer*innen enthält, das Skript jedoch
False
angezeigt hat, gibt dieser Status an, dass der Connector nicht vom Verzeichnisserver lesen konnte. Wenn Sie versuchen, bereitzustellen, stimmt Microsoft Entra ID möglicherweise nicht ordnungsgemäß mit Benutzern in diesem Quellverzeichnis mit Benutzern in Microsoft Entra ID überein. Warten Sie einige Minuten, bis der Connectorhost das Lesen von Objekten auf dem vorhandenen Verzeichnisserver abgeschlossen hat, und führen Sie das Skript anschließend erneut aus. Sollte weiterhinFalse
ausgegeben werden, vergewissern Sie sich, dass die Konfiguration Ihres Connectors und die Berechtigungen auf dem Verzeichnisserver dem Connector das Lesen vorhandener Benutzer ermöglichen.
Testen der Verbindung von Microsoft Entra ID mit dem Connectorhost
Kehren Sie zu dem Webbrowserfenster zurück, in dem Sie die Anwendungsbereitstellung im Portal konfiguriert haben.
Hinweis
Wenn für das Fenster ein Timeout aufgetreten ist, müssen Sie den Agent erneut auswählen.
- Melden Sie sich beim Azure-Portal an.
- Wechseln Sie zu Unternehmensanwendungen und der Anwendung Lokale ECMA-App.
- Klicken Sie auf Bereitstellung.
- Wenn Erste Schritte angezeigt wird, ändern Sie den Modus in Automatisch. Wählen Sie im Abschnitt Lokale Konnektivität den Agent aus, den Sie gerade bereitgestellt haben, wählen Sie dann Agent(s) zuweisen aus, und warten Sie 10 Minuten. Wechseln Sie andernfalls zu Bereitstellung bearbeiten.
Geben Sie im Abschnitt Administratoranmeldeinformationen die folgende URL ein. Ersetzen Sie den Teil
connectorName
durch den Namen des Connectors auf dem ECMA-Host (beispielsweiseLDAP
). Wenn Sie ein Zertifikat Ihrer Zertifizierungsstelle für den Ecma International-Host bereitgestellt haben, ersetzen Sielocalhost
durch den Hostnamen des Servers, auf dem der ECMA-Host installiert ist.Eigenschaft Wert Mandanten-URL https://localhost:8585/ecma2host_connectorName/scim Geben Sie den Wert des geheimen Tokens ein, das Sie beim Erstellen des Connectors definiert haben.
Hinweis
Wenn Sie den Agent gerade der Anwendung zugewiesen haben, warten Sie 10 Minuten, bis die Registrierung abgeschlossen ist. Der Konnektivitätstest funktioniert erst, wenn die Registrierung abgeschlossen ist. Sie können erzwingen, dass die Agent-Registrierung abgeschlossen wird, indem Sie den Bereitstellungs-Agent auf Ihrem Server neu starten, um den Registrierungsprozess zu beschleunigen. Navigieren Sie zu Ihrem Server, suchen Sie über die Windows-Suchleiste nach Dienste, identifizieren Sie den Dienst Microsoft Entra Connect-Bereitstellungs-Agent, klicken Sie mit der rechten Maustaste auf den Dienst, und starten Sie ihn neu.
Wählen Sie Verbindung testen aus, und warten Sie eine Minute.
Wenn der Verbindungstest erfolgreich war und angezeigt wird, dass die angegebenen Anmeldeinformationen zum Aktivieren der Bereitstellung autorisiert sind, wählen Sie Speichern aus.
Erweitern des Microsoft Entra-Schemas
Wenn Ihr Verzeichnisserver zusätzliche Attribute benötigt, die nicht zum Microsoft Entra-Standardschema für Benutzer gehören, können Sie bei der Bereitstellung konfigurieren, dass Werte dieser Attribute über eine Konstante oder einen aus anderen Microsoft Entra-Attributen transformierten Ausdruck oder durch Erweitern des Microsoft Entra-Schemas bereitgestellt werden.
Wenn der Verzeichnisserver erfordert, dass Benutzer über ein Attribut wie uidNumber
für das OpenLDAP-POSIX-Schema verfügen, und dieses Attribut noch nicht Teil Ihres Microsoft Entra-Benutzerschemas ist und für die einzelnen Benutzer jeweils eindeutig sein muss, müssen Sie dieses Attribut entweder über einen Ausdruck aus anderen Benutzerattributen generieren oder das Verzeichniserweiterungsfeature verwenden, um dieses Attribut als Erweiterung hinzuzufügen.
Wenn Ihre Benutzer aus Active Directory Domain Services stammen und in diesem Verzeichnis über das Attribut verfügen, können Sie mithilfe von Microsoft Entra Connect oder der Microsoft Entra Connect-Cloudsynchronisierung konfigurieren, dass das Attribut von Active Directory Domain Services mit Microsoft Entra ID synchronisiert wird, damit es für die Bereitstellung auf anderen Systemen verfügbar ist.
Wenn Ihre Benutzer aus Microsoft Entra ID stammen, müssen Sie für jedes neue Attribut, das Sie für Benutzer speichern müssen, eine Verzeichniserweiterung definieren. Aktualisieren Sie dann die Microsoft Entra-Benutzer*innen, die bereitgestellt werden sollen, um den einzelnen Benutzer*innen einen Wert für diese Attribute zuzuweisen.
Konfigurieren von Attributzuordnungen
In diesem Abschnitt wird die Zuordnung zwischen den Attributen von Microsoft Entra-Benutzer*innen und den Attributen konfiguriert, die Sie zuvor im Assistenten für die ECMA-Hostkonfiguration ausgewählt haben. Wenn der Connector später ein Objekt auf einem Verzeichnisserver erstellt, werden die Attribute von Microsoft Entra-Benutzer*innen über den Connector an den Verzeichnisserver gesendet und in dieses neue Objekt integriert.
Wählen Sie im Microsoft Entra Admin Center unter Unternehmensanwendungen die Anwendung Lokale ECMA-App und dann die Seite Bereitstellung aus.
Wählen Sie Bereitstellung bearbeiten aus.
Erweitern Sie Zuordnungen, und wählen Sie Microsoft Entra-Benutzer bereitstellen aus. Wenn Sie die Attributzuordnungen für diese Anwendung zum ersten Mal konfiguriert haben, ist nur eine Zuordnung für einen Platzhalter vorhanden.
Vergewissern Sie sich, dass das Schema des Verzeichnisservers in Microsoft Entra ID verfügbar ist, indem Sie das Kontrollkästchen Erweiterte Optionen anzeigen aktivieren und Attributliste für ScimOnPremises bearbeiten auswählen. Überprüfen Sie, ob alle im Konfigurations-Assistenten ausgewählten Attribute aufgeführt sind. Warten Sie andernfalls einige Minuten, bis das Schema aktualisiert wurde, wählen Sie dann in der Navigationszeile Attributzuordnung und dann erneut Attributliste für ScimOnPremises bearbeiten aus, um die Seite neu zu laden. Wenn die Attribute aufgelistet werden, wählen Sie „Abbrechen“ aus, um zur Zuordnungsliste zurückzukehren.
Jeder Benutzer in einem Verzeichnis muss über einen eindeutigen Distinguished Name verfügen. Sie können mithilfe einer Attributzuordnung angeben, wie der Connector einen Distinguished Name erstellen soll. Wählen Sie Neue Zuordnung hinzufügen aus. Verwenden Sie die folgenden Werte, um die Zuordnung zu erstellen. Ändern Sie dabei die Distinguished Names in dem Ausdruck so, dass sie denen der Organisationseinheit oder eines anderen Containers in Ihrem Zielverzeichnis entsprechen.
- Zuordnungstyp: Ausdruck
- Ausdruck bei der Bereitstellung in AD LDS:
Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
- Ausdruck bei der Bereitstellung in OpenLDAP:
Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- Zielattribut:
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- Diese Zuordnung anwenden: Nur beim Erstellen von Objekten
Wenn für den Verzeichnisserver mehrere strukturelle Objektklassenwerte (oder Hilfsobjektklassenwerte) im Attribut
objectClass
angegeben werden müssen, fügen Sie diesem Attribut eine Zuordnung hinzu. In dieser exemplarischen Bereitstellung für AD LDS mussobjectClass
nicht zugeordnet werden. Bei anderen Verzeichnisservern oder Schemas kann diese Zuordnung allerdings erforderlich sein. Wählen Sie zum Hinzufügen einer Zuordnung fürobjectClass
die Option Neue Zuordnung hinzufügen aus. Verwenden Sie die folgenden Werte, um die Zuordnung zu erstellen, und ändern Sie dabei die Objektklassennamen im Ausdruck so, dass sie denen des Zielverzeichnisschemas entsprechen.- Zuordnungstyp: Ausdruck
- Ausdruck bei der Bereitstellung des inetOrgPerson-Schemas:
Split("inetOrgPerson",",")
- Ausdruck bei der Bereitstellung des POSIX-Schemas:
Split("inetOrgPerson,posixAccount,shadowAccount",",")
- Zielattribut:
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- Diese Zuordnung anwenden: Nur beim Erstellen von Objekten
Wenn bei einer Bereitstellung für AD LDS eine Zuordnung von userPrincipalName zu PLATZHALTER vorhanden ist, klicken Sie auf diese Zuordnung, und bearbeiten Sie sie. Verwenden Sie die folgenden Werte, um die Zuordnung zu aktualisieren:
- Zuordnungstyp: Direkt
- Quellattribut:
userPrincipalName
- Zielattribut:
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
- Rangfolge für Abgleich: 1
- Diese Zuordnung anwenden: Nur beim Erstellen von Objekten
Fügen Sie bei einer Bereitstellung für AD LDS eine Zuordnung für isSoftDeleted hinzu. Wählen Sie Neue Zuordnung hinzufügen aus. Verwenden Sie die folgenden Werte, um die Zuordnung zu erstellen:
- Zuordnungstyp: Direkt
- Quellattribut:
isSoftDeleted
- Zielattribut:
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled
Wählen Sie für jede der Zuordnungen aus der folgenden Tabelle für Ihren Verzeichnisserver die Option Neue Zuordnung hinzufügen aus, und geben Sie jeweils das Quell- und Zielattribut an. Bei der Bereitstellung in einem vorhandenen Verzeichnis mit vorhandenen Benutzern müssen Sie die Zuordnung für das gemeinsame Attribut bearbeiten, um Objekte mit diesem Attribut abgleichen für dieses Attribut festzulegen. Weitere Informationen zur Attributzuordnung finden Sie hier.
Für AD LDS:
Zuordnungstyp Quellattribut Zielattribut Direkt displayName
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName
Für OpenLDAP:
Zuordnungstyp Quellattribut Zielattribut Direkt displayName
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn
Direkt surname
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn
Direkt userPrincipalName
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail
Für OpenLDAP mit POSIX-Schema müssen Sie auch die Attribute
gidNumber
,homeDirectory
,uid
unduidNumber
angeben. Jede*r Benutzer*in benötigt eine eindeutigeuid
und eine eindeutigeuidNumber
. In der Regel wirdhomeDirectory
durch einen Ausdruck festgelegt, der von der userID des Benutzers/der Benutzerin abgeleitet wird. Wenn z. B. eine Benutzer-uid
durch einen vom Benutzerprinzipalnamen abgeleiteten Ausdruck generiert wird, kann der Wert für das Basisverzeichnis des jeweiligen Benutzers/der jeweiligen Benutzerin durch einen ähnlichen Ausdruck generiert werden, der ebenfalls von dem Benutzerprinzipalnamen abgeleitet wird. Je nach Anwendungsfall sollen sich möglicherweise alle Benutzer*innen in derselben Gruppe befinden, daher würden Sie diegidNumber
aus einer Konstanten zuweisen.Zuordnungstyp Quellattribut Zielattribut Ausdruck ToLower(Word([userPrincipalName], 1, "@"), )
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
Direkt (Attribut spezifisch für Ihr Verzeichnis) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber
Ausdruck Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory
Dauerhaft 10000
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber
Bei der Bereitstellung in einem anderen Verzeichnis als AD LDS fügen Sie
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword
eine Zuordnung hinzu, die ein anfängliches zufälliges Kennwort für Benutzer*innen festlegt. Für AD LDS gibt es keine Zuordnung für userPassword.Wählen Sie Speichern.
Sicherstellen der erforderlichen Attribute für Benutzer*innen, die für die Anwendung bereitgestellt werden sollen
Wenn Personen über vorhandene Benutzerkonten im LDAP-Verzeichnis verfügen, müssen Sie sicherstellen, dass die Microsoft Entra-Benutzerdarstellung über die für den Abgleich erforderlichen Attribute verfügt.
Wenn Sie planen, neue Benutzer im LDAP-Verzeichnis zu erstellen, müssen Sie sicherstellen, dass die Microsoft Entra-Darstellungen dieser Benutzer über die Quellattribute verfügen, die für das Benutzerschema des Zielverzeichnisses erforderlich sind.
Sie können die Microsoft Graph PowerShell-Cmdlets verwenden, um die Überprüfung von Benutzer*innen auf die erforderlichen Attribute zu automatisieren.
Angenommen, Ihre Bereitstellung erfordert, dass Benutzer*innen über die drei Attribute DisplayName
, surname
und extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty
verfügen. Sie können das Get-MgUser
-Cmdlet verwenden, um die einzelnen Benutzer*innen abzurufen und zu überprüfen, ob die erforderlichen Attribute vorhanden sind. Beachten Sie, dass das Get-MgUser
-Cmdlet in Graph v1.0 standardmäßig keines der Verzeichniserweiterungsattribute von Benutzern zurückgibt, es sei denn, die Attribute werden in der Anforderung als eine der zurückzugebenden Eigenschaften angegeben.
$userPrincipalNames = (
"alice@contoso.com",
"bob@contoso.com",
"carol@contoso.com" )
$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")
$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}
foreach ($un in $userPrincipalNames) {
$nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}
Sammeln vorhandener Benutzer aus dem LDAP-Verzeichnis
Viele LDAP-Verzeichnisse, so wie Active Directory, enthalten einen Befehl, der eine Liste der Benutzer ausgibt.
Ermitteln Sie, welche Benutzer*innen in diesem Verzeichnis Benutzer*innen der Anwendung sein können. Diese Auswahl hängt von der Konfiguration Ihrer Anwendung ab. Für einige Anwendungen ist jeder Benutzer, der in einem LDAP-Verzeichnis vorhanden ist, ein gültiger Benutzer. Andere Anwendungen erfordern möglicherweise, dass Benutzer*innen über ein bestimmtes Attribut verfügen oder Mitglied einer Gruppe in diesem Verzeichnis sind.
Führen Sie den Befehl aus, der diese Teilmenge von Benutzern aus Ihrem Verzeichnis abruft. Stellen Sie sicher, dass die Ausgabe die Benutzerattribute enthält, die für den Abgleich mit Microsoft Entra ID verwendet werden. Beispiele für diese Attribute sind Mitarbeiter-ID, Kontoname und E-Mail-Adresse.
Mit diesem Befehl würde beispielsweise eine AD LDS
csvde
CSV-Datei im aktuellen Verzeichnis mit demuserPrincipalName
Attribut jeder Person im Verzeichnis erzeugt:$out_filename = ".\users.csv" csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
Übertragen Sie bei Bedarf die CSV-Datei mit der Benutzerliste in ein System mit installierten Microsoft Graph PowerShell-Cmdlets.
Nachdem Sie nun über eine Liste aller Benutzer*innen aus der Anwendung verfügen, führen Sie für diese Benutzer*innen aus dem Datenspeicher der Anwendung einen Abgleich mit den Benutzer*innen in Microsoft Entra ID durch. Bevor Sie fortfahren, sehen Sie sich die Informationen zum Abgleichen von Benutzer*innen in den Quell- und Zielsystemen an.
Abrufen der IDs der Benutzer*innen in Microsoft Entra ID
In diesem Abschnitt wird gezeigt, wie Sie mithilfe von Microsoft Graph PowerShell-Cmdlets mit Microsoft Entra ID interagieren.
Wenn Ihre Organisation diese Cmdlets zum ersten Mal für dieses Szenario verwendet, müssen Sie über die Rolle „Globaler Administrator“ verfügen, um die Verwendung von Microsoft Graph PowerShell in Ihrem Mandanten zuzulassen. Für nachfolgende Interaktionen können Rollen mit geringerem Berechtigungsumfang verwendet werden. Dazu zählen z. B.:
- „Benutzeradministrator“, wenn Sie beabsichtigen, neue Benutzer*innen zu erstellen.
- „Anwendungsadministrator“ oder Identity Governance-Administrator, wenn Sie lediglich Anwendungsrollenzuweisungen verwalten.
Öffnen Sie PowerShell.
Wenn die Microsoft Graph PowerShell-Module noch nicht installiert sind, installieren Sie das
Microsoft.Graph.Users
-Modul und andere Module mit dem folgenden Befehl:Install-Module Microsoft.Graph
Wenn die Module bereits installiert sind, stellen Sie sicher, dass Sie eine aktuelle Version verwenden:
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
Herstellen einer Verbindung mit Microsoft Entra ID:
$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"
Wenn Sie diesen Befehl zum ersten Mal verwendet haben, müssen Sie möglicherweise einwilligen, dass die Microsoft Graph-Befehlszeilentools über diese Berechtigungen verfügen.
Lesen Sie die Liste der Benutzer, die vom Datenspeicher der Anwendung in die PowerShell-Sitzung abgerufen wurden. Wenn die Benutzerliste sich in einer CSV-Datei befindet, können Sie das PowerShell-Cmdlet
Import-Csv
verwenden und den Dateinamen aus dem vorherigen Abschnitt als Argument angeben.Wenn die aus SAP Cloud Identity Services abgerufene Datei z. B. Users-exported-from-sap.csv heißt und sich im aktuellen Verzeichnis befindet, geben Sie diesen Befehl ein.
$filename = ".\Users-exported-from-sap.csv" $dbusers = Import-Csv -Path $filename -Encoding UTF8
Wenn Sie allerdings beispielsweise eine Datenbank oder ein Verzeichnis verwenden und der Name der Datei users.csv lautet und sich die Datei im aktuellen Verzeichnis befindet, geben Sie diesen Befehl ein:
$filename = ".\users.csv" $dbusers = Import-Csv -Path $filename -Encoding UTF8
Wählen Sie die Spalte der Datei users.csv aus, die einem Benutzerattribut in Microsoft Entra ID entspricht.
Wenn Sie SAP Cloud Identity Services verwenden, ist die Standardzuordnung zwischen dem SAP SCIM-Attribut
userName
und dem Microsoft Entra ID-AttributuserPrincipalName
:$db_match_column_name = "userName" $azuread_match_attr_name = "userPrincipalName"
Ein weiteres Beispiel: Wenn Sie eine Datenbank oder ein Verzeichnis verwenden, kann eine Datenbank beispielsweise Benutzer enthalten, deren Wert in der Spalte
EMail
mit dem Wert des Microsoft Entra ID-AttributsuserPrincipalName
übereinstimmt:$db_match_column_name = "EMail" $azuread_match_attr_name = "userPrincipalName"
Rufen Sie die IDs dieser Benutzer*innen in Microsoft Entra ID ab.
Im folgenden PowerShell-Skript werden die zuvor angegebenen Werte
$dbusers
,$db_match_column_name
und$azuread_match_attr_name
verwendet. Mit diesem Skript wird Microsoft Entra ID abgefragt, um eine*n Benutzer*in mit Attributen zu ermitteln, deren Werte mit den Datensätzen in der Quelldatei übereinstimmen. Wenn es viele Benutzer in der Datei gibt, die aus SAP Cloud Identity Services, einer Datenbank oder einem Verzeichnis als Quelle abgerufen wurde, kann die Ausführung dieses Skripts einige Minuten dauern. Wenn in Microsoft Entra ID kein Attribut mit dem Wert vorhanden ist und Siecontains
oder einen anderen Filterausdruck verwenden müssen, müssen Sie dieses Skript und das Skript in Schritt 11 unten so anpassen, dass ein anderer Filterausdruck verwendet wird.$dbu_not_queried_list = @() $dbu_not_matched_list = @() $dbu_match_ambiguous_list = @() $dbu_query_failed_list = @() $azuread_match_id_list = @() $azuread_not_enabled_list = @() $dbu_values = @() $dbu_duplicate_list = @() foreach ($dbu in $dbusers) { if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { $val = $dbu.$db_match_column_name $escval = $val -replace "'","''" if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval } $filter = $azuread_match_attr_name + " eq '" + $escval + "'" try { $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop) if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else { $id = $ul[0].id; $azuread_match_id_list += $id; if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id } } } catch { $dbu_query_failed_list += $dbu } } else { $dbu_not_queried_list += $dbu } }
Zeigen Sie die Ergebnisse der vorherigen Abfragen an. Sehen Sie nach, ob Benutzer in SAP Cloud Identity Services, in der Datenbank oder im Verzeichnis aufgrund von Fehlern oder fehlenden Übereinstimmungen nicht in Microsoft Entra ID gefunden wurden.
Mit dem folgenden PowerShell-Skript wird die Anzahl von Datensätzen angezeigt, die nicht gefunden wurden:
$dbu_not_queried_count = $dbu_not_queried_list.Count if ($dbu_not_queried_count -ne 0) { Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name." } $dbu_duplicate_count = $dbu_duplicate_list.Count if ($dbu_duplicate_count -ne 0) { Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value" } $dbu_not_matched_count = $dbu_not_matched_list.Count if ($dbu_not_matched_count -ne 0) { Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name." } $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count if ($dbu_match_ambiguous_count -ne 0) { Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous." } $dbu_query_failed_count = $dbu_query_failed_list.Count if ($dbu_query_failed_count -ne 0) { Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors." } $azuread_not_enabled_count = $azuread_not_enabled_list.Count if ($azuread_not_enabled_count -ne 0) { Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in." } if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) { Write-Output "You will need to resolve those issues before access of all existing users can be reviewed." } $azuread_match_count = $azuread_match_id_list.Count Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."
Nach Abschluss des Skripts wird ein Fehler ausgegeben, wenn Datensätze aus der Datenquelle nicht in Microsoft Entra ID gefunden wurden. Sollten nicht alle Datensätze für Benutzer*innen aus dem Datenspeicher der Anwendung als Benutzer*innen in Microsoft Entra ID gefunden werden, müssen Sie untersuchen, welche Datensätze nicht übereinstimmen und warum.
Möglicherweise wurden z. B. die E-Mail-Adresse und der Benutzerprinzipalname einer Person in Microsoft Entra ID geändert, ohne dass die entsprechende
mail
-Eigenschaft in der Datenquelle der Anwendung aktualisiert wurde. Oder Benutzer*innen haben die Organisation bereits verlassen, sind aber noch immer in der Datenquelle der Anwendung vorhanden. Eine weitere Möglichkeit für fehlende Übereinstimmungen ist, dass ein Anbieter- oder Superadministratorkonto in der Datenquelle der Anwendung vorhanden ist, die keiner bestimmten Person in Microsoft Entra ID entspricht.Wenn Benutzer*innen vorhanden sind, die nicht in Microsoft Entra ID gefunden werden konnten oder die nicht aktiv waren und sich nicht anmelden konnten, Sie den Zugriff dieser Benutzer und Benutzerinnen jedoch überprüfen oder ihre Attribute in SAP Cloud Identity Services, in der Datenbank oder im Verzeichnis aktualisieren möchten, müssen Sie die Anwendung oder die Abgleichsregel aktualisieren oder Microsoft Entra ID-Benutzer/-Benutzerinnen dafür aktualisieren oder erstellen. Weitere Informationen dazu, welche Änderung vorgenommen werden sollte, finden Sie unter Verwalten von Zuordnungen und Benutzerkonten in Anwendungen, die nicht mit Benutzern in Microsoft Entra ID übereinstimmen.
Wenn Sie die Option zum Erstellen von Benutzern in Microsoft Entra ID auswählen, können Sie Benutzer mithilfe einer der folgenden Optionen per Massenvorgang erstellen:
- Eine CSV-Datei, wie unter Massenerstellen von Benutzer*innen im Microsoft Entra Admin Center beschrieben
- das Cmdlet New-MgUser
Stellen Sie sicher, dass für diese neuen Benutzer die für Microsoft Entra ID erforderlichen Attribute aufgefüllt werden, um sie später mit vorhandenen Benutzer*innen in der Anwendung abzugleichen. Außerdem müssen die Attribute aufgefüllt werden, die von Microsoft Entra ID benötigt werden, einschließlich
userPrincipalName
,mailNickname
unddisplayName
.userPrincipalName
muss im Vergleich zu allen anderen Benutzern im Verzeichnis eindeutig sein.Es kann beispielsweise Benutzer*innen in der Datenbank geben, auf die Folgendes zutrifft: Der Wert in der Spalte
EMail
ist der Wert, den Sie als Microsoft Entra-Benutzerprinzipalnamen verwenden möchten, der Wert in der SpalteAlias
enthält den Microsoft Entra ID-E-Mail-Kontonamen, und der Wert in der SpalteFull name
enthält den Benutzeranzeigenamen:$db_display_name_column_name = "Full name" $db_user_principal_name_column_name = "Email" $db_mail_nickname_column_name = "Alias"
Dann können Sie dieses Skript verwenden, um Microsoft Entra-Benutzer für diejenigen Benutzer in SAP Cloud Identity Services, der Datenbank oder im Verzeichnis zu erstellen, die nicht mit Benutzern in Microsoft Entra ID übereinstimmten. Beachten Sie, dass Sie dieses Skript möglicherweise bearbeiten müssen, um weitere Microsoft Entra-Attribute hinzuzufügen, die in Ihrer Organisation benötigt werden, oder um das entsprechende Microsoft Entra-Attribut bereitzustellen, wenn der
$azuread_match_attr_name
weder einmailNickname
noch einuserPrincipalName
ist.$dbu_missing_columns_list = @() $dbu_creation_failed_list = @() foreach ($dbu in $dbu_not_matched_list) { if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) { $params = @{ accountEnabled = $false displayName = $dbu.$db_display_name_column_name mailNickname = $dbu.$db_mail_nickname_column_name userPrincipalName = $dbu.$db_user_principal_name_column_name passwordProfile = @{ Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_}) } } try { New-MgUser -BodyParameter $params } catch { $dbu_creation_failed_list += $dbu; throw } } else { $dbu_missing_columns_list += $dbu } }
Nachdem Sie Microsoft Entra ID fehlende Benutzer hinzugefügt haben, führen Sie das Skript aus Schritt 7 erneut aus. Führen Sie dann das Skript aus Schritt 8 aus. Überprüfen Sie, ob keine Fehler gemeldet werden.
$dbu_not_queried_list = @() $dbu_not_matched_list = @() $dbu_match_ambiguous_list = @() $dbu_query_failed_list = @() $azuread_match_id_list = @() $azuread_not_enabled_list = @() $dbu_values = @() $dbu_duplicate_list = @() foreach ($dbu in $dbusers) { if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { $val = $dbu.$db_match_column_name $escval = $val -replace "'","''" if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval } $filter = $azuread_match_attr_name + " eq '" + $escval + "'" try { $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop) if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else { $id = $ul[0].id; $azuread_match_id_list += $id; if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id } } } catch { $dbu_query_failed_list += $dbu } } else { $dbu_not_queried_list += $dbu } } $dbu_not_queried_count = $dbu_not_queried_list.Count if ($dbu_not_queried_count -ne 0) { Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name." } $dbu_duplicate_count = $dbu_duplicate_list.Count if ($dbu_duplicate_count -ne 0) { Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value" } $dbu_not_matched_count = $dbu_not_matched_list.Count if ($dbu_not_matched_count -ne 0) { Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name." } $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count if ($dbu_match_ambiguous_count -ne 0) { Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous." } $dbu_query_failed_count = $dbu_query_failed_list.Count if ($dbu_query_failed_count -ne 0) { Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors." } $azuread_not_enabled_count = $azuread_not_enabled_list.Count if ($azuread_not_enabled_count -ne 0) { Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in." } if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) { Write-Output "You will need to resolve those issues before access of all existing users can be reviewed." } $azuread_match_count = $azuread_match_id_list.Count Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."
Zuweisen von Benutzern zu einer Anwendung
Da der Microsoft Entra-ECMA-Connectorhost und Microsoft Entra ID nun miteinander kommunizieren und die Attributzuordnungen konfiguriert sind, können Sie mit der Konfiguration der Benutzer für den Bereitstellungsbereich fortfahren.
Wichtig
Wenn Sie mit der Rolle „Hybrididentitätsadmin“ angemeldet wurden, müssen Sie sich zum Ausführen der Schritte in diesem Abschnitt zuerst abmelden und dann mit einem Konto anmelden, das mindestens über die Rolle „Anwendungsadmin“ verfügt. Die Rolle „Hybrididentitätsadministrator“ verfügt nicht über Berechtigungen zum Zuweisen von Benutzern zu Anwendungen.
Wenn vorhandene Benutzer in der LDAP-Verzeichnis vorhanden sind, sollten Sie Anwendungsrollenzuweisungen für diese vorhandenen Benutzer erstellen. Weitere Informationen zum Erstellen von großen Mengen von Anwendungsrollenzuweisungen New-MgServicePrincipalAppRoleAssignedTo
finden Sie unter Verwalten der vorhandenen Benutzer einer Anwendung in Microsoft Entra ID.
Ist das LDAP-Verzeichnis leer, wählen Sie eine*n Testbenutzer*in aus Microsoft Entra ID aus, die/der über die erforderlichen Attribute verfügt und für den Verzeichnisserver der Anwendung bereitgestellt wird.
- Stellen Sie sicher, dass der ausgewählte Benutzer über alle Eigenschaften verfügt, die den erforderlichen Attributen des Verzeichnisserverschemas zugeordnet werden.
- Wählen Sie im Azure-Portal die Option Unternehmensanwendungen aus.
- Wählen Sie die Anwendung Lokale ECMA-App aus.
- Wählen Sie links unter Verwalten die Option Benutzer und Gruppen aus.
- Wählen Sie Benutzer/Gruppe hinzufügen aus.
- Wählen Sie unter Benutzer die Option Keine Elemente ausgewählt aus.
- Wählen Sie auf der rechten Seite eine*n Benutzer*in und dann die Schaltfläche Auswählen aus.
- Wählen Sie nun Zuweisen aus.
Testen der Bereitstellung
Nachdem nun Ihre Attribute zugeordnet und erste Benutzer*innen zugewiesen sind, können Sie die bedarfsorientierte Bereitstellung mit einem/einer Ihrer Benutzer*innen testen.
Wählen Sie auf dem Server, auf dem der Microsoft Entra-ECMA-Connectorhost ausgeführt wird, Starten aus.
Geben Sie run (Ausführen) und services.msc in das Feld ein.
Vergewissern Sie sich in der Liste Dienste, dass sowohl der Dienst Microsoft Entra Connect-Bereitstellungs-Agent als auch der Dienst Microsoft ECMA2Host ausgeführt wird. Wählen Sie andernfalls Starten aus.
Wählen Sie im Azure-Portal die Option Unternehmensanwendungen aus.
Wählen Sie die Anwendung Lokale ECMA-App aus.
Wählen Sie links Bereitstellung aus.
Klicken Sie auf Bei Bedarf bereitstellen.
Suchen Sie nach einem Ihrer Testbenutzer, und wählen Sie Bereitstellen aus.
Nach einigen Sekunden wird die Meldung Der Benutzer wurde erfolgreich im Zielsystem erstellt mit einer Liste der Benutzerattribute angezeigt. Wenn stattdessen ein Fehler angezeigt wird, finden Sie weitere Informationen unter Problembehandlung bei Bereitstellungsfehlern.
Benutzerbereitstellung starten
Nachdem der Test der bedarfsgesteuerten Bereitstellung erfolgreich war, fügen Sie die verbleibenden Benutzer*innen hinzu.
- Wählen Sie im Azure-Portal die Anwendung aus.
- Wählen Sie links unter Verwalten die Option Benutzer und Gruppen aus.
- Stellen Sie sicher, dass alle Benutzer*innen der Anwendungsrolle zugewiesen sind.
- Wechseln Sie zurück zur Seite für die Bereitstellungskonfiguration.
- Stellen Sie sicher, dass der Bereich nur auf zugewiesene Benutzer*innen und Gruppen festgelegt ist, legen Sie die Bereitstellung auf Ein fest, und wählen Sie Speichern aus.
- Warten Sie einige Minuten, bis die Bereitstellung gestartet wurde. Dies kann bis zu 40 Minuten dauern. Gehen Sie nach Abschluss des Bereitstellungsauftrags wie im folgenden Abschnitt beschrieben vor.
Beheben von Fehlern bei der Bereitstellung
Wenn ein Fehler angezeigt wird, wählen Sie Bereitstellungsprotokolle anzeigen aus. Suchen Sie im Protokoll nach einer Zeile mit dem Status Fehler, und klicken Sie auf diese Zeile.
Wenn die Fehlermeldung Fehler beim Erstellen des Benutzers lautet, überprüfen Sie die angezeigten Attribute anhand der Anforderungen des Verzeichnisschemas.
Weitere Informationen finden Sie auf der Registerkarte Problembehandlung und Empfehlungen.
Wenn in der Fehlermeldung zur Problembehandlung angegeben ist, dass ein objectClass-Wert invalid per syntax
ist, stellen Sie sicher, dass das Bereitstellungsattribut zum objectClass
-Attribut nur Namen von Objektklassen enthält, die vom Verzeichnisserver erkannt werden.
Bei weiteren Fehlern finden Sie möglicherweise Antworten unter Problembehandlung bei der lokalen Anwendungsbereitstellung.
Wenn Sie die Bereitstellung für diese Anwendung anhalten möchten, können Sie auf der Seite für die Bereitstellungskonfiguration den Status der Bereitstellungskonfiguration in Aus ändern und Speichern auswählen. Durch diese Aktion wird der Bereitstellungsdienst in Zukunft nicht mehr ausgeführt.
Überprüfen der erfolgreichen Bereitstellung von Benutzern
Überprüfen Sie im Anschluss an die Wartezeit den Verzeichnisserver, um sich zu vergewissern, dass Benutzer bereitgestellt werden. Diese Abfrage, die Sie auf dem Verzeichnisserver ausführen, hängt davon ab, welche Befehle Ihr Verzeichnisserver bereitstellt.
Die folgenden Anweisungen veranschaulichen die Überprüfung von AD LDS.
- Öffnen Sie den Server-Manager, und wählen Sie links „AD LDS“ aus.
- Klicken Sie mit der rechten Maustaste auf Ihre Instanz von AD LDS, und wählen Sie im Kontextmenü die Option „Ldp.exe“ aus.
- Wählen Sie im oberen Bereich der Datei „Ldp.exe“ die Option Verbindung und anschließend Verbinden aus.
- Geben Sie die folgenden Informationen ein, und klicken Sie anschließend auf OK:
- Wählen Sie im oberen Bereich unter Verbindung die Option Binden aus.
- Übernehmen Sie die Standardwerte, und klicken Sie auf OK.
- Wählen Sie im oberen Bereich die Option Ansicht und anschließend Baum aus.
- Geben Sie für den Basis-DN die Zeichenfolge CN=App,DC=contoso,DC=lab ein, und klicken Sie auf OK.
- Erweitern Sie auf der linken Seite den Distinguished Name, und klicken Sie auf CN=CloudUsers,CN=App,DC=contoso,DC=lab. Sie sollten Ihre Benutzer*innen sehen, die von Microsoft Entra ID bereitgestellt wurden.
Die folgenden Anweisungen veranschaulichen die Überprüfung von OpenLDAP.
- Öffnen Sie ein Terminalfenster mit einer Befehlsshell auf dem System mit OpenLDAP.
- Geben Sie den Befehl
ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
ein. - Überprüfen Sie, ob das resultierende LDIF die Benutzer*innen enthält, die über Microsoft Entra ID bereitgestellt werden.