All users of the network are already registered on a central LDAP database. The problem currently encountered is that passwords must be sent using MS-CHAP to an LDAP server (via freeRADIUS) storing plain text passwords. My understand of the LDAP configuration is that a password cannot be 'retrieved' from LDAP and instead a supplied password can only be compared to that which is stored. To get around this we have created an extra attribute in the LDAP database in which an MS-CHAP encrypted version of the users password is stored. This should allow MS-CHAP to MS-CHAP comparison however it doesn't appear to be working.
The ldap.attrib file has been changed to map NT-Password to point to the gecos field (where the MS-CHAP password is stored). I am running freeRADIUS 0.8.1 on RedHat Linux 7.3. freeRADIUS itself is running fine and will authenticate PAP against the LDAP database so I know that the freeRADIUS to LDAP communication is fine.
A copy of the LDAP module from radiusd.conf is shown here:
ldap {
server = "xxx"
port = 389
basedn = "o=uol"
filter = "(&(objectClass=User)(cn=%{Stripped-User-Name:-%{User-Name}})(loginDisabled
=FALSE))"
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
password_attribute = "NT-Password"
timeout = 4
timelimit = 3
net_timeout = 1
}
Also the authorize and authentication sections are also as follows:
authorize {
preprocess
ldap
}
authenticate { authtype MS-CHAP { mschap } }
and finally to test this I am using the Microsoft Windows 2000 VPN client, set to send MS-CHAP passwords to the radius server. The debug output from freeRADIUS is as follows:
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1:32804, id=140, length=126
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "testuser"
MS-CHAP-Challenge = 0x55f62411fc71c9c1
MS-CHAP-Response = 0x010100000000000000000000000000000000000000000000000
0442ccd457fa62aeb0191c5762fee6cecd8bde7f16e5e00b3
NAS-IP-Address = x.x.x.x
NAS-Port = 0
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_ldap: - authorize
rlm_ldap: performing user authorization for dtyson
radius_xlat: '(&(objectClass=User)(cn=testuser)(loginDisabled=FALSE))'
radius_xlat: 'o=uol'
ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to xxx:389, authentication 0
rlm_ldap: bind as / to xxx:389
rlm_ldap: waiting for bind result ...
rlm_ldap: performing search in o=uol, with filter (&(objectClass=User)(cn=testuser
)(loginDisabled=FALSE))
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding gecos as NT-Password, value 937958CFCA106B3CDAE1645D3377E078 &
op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: user testuser authorized to use remote access
ldap_release_conn: Release Id: 0
modcall[authorize]: module "ldap" returns ok
modcall: group authorize returns ok
rad_check_password: Found Auth-Type LDAP
auth: type "LDAP"
auth: Failed to validate the user.
Login incorrect: [testuser/<no User-Password attribute>] (from client localhost po
rt 0)
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 140 to 127.0.0.1:32804
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 140 with timestamp 3e7ad9e9
Nothing to do. Sleeping until we see a request.
Thanks in advance,
Stephen A. Moore PC & Network Support Engineer Computing Services Department The University of Liverpool
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
