How do you have this setup? Check out doc/configurable_failover. That should show you how to do it.
I'm using configurable failover to get it to roll as it is.
From my radiusd.conf file:
Authorize{ ldap1{ reject=1 } ldap2{ reject=1 ok=return } } Authenticate{ Auth-Type LDAP { ldap1{ reject=1 ok=return } ldap2{ reject=1 ok=return } } } The output I see when I try to authenticate with an openldap username/password where the username is also in AD rad_recv: Access-Request packet from host 130.74.186.38:17688, id=1, length=46 User-Name = "username" User-Password = "test123" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for username radius_xlat: '(sAMAccountName=username)' radius_xlat: 'cn=Users,dc=dept,dc=university,dc=edu' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ad.dept.university.edu:389, authentication 0 rlm_ldap: bind as cn=aduser,cn=Users,dc=dept,dc=university,dc=edu/adpassword to ad.dept.university.edu:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in cn=Users,dc=dept,dc=university,dc=edu, with filter (sAMAccountName=username) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user username authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap1" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for username radius_xlat: '(uid=username)' radius_xlat: 'dc=university,dc=edu,c=US' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to openldap.university.edu:1744, authentication 0 rlm_ldap: bind as uid=ldapuser,ou=Special Users,dc=university,dc=edu,c=US/ldappassword to openldap.university.edu:1744 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=university,dc=edu,c=US, with filter (uid=username) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user username authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap2" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "username" with password "test123" rlm_ldap: user DN: CN=name\, user,CN=Users,DC=dept,DC=university,DC=edu rlm_ldap: (re)connect to ad.dept.university.edu:389, authentication 1 rlm_ldap: bind as CN=name\, user,CN=Users,DC=dept,DC=university,DC=edu/test123 to ad.dept.university.edu:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind failed with invalid credentials modcall[authenticate]: module "ldap1" returns reject for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "username" with password "test123" rlm_ldap: user DN: CN=name\, user,CN=Users,DC=dept,DC=university,DC=edu rlm_ldap: (re)connect to openldap.university.edu:1744, authentication 1 (THIS LINE IS THE PROBLEM) rlm_ldap: bind as CN=name\, user,CN=Users,DC=dept,DC=university,DC=edu/test123 to openldap.university.edu:1744 rlm_ldap: waiting for bind result ... rlm_ldap: CN=name\, user,CN=Users,DC=dept,DC=university,DC=edu bind to openldap.university.edu:1744 failed No such object rlm_ldap: ldap_connect() failed modcall[authenticate]: module "ldap2" returns fail for request 0 modcall: group Auth-Type returns fail for request 0 auth: Failed to validate the user. The above problem line should be: rlm_ldap: bind as uid=username, ou=People, dc=university,dc=edu,c=us/test123 to openldap.university.edu:1744 However, it is taking the userdn from the ad server which gave the first authorize ok. What I need is for it to attempt to authenticate with the appropriate userdn depending on which server it is authenticating to. So it would use the userdn from AD authenticating to the AD server and the openldap userdn when authenticating to the openldap server. Thanks
ggreen@olemiss.edu wrote:
How do you have this setup? Check out
doc/configurable_failover. That
should show you how to do it.
I'm using configurable failover to get it to roll as it is.
From my radiusd.conf file:
[ snip ]
The above problem line should be: rlm_ldap: bind as uid=username, ou=People, dc=university,dc=edu,c=us/test123 to openldap.university.edu:1744 However, it is taking the userdn from the ad server which gave the first authorize ok. What I need is for it to attempt to authenticate with the appropriate userdn depending on which server it is authenticating to. So it would use the userdn from AD authenticating to the AD server and the openldap userdn when authenticating to the openldap server.
For what it is worth, we've seen the same problem here - we applied a local hack to rlm_ldap.c to work around the problem but it isn't a proper fix. --Craig
The above problem line should be: rlm_ldap: bind as uid=username, ou=People, dc=university,dc=edu,c=us/test123 to openldap.university.edu:1744 However, it is taking the userdn from the ad server which gave the first authorize ok. What I need is for it to attempt to authenticate with the appropriate userdn depending on which server it is authenticating to. So it would use the userdn from AD authenticating to the AD server and the openldap userdn when authenticating to the openldap server.
I see what is happening, that's a tough one. You are passing both authorization modules since the username is the same for your search filter. Then it tries to bind with the first DN that passed the authorization, but that is the incorrect DN since you want to use the openldap version of that user. The easiest method to work around this right away, is if there is something coming in the packet that will tell you whether this should be an AD or openldap user. If that's the case, then you can make a rule specifying which Autz type and Auth type to use. For example. Say all AD users come from nas-ip of 1.1.1.1 and all openldap users come from nas-ip of 1.1.1.2. In users file. DEFAULT NAS-IP-Address == 1.1.1.1, Autz-Type := ldap1, Auth-Type := ldap2 DEFAULT NAS-IP-Address == 1.1.1.2, Autz-Type := ldap2, Auth-Type := ldap2 DEFAULT Auth-Type := Reject That would get you what you want. Note that it doesn't have to be nas-ip, you can go off any radius attribute that is consistantly in those auth requests. However, if there is nothing identifying whether it should be an AD lookup vs an openldap lookup, then its going to be harder. ( I think - although I don't know the internals, so a developer could answer this better). The overlap of the names makes it hard. Are these actually different users, with the same RDN or are they the same user that exists in both AD and openldap? I'd have to think about this a bit based on your answer to see if I can think of anything.
participants (3)
-
Craig Huckabee -
Dusty Doris -
ggreen＠olemiss.edu