Alan:

The supplicant is sending a certificate that the server doesn't recognize. I have turned off everything I can find on the windows box about verifying certs and the like but still no joy. Is there a way to tell the FreeRADIUS box to accept the cert?

What "strange things" show up in the log? Is it a secret? No, no secrets just the following weirdness:

rad_recv: Access-Request packet from host 10.11.30.5 port 32853, id=253, length=164 User-Name = "umhb\\test1" NAS-IP-Address = 10.11.30.5 NAS-Port = 641 Called-Station-Id = "00-0F-7D-09-73-20:Temp" Calling-Station-Id = "00-17-C4-F0-75-C8" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 1Mbps/36Mbps 802.11g" EAP-Message = 0x0200000f01756d68625c7465737431 Message-Authenticator = 0x149047682e6d36b8bc634cfa08e39088 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_perl: Added pair NAS-Port-Type = Wireless-802.11 rlm_perl: Added pair Calling-Station-Id = 00-17-C4-F0-75-C8 rlm_perl: Added pair Called-Station-Id = 00-0F-7D-09-73-20:Temp rlm_perl: Added pair Message-Authenticator = 0x149047682e6d36b8bc634cfa08e39088 rlm_perl: Added pair User-Name = umhb\\test1 rlm_perl: Added pair EAP-Message = 0x0200000f01756d68625c7465737431 rlm_perl: Added pair Connect-Info = CONNECT 1Mbps/36Mbps 802.11g rlm_perl: Added pair NAS-IP-Address = 10.11.30.5 rlm_perl: Added pair NAS-Port = 641 rlm_perl: Added pair Framed-MTU = 1400 ++[perl] returns ok [suffix] No '@' in User-Name = "umhb\ est11", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 15 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = EAP +- 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. Login incorrect: [umhb\\\test1] (from client Sanderford port 641 cli 00-17-C4-F0-75-C8) Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> umhb\ est11 attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 56 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 56 Sending Access-Reject of id 253 to 10.11.30.5 port 32853 Waking up in 4.9 seconds. Cleaning up request 56 ID 253 with timestamp +14627 ------------------------------------- The user (me) types in umhb\test1, but for some reason the server sees umhb\\test1 which gets expanded into umhb\ est11. There is even a umhb\\\test1 in there! I know this has got to be a MS thing as it works perfectly with Linux .. probably mac too as they are linux based. Jake Sallee Godfather Of Bandwidth Network Engineer Fone: 254-295-4658 Phax: 254-295-4221

Thanks for the info, I have the client setup the way you suggest, in Win 7 almost everything you said were defaults. However I still get the unknown CA problem. Does anyone know how I can tell the FreeRADIUS server to accept the client cert automatically? Jake Sallee Godfather Of Bandwidth Network Engineer 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.o rg] On Behalf Of Alan Buxey Sent: Monday, August 02, 2010 5:59 PM To: FreeRadius users mailing list Subject: Re: windows users having trouble authenticating hi, wierd output due to special character.... \t, \r , \n all did similar things in the output (latest version has fixed for this). issue with windows is to do with certs etc. you need to configure the supplicant to use PEAP, not to use the windows login, if you havent sorted out certs, then you need to not check any radius server ot tick anything..and not have the 'do not prompt for new certs' etc unticked. best to put the CA that the RADIUS server was signed with onto the host (in trusted CA local root store). alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Sallee, Stephen (Jake) wrote:

I am still getting this error in my debug output:

rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

I have upgraded to version 2.1.8+dfsg-1ubuntu1, still no joy!

No amount of upgrading FreeRADIUS will make it work. This message comes because (a) the supplicant has a client certificate issued by a CA unknown to FreeRADIUS, or (b) the supplicant is telling FreeRADIUS that the servers CA is unknown to the client.

PLEASE someone tell me how to make FreeRADIUS automatically accept the client cert.

PEAP doesn't work like that. If you issued client certs, then FreeRADIUS *MUST* be configured to know about the CA.

I have about 2 thousand clients that are not owned by my university, I cannot install the server cert on all of them, the logistics are too much. PLEASE HELP!

We're trying. We're asking you to listen to our responses. PEAP (or any TLS based EAP method) *cannot* do what you ask. It's impossible, and it was designed to be impossible by the people who created the cryptography algorithms. If you want to have it work, then (a) configure FreeRADIUS to know about the CA that issued the client cert, or (b) put the FreeRADIUS cert/CA on a web site, for the clients to download themselves. I understand what you want, but please understand that there are limitations to the protocols *independent* of FreeRADIUS. Alan DeKok.

Sallee, Stephen (Jake) wrote:

Thank you for your response, I think I finally know what is going on. I need to get a real cert from my FreeRADIUS Server, any sugestions about which vendor, IE Verisign vs thawte vs ?

Nope.

I was under the impression that the clients was sending a cert to the server and the server was rejecting it, instead it seems that the clients are rejecting the server.

Using a known root CA for RADIUS authentication isn't really recommended. But if it solves the problem... And you'll need to make sure that the cert you get has the correct OIDs in it. See eap.conf. Alan DeKok.

John Dennis wrote:

On 08/03/2010 01:30 PM, Alan DeKok wrote:

...

Using a known root CA for RADIUS authentication isn't really recommended.

Why?

P.S. just to clarify, it's not "using a known root CA for RADIUS authentication", rather it's using a server cert signed by a known root CA.

Sure. It's because *anyone* can set up an AP, and a RADIUS server that your PC will accept. If the AP has the same SSID as (say) your work, it will happily send your work username && login via EAP to the rogue AP. The various EAP methods *should* have tied usernames (i.e. domains) to a field in the certificate. e.g. a cert with CN "radius@example.com" should be sent logins for "user@example.com", but NEVER sent logins for "user@example.net" You should ONLY send your login credentials when you *know* who it is on the other end of the EAP conversation. Alan DeKok.

Sallee, Stephen (Jake) wrote:

...

The various EAP methods *should* have tied usernames (i.e. domains) to a field in the certificate. e.g. a cert with CN "radius@example.com" should be sent logins for "user@example.com", but NEVER sent logins for "user@example.net"

How does this workout with child domains? For example: I have two domains 1) umhb.edu and 2) Cru.umhb.edu. "Cru" is a child of "umhb.edu", if I get a single cert for FreeRADIUS.umhb.edu will it be ok for authenticating users on both umhb.edu AND Cru.umhb.edu?

I said it SHOULD have been that way. It doesn't work that way now. There is NO tying of certificate CNs to user names. Alan DeKok.

Alan DeKok wrote:

John Dennis wrote:

...

On 08/03/2010 01:30 PM, Alan DeKok wrote:

...

Using a known root CA for RADIUS authentication isn't really recommended. Why?

P.S. just to clarify, it's not "using a known root CA for RADIUS authentication", rather it's using a server cert signed by a known root CA.

Sure.

It's because *anyone* can set up an AP, and a RADIUS server that your PC will accept. If the AP has the same SSID as (say) your work, it will happily send your work username && login via EAP to the rogue AP.

The level of risk here varies depending on the EAP method. If you are using EAP-TLS, the server only gets a copy of the certificate so there is no risk of him stealing your credentials. With EAP-PEAP/MSCHAPv2 I believe the attacker can get enough information to perform a dictionary attack against your password which depending on it's strength may or may not be a problem (I'm not certain about this one if somebody else wants to chime in). And then there is EAP-TTLS where the rogue server will end up with a cleartext copy of the username and password if the user can be tricked into accepting the servers certificate.

The various EAP methods *should* have tied usernames (i.e. domains) to a field in the certificate. e.g. a cert with CN "radius@example.com" should be sent logins for "user@example.com", but NEVER sent logins for "user@example.net"

You should ONLY send your login credentials when you *know* who it is on the other end of the EAP conversation.

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

-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------