Hi, I am trying to make PEAP working with an LDAP/Samba backend and MSCHAPv2. It works well for the user authentication (they have lm and nt stored in the LDAP). However, the machine auth is causing issues. It appears to have only the NT-Password stored in the LDAP. I thought it should be sufficient for the MSCHAP to handle the auth, is it? ldap] looking for check items in directory... [ldap] acctFlags -> SMB-Account-CTRL-TEXT == "[W ]" [ldap] userPassword -> Password-With-Header == "..." [ldap] ntPassword -> NT-Password == 0x34343446...242 [ldap] looking for reply items in directory... [ldap] user host/dti-dahport authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [mschapv2] # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel [mschapv2] +- entering group MS-CHAP {...} [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] Found NT-Password [mschap] Creating challenge hash with username: host/dti-dahport [mschap] Told to do MS-CHAPv2 for host/dti-dahport with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject My MSCHAP Config : mschap { use_mppe = yes require_encryption = yes require_strong = yes with_ntdomain_hack = yes } Any thoughts? Thanks! -- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
Francois Gaudreault wrote:
I am trying to make PEAP working with an LDAP/Samba backend and MSCHAPv2. It works well for the user authentication (they have lm and nt stored in the LDAP). However, the machine auth is causing issues. It appears to have only the NT-Password stored in the LDAP. I thought it should be sufficient for the MSCHAP to handle the auth, is it?
It should. But machine authentication is... weird. If you're running a recent version, maching authentication *should* worl.
ldap] looking for check items in directory... [ldap] acctFlags -> SMB-Account-CTRL-TEXT == "[W ]" [ldap] userPassword -> Password-With-Header == "..." [ldap] ntPassword -> NT-Password == 0x34343446...242
Hmm... that looks a lot like it's ASCII. i.e. "444..." Maybe that's the problem? You have an ASCII string that's being interpreted as the NT password. Instead, it needs to be interpreted as the *printed* form of the password. Make sure it's the correct length (16), and that the password is being treated as hex. One way to do this is to list "pap" last in the authorize section. It goes through the various password attributes, and fixes them to be correct. Alan DeKok.
Hi Alan,
ldap] looking for check items in directory... [ldap] acctFlags -> SMB-Account-CTRL-TEXT == "[W ]" [ldap] userPassword -> Password-With-Header == "..." [ldap] ntPassword -> NT-Password == 0x34343446...242
Hmm... that looks a lot like it's ASCII. i.e. "444..." Maybe that's the problem? You have an ASCII string that's being interpreted as the NT password. Instead, it needs to be interpreted as the *printed* form of the password. I had a look in the LDAP, and the ntPassword is having the correct lenght : ntPassword: 44AFA3XXXXXXXXXXXXXXXXXXXXXXX856
One way to do this is to list "pap" last in the authorize section. It goes through the various password attributes, and fixes them to be correct.
I did enable pap, but without success. [ldap] looking for check items in directory... [ldap] acctFlags -> SMB-Account-CTRL-TEXT == "[W ]" [ldap] userPassword -> Password-With-Header == "JDEkMWs..." [ldap] ntPassword -> NT-Password == 0x34343446... [ldap] looking for reply items in directory... [ldap] user host/dti-dahport authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok [pap] Failed to decode Password-With-Header = "JDEkMWs..." [pap] Normalizing NT-Password from hex encoding [pap] WARNING: Auth-Type already set. Not setting to PAP ... [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] Found NT-Password [mschap] Creating challenge hash with username: host/dti-dahport [mschap] Told to do MS-CHAPv2 for host/dti-dahport with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect Is it possible that the issue is somewhere else? The nt/lmPassword are properly handled when we do user auth, and the printout in debug is also in a 0xsomething format. -- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
Hi,
[mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] Found NT-Password [mschap] Creating challenge hash with username: host/dti-dahport [mschap] Told to do MS-CHAPv2 for host/dti-dahport with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect
hmm, with nt_domain_hack = yes and --username=%{%{mschap:User-Name} used for the auth attempt , things shoud work as Alan said, MS host authentication is 'wierd' - the record tends to have a $ or so within it...but whatever you see as the attempt in debug mode should work on the command line alan
On 12-02-09 11:41 AM, Alan Buxey wrote:
hmm, with nt_domain_hack = yes and --username=%{%{mschap:User-Name} used for the auth attempt , things shoud work
By saying "--username=%{mshcap:user-name}" you refer to the ntlm_auth line in the mschap module right? However, we are not using AD, we are using LDAP populating the NT-Password field, we don't need this ntlm_auth line in the mschap module do we? Like I said, it's working well with user authentication. -- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
On 09/02/12 16:49, Francois Gaudreault wrote:
On 12-02-09 11:41 AM, Alan Buxey wrote:
hmm, with nt_domain_hack = yes and --username=%{%{mschap:User-Name} used for the auth attempt , things shoud work
By saying "--username=%{mshcap:user-name}" you refer to the ntlm_auth line in the mschap module right? However, we are not using AD, we are using LDAP populating the NT-Password field, we don't need this ntlm_auth line in the mschap module do we? Like I said, it's working well with user authentication.
Can you share the unobfuscated values for an attempt? The MS-CHAP challenge/response, NT-Password and User-Name? I've got a little script that performs blob generation and validation, and I can see if it's using name$ or host/name.domain as the challenge mix-in.
On 09/02/12 17:02, Phil Mayers wrote:
On 09/02/12 16:49, Francois Gaudreault wrote:
On 12-02-09 11:41 AM, Alan Buxey wrote:
hmm, with nt_domain_hack = yes and --username=%{%{mschap:User-Name} used for the auth attempt , things shoud work
By saying "--username=%{mshcap:user-name}" you refer to the ntlm_auth line in the mschap module right? However, we are not using AD, we are using LDAP populating the NT-Password field, we don't need this ntlm_auth line in the mschap module do we? Like I said, it's working well with user authentication.
Can you share the unobfuscated values for an attempt? The MS-CHAP challenge/response, NT-Password and User-Name? I've got a little script that performs blob generation and validation, and I can see if it's using name$ or host/name.domain as the challenge mix-in.
Also, maybe try this: authorize { ... update request { MS-CHAP-User-Name = "%{mschap:User-Name}" } ... } This should expand to "name$" for "host/name.domain". The mschap module will prefer MS-CHAP-User-Name as input to to challenge generation, and may work.
Francois Gaudreault wrote:
I had a look in the LDAP, and the ntPassword is having the correct lenght : ntPassword: 44AFA3XXXXXXXXXXXXXXXXXXXXXXX856
Yup. That's the hex version.
I did enable pap, but without success. ... [pap] Normalizing NT-Password from hex encoding
That's something, at least.
[pap] WARNING: Auth-Type already set. Not setting to PAP ... [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] Found NT-Password [mschap] Creating challenge hash with username: host/dti-dahport [mschap] Told to do MS-CHAPv2 for host/dti-dahport with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect
Is it possible that the issue is somewhere else? The nt/lmPassword are properly handled when we do user auth, and the printout in debug is also in a 0xsomething format.
The issue could be somewhere else. From what I recall, host authentication is... weird. The name in the MS-CHAP blob might *not* be the same as the User-Name field. If that happens, the calculated response using the User-Name will be wrong. Grab the debug output and use it as a test case. You should be able to replay the packets verbatim. Configure a static password. Also try configuring "MS-CHAP-User-Name", which will end up being the name used for the MS-CHAP calculations. Decode the MS-CHAP blobs manually to see if the name in them is the same as the User-Name. Alan DeKok.
On 09/02/12 16:42, Alan DeKok wrote:
The issue could be somewhere else. From what I recall, host authentication is... weird. The name in the MS-CHAP blob might *not* be the same as the User-Name field. If that happens, the calculated response using the User-Name will be wrong.
Looking at the code in rlm_mschap, it seems clearly to be wrong for host-based (non ntlm_auth) cases; it basically does: 1. Look for MS-CHAP-User-Name (this was added to make EAP-MSCHAPv2 work) 2. Otherwise, look for User-Name; if with_ntdomain_hack is set, strip leading DOMAIN\ Code for converting host/name.domain to name$ is absent here. As you've suggested, setting MS-CHAP-User-Name to name$ will probably make it work. Ironically, since the mschap xlat function *DOES* handle this case, setting: update request { MS-CHAP-User-Name := "%{mschap:User-Name}" } ...will work! TBH I wonder if this code should be entirely reworked for 3.0; it might be better to set MS-CHAP-User-Name in the "authorize" section (unless already set e.g. by rlm_eap_mschapv2) so that it's ready for use in authenticate. We could take the opportunity to handle user@domain too. AFAIK the formats we should handle are: bareuser DOMAIN\user user@domain.com host/name.domain.com Problem being, I'm wary of fiddling with this code; it's been arrived at with years of testing, and it's not impossible something would break, or some security hole be opened up...
Interesting. Let me give it a shot and see how it goes. Thanks! On 12-02-09 12:19 PM, Phil Mayers wrote:
On 09/02/12 16:42, Alan DeKok wrote:
The issue could be somewhere else. From what I recall, host authentication is... weird. The name in the MS-CHAP blob might *not* be the same as the User-Name field. If that happens, the calculated response using the User-Name will be wrong.
Looking at the code in rlm_mschap, it seems clearly to be wrong for host-based (non ntlm_auth) cases; it basically does:
1. Look for MS-CHAP-User-Name (this was added to make EAP-MSCHAPv2 work) 2. Otherwise, look for User-Name; if with_ntdomain_hack is set, strip leading DOMAIN\
Code for converting host/name.domain to name$ is absent here.
As you've suggested, setting MS-CHAP-User-Name to name$ will probably make it work. Ironically, since the mschap xlat function *DOES* handle this case, setting:
update request { MS-CHAP-User-Name := "%{mschap:User-Name}" }
...will work!
TBH I wonder if this code should be entirely reworked for 3.0; it might be better to set MS-CHAP-User-Name in the "authorize" section (unless already set e.g. by rlm_eap_mschapv2) so that it's ready for use in authenticate.
We could take the opportunity to handle user@domain too. AFAIK the formats we should handle are:
bareuser DOMAIN\user user@domain.com host/name.domain.com
Problem being, I'm wary of fiddling with this code; it's been arrived at with years of testing, and it's not impossible something would break, or some security hole be opened up... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
Doing the MS-CHAP-User-Name change got me this error : mschapv2] # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel [mschapv2] +- entering group MS-CHAP {...} [mschap] Found NT-Password [mschap] ERROR: User-Name (host/dti-dahport) is not the same as MS-CHAP Name (dti-dahport$) from EAP-MSCHAPv2 On 12-02-09 12:32 PM, Francois Gaudreault wrote:
Interesting. Let me give it a shot and see how it goes.
Thanks!
On 12-02-09 12:19 PM, Phil Mayers wrote:
On 09/02/12 16:42, Alan DeKok wrote:
The issue could be somewhere else. From what I recall, host authentication is... weird. The name in the MS-CHAP blob might *not* be the same as the User-Name field. If that happens, the calculated response using the User-Name will be wrong.
Looking at the code in rlm_mschap, it seems clearly to be wrong for host-based (non ntlm_auth) cases; it basically does:
1. Look for MS-CHAP-User-Name (this was added to make EAP-MSCHAPv2 work) 2. Otherwise, look for User-Name; if with_ntdomain_hack is set, strip leading DOMAIN\
Code for converting host/name.domain to name$ is absent here.
As you've suggested, setting MS-CHAP-User-Name to name$ will probably make it work. Ironically, since the mschap xlat function *DOES* handle this case, setting:
update request { MS-CHAP-User-Name := "%{mschap:User-Name}" }
...will work!
TBH I wonder if this code should be entirely reworked for 3.0; it might be better to set MS-CHAP-User-Name in the "authorize" section (unless already set e.g. by rlm_eap_mschapv2) so that it's ready for use in authenticate.
We could take the opportunity to handle user@domain too. AFAIK the formats we should handle are:
bareuser DOMAIN\user user@domain.com host/name.domain.com
Problem being, I'm wary of fiddling with this code; it's been arrived at with years of testing, and it's not impossible something would break, or some security hole be opened up... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
On 02/09/2012 07:55 PM, Francois Gaudreault wrote:
Doing the MS-CHAP-User-Name change got me this error :
mschapv2] # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel [mschapv2] +- entering group MS-CHAP {...} [mschap] Found NT-Password [mschap] ERROR: User-Name (host/dti-dahport) is not the same as MS-CHAP Name (dti-dahport$) from EAP-MSCHAPv2
Ah, of course. I think you're going to need to rewrite the User-Name attribute instead; that check is there to prevent clients sending a User-Name that differed from the MS-CHAP value, and circumventing authorization checks. I will try to come up with a patch that does all this properly later today, but this should work: authorize { ... if (User-Name =~ /^host\/([^.]+)/) { update request { User-Name := "%{1}$" } } ... } Note to the archives: This is NOT GENERAL ADVICE. This advice is specific to the issue Francois is facing (performing machine auth with access to the NT-Password, as opposed to via Active Directory)
Hi Phil, Still no go. Now EAP complains : pap] Config already contains "known good" password. Ignoring Password-With-Header [pap] Normalizing NT-Password from hex encoding [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop ++? if (User-Name =~ /^host\/([^.]+)/) ? Evaluating (User-Name =~ /^host\/([^.]+)/) -> TRUE ++? if (User-Name =~ /^host\/([^.]+)/) -> TRUE ++- entering if (User-Name =~ /^host\/([^.]+)/) {...} expand: %{1}$ -> dti-dahport$ +++[request] returns noop ++- if (User-Name =~ /^host\/([^.]+)/) returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel +- entering group authenticate {...} [eap] Identity does not match User-Name, setting from EAP Identity. [eap] Failed in handler ++[eap] returns invalid Failed to authenticate the user. I tried to put the blob before eap in authorize or after, but the result is the same. It breaks when entering the authenticate section. On 12-02-10 4:52 AM, Phil Mayers wrote:
On 02/09/2012 07:55 PM, Francois Gaudreault wrote:
Doing the MS-CHAP-User-Name change got me this error :
mschapv2] # Executing group from file /etc/raddb/sites-enabled/packetfence-tunnel [mschapv2] +- entering group MS-CHAP {...} [mschap] Found NT-Password [mschap] ERROR: User-Name (host/dti-dahport) is not the same as MS-CHAP Name (dti-dahport$) from EAP-MSCHAPv2
Ah, of course.
I think you're going to need to rewrite the User-Name attribute instead; that check is there to prevent clients sending a User-Name that differed from the MS-CHAP value, and circumventing authorization checks.
I will try to come up with a patch that does all this properly later today, but this should work:
authorize { ... if (User-Name =~ /^host\/([^.]+)/) { update request { User-Name := "%{1}$" } } ... }
Note to the archives: This is NOT GENERAL ADVICE. This advice is specific to the issue Francois is facing (performing machine auth with access to the NT-Password, as opposed to via Active Directory) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
On 10/02/12 14:36, Francois Gaudreault wrote:
Hi Phil,
Still no go. Now EAP complains :
[eap] Identity does not match User-Name, setting from EAP Identity.
Oh dear... I'll need to test this, but I have a horrible feeling you're between a rock & hard place here - EAP identity check is designed to stop mangling User-Name, mschap is hard-coded to stop you mangling MS-CHAP-User-Name... I think it'll need a source code patch, but will try to test it.
participants (4)
-
Alan Buxey -
Alan DeKok -
Francois Gaudreault -
Phil Mayers