Zum Inhalt springen

Active Directory Sicherheitsanbieter im Jitterbit App Builder

Der Active Directory (AD)-Sicherheitsanbieter ist ein formularbasiertes Authentifizierungsschema. Bei Verwendung des AD-Sicherheitsanbieters geben Benutzer ihren AD-Benutzernamen und ihr AD-Passwort an App Builder. App Builder verwendet LDAP, um die vom Benutzer bereitgestellten Anmeldeinformationen anhand eines AD-Speichers zu validieren.

Moderne Bereitstellungen sollten SAML Single Sign-On bevorzugen (SSO) und WS-Federation gegenüber AD-Authentifizierung. SAML SSO und WS-Federation bieten mehr Sicherheit, da Benutzer ihre Anmeldeinformationen nicht an eine Drittpartei weitergeben müssen. Da AD einen vorhandenen Authentifizierungskontext nicht berücksichtigt, ist die AD-Authentifizierung kein richtiges SSO-Schema. Aus diesem Grund bieten SAML SSO und WS-Federation im Allgemeinen eine bessere Benutzerfreundlichkeit, da Benutzer ihre Anmeldeinformationen nicht erneut eingeben müssen. Und schließlich benötigen SAML SSO- und WS-Federation-Sicherheitstoken, da sie vom Browser über HTTP vermittelt werden, keine Drittpartei, um direkten Zugriff auf AD-Domänencontroller zu haben. Dadurch sind SAML SSO und WS-Federation besser für Cloudbereitstellungen geeignet.

Konfiguration

Der AD-Sicherheitsanbieter unterstützt sowohl die Benutzer- als auch die Gruppenbereitstellung. Benutzer und Gruppen werden mit ihrem SAM-Kontonamen registriert.

Parameter

Parameter Standardwert Beispiel Erforderlich Beschreibung
Container DC=Beispiel,DC=com Nein AD LDAP Containerspezifikation.
Kontext Domäne AD-Kontexttyp. Gültige Werte sind Domäne, Maschine und Anwendungsverzeichnis.
Domäne example.com
example.com:389
Ja Active Directory (AD)-Domänenname. Kann eine optionale Port enthalten.
Passwort Nein Passwort für AD-Konto. Weitere Informationen finden Sie weiter unten.
Benutzername Nein Benutzername des AD-Kontos. Weitere Informationen finden Sie unten.

Standardmäßig App Builder stellt als IIS-Anwendungspoolbenutzer eine Verbindung zu AD-Domänencontrollern her. Dies funktioniert möglicherweise nicht in allen Situationen, insbesondere wenn der Webserver nicht in der AD-Domäne gehostet wird. In diesem Fall müssen Sie den Benutzernamen und das Kennwort eines Kontos in der Domäne angeben. Beachten Sie beim Erstellen des Kontos Folgendes:

  • Das Konto muss Lesezugriff auf den AD-Baum haben: Die Mitgliedschaft in der Sicherheitsgruppe „Domänenbenutzer“ ist ausreichend.
  • Das Konto kann, muss aber nicht, der durch die Containerspezifikation identifizierten Organisationseinheit angehören.

Ansprüche

Der Active Directory Anbieter ordnet die folgenden UserPrincipal-Eigenschaften Anspruchstypen zu:

  • SamAccountName
  • Name
  • Anzeigename
  • Email-Adresse Sprachtelefonnummer

Weitere Informationen

So validieren Sie Anmeldeinformationen anhand eines Active Directory (AD)-Speichers: App Builder muss sich per LDAP mit den AD-Domänencontrollern verbinden können. Traditionell geschieht dies über Port 389.

Beim Überschreiten von Domänengrenzen kann eine Verzögerung von 20 Sekunden oder mehr auftreten. Das Anhängen der Port an die Domäne (z. B. example.com:389) kann die Leistung verbessern.

Fehlerbehebung

Fehler: „Auf dem Server ist kein solches Objekt vorhanden.“

Dieser Fehler kann bedeuten, dass die Containerspezifikation falsch ist. Er kann sich auf eine nicht vorhandene Organisationseinheit beziehen. Wenn mit verschachtelten Organisationseinheiten gearbeitet wird, kann dies bedeuten, dass die Reihenfolge falsch ist. Organisationseinheiten müssen in umgekehrter Reihenfolge angegeben werden. Beispielsweise bei folgendem Pfad:

\Sales\North America

Die korrekte Containerspezifikation wäre:

OU=North America,OU=Sales,DC=example,DC=com

Beachten Sie, dass bei den Namen der Organisationseinheiten die Groß-/Kleinschreibung nicht beachtet wird.

Fehler: „Der Server konnte nicht kontaktiert werden.“ oder „Der LDAP -Server ist nicht verfügbar.“

Dieser Fehler zeigt an, dass App Builder Es konnte keine Verbindung zum Active Directory Domänencontroller hergestellt werden. Überprüfen Sie die Domäneneigenschaft.

Die Clients kommunizieren über LDAP mit Active Directory. Wie im folgenden Microsoft Knowledgebase-Artikel beschrieben, kommuniziert der LDAP Server über Port 389 und verwendet dabei sowohl das UDP- als auch das TCP-Protokoll.

https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows

Mit dem Tool Portqry lässt sich die Verbindung zum Active Directory testen:

https://support.microsoft.com/en-us/help/816103/how-to-use-portqry-to-troubleshoot-active-directory-connectivity-issue

Das Tool kann von der Microsoft-Website heruntergeladen werden:

https://www.microsoft.com/en-us/download/confirmation.aspx?id=17148

Beachten Sie, dass das Portqry-Tool vom App Builder Webserver.

Um die Verbindung zu Port 389 mit UDP zu testen, führen Sie den folgenden Befehl aus:

> portqry -n ad.example.com -e 389 -p udp

Ersetzen Sie „ad.example.com“ durch den Hotname oder die IP-Adresse des Active Directory Servers.

So testen Sie die Verbindung zu Port 389 mit TCP:

> portqry -n ad.example.com -e 389 -p tcp

Wenn die Tests erfolgreich sind, wird eine LDAP Abfrage mit dem aktuellen Datum und der Uhrzeit sowie verschiedenen Active Directory Eigenschaften angezeigt. Nachfolgend sehen Sie ein Beispiel für eine erfolgreiche LDAP Abfrage:

currentdate: 10/20/2018 11:22:33 (unadjusted GMT)
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=SERVER,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
namingContexts: DC=example,DC=com
defaultNamingContext: DC=example,DC=com
schemaNamingContext: CN=Schema,CN=Configuration,DC=example,DC=com
configurationNamingContext: CN=Configuration,DC=example,DC=com
rootDomainNamingContext: DC=example,DC=com
supportedControl: 1.2.840.113556.1.4.319
supportedLDAPVersion: 3
supportedLDAPPolicies: MaxPoolThreads
highestCommittedUSN: 249947
supportedSASLMechanisms: GSSAPI
dnsHostName: SERVER.example.com
ldapServiceName: example.com:server$@EXAMPLE.COM
serverName: CN=SERVER,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
isSynchronized: TRUE
isGlobalCatalogReady: TRUE
domainFunctionality: 6
forestFunctionality: 6
domainControllerFunctionality: 6

Fehler: „Der Benutzername oder das Passwort ist falsch.“

Wenn die Protokolldatei den Fehler „Der Benutzername oder das Passwort ist falsch“ enthält, kann dies bedeuten, dass der Benutzername oder das Passwort, das von App Builder zum Abfrage des Active Directory Domänencontrollers ist ungültig. Überprüfen Sie die Eigenschaften „Benutzername“ und „Passwort“.

Fehler: „Entweder der Benutzername oder das Passwort ist falsch.“

Beim Anmelden wird einem Benutzer möglicherweise die normale Fehlermeldung „Benutzername oder Kennwort sind falsch“ angezeigt, selbst wenn er gültige Anmeldeinformationen angegeben hat. Dies kann darauf hinweisen, dass der Benutzername im falschen Format angegeben wurde.

Geben Sie beim Anmelden den Benutzernamen nicht im Format „Benutzerprinzipalname“ (user@example.com) oder „Down-Level-Anmeldename“ (EXAMPLE\user) an. Geben Sie stattdessen den unqualifizierten Benutzernamen an.

Fehler: „Der angegebene Benutzername stimmte nicht mit dem SAM-Kontonamen eines Benutzerprinzipals überein.“

Dieser Fehler zeigt an, dass der Benutzer versucht, sich mit einem Konto zu authentifizieren, das nicht der Containerspezifikation entspricht. Beispielsweise kann die Containerspezifikation den Zugriff auf eine bestimmte Organisationseinheit beschränken. In diesem Fall würde dieser Fehler darauf hinweisen, dass das Benutzerkonto nicht zu dieser Organisationseinheit gehört.