CHAP/MS-CHAP/MS-CHAPv2 + LDAP problem
Hello, I'm having trouble authenticating from VPN box through Radius server to LDAP. My VPN uses MS-CHAP challenge/response system for authentification. Packet that comes from VPN to Radius server looks like this: User-Name = "admin" MS-CHAP-Challenge = 0x45bc0700dd22f6795f77bbe0d986328c MS-CHAP2-Response = 0x0100313396a8ea58cd1155c817c50a00715b0000000000000000b03e5340a5ae3c2ac4e 9408d57eae02fcfdbffab3f983a1b NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 10.1.1.202 But Radius can't autenticate to LDAP as there is no User-Password attribute in the packet. (rlm_ldap: Attribute "User-Password" is required for authentication). Is there a way to do this authentification and NOT turning MS-CHAP protocol in VPN box? Are there some kind of preauth hooks in Radius? I'm using freeradius-1.0.1-1.1.RHEL3 with openldap-2.0.27-17 and Netware 6.0 Directory Services. P.S. I tried to turn MS-CHAP protocol and it works great with PAP or plain-text passwords. So everything is configured to work well with LDAP. -- Best Regards, Vilius Šumskas LNK TV system administrator mob.: +370 614 75713
Vilius =?utf-8?b?xaB1bXNrYXM=?= <vilius@lnk.lt> wrote:
But Radius can't autenticate to LDAP as there is no User-Password attribute in the packet. (rlm_ldap: Attribute "User-Password" is required for authentication).
Use LDAP as a database, not as an authentication server. See many, many, posts on this topic to this list.
Is there a way to do this authentification and NOT turning MS-CHAP protocol in VPN box? Are there some kind of preauth hooks in Radius?
Have FreeRADIUS get the password from LDAP, and let FreeRADIUS do the authentication. Alan DeKok.
Alan DeKok <aland@ox.org> rašė:
Use LDAP as a database, not as an authentication server.
See many, many, posts on this topic to this list.
Is there a way to do this authentification and NOT turning MS-CHAP protocol in VPN box? Are there some kind of preauth hooks in Radius?
Have FreeRADIUS get the password from LDAP, and let FreeRADIUS do the authentication.
Alan DeKok.
Thanks. I finally figured it out by myself. Sorry for posting early. I have another problem though. When I connect to VPN, user and password are verified and radius says their are ok. After that VPN client registers me on the network (gets IP address and so on). But in the middle of registration something happens and I get disconnected. There are no errors in Radius server log. However there are some in VPN server's: Connect: ppp0 <--> /dev/ttyp0 MSCHAP-v2 peer authentication succeeded for admin found interface eth0 for proxy arp local IP address 10.1.1.1 remote IP address 10.1.1.202 executing firewall rules signal SIGUSR1 received - rebuilding portmappings RADIUS: server 213.190.40.42 not responding RADIUS: server 213.190.40.42 not responding Is is because of some strange external/internal IP problems? What Radius server must do after I authenticate? -- Best Regards, Vilius
Vilius =?utf-8?b?xaB1bXNrYXM=?= <vilius@lnk.lt> wrote:
When I connect to VPN, user and password are verified and radius says their are ok. After that VPN client registers me on the network (gets IP address and so on). But in the middle of registration something happens and I get disconnected.
If something happens after RADIUS sends an Access-Accept, it's not a RADIUS authentication problem.
RADIUS: server 213.190.40.42 not responding RADIUS: server 213.190.40.42 not responding
Is is because of some strange external/internal IP problems? What Radius server must do after I authenticate?
Nothing. RADIUS is driven by the client, not the server. Your client is trying to RADIUS after it's authenticated. Find out why. Alan DeKok.
Hello Alan, Friday, September 2, 2005, 5:56:12 PM, you wrote:
Vilius =?utf-8?b?xaB1bXNrYXM=?= <vilius@lnk.lt> wrote:
When I connect to VPN, user and password are verified and radius says their are ok. After that VPN client registers me on the network (gets IP address and so on). But in the middle of registration something happens and I get disconnected.
If something happens after RADIUS sends an Access-Accept, it's not a RADIUS authentication problem.
RADIUS: server 213.190.40.42 not responding RADIUS: server 213.190.40.42 not responding
Is is because of some strange external/internal IP problems? What Radius server must do after I authenticate?
Nothing. RADIUS is driven by the client, not the server.
Your client is trying to RADIUS after it's authenticated. Find out why.
I finally solved all my problems with RADIUS. It seems that my client required MPPE encryption from the server, and this options was turned off in RADIUS. So client got Access-Accept packet without MS-CHAP-MPPE keys. Solved this by turning use_mppe to yes. Thanks for the help everyone! -- Best regards, Vilius
On Thu, 2005-09-01 at 12:32 +0300, Vilius Šumskas wrote:
Hello,
I'm having trouble authenticating from VPN box through Radius server to LDAP. My VPN uses MS-CHAP challenge/response system for authentification. Packet that comes from VPN to Radius server looks like this:
User-Name = "admin" MS-CHAP-Challenge = 0x45bc0700dd22f6795f77bbe0d986328c MS-CHAP2-Response = 0x0100313396a8ea58cd1155c817c50a00715b0000000000000000b03e5340a5ae3c2ac4e 9408d57eae02fcfdbffab3f983a1b NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 10.1.1.202
But Radius can't autenticate to LDAP as there is no User-Password attribute in the packet. (rlm_ldap: Attribute "User-Password" is required for authentication).
insert the NT-Password (ntPassword) attribute into ldap user. this attibute is field with a NT hash value example: password: test NT Hash: 0CB6948805F797BF2A82807973B89537
Is there a way to do this authentification and NOT turning MS-CHAP protocol in VPN box? Are there some kind of preauth hooks in Radius?
I'm using freeradius-1.0.1-1.1.RHEL3 with openldap-2.0.27-17 and Netware 6.0 Directory Services.
P.S. I tried to turn MS-CHAP protocol and it works great with PAP or plain-text passwords. So everything is configured to work well with LDAP.
participants (3)
-
Alan DeKok -
Tiago Fernandes -
Vilius Šumskas