Sorry, I'm not sure how to respond using the original thread.
Georg,
I appreciate your help. I have tried using the LDAPUser
instead of ActiveDirectoryUser, but could not get the sAMMaccountName to work
after many attempts.
So, I have dug through ActiveDirectoryUser and have rigged a
way to pull the distinguished name from the AD attributes and to get this to
successfully bind.
My next issue is that I'm getting an NamingException at
org.apache.turbine.services.security.ldap.LDAPUserManager.store. It looks like
it is trying to save the user in AD, maybe? (Should this be saving the user in
turbine_user?)
Before I keep going, am I making this too complicated? This has been
successfully implemented, right?
Thanks!
I am not a AD specialist, but did you try using class LDAPUser instead of
ActiveDirectoryUser? The only difference is, that ActiveDirectoryUser has as
its binding using
CN= givenName lastName,..,
while the other just uses (configurable attribute name)
CN=username, .. .
where username is probably sAMAccountName (change configuration in
TurbineResources.properties to
services.SecurityService.user.class=org.apache.turbine.services.security.ldap.LDAPUser)
?
-Best regards, Georg
I am trying to change my Turbine 2.3.3 application (running under Tomcat) to
use AD for authentication. I understand that this is a 2-step process:
1) search by username (I use SAMAccount)
2) Bind or authenticate using the DN and password.
The search by SAMAccount is successful (I can verify this in trace data), but
the authentication by DN is not. What appears to be happening is that Turbine
is building the CN from the first and last names on the AD record. In AD it
appears that the CN varies, it could be first name/last name, first name/last
name/middle initial, etc. My question, why doesn't Turbine pull the CN off the
AD record for the user object instead of building it from first/last name? Is
there any way to make this work?
Thanks!
Michele
