Jan 29th, 2006, 11:13 AM
thinking about it I guess the current implementation solves 99% of all problems. (The remaining 1% is, when you need all groups for a user and you don't have a OU for all groups.)
For 'normal' applications it is totally ok to specify a fixed OU. If an application needs groups in different OUs you can nest groups in groups.
If I could make a wish I'd prefer a method to look for groups regardless of OU, rather than a list of DNs. [Just for the remaining 1% ;-) ] This would solve the multiple OU-problem without nesting, too.
BTW, keep on with your phantastic work. I convinced my boss to take a look a Spring and Acegi and he was surprised how easy it is to build consistent applications. In the next months we will port all our old Lotus Domino applications to Spring/Acegi.
Feb 1st, 2006, 08:02 AM
can't find packages
Feb 1st, 2006, 08:57 AM
Feb 1st, 2006, 10:38 AM
I'm trying to test the new LDAP functionality, but recent nightly cvs snapshots fail to build via maven (1.0.2)... it ends in compile errors which I do not have time to go into at the moment. Is there a nigthly build available that includes the latest LDAP packages?
UPDATE: managed to build it w/o junit tests (-Dmaven.test.skip). Will report testing results with IBM LDAP...
Last edited by roko; Feb 1st, 2006 at 11:24 AM.
Feb 6th, 2006, 04:26 AM
There were issues with CVS HEAD until early February due to the Apache Directory project having some incompatibilities. Luke ended up building a snapshot, and CVS HEAD works as of this moment. Luke has also been working with the Apache DS team to resolve the incompatibilities.
Feb 24th, 2006, 08:18 AM
Authentication with Microsoft Active Directory
Thanks for your posts with examples of configuration.
Did you notice the change in the LDAP classes in the 1.0.0 RC2?
I have tried to adapt your configuration to access a Microsoft Active Directory 2003 and I keep getting the error:
net.sf.acegisecurity.BadCredentialsException: Bad credentials; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece
Do you have a clue? A google search suggests that the admin user doesn't have the credentials but I'd like to know what parameter exactly is wrong (searchFilter, dn=, cn=, password ...)
I will post the answers in the forum once everything works ...
Feb 24th, 2006, 05:23 PM
Thank you for the information on Active Directory setup using LDAP. I have it mostly working, but for some reason, I am getting a PartialResultException. I believe this is because the Active Directory is returning referral information. I have looked at the traffic with Ethereal and I can see the user information getting returned up to the referrals. I did set java.naming.referral=forward as recommended (I also set it in the jndi.properties file in JBoss just in case).
Any thoughts on why Acegi is not handling the referrals? I am so close....
Feb 24th, 2006, 05:26 PM
I have found that that response is almost always due to the manager credentials. To get it to work for me with Active Directory, I had to use the principal name, ie., email@example.com (no cn's or dc's). That fixed mine right up.
Hope this helps!
Feb 26th, 2006, 10:43 AM
Ok, I have figured out how to work Active Directory with Acegi LDAP. The reason I was getting the PartialResultException was that Active Directory was returning referrals when Acegi started its authentication bind for the user logging into the application. Apparently, Active Directory disregards the Manage Referrals code sent by the client as part of LDAP v3. In my case, I was setting the search base to the top of the directory, i.e., dc=example,dc=com. In addition to the Users ou in the ldap tree, there are several other system ou's and these cause Active Directory to return referrals which causes the PartialResultException. Try it with something like
ldapsearch -x -b dc=example,dc=com -D firstname.lastname@example.org sAMAccountName=username -W
and you will see the referrals since the -b argument is set to the top of the directory.
Now, to get Acegi to work, you must specify the ou containing your user accounts in the userSearch bean as per the previous example. Since the search is limited to that ou, no referrals are obtained and Acegi works! Again, try it with an ldapsearch like
ldapsearch -x -b ou=Users,dc=example,dc=com -D email@example.com sAMAccountName=username -W
Note the addition of the ou=Users to the search base. The result will not contain the referrals.
Since some of the setup is different than the previous example for RC2, I am including my setup beans for Acegi LDAP authentication against Active Directory. Thanks for all the help!
<bean id="initialDirContextFactory" class="org.acegisecurity.providers.ldap.DefaultIni tialDirContextFactory">
<bean id="userSearch" class="org.acegisecurity.providers.ldap.search.Fil terBasedLdapUserSearch">
<ref local="initialDirContextFactory" />
<bean id="ldapAuthenticationProvider" class="org.acegisecurity.providers.ldap.LdapAuthen ticationProvider">
<bean class="org.acegisecurity.providers.ldap.authentica tor.BindAuthenticator">
<ref local="userSearch" />
<ref local="initialDirContextFactory" />
Apr 4th, 2006, 10:35 AM
Is the last pasted code on this page still the best practice on using Active Directory?