Authentifizierung mit LDAP gegen ADAM mit Spring-Sicherheit

Question

Ich versuche, eine Java-Anwendung mit Spring-Security zu bekommen, um mit einer lokalen ADAM-Instanz zu sprechen, die ich eingerichtet habe.

ich erfolgreich ADAM und Setup installiert haben, wie folgt ....

• Instanz auf localhost läuft: 389
• Root ist O=Company
  • Ein Kind OU=Company Users (orgnizationalUnit)
    • genannt Ein Großkind namens CN=Mike Q (Benutzer)
    • uid = mike und password = welcome

Dann habe ich Setup-Feder-Sicherheit (Version 3.0.3, feder Rahmen 3.0.4 und Feder-ldap 1.3.0). Frühlings-Datei

<security:ldap-server id="contextSource" url="ldap://localhost:389/o=Company"/> 

    <security:authentication-manager> 
    <security:ldap-authentication-provider user-dn-pattern="uid={0},ou=Company Users"/> 
    </security:authentication-manager> 

    <bean class="com.xxx.test.TestAuthentication" lazy-init="false"/> 

Und TestAuthentication

public class TestAuthentication 
{ 
    @Autowired 
    private AuthenticationManager authenticationManager; 

    public void initialise() 
    { 
     Authentication authentication = new UsernamePasswordAuthenticationToken("mike", "welcome"); 
     Authentication reponseAuthentication = authenticationManager.authenticate(authentication); 
    } 
} 

das Lauf bekomme ich folgende Fehler

Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C090336, comment: AcceptSecurityContext error, data 2030, vece] 
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3041) 
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987) 
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789) 
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703) 
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293) 
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) 
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) 
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) 
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) 
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) 
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) 
at javax.naming.InitialContext.init(InitialContext.java:223) 
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134) 
at org.springframework.ldap.core.support.LdapContextSource.getDirContextInstance(LdapContextSource.java:43) 
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:254) 

Wenn jemand darauf hinweisen könnte, wo ich falsch werde ich dankbar sein würde. An dieser Stelle möchte ich nur einen eingegebenen Benutzer/Passwort mit LDAP authentifizieren, nichts komplexer als das.

Ich bin auch an einigen allgemeinen Punkten interessiert, da dies mein erster Ausflug in die LDAP-Welt ist.

• Ist die Groß-/Kleinschreibung von LDAP abhängig?
• Sind Räume am besten zu vermeiden?
• Was sind die allgemeinen Anwendungsfälle/Best Practices, um das Senden des Kennworts im Klartext in der LDAP-Abfrage zu vermeiden?

Answer 1

OK, weil ich viel Zeit damit verbracht habe, dies zu lösen, hier ist die Antwort.

Fehlercode 2030 bedeutet, dass der DN des Benutzers ungültig ist.

Nach ein paar Versuchen und Fehler ist hier eine Konfiguration, die funktioniert und sucht Benutzer ordnungsgemäß. (Sie können dies wahrscheinlich mit dem Sicherheits-Namespace umschreiben, aber während ich daran arbeitete, war es klarer, die Raw Bean-Definitionen zu verwenden).

<bean id="contextSource" 
     class="org.springframework.security.ldap.DefaultSpringSecurityContextSource"> 
    <constructor-arg value="ldap://localhost:389/cn=Sandbox,dc=ITOrg"/> 
    <property name="userDn" value="cn=superuser,cn=People,cn=Sandbox,dc=ITOrg"/> 
    <property name="password" value="xxxxxx"/> 
    </bean> 

    <bean id="ldapAuthProvider" 
     class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider"> 
    <constructor-arg> 
     <bean class="org.springframework.security.ldap.authentication.BindAuthenticator"> 
     <constructor-arg ref="contextSource"/> 
     <property name="userDnPatterns"> 
      <list> 
      <value>cn={0},cn=People</value> 
      </list> 
     </property> 
     </bean> 
    </constructor-arg> 
    </bean> 

    <bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch"> 
    <constructor-arg index="0" value="cn=People"/> 
    <constructor-arg index="1" value="(cn={0})"/> 
    <constructor-arg index="2" ref="contextSource"/> 
    </bean> 

Die wichtigsten Dinge sind

<property name="userDn" value="cn=superuser,cn=People,cn=Sandbox,dc=ITOrg"/> 

Wenn die UserDN im Quell Kontext Angabe muss die FULL DN sein (es nicht nur anhängen es die Basis in der URL (Konstruktor arg geliefert tun).

Wenn BindAuthentication mit

<value>cn={0},cn=People</value> 

Dieser Wert ist ein Suffix auf dem baseDn der Kontextquelle.

Wenn ein Usersuche

Konfiguration

<constructor-arg index="0" value="cn=People"/> 
    <constructor-arg index="1" value="(cn={0})"/> 

Ich konnte es nicht mit cn=People ist in der zweiten arg zu arbeiten, aber das scheint gut zu funktionieren. Beachten Sie, dass Sie Attribute des Benutzers verwenden können, z. (uid={0})

Und hier einige Beispiel-Code die Bohne-Definitionen ...

@Autowired 
    private LdapUserSearch ldapUserSearch; 

    @Autowired 
    private AuthenticationProvider authenticationProvider; 

    public void initialise() 
    { 
     DirContextOperations dirContextOperations = ldapUserSearch.searchForUser("username"); 

     Authentication authentication = authenticationProvider.authenticate(new UsernamePasswordAuthenticationToken("username", "password"));  
    } 

Einige andere zufällige titbits ...

Error 52b - Invalid password 


[LDAP: error code 32 - 0000208D: NameErr: DSID-031521D2, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Sandbox,DC=ITOrg' 
    - This means the user is not in the administrator role (probably) 

Hoffnung das alles jemand anderes hilft.

Answer 2

Ich habe dieses Problem behoben, indem ich den Benutzer, den Sie versuchen, als Mitglied der Rolle des Administrators im selben Basis-DN zu verwenden, hinzufüge. Hoffe, dass hilft