wireless - freeradius - MS ldap

[Alhagie Puye]

> >-----Original Message-----
> >From: 
> >freeradius-users-bounces+apuye=datawave.com at lists.freeradius.
> >org 
> >[mailto:freeradius-users-bounces+apuye=datawave.com at lists.fre
> >eradius.org] On Behalf Of Dickson, John
> >Sent: January 4, 2006 9:27 AM
> >To: FreeRadius users mailing list
> >Subject: RE: wireless - freeradius - MS ldap
> >
> >Here is the output of my RADIUS server. I verfied the 
> >account on the LDAP server as a domain admin
> >
> >rad_recv: Access-Request packet from host 10.1.1.27:32773, id=254,
> >length=59
> >--- Walking the entire request list ---
> >Waking up in 31 seconds...
> >Threads: total/active/spare threads = 5/0/5 Thread 1 got 
> >semaphore Thread 1 handling request 0, (1 handled so far)
> >        User-Name = "radtest"
> >        User-Password = "Passw0rd"
> >        NAS-IP-Address = 255.255.255.255
> >        NAS-Port = 0
> >  Processing the authorize section of radiusd.conf
> >modcall: entering group authorize for request 0
> >  modcall[authorize]: module "preprocess" returns ok for request 0
> >  modcall[authorize]: module "chap" returns noop for request 0
> >  modcall[authorize]: module "mschap" returns noop for request 0
> >    rlm_realm: No '@' in User-Name = "radtest", looking up realm NULL
> >    rlm_realm: No such realm "NULL"
> >  modcall[authorize]: module "suffix" returns noop for request 0
> >  rlm_eap: No EAP-Message, not doing EAP
> >  modcall[authorize]: module "eap" returns noop for request 0
> >    users: Matched entry DEFAULT at line 152
> >  modcall[authorize]: module "files" returns ok for request 0
> >rlm_ldap: - authorize
> >rlm_ldap: performing user authorization for radtest
> >radius_xlat:  '(uid=radtest)'
> >radius_xlat:  'ou=Local Users,dc=name,dc=serverdm,dc=domain,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 name.serverdm.domain.edu:389, 
Can you resolve name.serverdm.domain.edu successfully? Please verify
that too.

> >authentication 0
> >rlm_ldap: bind as powerful/userspass to name.serverdm.domain.edu:389
> >rlm_ldap: waiting for bind result ...
> >rlm_ldap: LDAP login failed: check identity, password 

Verify first that you can infact query Active Directory with this
username/password combination.

There is a utility called ldapsearch. I believe it comes with OpenLDAP.
Use that to directly query AD for verification.

Here is an example:

ldapsearch -LLL -h name.serverdm.domain.edu -x -b
'dc=domain,dc=com''(samaccountname=powerful)' -D powerful  -w userspass

What does your "ldap" section in radiusd.conf look like? Can you please
provide copy?


This will make sure that the credentials are correct or not.
> >settings in ldap section of radiusd.conf
> >rlm_ldap: (re)connection attempt failed
> >rlm_ldap: search failed
> >rlm_ldap: ldap_release_conn: Release Id: 0
> >  modcall[authorize]: module "ldap" returns fail for request 0
> >modcall: group authorize returns fail for request 0 There 
> >was no response configured: rejecting request 0 Server 
> >rejecting request 0.
> >Finished request 0
> >Going to the next request
> >Thread 1 waiting to be assigned a request
> >rad_recv: Access-Request packet from host 10.1.1.27:32773, id=254,
> >length=59
> >Sending Access-Reject of id 254 to 10.1.1.27:32773
> >--- Walking the entire request list ---
> >Waking up in 3 seconds...
> >--- Walking the entire request list ---
> >Cleaning up request 0 ID 254 with timestamp 43bbea42 Nothing 
> >to do.  Sleeping until we see a request. 
> >
> >
> >-
> >List info/subscribe/unsubscribe? See 
> >http://www.freeradius.org/list/users.html
> >


This message (including any attachments) is confidential, may be privileged and is only intended for the person to whom it is addressed.  If you have received it by mistake please notify the sender by return e-mail and delete this message from your system.  Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.  E-mail communications are inherently vulnerable to interception by unauthorized parties and are susceptible to change.  We will use alternate communication means upon request.