PEAP/EAP-MSCHAPv2 with OpenLDAP
Hello, I have FreeRadius 3 and OpenLDAP and I want to use PEAP + EAP-MSCHAPv2 for authentication. I have NT-hash stored in a custom LDAP attribute. I am still finding contradicting information whether that setup is supported. Is it? If so, is NT-hash == MD4(user_password)? Is there a good guide/manual which exaplains all steps needed for get it working? Thanks. Mary Ann H.
I have FreeRadius 3 and OpenLDAP and I want to use PEAP + EAP-MSCHAPv2 for authentication. I have NT-hash stored in a custom LDAP attribute.
I am still finding contradicting information whether that setup is supported. Is it? If so, is NT-hash == MD4(user_password)?
Not quite, it's the password converted to UTF16-LE encoding and then run through MD4. https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/src/modules/rlm_... There's a helpful utility called smbcrypt which is built at part of the server: https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/src/modules/rlm_... you could probably use that to create the hashes. The steps would be: - Modify LDAP ACLs so only the RADIUS user can read your custom LDAP attribute (it's pretty much as good as cleartext because MD4 is very much broken). - Add an entry in the user mapping to map <your custom password attr> := &control:NT-Password https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-avail... - Call LDAP in the inner tunnel server to set the password attributes. -Arran
Well, it's not as easy as one might think. I am getting this error: NT-Password found but incorrect length, expected 16 bytes got 40 bytes. Authentication may fail MD4 hash has 32 characters, it's hex number so that means 2 characters = 1 byte. 32 / 2 = 16 bytes and this "length" is expected. Another 8 bytes (32 + 8 = 40) is header {nthash} with curled brackets including. I've tried {nt} header and blank header with no success. It seems that FreeRadius interprets value in my custom LDAP attribute as plain text not hex number. LDAP attribute is type "text". Custom LDAP attribute contains text value E217DE3A51C1329B751A28B9792F42DB. There was a thread about similar problem https://github.com/FreeRADIUS/freeradius-server/issues/679 I use FreeRadius 3.0.4 from CentOS 7 with backported fixes from upstream. ldap : User object found at DN "uid=112,ou=users,dc=tga,dc=net" (8) ldap : Processing user attributes (8) ldap : control:NT-Password := 0x7b6e747d4532313744453341353143313332394237353141323842393739324634324442 rlm_ldap (ldap): Released connection (9) (8) [ldap] = ok (8) [expiration] = noop (8) [logintime] = noop (8) } # authorize = updated (8) Found Auth-Type = EAP (8) # Executing group from file /etc/raddb/sites-enabled/tga (8) authenticate { (8) eap : Expiring EAP session with state 0xe671e8cee679f217 (8) eap : Finished EAP session with state 0xe671e8cee679f217 (8) eap : Previous EAP request found for state 0xe671e8cee679f217, released from the list (8) eap : Peer sent method MSCHAPv2 (26) (8) eap : EAP MSCHAPv2 (26) (8) eap : Calling eap_mschapv2 to process EAP data (8) eap_mschapv2 : # Executing group from file /etc/raddb/sites-enabled/tga (8) eap_mschapv2 : Auth-Type MS-CHAP { (8) WARNING: mschap : No Cleartext-Password configured. Cannot create LM-Password (8) WARNING: mschap : NT-Password found but incorrect length, expected 16 bytes got 32 bytes. Authentication may fail (8) WARNING: mschap : No Cleartext-Password configured. Cannot create NT-Password (8) mschap : Creating challenge hash with username: 112 (8) mschap : Client is using MS-CHAPv2 (8) ERROR: mschap : FAILED: No NT/LM-Password. Cannot perform authentication (8) ERROR: mschap : MS-CHAP2-Response is incorrect On Wed, Aug 2, 2017 at 10:17 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
I have FreeRadius 3 and OpenLDAP and I want to use PEAP + EAP-MSCHAPv2 for authentication. I have NT-hash stored in a custom LDAP attribute.
I am still finding contradicting information whether that setup is supported. Is it? If so, is NT-hash == MD4(user_password)?
Not quite, it's the password converted to UTF16-LE encoding and then run through MD4.
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/ src/modules/rlm_pap/rlm_pap.c#L995
There's a helpful utility called smbcrypt which is built at part of the server:
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/ src/modules/rlm_mschap/smbencrypt.c
you could probably use that to create the hashes.
The steps would be:
- Modify LDAP ACLs so only the RADIUS user can read your custom LDAP attribute (it's pretty much as good as cleartext because MD4 is very much broken). - Add an entry in the user mapping to map <your custom password attr> := &control:NT-Password
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/ raddb/mods-available/ldap#L116
- Call LDAP in the inner tunnel server to set the password attributes.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Aug 3, 2017, at 12:33 PM, mr mh1113 <mrmh1113@gmail.com> wrote:
Well, it's not as easy as one might think.
I am getting this error: NT-Password found but incorrect length, expected 16 bytes got 40 bytes. Authentication may fail
If you want it to "just work" your password value should be a binary type with no header. If you'd rather work around your issues... ldap if (control:NT-Password =~ /^{.*}(.*)/) { update control { NT-Password := "0x%{1}" } }
MD4 hash has 32 characters, it's hex number so that means 2 characters = 1 byte. 32 / 2 = 16 bytes and this "length" is expected. Another 8 bytes (32 + 8 = 40) is header {nthash} with curled brackets
The rest of the server knows nothing about LDAP's predilection for hash prefixes.
including. I've tried {nt} header and blank header with no success. It seems that FreeRadius interprets value in my custom LDAP attribute as plain text not hex number. LDAP attribute is type "text".
Yes.
Custom LDAP attribute contains text value E217DE3A51C1329B751A28B9792F42DB.
No, it should contain the binary value.
There was a thread about similar problem https://github.com/FreeRADIUS/freeradius-server/issues/679 I use FreeRadius 3.0.4 from CentOS 7 with backported fixes from upstream.
I'd strongly recommend using 3.0.15. http://packages.networkradius.com/centos/7/repo/ -Arran
On Aug 3, 2017, at 6:33 PM, mr mh1113 <mrmh1113@gmail.com> wrote:
Well, it's not as easy as one might think.
It should be simple if you use a recent version, and standard LDAP schemas. Despite various complaints, we *do* try to make it simple to configure the user.
MD4 hash has 32 characters, it's hex number so that means 2 characters = 1 byte. 32 / 2 = 16 bytes and this "length" is expected. Another 8 bytes (32 + 8 = 40) is header {nthash} with curled brackets
No... that's not an NT password. That's an NT password with magic LDAP crap pre-pended to it.
including. I've tried {nt} header and blank header with no success.
How about no header?
It seems that FreeRadius interprets value in my custom LDAP attribute as plain text not hex number.
So... you created a custom LDAP attribute / schema, and are surprised that FreeRADIUS doesn't magically figure out what you mean?
LDAP attribute is type "text".
Custom LDAP attribute contains text value E217DE3A51C1329B751A28B9792F42DB.
Then pass that text value directly into the NT-Password attribute. It *will* work. If the hash you give above is 32 characters long, and FreeRADIUS expects a 32-character hash... then it should be straightforward to connect the two.
There was a thread about similar problem https://github.com/FreeRADIUS/freeradius-server/issues/679 I use FreeRadius 3.0.4 from CentOS 7 with backported fixes from upstream.
Use 3.0.15. Please. 3.0.4 is *years* out of date. Alan DeKok.
It seems that FreeRadius interprets value in my custom LDAP attribute as plain text not hex number.
So... you created a custom LDAP attribute / schema, and are surprised that FreeRADIUS doesn't magically figure out what you mean?
Can't you feel the love!
LDAP attribute is type "text".
Custom LDAP attribute contains text value E217DE3A51C1329B751A28B9792F42DB.
Then pass that text value directly into the NT-Password attribute. It *will* work.
Not quite, still needs the 0x prefix to be treated as a hex string.
If the hash you give above is 32 characters long, and FreeRADIUS expects a 32-character hash
*16 character. I suppose we *could* add the auto-conversion heuristics to rlm_mschap. Anyone want to take that on? Copy paste code from rlm_pap? -Arran
On 3 August 2017 21:13:14 BST, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I suppose we *could* add the auto-conversion heuristics to rlm_mschap. Anyone want to take that on? Copy paste code from rlm_pap?
It's messy enough already in rlm_pap, moving it out somewhere else might be nicer? rlm_heuristicstofixupbrokenpasswords -- Matthew
hi,
I use FreeRadius 3.0.4 from CentOS 7 with backported fixes from upstream.
just to note - is this the CentOS provided 3.0.4 ? - if so, there are only some select fixes (security ones mainly) from upstream) - certainly not all the fixes and features - otherwise they'd just be providing you with 3.0.15 - you should just get 3.0.15 installed yourself, there really is no value to the RPM :( alan
new password module that has various options to deal with formatting/conversion etc? could then just call it in authorise after pap/ldap etc. alan On 5 August 2017 at 17:16, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
I use FreeRadius 3.0.4 from CentOS 7 with backported fixes from upstream.
just to note - is this the CentOS provided 3.0.4 ? - if so, there are only some select fixes (security ones mainly) from upstream) - certainly not all the fixes and features - otherwise they'd just be providing you with 3.0.15 - you should just get 3.0.15 installed yourself, there really is no value to the RPM :(
alan
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
mr mh1113