Konfigurieren von Microsoft Entra ID zum Bereitstellen von Benutzer*innen in LDAP-Verzeichnissen

Artikel
02/13/2024

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 eine Benutzerin 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. Die Benutzer müssen über die Rolle „Hybrididentitätsadministrator“ oder „Globaler Administrator“ 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.
Wählen Sie Neuer Connector aus.

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 Einstellung `SSL` oder `TLS` ohne konfiguriertes Clientzertifikat sendet der Connector eine einfache LDAP-Bindung, um sich mit einem Distinguished Name und einem Kennwort zu authentifizieren. Mit der Einstellung `SSL` oder `TLS` und einem angegebenen Clientzertifikat sendet der Connector eine LDAP-SASL-Bindung vom Typ `EXTERNAL`, 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 OpenLDAP `cn=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` oder `TLS` 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` oder `TLS` 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 oder `User` 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 Attribut `uid` 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 das objectClass-Attribut deaktiviert ist. Falls userPassword festgelegt wurde, muss auch das Kontrollkästchen für das userPassword-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 Wert ObjectTypePathcache 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 weiterhin False 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.
1. Melden Sie sich beim Azure-Portal an.
2. Wechseln Sie zu Unternehmensanwendungen und der Anwendung Lokale ECMA-App.
3. Klicken Sie auf Bereitstellung.
4. 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 (beispielsweise LDAP). Wenn Sie ein Zertifikat Ihrer Zertifizierungsstelle für den Ecma International-Host bereitgestellt haben, ersetzen Sie localhost 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.

Eigenschaft	Wert
Mandanten-URL	https://localhost:8585/ecma2host_connectorName/scim

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 muss objectClass nicht zugeordnet werden. Bei anderen Verzeichnisservern oder Schemas kann diese Zuordnung allerdings erforderlich sein. Wählen Sie zum Hinzufügen einer Zuordnung für objectClass 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 und uidNumber angeben. Jede*r Benutzer*in benötigt eine eindeutige uid und eine eindeutige uidNumber. In der Regel wird homeDirectory 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 die gidNumber 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 dem userPrincipalName 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 den folgenden 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-Attribut userPrincipalName:
```
$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-Attributs userPrincipalName ü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 Sie contains 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 und displayName. 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 Spalte Alias enthält den Microsoft Entra ID-E-Mail-Kontonamen, und der Wert in der Spalte Full 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 ein mailNickname noch ein userPrincipalName 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ätsadministrator“ angemeldet wurden, müssen Sie sich zum Ausführen der Schritte in diesem Abschnitt zuerst abmelden und dann mit einem Konto anmelden, das über die Rolle „Anwendungsadministrator“, „Cloudanwendungsadministrator“ oder „Globaler Administrator“ 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:
- Server: APP3
- Port: 636
- Aktivieren Sie das Kontrollkästchen „SSL“.
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.

Konfigurieren von Microsoft Entra ID zum Bereitstellen von Benutzer*innen in LDAP-Verzeichnissen

Voraussetzungen für die Bereitstellung von Benutzern in einem LDAP-Verzeichnis

Lokale Voraussetzungen

Unterstützte LDAP-Verzeichnisserver

Cloudanforderungen

Weitere Empfehlungen und Einschränkungen

Auswählen von Ausführungsprofilen

Festlegen der Art und Weise der Interaktion des LDAP-Connectors von Microsoft Entra mit dem Verzeichnisserver

Vorbereiten des LDAP-Verzeichnisses

Installieren und Konfigurieren des Microsoft Entra Connect-Bereitstellungs-Agent-Pakets

Konfigurieren der lokalen ECMA-App

Konfigurieren des Zertifikats für den Microsoft Entra-ECMA-Connectorhost

Konfigurieren eines generischen LDAP-Connectors

Stellen Sie sicher, dass der ECMA2Host-Dienst ausgeführt wird und auf dem Verzeichnisserver lesen kann.

Testen der Verbindung von Microsoft Entra ID mit dem Connectorhost

Erweitern des Microsoft Entra-Schemas

Konfigurieren von Attributzuordnungen

Sicherstellen der erforderlichen Attribute für Benutzer*innen, die für die Anwendung bereitgestellt werden sollen

Sammeln vorhandener Benutzer aus dem LDAP-Verzeichnis

Abrufen der IDs der Benutzer*innen in Microsoft Entra ID

Zuweisen von Benutzern zu einer Anwendung

Testen der Bereitstellung

Benutzerbereitstellung starten

Beheben von Fehlern bei der Bereitstellung

Überprüfen der erfolgreichen Bereitstellung von Benutzern

Nächste Schritte

Zusätzliche Ressourcen