Azure AD-Architektur für die lokale Bereitstellung der Anwendungsidentität (Vorschau)

Übersicht

Das folgende Diagramm enthält eine Übersicht über die Funktionsweise der lokalen Anwendungsbereitstellung.

Ein Diagramm, das die Architektur für die lokale Anwendungsbereitstellung zeigt.

Es gibt drei Hauptkomponenten für die Bereitstellung von Benutzern in einer lokalen Anwendung:

  • Der Bereitstellungs-Agent ermöglicht die Konnektivität zwischen Azure Active Directory (Azure AD) und Ihrer lokalen Umgebung.
  • Der ECMA-Host konvertiert Bereitstellungsanforderungen von Azure AD in Anforderungen, die an Ihre Zielanwendung gesendet werden. Er dient als Gateway zwischen Azure AD und Ihrer Anwendung. Mit dem Host können Sie vorhandene ECMA2-Connectors importieren, die mit dem Microsoft Identity Manager verwendet werden. Der ECMA-Host ist nicht erforderlich, wenn Sie eine SCIM-Anwendung oder ein SCIM-Gateway erstellt haben.
  • Der Azure AD-Bereitstellungsdienst dient als Synchronisierungs-Engine.

Hinweis

Eine Synchronisierung mit dem Microsoft Identity Manager ist nicht erforderlich. Sie können sie aber verwenden, um Ihren ECMA-Connector zu erstellen und zu testen, bevor Sie diesen auf den ECMA-Host importieren.

Firewallanforderungen

Sie müssen keine eingehenden Verbindungen mit dem Unternehmensnetzwerk öffnen. Für die Bereitstellungs-Agenten werden nur ausgehende Verbindungen mit dem Bereitstellungsdienst verwendet. Dies bedeutet, dass keine Firewallports für eingehende Verbindungen geöffnet werden müssen. Sie benötigen auch kein Umkreisnetzwerk (DMZ), da alle Verbindungen in ausgehender Richtung verlaufen und über einen sicheren Kanal erfolgen.

Architektur des ECMA-Connectorhosts

Der ECMA-Connectorhost umfasst mehrere Bereiche, die zum Erzielen einer lokalen Bereitstellung verwendet werden. Diese Bereiche werden in der folgenden konzeptionellen Abbildung dargestellt. In der nachstehenden Tabelle werden die Bereiche ausführlicher beschrieben.

ECMA-Connectorhost

Bereich BESCHREIBUNG
Endpunkte Verantwortlich für die Kommunikation mit und die Übertragung von Daten zum Azure AD-Bereitstellungsdienst.
In-Memory-Cache Wird verwendet, um die aus der lokalen Datenquelle importierten Daten zu speichern.
Automatische Synchronisierung Ermöglicht eine asynchrone Datensynchronisierung zwischen dem ECMA-Connectorhost und der lokalen Datenquelle.
Geschäftslogik Wird verwendet, um alle ECMA-Connectorhostaktivitäten zu koordinieren. Der Zeitpunkt für die automatische Synchronisierung kann im ECMA-Host auf der Seite mit den Eigenschaften konfiguriert werden.

Grundlegendes zu Ankerattributen und DNs (Distinguished Names)

Die folgenden Informationen dienen zur besseren Erläuterung der Ankerattribute und der Distinguished Names (DNs), die insbesondere vom genericSQL-Connector verwendet werden.

Das Ankerattribut ist ein eindeutiges Attribut eines Objekttyps, der sich nicht ändert und dieses Objekt im In-Memory-Cache des ECMA-Connectorhosts repräsentiert.

Der Distinguished Name (DN) ist ein Name, der ein Objekt eindeutig identifiziert, indem er dessen aktuellen Speicherort in der Verzeichnishierarchie angibt. Im Falle von SQL wird der Speicherort innerhalb der Partition angegeben. Der Name wird durch Verketten des Ankerattributs am Stamm der Verzeichnispartition gebildet.

Bei klassischen DNs in einem herkömmlichen Format, z. B. für Active Directory oder LDAP, stellen wir uns einen Namen ähnlich dem folgenden vor:

CN=Lola Jacobson,CN=Users,DC=contoso,DC=com

Für eine Datenquelle wie beispielsweise SQL, die flach und nicht hierarchisch aufgebaut ist, muss der DN jedoch entweder bereits in einer der Tabellen vorhanden sein oder anhand der Informationen erstellt werden, die wir dem ECMA-Connectorhost bereitstellen.

Erreicht wird dies, indem wir beim Konfigurieren des genericSQL-Connectors das Kontrollkästchen Automatisch generiert aktivieren. Wenn festgelegt wurde, dass der DN automatisch erzeugt werden soll, generiert der ECMA-Host einen DN im LDAP-Format: CN=<anchorvalue>,OBJECT=<type>. Dies setzt auch voraus, dass auf der Seite für die Konnektivität die Option „DN ist Anker“ deaktiviert ist.

„DN ist Anker“ deaktiviert

Der genericSQL-Connector erwartet, dass der DN im LDAP-Format aufgefüllt wird. Der genericSQL-Connector verwendet das LDAP-Format mit dem Komponentennamen „OBJECT=“. Dies ermöglicht die Verwendung von Partitionen (jeder Objekttyp ist eine Partition).

Da der ECMA-Connectorhost derzeit nur den USER-Objekttyp unterstützt, wird der OBJECT=<type> als OBJECT=USER festgelegt. Der DN für einen Benutzer mit dem Ankerwert „ljacobson“ würde also folgendermaßen lauten:

CN=ljacobson,OBJECT=USER

Workflow für die Benutzererstellung

  1. Der Azure AD-Bereitstellungsdienst fragt den ECMA-Connectorhost ab, um zu ermitteln, ob der Benutzer vorhanden ist. Hierbei wird das Attribut für den Abgleich als Filter verwendet Dieses Attribut wird im Azure AD-Portal unter „Unternehmensanwendungen“ > „Lokale Bereitstellung“ > „Bereitstellung“ > „Attribut für Abgleich“ definiert. Es wird mit dem Wert 1 für die Rangfolge für den Abgleich gekennzeichnet. Sie können ein oder mehrere Attribute für den Abgleich definieren und sie anhand der Rangfolge priorisieren. Es ist auch möglich, das Attribut für den Abgleich zu ändern. Attribut für den Abgleich

  2. Der ECMA-Connectorhost empfängt die GET-Anforderung und fragt den internen Cache ab, um zu ermitteln, ob der Benutzer vorhanden ist und importiert wurde. Dies erfolgt mit dem/den oben genannten übereinstimmenden Attribut(n). Wenn Sie mehrere übereinstimmende Attribute definieren, sendet der Azure AD Bereitstellungsdienst eine GET-Anforderung für jedes Attribut und der ECMA-Host überprüft den Cache auf eine Übereinstimmung, bis er fündig wird.

  3. Wenn der Benutzer nicht vorhanden ist, sendet Azure AD eine POST-Anforderung, um den Benutzer zu erstellen. Der ECMA-Connectorhost antwortet Azure AD mit HTTP 201 und gibt eine ID für den Benutzer an. Diese ID wird vom Ankerwert abgeleitet, der auf der Seite der Objekttypen definiert ist. Azure AD verwendet diesen Anker in nachfolgenden Anforderungen, um den ECMA-Connectorhost abzufragen.

  4. Wenn der Benutzer in Azure AD geändert wird, sendet Azure AD eine GET-Anforderung zum Abrufen des Benutzers. Hierbei wird anstelle des Attributs für den Abgleich aus Schritt 1 der Anker aus dem vorherigen Schritt verwendet. So kann z. B. der UPN geändert werden, ohne dass die Verbindung zwischen dem Benutzer in Azure AD und in der App unterbrochen wird.

Bewährte Methoden für den Agent

  • Die Verwendung desselben Agents für die lokale Bereitstellungsfunktion zusammen mit Workday/SuccessFactors/Azure AD Connect Cloud Sync wird derzeit nicht unterstützt. Wir arbeiten aktiv daran, die lokale Bereitstellung auf demselben Agent wie bei den anderen Bereitstellungsszenarien zu unterstützen.
    • Vermeiden Sie alle Arten von Inline-Untersuchungen der ausgehenden TLS-Kommunikation zwischen den Agents und Azure. Diese Art der Inline-Untersuchung führt zu einer Verschlechterung des Kommunikationsflusses.
  • Der Agent muss sowohl mit Azure als auch mit Ihren Anwendungen kommunizieren. Daher wirkt sich die Platzierung des Agenten auf die Latenz dieser beiden Verbindungen aus. Sie können die Wartezeit des End-to-End-Datenverkehrs verringern, indem Sie die einzelnen Netzwerkverbindungen optimieren. Jede Verbindung kann wie folgt optimiert werden:
    • Reduzieren Sie den Abstand zwischen den beiden Enden des Hops.
    • Wählen Sie das richtige zu durchlaufende Netzwerk. Wenn beispielsweise, anstelle des öffentlichen Internets beispielsweise ein privates Netzwerk durchlaufen wird, kann dies aufgrund von dedizierten Links schneller gehen.

Fragen zum Bereitstellungs-Agent

Hier werden einige häufig gestellte Fragen beantwortet.

Wie kann ich die Version meines Bereitstellungs-Agent ermitteln?

  1. Melden Sie sich bei dem Windows Server an, auf dem der Bereitstellungs-Agent installiert ist.
  2. Wechseln Sie zur Systemsteuerung>Deinstallieren oder Ändern eines Programms.
  3. Suchen Sie nach der Version für den Eintrag Microsoft Azure AD Connect-Bereitstellungs-Agent.

Kann ich den Bereitstellungs-Agent auf demselben Server installieren, auf dem Azure AD Connect oder Microsoft Identity Manager ausgeführt wird?

Ja. Sie können den Bereitstellungs-Agent auf demselben Server installieren, auf dem Azure AD Connect oder der Microsoft Identity Manager ausgeführt wird, aber das ist nicht zwingend erforderlich.

Wie konfiguriere ich den Bereitstellungs-Agent, damit dieser einen Proxyserver für die ausgehende HTTP-Kommunikation verwendet?

Der Bereitstellungs-Agent unterstützt die Verwendung von Proxys für ausgehenden Datenverkehr. Das können Sie durch das Bearbeiten der Konfigurationsdatei des Agenten C:\Programm Dateien\Microsoft Azure AD Connect Bereitstellungs-Agent\AADConnectProvisioningAgent.exe.config konfigurieren. Fügen Sie in der Datei gegen Ende unmittelbar vor dem schließenden </configuration> Tag die folgenden Zeilen ein. Ersetzen Sie die Variablen [proxy-server] und [proxy-port] durch den Namen Ihres Proxyservers und die Portwerte.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

Wie stelle ich sicher, dass der Bereitstellungs-Agent mit dem Azure AD-Mandanten kommunizieren kann und dass keine Firewalls die vom Agenten benötigten Ports blockieren?

Sie können auch überprüfen, ob alle erforderlichen Ports geöffnet sind.

Wie deinstalliere ich den Bereitstellungs-Agent?

  1. Melden Sie sich bei dem Windows Server an, auf dem der Bereitstellungs-Agent installiert ist.
  2. Wechseln Sie zur Systemsteuerung>Deinstallieren oder Ändern eines Programms.
  3. Deinstallieren Sie die folgenden Programme:
    • Microsoft Azure AD Connect-Bereitstellungs-Agent
    • Microsoft Azure AD Connect Agent Updater
    • Microsoft Azure AD Connect-Bereitstellungs-Agent-Paket

Verlauf des Bereitstellungs-Agents

In diesem Artikel werden die veröffentlichten Versionen und Features des Azure Active Directory Connect-Bereitstellungs-Agent aufgeführt. Das Azure AD-Team aktualisiert den Bereitstellungs-Agent regelmäßig mit neuen Features und Funktionen. Stellen Sie sicher, dass Sie nicht denselben Agent für die lokale Bereitstellung und die Cloudsynchronisierung/HR-gesteuerte Bereitstellung verwenden.

Microsoft stellt direkte Unterstützung für die neueste Agent-Version und die unmittelbare Vorgängerversion bereit.

Sie können die neueste Version des Agent über diesen Link herunterladen.

1.1.892.0

20. Mai 2022: zum Download freigegeben

Behobene Probleme

  • Es wurde Unterstützung für den Export von Änderungen an Integerattributen hinzugefügt, von der Kund*innen profitieren, die den generischen LDAP-Connector verwenden.

1.1.846.0

11. April  2022 – Zum Download freigegeben

Behobene Probleme

  • Wir haben die ObjectGUID-Unterstützung als Anker für den generischen LDAP-Connector hinzugefügt, wenn Benutzer in AD LDS bereitgestellt werden.

Nächste Schritte