There was no NT-Password in your access-request packet.
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
On Fri, 21 Mar 2003, Stephen A. Moore wrote:
> I am working on a project to provide a secure wireless network using VPN's
> for encryption and authentication.
>
> 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
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html