Please forgive the interjection, but does anyone know of a helper module like ntlm_auth that would work with LDAP, seems like such a tool would make questions like this a non-issue. Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 -----Original Message----- From: freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org [mailto:freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org] On Behalf Of Sven Hartge Sent: Thursday, November 10, 2011 5:24 PM To: freeradius-users@lists.freeradius.org Subject: Re: LDAP/MSCHAP Whitlow, Michael <mwhitlow@bumail.bradley.edu> wrote:

I am really close to a successful Freeradius implementation for 802.1X wireless using LDAP authentication on the back end.

Nope, you are not very close. You _cannot_ use any LDAP authentication (via binding with a DN to the LDAP server) with any CHAP authentication. This will never work. You cannot use LDAP as an authentication oracle here, you have to use it more like a database. See http://deployingradius.com/documents/protocols/oracles.html, quote: "An authentication oracle is a system where the RADIUS server does not perform the authentication itself, but instead passes the users authentication credentials to another system. " This does NOT work with MSCHAP, since the RADIUS server _does not have_ the complete authentication credentials in this case, it is missing the password. The only thing it has, is the hashed version, the so called "challenge".

Here is what I have:

- RADTEST / clear text Freeradius password from "users" file / WORKS GREAT

Works because of the cleartext password.

- Windows XP 802.1X PEAP/MS-CHAPv2 wireless client / clear text Freeradius password from "users" file / WORKS GREAT

Works because of the cleartext password.

- RADTEST / LDAP credentials / WORKS GREAT

Works, because this uses PAP, which does _not_ need a cleartext password on the RADIUS server, because radtest supplies a cleartext password itself in the RADIUS packet (inside attribute User-Password) and the servers ldap modules then can use this information to bind to the LDAP server using the username and the supplied password from radtest. CHAP does _not_ work like this.

- Windows XP 802.1X PEAP/MS-CHAPv2 wireless client / LDAP credentials / NO GO

Does not work, because you don't have any cleartext password in the RADIUS server, because your LDAP setup does not provide one. And before you ask: no, just reading userPassword from the LDAP server will not help, because in 99.9% this is a crypted password, mostly hashed using SHA1.

Here is the debug output. I have read others online with these symptoms but nothing I have found yet will help me.

This is untrue. This comes up every fscking time any one tries to use LDAP and MSCHAP. It is a common error.

[mschapv2] +- entering group MS-CHAP {...}

[mschap] No Cleartext-Password configured. Cannot create LM-Password.

[mschap] No Cleartext-Password configured. Cannot create NT-Password.

You will need to do the following: a) setup a special user inside your LDAP tree for freeradius. This special user needs to have the correct permissions to read an attribute with the cleartext password of any user. b) configure this special user in {confdir}/modules/ldap, search for "identity" c) change password_attribute to the cleartext-password attribute you are using if it is not userPassword. (I strongly recommend using a different password attribute for your users, but the default is OK too, if you don't mind having the main password for a user being in cleartext inside your LDAP tree.) This way FreeRADIUS logs into the LDAP server using its own credentials, searches for the username, reads the cleartext password and _THEN_ the mschapv2 module is able to work. This is the _only_ way to get MSCHAPv2 to work with LDAP. And this has been discussed in this list every time anyone tried to tie LDAP and FreeRADIUS. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

I agree with Jake, in that I *think* it would be possible to have a plugin or whatever interface with LDAP/AD in the same manner ntlm_auth does. I don't think one *needs* a cleartext password, but does need some way to compare apples-to-apples. That said, I don't know the inner workings of all the auth protocols involved here so I could be way off. Something tells me if it were easy/possible, Mr. DeKok would have likely written the plugin by now. ----- Original Message ----- From: Sven Hartge [mailto:sven@svenhartge.de] Sent: Thursday, November 10, 2011 06:18 PM To: freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org> Subject: Re: LDAP/MSCHAP "Sallee, Stephen (Jake)" <Jake.Sallee@umhb.edu> wrote:

Please forgive the interjection, but does anyone know of a helper module like ntlm_auth that would work with LDAP, seems like such a tool would make questions like this a non-issue.

No, will not work. You can't transform the normally used hashes back into a cleartext password. (This is kind of the whole point of a hash.) As long you don't have any means to provide FreeRADIUS with a cleartext password or the NT/LM-Hash, you are doomed. ntlm_auth just offloads the whole Challenge-Response exchange from the RADIUS server to the ActiveDirectory (as far as I understand it) using the ntlm_auth binary from Samba. Again: the AD will have to know the cleartext password in some way (either encrypted or somehow "pre-hashed") to make this work. (Don't know the specifics, I am a Unix guy, the only Windows near me is on my gaming computer.) Grüße, S° -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>

Am 11.11.2011 03:56, schrieb Fajar A. Nugraha:

On Fri, Nov 11, 2011 at 8:29 AM, Gary Gatten <Ggatten@waddell.com> wrote:

...

I agree with Jake, in that I *think* it would be possible to have a plugin or whatever interface with LDAP/AD in the same manner ntlm_auth does. I don't think one *needs* a cleartext password, but does need some way to compare apples-to-apples. That's exactly what Alan is saying: " store your passwords in the LDAP as NT-Password or LM-Password " But if that works, why then all are saying that you can just work with plaintext? Its realy confusing.

Andreas

... although in my expreiments NT-Password alone is enough, but LM-Password alone is useless.

How can you create NT-Password? One way to do that is by hijacking the process where user enters password as plaintext (e.g. from the password prompt when user change their password) and use smbencrypt (part of freeradius)

Where do you store NT-Password in LDAP? In ntPassword or sambaNtPassword LDAP attribute (or any other attribute of your choice, as long as you remember to update raddb/ldap.attrmap as well)

If you have NT-Password, then you don't need user's cleartext password anymore, and you don't even need any helper tool.

-- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQGNBE6jHfABDACyzFkn6k+OtbRANjKZ6NEQOxnnsBSBSs6sT9EBF0U3MnnYW3/p YTW+7aUa/1FZTOWt9wb9H7t0SOqpgqUBmRo/sPteepXblnDaGEh8tzIWfaC9MKc1 QobU5zK9KcDKrs3SyGXEPOOQM8QdtE8KfSJFdUxfanFJUbfTbxq5Gqz1eaU4cWxp gR6GeVYnd11J8AdDDwkjPjx4ZJ5guZ+D646Qi3CT7KT6y8sXVPwpNA3CvGweYX0r STKyBf+nlQtOtByrgZW7BiSAxilYUL4mGE4KmuYAadJ+O6X7NOtz3OQaWgSGjqxH YxDu6orTzL4/csjoVXS9dgeGkhLJgAg72a2yxA4tx/8IXrGp3JVGYGEY2kYcq3k9 jq5hJezoy6s1N//mgm5KaB84zrU5cUcu8kXDppmnp7eXUPnBqj2g2O82buBNa48S wAtnbY4K5fbcnog8g6ouYXpAJo9yHcj+wraQ8+TNFx5nbkg3fZKuf3UeyL3dPKXf wsKehnZ3Ipqkb08AEQEAAbQiQW5kcmVhcyBSdWRhdCA8cnVkYXRAZW5kc3RlbGxl LmRlPokBuAQTAQIAIgUCTqMd8AIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQBw5gh+kRIv+yGQv5AQCRZt8wR2McgsTurZEZXz5UpxEPZB/dA/iXtPzZXJih XLRZFqcdT+c8DCLbhXjO5aLndOCIDwWmsnqX2fuGAjlM4GJAAUEARSNtWY7V+rUt PhdOz/flCZo/+p7wBi0XOJcWhysS7DV/ssSYdnuJvONUBXCQ/MpJsVXuKdgPa9IR hvi37Ang1Cxb7htKHIuA4wCuqz1/4VGNez/65qwjuYakbB4/rXkKWb17XqCZrtoo YiQSxPU7fP5lM4ybQXxP1qrptmaF9EqGTnj/xAU3tCE+PhB3baoVw6VG9nr9xYwh bqCGtTbtrkmYlgioC2fFHDgg3U1GVBIbi0AoddXSs5OekgSvt827OcyWVSyjobyn tH4/jwb8X8iOM/x8RZhzwKhpHA0k7ltTm7qXApARcL1tV6y4GIKwuy1RLZqkpNh1 teqYaxAKlxC77s6gftxqr7G6NCssgCCy2Y50LSvcQbZDPZeBdrPoGI/xAWNy4Otv 33k4P9hxJKHNqLYJN+Gn =UaS9 -----END PGP PUBLIC KEY BLOCK-----

Andreas Rudat <rudat@endstelle.de> wrote:

Am 11.11.2011 03:56, schrieb Fajar A. Nugraha:

...

On Fri, Nov 11, 2011 at 8:29 AM, Gary Gatten <Ggatten@waddell.com> wrote:

...

...

I agree with Jake, in that I *think* it would be possible to have a plugin or whatever interface with LDAP/AD in the same manner ntlm_auth does. I don't think one *needs* a cleartext password, but does need some way to compare apples-to-apples. That's exactly what Alan is saying: " store your passwords in the LDAP as NT-Password or LM-Password "

But if that works, why then all are saying that you can just work with plaintext? Its realy confusing.

NT/LM-Password is "special". This is why it works with MSCHAPv2, both being a MicroSoft "invention". S° -- Sigmentation fault. Core dumped.

Am 12.11.2011 23:00, schrieb Sven Hartge:

Sven Hartge <sven@svenhartge.de> wrote:

...

Andreas Rudat <rudat@endstelle.de> wrote:

...

Am 11.11.2011 03:56, schrieb Fajar A. Nugraha:

...

On Fri, Nov 11, 2011 at 8:29 AM, Gary Gatten <Ggatten@waddell.com> wrote:

...

I agree with Jake, in that I *think* it would be possible to have a plugin or whatever interface with LDAP/AD in the same manner ntlm_auth does. I don't think one *needs* a cleartext password, but does need some way to compare apples-to-apples. That's exactly what Alan is saying: " store your passwords in the LDAP as NT-Password or LM-Password " But if that works, why then all are saying that you can just work with plaintext? Its realy confusing. NT/LM-Password is "special". This is why it works with MSCHAPv2, both being a MicroSoft "invention". To be precise: MSCHAPv2 works with the NT/LM-Password as input to the Challenge-Handshake and not the "raw" cleartext password. This is why this works.

FreeRADIUS converts a cleartext password into the needed NT-Hash and then applies this to the MSCHAPv2 handshake. Or it uses a pre-existing NT-Hash from LDAP/MySQL/whatever.

Quote from http://en.wikipedia.org/wiki/NTLM ,---- | The NTLM protocol uses one or both of two hashed password values, both | of which are also stored on the server (or domain controller), and which | are password equivalent, meaning that if you grab the hash value from | the server, you can authenticate without knowing the actual password. `----

This also means you have to protect those Hashes inside your database like a raw cleartext password, as you can authenticate to any Windows box with the knowledge of the NT/LM-Hash.

This has been exploitet by several Windows trojan horses, which grabbed to NT-Hash from the Administrator user to login into other boxes on the network using the same password (or worse: the domain controller).

Grüße, S Ah much thanks for that clearing, so both is bad no matter which mechnism is used.

Andreas -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQGNBE6jHfABDACyzFkn6k+OtbRANjKZ6NEQOxnnsBSBSs6sT9EBF0U3MnnYW3/p YTW+7aUa/1FZTOWt9wb9H7t0SOqpgqUBmRo/sPteepXblnDaGEh8tzIWfaC9MKc1 QobU5zK9KcDKrs3SyGXEPOOQM8QdtE8KfSJFdUxfanFJUbfTbxq5Gqz1eaU4cWxp gR6GeVYnd11J8AdDDwkjPjx4ZJ5guZ+D646Qi3CT7KT6y8sXVPwpNA3CvGweYX0r STKyBf+nlQtOtByrgZW7BiSAxilYUL4mGE4KmuYAadJ+O6X7NOtz3OQaWgSGjqxH YxDu6orTzL4/csjoVXS9dgeGkhLJgAg72a2yxA4tx/8IXrGp3JVGYGEY2kYcq3k9 jq5hJezoy6s1N//mgm5KaB84zrU5cUcu8kXDppmnp7eXUPnBqj2g2O82buBNa48S wAtnbY4K5fbcnog8g6ouYXpAJo9yHcj+wraQ8+TNFx5nbkg3fZKuf3UeyL3dPKXf wsKehnZ3Ipqkb08AEQEAAbQiQW5kcmVhcyBSdWRhdCA8cnVkYXRAZW5kc3RlbGxl LmRlPokBuAQTAQIAIgUCTqMd8AIbDwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQBw5gh+kRIv+yGQv5AQCRZt8wR2McgsTurZEZXz5UpxEPZB/dA/iXtPzZXJih XLRZFqcdT+c8DCLbhXjO5aLndOCIDwWmsnqX2fuGAjlM4GJAAUEARSNtWY7V+rUt PhdOz/flCZo/+p7wBi0XOJcWhysS7DV/ssSYdnuJvONUBXCQ/MpJsVXuKdgPa9IR hvi37Ang1Cxb7htKHIuA4wCuqz1/4VGNez/65qwjuYakbB4/rXkKWb17XqCZrtoo YiQSxPU7fP5lM4ybQXxP1qrptmaF9EqGTnj/xAU3tCE+PhB3baoVw6VG9nr9xYwh bqCGtTbtrkmYlgioC2fFHDgg3U1GVBIbi0AoddXSs5OekgSvt827OcyWVSyjobyn tH4/jwb8X8iOM/x8RZhzwKhpHA0k7ltTm7qXApARcL1tV6y4GIKwuy1RLZqkpNh1 teqYaxAKlxC77s6gftxqr7G6NCssgCCy2Y50LSvcQbZDPZeBdrPoGI/xAWNy4Otv 33k4P9hxJKHNqLYJN+Gn =UaS9 -----END PGP PUBLIC KEY BLOCK-----

I wanted to say thanks to everybody from this list who has given me a hand over the past few weeks. I have successfully configured Freeradius to authenticate 802.1X wireless clients from an AD domain and assign them the appropriate VLAN tag based on AD/LDAP group membership. Many thanks to everybody. -----Original Message----- From: freeradius-users-bounces+mwhitlow=bumail.bradley.edu@lists.freeradius.org [mailto:freeradius-users-bounces+mwhitlow=bumail.bradley.edu@lists.freeradius.org] On Behalf Of Sven Hartge Sent: Sunday, November 13, 2011 8:39 AM To: freeradius-users@lists.freeradius.org Subject: Re: LDAP/MSCHAP Andreas Rudat <rudat@endstelle.de> wrote:

Am 12.11.2011 23:00, schrieb Sven Hartge:

...

This also means you have to protect those Hashes inside your database like a raw cleartext password, as you can authenticate to any Windows box with the knowledge of the NT/LM-Hash.

This has been exploitet by several Windows trojan horses, which grabbed to NT-Hash from the Administrator user to login into other boxes on the network using the same password (or worse: the domain controller).

Ah much thanks for that clearing, so both is bad no matter which mechnism is used.

Yes. Storing the NT-Hash has the advantage of not completley exposing the cleartext password to a possible intruder. Storing the LM-Hash is just dumb, because a) it limits the the length of the password to 16 characters and b) LM-Hash is easily broken in seconds by todays computers. Storing the raw cleartext password is as bad, but it enables one to use other challange-handshake auths, if needed. I chose to store the raw cleartext password in LDAP, but in a different attribute than the normal userPassword. This way, if my LDAP servers ever get compromised (or I mess up with an ACL, enabling anyone to read the cleartext password), just the WLAN/Dialup-Password of a user is revealed and not the master password for the account, which is used for mail, login in to computers, etc. Grüße, Sven. -- Sigmentation fault. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Tue, Nov 15, 2011 at 01:58:25PM -0600, Whitlow, Michael wrote:

All,

I have one minor issue to ask the group about.

Using Freeradius to authenticate 802.1X wireless clients, I noticed that if I try to connect to the wireless network and I purposely put in a bad password I still get the popup to validate the server certificate.

On the other radius implementations I am used to the cert validation does not happen until after the user is authenticated. I imagine I have something configured not quite right but I don't know what.

So, in Freeradius is there a way to change it so the validate server certificate comes only after successfull authentication?

Thanks much,

Mike

If the server cert is bogus, you should not send any authentication information down a compromised connection. It sounds like it is functioning correctly now and was broken then. Cheers, Ken

On 11/11/2011 01:29 AM, Gary Gatten wrote:

I agree with Jake, in that I *think* it would be possible to have a plugin or whatever interface with LDAP/AD in the same manner ntlm_auth does. I don't think one *needs* a cleartext password, but

To quote from the other email I just sent: """ People wanting to do MSCHAP must have either: 1. The NT or LM hashes 2. The cleartext password, to generate the NT/LM hashes 3. Access to a system which will perform the MSCHAP crypto for them (i.e. a domain controller, access via samba/ntlm_auth) """ If you're talking about writing something that interfaces with Active Directory "in the same way" as ntlm_auth, you're essentially talking about writing a (presumably easier to setup/run than samba/ntlm_auth) program to do #3. However: I will note there's no evidence that the OP was using AD. He could have just been using a plain LDAP server.

does need some way to compare apples-to-apples. That said, I don't know the inner workings of all the auth protocols involved here so I could be way off. Something tells me if it were easy/possible, Mr. DeKok would have likely written the plugin by now.

As it happens, I do know the protocols and internal windows APIs, and did look into this a while back. It is *possible* but very tricky, and it's unclear to me it would be "easier" than samba/ntlm_auth. A few points: 1. You CANNOT access the required APIs remotely; you MUST be running as a local process on a windows domain controller. Thankfully there are other APIs which a domain member can call as an RPC which proxy to these APIs, but you need a domain machine account to call them (this is what Samba/ntlm_auth does) 2. The required APIs are very, very scantily documented 3. The required APIs ONLY permit you to perform the MSCHAP calculations; they don't give you access to any password hashes. So, basically you would end up with: 1. A C program, which you have to compile for windows, which calls the internal LSA APIs to perform an MSCHAP challenge/response 2. Which you then have to run on a windows server, which calls the RPC on your domain controllers (this is EXACTLY what Samba/ntlm_auth does) 3. Some kind of authentication to secure the FreeRADIUS -> program network comms I got about halfway through step 1 - the API calls were executing, but the call failed despite being passed a valid challenge/response. I assume there are some (more) undocumented API subtleties. Given the difficulties and awkwardness of the solution, I gave up and concluded people should just run Samba, or if they really can't tolerate that, run a dumb copy of IAS/NPS and proxy the MSCHAP/EAP-MSCHAP to that. Cheers, Phil

On 11/10/2011 11:36 PM, Sallee, Stephen (Jake) wrote:

Please forgive the interjection, but does anyone know of a helper module like ntlm_auth that would work with LDAP, seems like such a tool would make questions like this a non-issue.

MSCHAP is a challenge-response mechanism. To execute the cryptographic calculation, you MUST have access to the NT or LM hashes of the users password. It's unclear to me what kind of "helper" module you're envisaging; perhaps a USB-attached quantum computer that can crack the crypto in realtime ;o) In all seriousness - there's nothing to "help" here. People wanting to do MSCHAP must have either: 1. The NT or LM hashes 2. The cleartext password, to generate the NT/LM hashes 3. Access to a system which will perform the MSCHAP crypto for them (i.e. a domain controller, access via samba/ntlm_auth) This is by design - the cryptographic properties of MSCHAP were created intentionally to make this the case.