Kyle Plimack wrote:

I have pap working (i.e. I ran radtest and got an access-accept). I don’t want to configure certs on each of my hosts for each of my clients, so I’d like to use PEAP/msChapV2 so that dot1x clients are prompted for and username/password.

According the the deployingradius.com guide, once pap is working, mschapv2 should “just work”. It doesn’t.

Your debug output shows you are using PEAP. That is *not* MSCHAPv2.

I’ve put the log on pastebin where it is formatted in a more friendly way http://pastebin.com/9tSjQW1f

You have added "ldap" to the "inner-tunnel" section. That's good. You haven't read the WARNING in the debug output, as pointed out by John. That's bad. The server NEEDS a "known good" password in order to authenticate the user. The LDAP server didn't supply one. Ensure that that LDAP server returns a password. It *will* work. This problem has come up many, many, times before. The solution is always the same: what we already told you. Alan DeKok.

Doing an ldapsearch put me on the right track, I had created a user 'radiusd', but that user did not have the rights to request the userPassword. The error I am getting now is: Found Auth-Type = EAP +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [mschapv2] +- entering group MS-CHAP {...} [mschap] Told to do MS-CHAPv2 for kplimack with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject I added an entry to ldap.attrmap, "checkItem Cleartext-Password userPassword" The Password is not cleartext, but I read somewhere that radius is supposed to figure that out automatically from a header. This is what is returned: rlm_ldap: userPassword -> Cleartext-Password == "{SSHA}xQjX16XbCUSXpiR2y****************" Full Log: http://pastebin.com/ZJuPsyrb On 6/18/10 7:14 AM, "John Dennis" <jdennis@redhat.com> wrote: On 06/18/2010 02:01 AM, Alan DeKok wrote:

Kyle Plimack wrote:

...

I have pap working (i.e. I ran radtest and got an access-accept). I don't want to configure certs on each of my hosts for each of my clients, so I'd like to use PEAP/msChapV2 so that dot1x clients are prompted for and username/password.

According the the deployingradius.com guide, once pap is working, mschapv2 should "just work". It doesn't.

Your debug output shows you are using PEAP. That is *not* MSCHAPv2.

...

I've put the log on pastebin where it is formatted in a more friendly way http://pastebin.com/9tSjQW1f

You have added "ldap" to the "inner-tunnel" section. That's good. You haven't read the WARNING in the debug output, as pointed out by John. That's bad.

The server NEEDS a "known good" password in order to authenticate the user. The LDAP server didn't supply one. Ensure that that LDAP server returns a password. It *will* work.

Do an ldapsearch on the command line for the user to see what is getting returned to radius. Look for the password attributes, are they there? Is there a cleartext password rather than just hashes? Does the cleartext password attribute in ldap match the password attribute in your radius ldap config (by default it's userPassword). Does your /etc/raddb/ldap.attrmap file have this line? checkItem Cleartext-Password userPassword Don't forget to put an ACL on the password attributes in ldap, you don't want others to be able to read them! If you don't want to store cleartext passwords you'll need to restrict the protocols you support. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

So how do I get pap to do it? On 6/18/10 12:50 PM, "Alan DeKok" <aland@deployingradius.com> wrote: Kyle Plimack wrote:

I added an entry to ldap.attrmap, "checkItem Cleartext-Password userPassword" The Password is not cleartext, but I read somewhere that radius is supposed to figure that out automatically from a header. This is what is returned:

rlm_ldap: userPassword -> Cleartext-Password == "{SSHA}xQjX16XbCUSXpiR2y****************"

It is impossible to do MS-CHAP with SSHA passwords. http://deployingradius.com/documents/protocols/compatibility.html Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On 06/18/2010 04:03 PM, Kyle Plimack wrote:

So how do I get pap to do it?

If you're asking how to you get pap to do mschap then that's a nonsensical question. Here is how things work: The client sends you a radius auth request, you don't get to decide what's in it, the client does. The radius server looks the request and says "hmmm... lets see what do we have here? What can I do with this?" The answer to that is what auth types you have enabled, what the server can lookup, and what's in the request. The server will do something like this: "Yo unix module, can you handle this one?" "Hey pap module, can you handle this one?" "Yo mschap module, can you handle this one?" At some point hopefully one of the modules will say: "No problem I got it" The decision as to whether a module can handle the request is made by the module by looking at the data available to it. So lets say the client sends a request with a password and you've got pap enabled. The pap module looks at the request and says "hmmm ... do I have a password for this user" if so then compare my copy of the password to what's in the request. How does radius find a user's password? By consulting it's backend data store which can be the users file, a SQL database, or ldap. So before the pap module runs ldap will run. ldap says "hmm... Can I find passwords for this user?" If so I'll add them to the request as a check item so my dear friend the pap module can use them, you know that pap guy, he's always looking for passwords. But WAIT! What if the client sends a MSCHAP request? What does the radius server say then? "Well that's a fine kettle of fish! That client has really really tied my hands on this one" The only thing the server can do is run the mschap logic. The mshap module looks the request to see if there is a check item with either a clear text password or nt-hash (why? look at the protocol table). If those haven't been added by one of the datastores the mschap module says: "Sorry boss, no can do" But now the server has run out of options, it's only choice was mschap because that's what the client sent it and the mscap module can't handle it. So the server replies: "Loser! You ain't getting in here with those credentials" (Well really Auth-Reject) -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/

So I gave in and connected radius to my active directory (which we wish we could get rid of). I'm getting the following error now Any thoughts on correcting this winbind error? [mschapv2] +- entering group MS-CHAP {...} [mschap] NT Domain delimeter found, should we have enabled with_ntdomain_hack? [mschap] Told to do MS-CHAPv2 for VIDEOEGG\kplimack with NT-Password [mschap] expand: %{Stripped-User-Name} -> [mschap] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [mschap] expand: %{User-Name:-None} -> VIDEOEGG\kplimack [mschap] expand: --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} -> --username=VIDEOEGG\kplimack [mschap] expand: %{mschap:NT-Domain} -> VIDEOEGG [mschap] expand: --domain=%{%{mschap:NT-Domain}:-VIDEOEGG} -> --domain=VIDEOEGG [mschap] mschap2: a0 [mschap] NT Domain delimeter found, should we have enabled with_ntdomain_hack? [mschap] expand: --challenge=%{mschap:Challenge:-00} -> --challenge=f83a0b16419a7f71 [mschap] expand: --nt-response=%{mschap:NT-Response:-00} -> --nt-response=fa180186e7d362c5ee57c6c776619d4d72173918ebc17b93 Exec-Program output: Reading winbind reply failed! (0xc0000001) Exec-Program-Wait: plaintext: Reading winbind reply failed! (0xc0000001) Exec-Program: returned: 1 [mschap] External script failed. [mschap] FAILED: MS-CHAP2-Response is incorrect On 6/18/10 1:54 PM, "Arran Cudbard-Bell" <a.cudbardb@googlemail.com> wrote: That has to go in the wiki somewhere. That's possibly the best explanation of how FreeRADIUS processes requests I've ever heard... :) -Arran On Jun 18, 2010, at 1:50 PM, John Dennis wrote:

On 06/18/2010 04:03 PM, Kyle Plimack wrote:

...

So how do I get pap to do it?

If you're asking how to you get pap to do mschap then that's a nonsensical question.

Here is how things work:

The client sends you a radius auth request, you don't get to decide what's in it, the client does.

The radius server looks the request and says

"hmmm... lets see what do we have here? What can I do with this?"

The answer to that is what auth types you have enabled, what the server can lookup, and what's in the request.

The server will do something like this:

"Yo unix module, can you handle this one?"

"Hey pap module, can you handle this one?"

"Yo mschap module, can you handle this one?"

At some point hopefully one of the modules will say:

"No problem I got it"

The decision as to whether a module can handle the request is made by the module by looking at the data available to it.

So lets say the client sends a request with a password and you've got pap enabled. The pap module looks at the request and says

"hmmm ... do I have a password for this user"

if so then compare my copy of the password to what's in the request.

How does radius find a user's password? By consulting it's backend data store which can be the users file, a SQL database, or ldap.

So before the pap module runs ldap will run. ldap says

"hmm... Can I find passwords for this user?" If so I'll add them to the request as a check item so my dear friend the pap module can use them, you know that pap guy, he's always looking for passwords.

But WAIT! What if the client sends a MSCHAP request? What does the radius server say then?

"Well that's a fine kettle of fish! That client has really really tied my hands on this one" The only thing the server can do is run the mschap logic.

The mshap module looks the request to see if there is a check item with either a clear text password or nt-hash (why? look at the protocol table). If those haven't been added by one of the datastores the mschap module says:

"Sorry boss, no can do"

But now the server has run out of options, it's only choice was mschap because that's what the client sent it and the mscap module can't handle it. So the server replies:

"Loser! You ain't getting in here with those credentials" (Well really Auth-Reject)

-- John Dennis <jdennis@redhat.com>

Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

John Dennis wrote:

On 06/18/2010 04:03 PM, Kyle Plimack wrote:

...

So how do I get pap to do it?

If you're asking how to you get pap to do mschap then that's a nonsensical question.

Here is how things work:

http://wiki.freeradius.org/Concepts Nice discussion, thanks. Alan DeKok.

On 06/18/2010 02:11 PM, Kyle Plimack wrote:

Doing an ldapsearch put me on the right track, I had created a user ‘radiusd’, but that user did not have the rights to request the userPassword.

The error I am getting now is:

Found Auth-Type = EAP +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [mschapv2] +- entering group MS-CHAP {...} [mschap] Told to do MS-CHAPv2 for kplimack with NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject

I added an entry to ldap.attrmap, “checkItem Cleartext-Password userPassword” The Password is not cleartext, but I read somewhere that radius is supposed to figure that out automatically from a header. This is what is returned:

rlm_ldap: userPassword -> Cleartext-Password == "{SSHA}xQjX16XbCUSXpiR2y****************"

That's not a clear text password is it? You can't do MSCHAP with SHA1. Please look at: http://deployingradius.com/documents/protocols/compatibility.html Which password type is compatible with *all* authentication mechanisms? Which will work with SHA1? If you have multiple password attributes in ldap per user, for instance different hashes and hopefully a cleartext then set the userPassword attribute in ldap.attrmap to User-Password and enable auto_header in the ldap module config. The ldap will read *every* password attribute defined for the user and map them passed on the {} prefix. In the above case your prefix was {SSHA} do rlm_ldap will map that to PW_SSHA_PASSWORD. But you already know from reading the protocol table it won't work with MSCHAP, right? Which type of password works with everything? Look at the table. What works with MSCHAP? Look at the table. Now, go back and add the necessary password attributes to your ldap. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/