AD's chasing of LDAP referrals can be a bit of a problem. It slows lookups down significantly, and also results in failures like the one you have seen. In my experience, if you are using AD, it would be better to use the LDAP interface to the Global Catalogue, rather than to the standard AD. In most AD deployments, this works fine (depends on your tree/forest design, AFAIK). The speed-up can be astonishing, and eliminates a lot of the failure issues, as well as potential network-related geographical issues when referrals take you across slow WAN links. Of course, the GC does not have all attributes/fields, but for things like group memberships, userid-password binding/validation, etc, it works fine.
To use the GC, point rlm_ldap to your AD servers that also host the GC, but use the port 3268 instead of 389 (or 3269 for LDAP/TLS - for this you will have to use FR >= 1.0.0, so that you can use ports other than 636 for LDAP with TLS: ie. use start_tls=no and tls_mode=yes). Tarun -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Griego Sent: Wednesday, 29 September 2004 12:02 AM To: [EMAIL PROTECTED] Subject: Re: Revisited: Auth via LDAP to Microsoft AD (long) This sounds like an issue of chasing LDAP referrals. AD is pretty referral-happy. On a cursory look, it doesn't look like the rlm_ldap module supports chasing referrals. A config option should probably be added to support this. --Mike On Tue, 2004-09-28 at 07:50, Kellogg, Chris wrote: > Hi, everyone. > > Forgive me, this is a bit of a rehash of an old subject. I am unable to > get authentication via LDAP to work correctly when I set the 'basedn' to > the top-level of our AD structure: > > basedn = "dc=subdomain,dc=domain,dc=com" > > --- radius -sx output --- > rad_recv: Access-Request packet from host nas-test.domain.com:2180, > id=51, length=72 > User-Name = "username" > User-Password = "userpw" > Vendor-3076-Attr-32 = 0x00000009 > NAS-IP-Address = 127.0.0.1 > NAS-Port-Type = Virtual > rlm_ldap: - authenticate > rlm_ldap: login attempt by "username" with password "userpw" > rlm_ldap: ldap_get_conn: Checking Id: 0 > rlm_ldap: ldap_get_conn: Got Id: 0 > rlm_ldap: (re)connect to msad-gc.subdomain.domain.com:389, > authentication 0 > rlm_ldap: bind as identity/password to msad-gc.subdomain.domain.com:389 > rlm_ldap: waiting for bind result ... > rlm_ldap: Bind was successful > rlm_ldap: ldap_search() failed: Operations error > rlm_ldap: ldap_release_conn: Release Id: 0 > Sending Access-Reject of id 51 to nas-test.domain.com:2180 > --- /radius -sx output --- > > > Inside that sub, there is a series of OUs and DNs. If I set basedn to > point into one of those: > > basedn = "ou=users,dc=subdomain,dc=domain,dc=com" > > I am able to get authentication for any user account inside the 'users' > OU or inside any OU that is underneath the 'users' OU: > --- radius -sx output --- > rad_recv: Access-Request packet from host nas-test.domain.com:2180, > id=53, length=72 > User-Name = "username" > User-Password = "userpw" > Vendor-3076-Attr-32 = 0x00000009 > NAS-IP-Address = 127.0.0.1 > NAS-Port-Type = Virtual > rlm_ldap: - authenticate > rlm_ldap: login attempt by "username" with password "userpw" > rlm_ldap: ldap_get_conn: Checking Id: 0 > rlm_ldap: ldap_get_conn: Got Id: 0 > rlm_ldap: (re)connect to msad-gc.subdomain.domain.com:389, > authentication 0 > rlm_ldap: bind as identity/password to msad-gc.subdomain.domain.com:389 > rlm_ldap: waiting for bind result ... > rlm_ldap: Bind was successful > rlm_ldap: ldap_release_conn: Release Id: 0 > rlm_ldap: user DN: CN=Name\, > User,OU=Testing,OU=users,DC=subdomain,DC=domain,DC=com > rlm_ldap: (re)connect to msad-gc.subdomain.domain.com:389, > authentication 1 > rlm_ldap: bind as CN=Name\, > User,OU=Testing,OU=users,DC=subdomain,DC=domain,DC=com/userpw to > msad-gc.subdomain.domain.com:389 > rlm_ldap: waiting for bind result ... > rlm_ldap: Bind was successful > rlm_ldap: user username authenticated succesfully > Sending Access-Accept of id 53 to nas-test.domain.com:2180 > --- /radius -sx output --- > > Anyone have any ideas on this? I'm not even sure where to start looking > on this... > > Thanks, > > Chris. > > Christopher M. Kellogg, GCFW > Principle Network Administrator, DynCorp, A CSC Company > 6500 West Freeway Suite 600, Fort Worth, TX > (817)570-1956 Ofc / (817)737-1638 Fax > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
