Re: LDAP Groups and EAP
I tried updating to version 2.0. I like the debug interface much better, it makes it alot easier to read. Nice job! Unfortunately, this upgrade introduced a new issue for me. When doing group ldap searches, it looks like the Ldap-UserDN variable doesn't get populated. The server successfully binds and finds the user, but in the expand section: rlm_ldap: ldap_release_conn: Release Id: 0 expand: (|(&objectClass=GroupOfNames)(member=%{Ldap-UserDN}))(&objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDN})))->(|(&objectClass=GroupOfNames)(member=))(&(objectClass=GrouOfUniqueNames)(uniquemember=))) It then fails to find the ldap group, because of the member= and uniquemember= are blank. A few lines below that, though, it comes up with the correct full DN search: rlm_ldap: performing search in cn=somegroup,ou=something,ou=something with filter (|(&objectClass=GroupOfNames)(member=))(&(objectClass=GrouOfUniqueNames)(uniquemember=))) rlm_ldap: object not found or got ambigous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing serach in cn=xxx,ou=something,ou=something with filter (objectclass=*) rlm_ldap::ldap_groupcmp: ldap_get_values failed I tried using my old config from 1.1, as well as re-writing it, as well as using the new and old ldap.attrmap. This is verified to work in version 1.1 for me. This is against eDirectory, configured with the --with-edir option ----- Original Message ---- From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Saturday, January 12, 2008 3:40:39 AM Subject: Re: LDAP Groups and EAP Brian Wilson wrote:
I am running Freeradius 1.1.0
Please upgrade to at least 1.1.7. It solves a lot of security issues, *and* helps with the problem you're seeing, too.
When I try to authenticate, the radius server receives about 7 Access-requests.
That's the way EAP works.
Notice that there is no additional call to ldap_group between the authorize and the resulting failure in the files module.
The *inner* tunnel session doesn't match a huntgroup.
Is there something i'm missing in the configuration file?
I would suggest trying 2.0. The new virtual server feature should make this configuration much simpler. The new "unlang" feature should also simplify the writing of policies. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Brian Wilson wrote:
I tried updating to version 2.0. I like the debug interface much better, it makes it alot easier to read. Nice job!
Thanks. It was a fair amount of work, but I think it's worth it.
Unfortunately, this upgrade introduced a new issue for me. When doing group ldap searches, it looks like the Ldap-UserDN variable doesn't get populated. The server successfully binds and finds the user, but in the expand section:
Hmm... I don't think that code was changed at all in 2.0. I don't use the LDAP module much, so I'm not sure what else to say... Where is the LDAP-UserDN being set from? Alan DeKok.
Alan DeKok wrote:
Brian Wilson wrote:
I tried updating to version 2.0. I like the debug interface much better, it makes it alot easier to read. Nice job!
Thanks. It was a fair amount of work, but I think it's worth it.
Unfortunately, this upgrade introduced a new issue for me. When doing group ldap searches, it looks like the Ldap-UserDN variable doesn't get populated. The server successfully binds and finds the user, but in the expand section:
Hmm... I don't think that code was changed at all in 2.0. I don't use the LDAP module much, so I'm not sure what else to say...
Where is the LDAP-UserDN being set from?
It is set by rlm_ldap by performing an LDAP search on the USER_NAME attribute. If the search succeeds the ldap-userdn is set to the dn the user name was found under. This dn can then be used to efficiently point to the user data in the LDAP tree, think of it as a pointer (cursor) to be used in future LDAP queries in subsequent processing. -- John Dennis <jdennis@redhat.com>
John Dennis wrote:
Where is the LDAP-UserDN being set from?
It is set by rlm_ldap by performing an LDAP search on the USER_NAME attribute. If the search succeeds the ldap-userdn is set to the dn the user name was found under. This dn can then be used to efficiently point to the user data in the LDAP tree, think of it as a pointer (cursor) to be used in future LDAP queries in subsequent processing.
Ah. In 2.0, it's stored in the control items, not in the incoming request: %{control:LDAP-UserDn} ... Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Wilson -
John Dennis