AD ldap bind works with 1.01, fails with 1.04
Hi Folks We're implementing freeradius with EAP/TLS for our wireless and have found a strange happening with 1.04. This will only happen when attempting to query our student domain (w2k3 AD tree), but not our staff (w2k3 AD tree). If I remove the section (below) for student, it will authenticate staff and log them on happily. At the moment, we have acu.edu.au | / \ staff student I have a test box with FC3/FreeRadius 1.01 which will search through both domains and authenticate the user. I copy the config over to the FC4/FreeRadius 1.04 box and it works on staff, but returns the following on student (the tree is laid out the same as staff); ldap_search() failed: Operations error Is this a bug (known or unknown) or have I just not allowed something like referrals to work. I don't want to have to put openldap on the radius box if I can help it, but if that's the only solution then we'll reassess 1.01 on FC3 Config is as below (some sanitisation done to protect the innocent networks involved). ldap student { server = "192.148.xxx.xxx" identity = "cn=xxxxxxxxx,cn=users,dc=student,dc=acu,dc=edu,dc=au" password = "xxxxxxxxx" basedn = "dc=student,dc=acu,dc=edu,dc=au" filter = "(samaccountname=%{Stripped-User-Name:-%{User-Name}})" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 } ldap staff { server = "192.148.xxx.xxx" identity = "cn=xxxxxx,cn=users,dc=staff,dc=acu,dc=edu,dc=au" password = "xxxxxx" basedn = "dc=staff,dc=acu,dc=edu,dc=au" filter = "(samaccountname=%{Stripped-User-Name:-%{User-Name}})" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 } <snip> authorize { suffix eap staff student } authenticate { Auth-Type PAP { pap } Auth-Type LDAP { student staff } eap } many thanks Stephen Walsh Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++
Hi Folks Correction to previous email: We can bind to the server, when the time comes to search it fails; radiusd -X -A rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: closing existing LDAP connection rlm_ldap: (re)connect to 192.148.xxx.xxx:389, authentication 0 rlm_ldap: bind as cn=xxxxxxxx,cn=users,dc=student,dc=acu,dc=edu,dc=au/xxxxxxxx to 192.148.223.125:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=student,dc=acu,dc=edu,dc=au, with filter (samaccountname=testuser) rlm_ldap: ldap_search() failed: Operations error rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 Stephen Walsh s.walsh@signadou.acu.edu.au Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++ Stephen Walsh <S.Walsh@signadou .acu.edu.au> To Sent by: freeradius-users@lists.freeradius.o freeradius-users- rg bounces+s.walsh=s cc ignadou.acu.edu.a u@lists.freeradiu Subject s.org AD ldap bind works with 1.01, fails with 1.04 24/01/2006 04:28 PM Please respond to FreeRadius users mailing list <freeradius-users @lists.freeradius .org> Hi Folks We're implementing freeradius with EAP/TLS for our wireless and have found a strange happening with 1.04. This will only happen when attempting to query our student domain (w2k3 AD tree), but not our staff (w2k3 AD tree). If I remove the section (below) for student, it will authenticate staff and log them on happily. At the moment, we have acu.edu.au | / \ staff student I have a test box with FC3/FreeRadius 1.01 which will search through both domains and authenticate the user. I copy the config over to the FC4/FreeRadius 1.04 box and it works on staff, but returns the following on student (the tree is laid out the same as staff); ldap_search() failed: Operations error Is this a bug (known or unknown) or have I just not allowed something like referrals to work. I don't want to have to put openldap on the radius box if I can help it, but if that's the only solution then we'll reassess 1.01 on FC3 Config is as below (some sanitisation done to protect the innocent networks involved). ldap student { server = "192.148.xxx.xxx" identity = "cn=xxxxxxxxx,cn=users,dc=student,dc=acu,dc=edu,dc=au" password = "xxxxxxxxx" basedn = "dc=student,dc=acu,dc=edu,dc=au" filter = "(samaccountname=%{Stripped-User-Name:-%{User-Name}})" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 } ldap staff { server = "192.148.xxx.xxx" identity = "cn=xxxxxx,cn=users,dc=staff,dc=acu,dc=edu,dc=au" password = "xxxxxx" basedn = "dc=staff,dc=acu,dc=edu,dc=au" filter = "(samaccountname=%{Stripped-User-Name:-%{User-Name}})" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 } <snip> authorize { suffix eap staff student } authenticate { Auth-Type PAP { pap } Auth-Type LDAP { student staff } eap } many thanks Stephen Walsh Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Stephen Walsh <S.Walsh@signadou.acu.edu.au> wrote:
ldap_search() failed: Operations error
It's a combination of factors. What's happening is that your LDAP search isn't fully qualified, so when something isn't found in "students", AD returns a referral to "staff". OpenLDAP fails to use the authentication credentials for the referral that it was given for the original query. And lo, "operations error", which is such a useful message. It's a cross-domain referral problem. You have a "staff" domain, and a "student" domain, each of which trusts each other in AD. The solution is to fully qualify all of the queries so that AD doesn't return a referral. Usually adding "ou=people" (or something like that) will usually do the trick. Alan DeKok.
Thanks Alan; I think I understand what you mean, however each of our trees is sorted by campus, then OU, then users. Student | | |---Brisbane | |---Sydney1 | |---Sydney2 | |---Canberra | |--computers | |--Printers | |---users and the same for staff. What's the best way to format the baseDN to allow for recursive searches through each OU container. At the moment I have basedn= "ou=users,dc=student,dc=acu,dc=edu,dc=au", which is obviously wrong. Many thanks Stephen Walsh s.walsh@signadou.acu.edu.au Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++ Stephen Walsh <S.Walsh@signadou.acu.edu.au> wrote:
ldap_search() failed: Operations error
It's a combination of factors. What's happening is that your LDAP search isn't fully qualified, so when something isn't found in "students", AD returns a referral to "staff". OpenLDAP fails to use the authentication credentials for the referral that it was given for the original query. And lo, "operations error", which is such a useful message. It's a cross-domain referral problem. You have a "staff" domain, and a "student" domain, each of which trusts each other in AD. The solution is to fully qualify all of the queries so that AD doesn't return a referral. Usually adding "ou=people" (or something like that) will usually do the trick. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan; I've tested it further and you are right, the search isn't recursively entering the tree. What in the search changed between 1.01 (which works) and 1.04 (which returns errors when trying to enter the OU's)? If is possible to revert to the 1.01 search under 1.04? many thanks Stephen Walsh s.walsh@signadou.acu.edu.au Client Support Officer (Technology) Australian Catholic University (Limited) PO Box 256, Dickson ACT 2602 Phone: +61 2 6209 1133 Fax: +61 2 6209 1179 Mobile: +61 419 496796 +++++++++++++++++++++++++++++++++++++++++++++++++ CRICOS Registration: 00004G, 00112C, 00873F, 00885B ABN 15 050 192 660 +++++++++++++++++++++++++++++++++++++++++++++++++ "Alan DeKok" <aland@ox.org> Sent by: To freeradius-users- FreeRadius users mailing list bounces+s.walsh=s <freeradius-users@lists.freeradius. ignadou.acu.edu.a org> u@lists.freeradiu cc s.org Subject Re: AD ldap bind works with 1.01, 25/01/2006 04:16 fails with 1.04 AM Please respond to FreeRadius users mailing list <freeradius-users @lists.freeradius .org> Stephen Walsh <S.Walsh@signadou.acu.edu.au> wrote:
ldap_search() failed: Operations error
It's a combination of factors. What's happening is that your LDAP search isn't fully qualified, so when something isn't found in "students", AD returns a referral to "staff". OpenLDAP fails to use the authentication credentials for the referral that it was given for the original query. And lo, "operations error", which is such a useful message. It's a cross-domain referral problem. You have a "staff" domain, and a "student" domain, each of which trusts each other in AD. The solution is to fully qualify all of the queries so that AD doesn't return a referral. Usually adding "ou=people" (or something like that) will usually do the trick. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Stephen Walsh <S.Walsh@signadou.acu.edu.au> wrote:
I've tested it further and you are right, the search isn't recursively entering the tree. What in the search changed between 1.01 (which works) and 1.04 (which returns errors when trying to enter the OU's)?
I have no idea. I've looked, and can't see anything that would affect that. Alan DeKok.
participants (2)
-
Alan DeKok -
Stephen Walsh