PEAP problem when using domain suffix
Hi Have set up freeradius on a SLES10SP1 box in order to do 802.1X authentication. All is fine if the client submits a request using just the user name e.g. test05 in the case below: Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: Told to do MS-CHAPv2 for test05 with NT-Password rlm_mschap: adding MS-CHAPv2 MPPE keys modcall[authenticate]: module "mschap" returns ok for request 6 modcall: leaving group MS-CHAP (returns ok) for request 6 MSCHAP Success modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 PEAP: Got tunneled Access-Challenge modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 However, if the user submits a request with the domain name appended such as @xyz.edu.hk, then the request fails at the same point in the process as shown: Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: Told to do MS-CHAPv2 for test08@xyz.edu.hk with NT-Password rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 6 modcall: leaving group MS-CHAP (returns reject) for request 6 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 6 modcall: leaving group authenticate (returns reject) for request 6 auth: Failed to validate the user. Found Post-Auth-Type Processing the post-auth section of radiusd.conf modcall: entering group REJECT for request 6 I defined the domain suffix in the proxy conf file and set it to LOCAL because the local server should process the requests no matter whether the suffix is there or not. I also tried rewriting the User-Name attribute to remove the suffix (which is already done by Stripped-User-Name) but that caused another problem. So I'm at the point where just scratching my head...any hints most appreciated. Graham Marsh Hong Kong
Graham Marsh wrote:
Hi
Have set up freeradius on a SLES10SP1 box in order to do 802.1X authentication. All is fine if the client submits a request using just the user name e.g. test05 in the case below:
Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: Told to do MS-CHAPv2 for test05 with NT-Password rlm_mschap: adding MS-CHAPv2 MPPE keys modcall[authenticate]: module "mschap" returns ok for request 6 modcall: leaving group MS-CHAP (returns ok) for request 6 MSCHAP Success modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 PEAP: Got tunneled Access-Challenge modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6
However, if the user submits a request with the domain name appended such as @xyz.edu.hk, then the request fails at the same point in the process as shown:
Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: Told to do MS-CHAPv2 for test08@xyz.edu.hk with NT-Password rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 6 modcall: leaving group MS-CHAP (returns reject) for request 6 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 6 modcall: leaving group authenticate (returns reject) for request 6 auth: Failed to validate the user. Found Post-Auth-Type Processing the post-auth section of radiusd.conf modcall: entering group REJECT for request 6
I defined the domain suffix in the proxy conf file and set it to LOCAL because the local server should process the requests no matter whether the suffix is there or not.
I also tried rewriting the User-Name attribute to remove the suffix (which is already done by Stripped-User-Name) but that caused another problem.
You will need to strip it; what "other" problem did it cause?
You will need to strip it; what "other" problem did it cause?
The "other" problem it caused was as follows and as another respondent wrote, you can't mess with the User-Name attribute, so that's the wrong path to take it seems. Anyway I found some additional info in the main branch of the thread. FYI the appropriate debug log section is as follows when I rewrite the User-Name attribute: Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Identity does not match User-Name, setting from EAP Identity. rlm_eap: Failed in handler modcall[authenticate]: module "eap" returns invalid for request 6 modcall: leaving group authenticate (returns invalid) for request 6 auth: Failed to validate the user. Found Post-Auth-Type Processing the post-auth section of radiusd.conf modcall: entering group REJECT for request 6
hi, you need to remove the domain suffix but you cannot play with the User-Name attribute or the response will be wrong - use the 'stripped-user-name' attribute for the authenticate step - and ensure that if you are querying an LDAP or AD et cin that stage that DOMAIN being used is the correct domain - either overwrite the value or set it to NULL alan
A.L.M.Buxey@lboro.ac.uk wrote:
hi,
you need to remove the domain suffix but you cannot play with the User-Name attribute or the response will be wrong - use the 'stripped-user-name' attribute for the authenticate step - and ensure that if you are querying an LDAP or AD et cin that stage that DOMAIN being used is the correct domain - either overwrite the value or set it to NULL
The problem is that rlm_mschap always reads the "User-Name" attribute for generating the chal/resp i.e. when *not* using ntlm_auth. If "with_ntdomain_hack" is enabled, rlm_mschap strips prefix "domain\" but not suffix formats. Given that (in 2.0.3 at least) with_ntdomain_hack *only* controls the username string fed into the chal/resp code, it should really be on all the time, and be extended to handle suffix formats.
On 6/6/08, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
hi,
you need to remove the domain suffix but you cannot play with the User-Name attribute or the response will be wrong - use the 'stripped-user-name' attribute for the authenticate step - and ensure that if you are querying an LDAP or AD et cin that stage that DOMAIN being used is the correct domain - either overwrite the value or set it to NULL
The problem is that rlm_mschap always reads the "User-Name" attribute for generating the chal/resp i.e. when *not* using ntlm_auth.
If "with_ntdomain_hack" is enabled, rlm_mschap strips prefix "domain\" but not suffix formats.
Given that (in 2.0.3 at least) with_ntdomain_hack *only* controls the username string fed into the chal/resp code, it should really be on all the time, and be extended to handle suffix formats.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I have some additional info that is interesting if not rather odd: The results I posted in the original message were generated using the Odyssey Access Client, I apologise for not mentioning that first. So with OAC, the username without suffix works, with suffix fails. Further background info is that auth is taking place using the LDAP against back-end LDAP server hosted on Novell eDirectory. Anyway, the interesting thing is that when the native client in XP SP3 is used with or without suffix, it works in both cases. Here is the debug output from the radiusd when the XP SP3 client is used (IP/domain obfuscated): modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 rlm_mschap: Told to do MS-CHAPv2 for test05@xyz.edu.hk with NT-Password rlm_mschap: adding MS-CHAPv2 MPPE keys modcall[authenticate]: module "mschap" returns ok for request 6 modcall: leaving group MS-CHAP (returns ok) for request 6 MSCHAP Success modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 PEAP: Got tunneled Access-Challenge modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 Sending Access-Challenge of id 161 to n.n.n.n port 1812 EAP-Message = 0x0107004a1900170301003f67df50a0706efc458cf1803e59b35c681b98887353fbe3bc0257e4bae1ca8c7abb99f141ae3fce73617a05c40b098b432f417740876f7f9eb5599bc9c65cce Message-Authenticator = 0x00000000000000000000000000000000 State = 0xb409dd0bde5ee996d642ea46017f223c Finished request 6 How strange! Here is the debug output from the OAC but it's rather cryptic and I suppose not much help: 00149,09 2008/06/06 17:42:06.742 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5281 - 'odService'
>> Starting authentication
00150,09 2008/06/06 17:42:06.742 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.742 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00149,09 2008/06/06 17:42:06.742 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5281 - 'odService'
>> Starting authentication
00150,09 2008/06/06 17:42:06.742 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.792 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.792 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.822 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.822 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.852 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.862 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.882 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.882 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.902 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.902 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:06.932 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:06.942 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:09.986 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00150,09 2008/06/06 17:42:09.986 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:14.032 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00175,09 2008/06/06 17:42:14.032 0 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicantMgr.cpp:257 - 'odService' [NRM] Processing EAP-Failure: code = 4, id = 7, length = 4 00153,09 2008/06/06 17:42:14.032 3 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5207 - 'ClientMgr' Supplicant state: authentication failed 00164,09 2008/06/06 17:42:14.042 0 SYSTEM odClientService.exe (null) p1404 t844 odysseyEapAkaClientIdentity.h:119 - 'odService' SetOdysseyIdentity: pIdentity = 0x00000000 00150,09 2008/06/06 17:42:14.042 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00150,09 2008/06/06 17:42:14.042 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(0) returned success 00164,09 2008/06/06 17:42:14.052 0 SYSTEM odClientService.exe (null) p1404 t844 odysseyEapAkaClientIdentity.h:119 - 'odService' SetOdysseyIdentity: pIdentity = 0x01a531f8 00161,09 2008/06/06 17:42:29.294 1 SYSTEM odClientService.exe (null) p1404 t620 OdysseySupplicantMgr.cpp:7651 - 'odService' OdysseySupplicantMgr::DoThread() event loop 00149,09 2008/06/06 17:42:29.294 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5281 - 'odService'
>> Starting authentication
00153,09 2008/06/06 17:42:29.294 3 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5207 - 'ClientMgr' Supplicant state: authentication failed 00164,09 2008/06/06 17:42:29.294 0 SYSTEM odClientService.exe (null) p1404 t844 odysseyEapAkaClientIdentity.h:119 - 'odService' SetOdysseyIdentity: pIdentity = 0x00000000 00150,09 2008/06/06 17:42:29.294 2 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:95 - 'odService' SetThreadPriority(1) returned success 00161,09 2008/06/06 17:42:29.294 1 SYSTEM odClientService.exe (null) p1404 t620 OdysseySupplicantMgr.cpp:7651 - 'odService' OdysseySupplicantMgr::DoThread() event loop 00138,09 2008/06/06 17:42:29.344 2 SYSTEM odClientService.exe (null) p1404 t620 OdysseySupplicantMgr.cpp:5262 - 'odService' Configuring adapters 00173,09 2008/06/06 17:42:29.344 1 SYSTEM odClientService.exe (null) p1404 t620 OdysseySupplicantMgr.cpp:5132 - 'odService' updating adapter {7F8EC7AA-9090-43E2-9C19-04CB8B04EF62} 00141,09 2008/06/06 17:42:29.344 3 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:4097 - 'ClientMgr' No equivalent network found 00138,09 2008/06/06 17:42:29.344 3 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicant.cpp:5171 - 'ClientMgr' Supplicant state: logoff 00148,09 2008/06/06 17:42:29.344 0 SYSTEM odClientService.exe (null) p1404 t844 OdysseySupplicantMgr.cpp:257 - 'odService' [NRM] Transmitting EAPOL-Logoff 00142,09 2008/06/06 17:42:29.344 3 SYSTEM odClientService.exe (null) p1404 t844 <>:0 - '' 0000 01 02 00 00 .... 00218,09 2008/06/06 17:42:29.344 3 SYSTEM odClientService.exe (null) p1404 t620 OdysseySupplicantMgr.cpp:6757 - 'odService' COdysseySupplicantMgr::CheckConnectStatus() new connect status = 0X00000010 L2_AUTHENTICATION_FAILED 00140,09 2008/06/06 17:42:29.344 2 admin OdTray.exe odTray p3384 tD40 OdTrayWindow.cpp:528 - 'ClientMgr' OD_CONNECT_STATUS is 0x00000010 - FAILED 00154,09 2008/06/06 17:42:29.344 3 admin OdTray.exe odTray p3384 tD40 OdTrayWindow.cpp:529 - 'ClientMgr' OD_CONNECT_STATUS (detailed) - L2_AUTHENTICATION_FAILED 00203,09 2008/06/06 17:42:29.354 2 admin OdTray.exe odTray p3384 tD40 OdTrayWindow.cpp:640 - 'ClientMgr' OdTray notification message- Your authentication has failed. Click on this message for more information.
Graham Marsh wrote:
The results I posted in the original message were generated using the Odyssey Access Client, I apologise for not mentioning that first. So with OAC, the username without suffix works, with suffix fails. ... Anyway, the interesting thing is that when the native client in XP SP3 is used with or without suffix, it works in both cases.
i.e. the Odyssey client does something different from what the native Windows supplicant does. Odyssey is broken. Given the number of people using it, I don't think that they will fix it. The only way around this is to update the configuration in the "authenticate" section to try a second method of calculating the MS-CHAP response, if the first method fails. Ugh. Alan DeKok.
Phil Mayers wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
hi,
you need to remove the domain suffix but you cannot play with the User-Name attribute or the response will be wrong - use the 'stripped-user-name' attribute for the authenticate step - and ensure that if you are querying an LDAP or AD et cin that stage that DOMAIN being used is the correct domain - either overwrite the value or set it to NULL
The problem is that rlm_mschap always reads the "User-Name" attribute for generating the chal/resp i.e. when *not* using ntlm_auth.
If "with_ntdomain_hack" is enabled, rlm_mschap strips prefix "domain\" but not suffix formats.
Given that (in 2.0.3 at least) with_ntdomain_hack *only* controls the username string fed into the chal/resp code, it should really be on all the time, and be extended to handle suffix formats.
I've written a small patch for 2.0.4 which fixes this: http://bugs.freeradius.org/show_bug.cgi?id=562
----- Original Message ----- From: "Phil Mayers" <p.mayers@imperial.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Friday, June 06, 2008 8:17 PM Subject: Re: PEAP problem when using domain suffix
Phil Mayers wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
hi,
you need to remove the domain suffix but you cannot play with the User-Name attribute or the response will be wrong - use the 'stripped-user-name' attribute for the authenticate step - and ensure that if you are querying an LDAP or AD et cin that stage that DOMAIN being used is the correct domain - either overwrite the value or set it to NULL
The problem is that rlm_mschap always reads the "User-Name" attribute for generating the chal/resp i.e. when *not* using ntlm_auth.
If "with_ntdomain_hack" is enabled, rlm_mschap strips prefix "domain\" but not suffix formats.
Given that (in 2.0.3 at least) with_ntdomain_hack *only* controls the username string fed into the chal/resp code, it should really be on all the time, and be extended to handle suffix formats.
I've written a small patch for 2.0.4 which fixes this:
http://bugs.freeradius.org/show_bug.cgi?id=562 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
That's amazing; thanks for the quick update; would you be so kind as to provide a very quick HowTo in order to get this implemented...my guess is something like this: - download the source of 2.0.4 - merge the patch (but I'm a bit vague on this point - unless you've merged it already) - compile it (also a bit vague on updating an existing implementation and doing make install or whatever) - test cheers gm
Hi,
I've written a small patch for 2.0.4 which fixes this:
http://bugs.freeradius.org/show_bug.cgi?id=562 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
That's amazing; thanks for the quick update; would you be so kind as to provide a very quick HowTo in order to get this implemented...my guess is something like this:
- download the source of 2.0.4 - merge the patch (but I'm a bit vague on this point - unless you've merged it already) - compile it (also a bit vague on updating an existing implementation and doing make install or whatever) - test
1) download freeradius 2.0.4 2) extract freeradius 2.0.4 3) download the patch 4) go to the directory in which the original file is located and patch it with the patch eg patch -p0 < /tmp/patch-file-you-downloaded.diff - you should see a message printed saying how it was successful(!) 5) run ./configure from the top directory of the archive using the same options as your currently running version (*) 6) make install. done! * - if you are using an RPM or PKG etc then you will need to remake the RPM or PKG using the usual package tools.. but you will need to delete the freeradius-2.0.4.tar.gz and remake it from your newly patched version! and then ensure that the package tool USES that .tar.gz source and doesnt pull the vanilla one down! alan
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Graham Marsh -
Phil Mayers