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 Kennwort an App Builder weiter. App Builder verwendet LDAP, um die vom Benutzer angegebenen 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 sind SAML SSO und WS-Federation im Allgemeinen benutzerfreundlicher, da Benutzer ihre Anmeldeinformationen nicht erneut eingeben müssen. Da SAML SSO- und WS-Federation-Sicherheitstoken vom Browser über HTTP vermittelt werden, benötigen sie keinen Drittpartei auf AD-Domänencontroller. Dadurch eignen sich SAML SSO und WS-Federation besser für Cloud-Bereitstellungen.
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, Rechner und Anwendungsverzeichnis. | ||
Domäne | example.com example.com:389 | Ja | Active Directory (AD)-Domänenname. Kann eine optionale Port enthalten. | |
Passwort | Nein | AD-Kontopasswort. Weitere Informationen finden Sie unten. | ||
Benutzername | Nein | Benutzername des AD-Kontos. Weitere Informationen finden Sie unten. |
Standardmäßig verbindet sich App Builder als IIS-Anwendungspoolbenutzer mit AD-Domänencontrollern. Dies funktioniert möglicherweise nicht in allen Situationen, insbesondere wenn der Webserver nicht in der AD-Domäne gehostet wird. In diesem Fall benötigen Sie den Benutzernamen und das Kennwort eines Domänenkontos. Beachten Sie beim Erstellen eines Kontos Folgendes:
- Das Konto muss über Lesezugriff auf den AD-Baum verfügen: Die Mitgliedschaft in der Sicherheitsgruppe „Domänenbenutzer“ ist ausreichend.
- Das Konto kann, muss aber nicht, zu der durch die Containerspezifikation identifizierten Organisationseinheit gehören.
Ansprüche
Der Active Directory-Anbieter ordnet die folgenden UserPrincipal-Eigenschaften Anspruchstypen zu:
- SamAccountName
- Name
- Anzeigename
- E-Mail-Adresse Sprachtelefonnummer
Weitere Informationen
Um Anmeldeinformationen anhand eines Active Directory (AD)-Speichers zu validieren, muss App Builder über LDAP eine Verbindung zu den AD-Domänencontrollern herstellen können. Traditionell geschieht dies über Port 389.
Beim Überschreiten von Domänengrenzen kann es zu einer Verzögerung von 20 Sekunden oder mehr kommen. 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 auf eine fehlerhafte Containerspezifikation hinweisen. Er kann sich auf eine nicht vorhandene Organisationseinheit beziehen. Bei verschachtelten Organisationseinheiten kann dies auf eine falsche Reihenfolge hinweisen. Organisationseinheiten müssen in umgekehrter Reihenfolge angegeben werden. Beispiel:
\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ß- und Kleinschreibung nicht beachtet wird.
Fehler: „Der Server konnte nicht kontaktiert werden.“ oder „Der LDAP Server ist nicht verfügbar.“
Dieser Fehler weist darauf hin, dass App Builder keine Verbindung zum Active Directory Domänencontroller herstellen konnte. Ü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 Portqry-Tool kann die Konnektivität zu Active Directory getestet werden:
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 ausgeführt werden muss.
Um die Konnektivität 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 Konnektivität zu Port 389 mithilfe von 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. Das folgende Beispiel zeigt 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 Kennwort ist falsch“ enthält, kann dies darauf hinweisen, dass der von App Builder zur Abfrage des Active Directory Domänencontrollers verwendete Benutzername oder das Kennwort ungültig ist. Überprüfen Sie die Eigenschaften „Benutzername“ und „Kennwort“.
Fehler: „Entweder der Benutzername oder das Passwort ist falsch.“
Beim Anmelden wird möglicherweise die Fehlermeldung „Benutzername oder Kennwort falsch“ angezeigt, selbst wenn gültige Anmeldeinformationen angegeben wurden. 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 weist darauf hin, 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 einschränken. In diesem Fall würde dieser Fehler darauf hinweisen, dass das Benutzerkonto nicht zu dieser Organisationseinheit gehört.