Zum Inhalt springen

Active Directory-Sicherheitsanbieter im Jitterbit App Builder

Der Active Directory (AD) Sicherheitsanbieter ist ein formularbasiertes Authentifizierungsschema. Bei der Verwendung des AD-Sicherheitsanbieters geben die Benutzer ihren AD-Benutzernamen und ihr Passwort in den App Builder ein. Der App Builder verwendet LDAP, um die vom Benutzer bereitgestellten Anmeldeinformationen gegen einen AD-Speicher zu validieren.

Moderne Implementierungen sollten SAML Single Sign-On (SSO) und WS-Federation der AD-Authentifizierung vorziehen. SAML SSO und WS-Federation bieten eine höhere Sicherheit, da Benutzer ihre Anmeldeinformationen nicht an eine Drittanbieteranwendung weitergeben müssen. Da AD einen bestehenden 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 sie nicht erfordern, dass ein Benutzer seine Anmeldeinformationen erneut eingibt. Schließlich, da SAML SSO und WS-Federation-Sicherheitstoken über den Browser über HTTP vermittelt werden, benötigen sie keinen direkten Zugriff einer Drittanbieteranwendung auf AD-Domänencontroller. Dies macht SAML SSO und WS-Federation geeigneter für Cloud-Implementierungen.

Konfiguration

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

Parameter

Parameter Standardwert Beispiel Erforderlich Beschreibung
Container DC=example,DC=com Nein AD LDAP-Container-Spezifikation.
Kontext Domäne AD-Kontexttyp. Gültige Werte sind Domäne, Maschine und Anwendungsdirectory.
Domäne example.com
example.com:389
Ja Active Directory (AD) Domänenname. Kann eine optionale Portnummer enthalten.
Passwort Nein AD-Kontopasswort. Siehe unten für weitere Informationen.
Benutzername Nein AD-Konto-Benutzername. Siehe unten für weitere Informationen.

Standardmäßig verbindet sich der App Builder mit AD-Domänencontrollern als Benutzer des IIS-Anwendungspools. 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 Passwort eines Kontos in der Domäne angeben. Bei der Erstellung des Kontos sollten Sie Folgendes beachten:

  • Das Konto muss Lesezugriff auf den AD-Baum haben: Die Mitgliedschaft in der Sicherheitsgruppe "Domänenbenutzer" ist ausreichend.
  • Das Konto kann zur organisatorischen Einheit gehören, die durch die Containerspezifikation identifiziert wird, muss dies jedoch nicht.

Claims

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

  • SamAccountName
  • Name
  • DisplayName
  • EmailAddress
  • VoiceTelephoneNumber

Zusätzliche Informationen

Um Anmeldeinformationen gegen einen Active Directory (AD)-Speicher zu validieren, muss der App Builder in der Lage sein, sich über LDAP mit den AD-Domänencontrollern zu verbinden. Traditionell erfolgt dies über Port 389.

Es kann zu einer Verzögerung von 20 Sekunden oder mehr kommen, wenn Domänengrenzen überschritten werden. Das Anhängen der Portnummer an die Domäne (z. B. example.com:389) kann die Leistung verbessern.

Fehlerbehebung

Fehler: "Es gibt kein solches Objekt auf dem Server."

Dieser Fehler kann darauf hindeuten, dass die Containervorgabe falsch ist. Sie kann sich auf eine nicht vorhandene organisatorische Einheit beziehen. Wenn Sie mit geschachtelten organisatorischen Einheiten arbeiten, kann dies bedeuten, dass die Reihenfolge falsch ist. Organisatorische Einheiten müssen in umgekehrter Reihenfolge angegeben werden. Zum Beispiel, gegebenenfalls den folgenden Pfad:

\Sales\North America

Die korrekte Containervorgabe wäre:

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

Beachten Sie, dass die Namen der organisatorischen Einheiten nicht groß-/kleinschreibungsempfindlich sind.

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

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

Clients kommunizieren über LDAP mit Active Directory. Wie im folgenden Microsoft Knowledgebase-Artikel erwähnt, kommuniziert der LDAP-Server über Port 389 sowohl mit den UDP- als auch mit den TCP-Protokollen.

https://support.microsoft.com/de-de/hilfe/832017/dienstübersicht-und-netzwerkportanforderungen-für-windows

Das Portqry-Tool kann verwendet werden, um die Konnektivität zu Active Directory zu testen:

https://support.microsoft.com/de-de/hilfe/816103/wie-sie-portqry-verwenden-um-active-directory-konnektivitätsprobleme-zu-beheben

Das Tool kann von der Microsoft-Website heruntergeladen werden:

https://www.microsoft.com/de-de/download/bestätigung.aspx?id=17148

Beachten Sie, dass das Portqry-Tool vom App Builder-Webserver aus ausgeführt werden muss.

Um die Konnektivität zu Port 389 über 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 Hostnamen oder die IP-Adresse des Active Directory-Servers.

Um die Konnektivität zu Port 389 über TCP zu testen:

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

Wenn die Tests erfolgreich sind, sehen Sie eine LDAP-Abfrageantwort, die das aktuelle Datum und die Uhrzeit sowie verschiedene Active Directory-Eigenschaften enthält. Folgendes ist ein Beispiel für eine erfolgreiche LDAP-Abfrageantwort:

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 vom App Builder verwendet wird, um den Active Directory-Domänencontroller abzufragen, ungültig ist. Überprüfen Sie die Eigenschaften Benutzername und Passwort.

Fehler: "Entweder ist der Benutzername oder das Passwort falsch."

Ein Benutzer kann beim Anmelden die normale Fehlermeldung "Entweder ist der Benutzername oder das Passwort falsch" sehen, selbst wenn er gültige Anmeldeinformationen angegeben hat. Dies kann darauf hindeuten, dass der Benutzername im falschen Format angegeben wurde.

Geben Sie beim Anmelden den Benutzernamen nicht im Format des Benutzerprinzipals (user@example.com) oder des Down-Level-Anmeldenamens (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 mit der Container-Spezifikation übereinstimmt. Zum Beispiel kann die Container-Spezifikation den Zugriff auf eine bestimmte Organisationseinheit einschränken. In diesem Fall würde dieser Fehler anzeigen, dass das Benutzerkonto nicht zur Organisationseinheit gehört.