V1.10 File and LDAP Problems
I have installed Freeradius 1.10, on Solaris 8. Using default radiusd.conf, and users file, added a couple of users. Tested and I am able to auth my testme user. I then add in the LDAP module, and un-comment ldap places in the radiusd.conf file. I again try to auth the same user who is in the user text file, and I can not auth that user. No other changes, just put the ldap directives in and it seems to break text file auth. I need to have the capability to fall back to text file of users in case the LDAP server is not available/problems/etc. Below are traces from each test. Note in the second test, that I know the login to the LDAP server is not valid, but this simulates the server being broken etc. I have also tested with a valid connection and get the same results. DEGUG FOLLOWS:-------------------------------------------------------------- WORKING: The ldap module is not enabled in the radiusd.conf file: Ready to process requests. rad_recv: Access-Request packet from host 10.0.90.32:2016, id=61, length=46 User-Name = "testme" User-Password = "123456" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched entry testme at line 142 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "testme", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [testme] (from client Dallas port 0) Sending Access-Accept of id 61 to 10.0.90.32 port 2016 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 61 with timestamp 43fe2e2d Nothing to do. Sleeping until we see a request. NOT WORKING: Ready to process requests. rad_recv: Access-Request packet from host 10.0.90.32:2017, id=62, length=46 User-Name = "testme" User-Password = "123456" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched entry testme at line 142 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for testme radius_xlat: '(sAMAccountname=testme)' radius_xlat: 'dc=consolidated,dc=com' 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 10.0.60.177:389, authentication 0 rlm_ldap: bind as cn=someuser,cn=Users,dc=ourcompany,dc=com/secret to 10.0.xx.xxx:389 rlm_ldap: waiting for bind result ... rlm_ldap: LDAP login failed: check identity, password 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: leaving group authorize (returns fail) for request 0 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 62 with timestamp 43fe2e82 Nothing to do. Sleeping until we see a request. Gerry Dalton, Network System Support Consolidated Communications Cell: 214 532-1905
NOT WORKING:
Ready to process requests. rad_recv: Access-Request packet from host 10.0.90.32:2017, id=62, length=46 User-Name = "testme" User-Password = "123456" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 users: Matched entry testme at line 142 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for testme radius_xlat: '(sAMAccountname=testme)' radius_xlat: 'dc=consolidated,dc=com' 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 10.0.60.177:389, authentication 0 rlm_ldap: bind as cn=someuser,cn=Users,dc=ourcompany,dc=com/secret to 10.0.xx.xxx:389 rlm_ldap: waiting for bind result ... rlm_ldap: LDAP login failed: check identity, password settings in ldap section of radiusd.conf
Looks like you don't have the LDAP information setup correctly. FreeRADIUS can't login to LDAP with the settings (un)specified.
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: leaving group authorize (returns fail) for request 0
LDAP returns fail, which is weighted heavier than the both the "noop" returned by mschap and the "ok" returned by files. Because LDAP returns "fail," the entire request returns "fail." You can specify different weighted settings for noop, fail, etc, but the obvious answer is to fix your LDAP settings and then try again. Once you can login to the LDAP, if the user does not exist in there then LDAP should return "noop" for the request. If you want a user to exist in both the LDAP and the users file with different passwords, that requires a bit of tweaking but I've got it working if you need to see how sometime. Hope this helps! Andrew
participants (2)
-
Andrew Browning -
Gerry Dalton