Ich arbeite an einer Java-Anwendung eines Drittanbieters, deren Benutzer ich mithilfe von Active Directory authentifizieren muss.
Diese Anwendung wird auf RHEL 6.5 gehostet und verwendet LDAP zur Authentifizierung mit Windows Active Directory. Der AD-Server wurde eingerichtet und funktioniert einwandfrei mit einer früheren Version der Anwendung (die so konfiguriert wurde, dass die Integration aktiviert wurde).
Für die neuere Version hat der Anbieter einige Schritte zum Ändern/Konfigurieren der Anwendungsdateien für die Verbindung mit dem AD-Server dargelegt, die uns bei der Authentifizierung helfen sollen.
Eine der Komponenten der Anwendung ist CAS, das derzeit so konfiguriert ist, dass es die Datenbank als Authentifizierungshandler verwendet. Wenn wir die Anmeldeinformationen eingeben – Benutzername: abcd, Passwort: samplepswd – können wir uns erfolgreich anmelden.
Da die geschäftliche Anforderung die Authentifizierung mit Active Directory unter Verwendung von LDAP ist, müssen wir die CAS-Eigenschaftendatei ändern. Gemäß den Anweisungen des Produktanbieters haben wir die folgenden Eigenschaften geändert, um LDAP zu verwenden -
authenticationHandler.type=ldap
ldapSSLConfig.enabled=false
ldapContextSource.url=ldap://sample.ADserver.example.net:389
ldapContextSource.userDn=abcd
ldapContextSource.password=samplepswd
ldapAuthenticationHandler.filter=uid=%u
ldapAuthenticationHandler.searchBase=OU=DEF,OU=PQR,OU=XYZ,DC=ADserver,DC=example,DC=net
Wir müssen auch Änderungen in der casAuthConfig XML-Datei für die folgenden Eigenschaften vornehmen (da die anonyme Suche nicht unterstützt wird): 1. anonymousReadOnly, Wert ist auf false gesetzt 2. java.naming.security.authentication, Wert ist auf simple gesetzt
Es besteht auch die Möglichkeit, LDAP über SSL zu verwenden, aber derzeit nutzen wir dies nicht. Wenn wir jedoch SSL verwenden, müssen zusätzliche Änderungen an den folgenden Eigenschaften vorgenommen werden:
ldapSSLConfig.enabled=true
ldapSSLConfig.trustStorePath=/home/dir1/subdir1/subdir2/keystorename.keystore
ldapSSLConfig.trustStoreType=jceks
Dies sind die einzigen Konfigurationsänderungen, die auf unserer (Client-)Seite vorgenommen wurden; und tatsächlich die einzigen Änderungen, die vorgenommen wurden. Auf dem Server (AD-Server) wurde nichts hinzugefügt/geändert, außer einem anderen Benutzer, aber das hat keine Auswirkungen auf das vorhandene Setup.
Nach dem Neustart von cas, um die Änderungen widerzuspiegeln, wird die Fehlermeldung „falsche Anmeldeinformationen“ angezeigt, obwohl die eingegebenen Werte korrekt sind:
2015-09-16 12:12:30,558 INFO [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - Authenticating credential using handler
com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler
2015-09-16 12:12:30,558 DEBUG [com.pqr.cas.authentication.support.DelegatingAuthenticationHandler] - credentials.getUsername() = abcd
2015-09-16 12:12:30,672 INFO [com.pqr.cas.adaptors.ldappwd.BindLdapAuthenticationHandler] - Search for cn=abcd returned 0 results.
2015-09-16 12:12:30,672 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - AuthenticationHandler:
com.pqr.cas.authentication.support.DelegatingAuthenticationHandler failed to authenticate the user which provided the following credentials:
[username: abcd]
2015-09-16 12:12:30,676 ERROR [org.jasig.cas.integration.restlet.TicketResource] - error.authentication.credentials.bad
org.jasig.cas.ticket.TicketCreationException: error.authentication.credentials.bad
at org.jasig.cas.CentralAuthenticationServiceImpl.createTicketGrantingTicket_aroundBody10(CentralAuthenticationServiceImpl.java:423)
Kann mir bitte jemand bei diesem Problem helfen? Oder vielleicht in die richtige Richtung weisen? Für jede Hilfe wäre ich sehr dankbar.
Danke schön.
Antwort1
Ich sehe einige potenzielle Probleme in Ihrer Konfiguration.
ldapContextSource.userDn und .password sollten die Anmeldeinformationen für ein Konto in AD sein, das Lesezugriff auf alle Benutzerkonten hat, die sich bei der Anwendung anmelden würden. Der .userDn-Wert soll eigentlich eine LDAP-DN-Zeichenfolge sein (ähnlich wie bei .searchBase), aber für Active Directory können Sie stattdessen das Attribut userPrincipalName (UPN) verwenden (normalerweise ist dies[email geschützt]). Der Fehler „falsche Anmeldeinformationen“ kann also einfach darauf zurückzuführen sein, dass Sie den Benutzernamen nicht qualifizieren. Ich bevorzuge immer die Verwendung von UPN für LDAP-Integrationen, da das Konto innerhalb von AD verschoben werden kann und die Anwendung sich nicht darum kümmert (im Gegensatz zu einem DN, der sich ändern würde).
Vorausgesetzt, das klappt, wird Ihr .filter-Wert wahrscheinlich auch ein Problem darstellen. Obwohl das uid-Attribut in Active Directory vorhanden ist, wird es im Allgemeinen nicht standardmäßig ausgefüllt. Sie sollten es stattdessen in sAMAccountName ändern, wenn Sie möchten, dass sich Benutzer nur mit ihrem Benutzernamen anmelden.
Wenn Sie dazu kommen, LDAP über SSL (LDAPS) zu aktivieren, benötigen Sie ein TLS-Zertifikat auf Ihren Domänencontrollern, dem die Java-Anwendung vertraut. Wenn es sich um ein selbstsigniertes Zertifikat handelt, muss dieses Zertifikat in den Schlüsselspeicher gehen, auf den in den Dokumenten verwiesen wird. Wenn es sich um ein Zertifikat handelt, das von einer öffentlichen oder internen PKI-Infrastruktur generiert wurde, sollten Sie stattdessen die CA-Zertifikatskette für diese Infrastruktur hinzufügen. Sie müssen außerdem die LDAP-Server-URI in ldap ändern.S:// und Port 636 (oder 3269 für globale Katalogsuchen).