last hurdle...windows clients
freeradius-1.1.3-1.2.el5 I am authenticating Windows RRAS connections, Macintosh wifi, iPhone wifi all with LDAP and mschapv2 (using sambaNTPassword hashes in OpenLDAP) My users basically consists of... DEFAULT Auth-Type = LDAP eap.conf default_eap_type = mschapv2 and of course my certificates and LDAP setup which works for all the above authentications. My problem is Windows XP laptops (updated to SP3) and I have generated certificates for them. I have loaded both the CA and p12 certificates on a Windows client, set for WPA, TKIP, PEAP but it never asks me for a user name and password and thus always tries to authenticate as anonymous (log below)...even if I check the box to 'Automatically use my Windows name and password' - it still comes in as 'anonymous' Is there some thing else I need to add so that Windows also uses name/password or do I have something else in Auth-Type to just allow those with the certificates? How do I do this? I don't understand the message about unknown_ca in the log below either because I am acting as my own CA and this same cacert.pem seems to be happy on the Windows system I imported it on and I've been using it for a bunch of other daemons. Craig rad_recv: Access-Request packet from host 192.168.1.251:2050, id=112, length=172 User-Name = "anonymous" NAS-IP-Address = 192.168.1.251 NAS-Port = 0 Called-Station-Id = "00-21-29-E3-D1-8A" Calling-Station-Id = "00-04-23-62-BD-3D" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0288001119800000000715030100020230 State = 0xce80cf1b72bd9479de376550dc6d9052 Message-Authenticator = 0x90183570c2ef1940d04e9e5dc579a1bd Processing the authorize section of radiusd.conf modcall: entering group authorize for request 59 modcall[authorize]: module "preprocess" returns ok for request 59 modcall[authorize]: module "chap" returns noop for request 59 modcall[authorize]: module "mschap" returns noop for request 59 rlm_realm: No '@' in User-Name = "anonymous", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 59 rlm_eap: EAP packet type response id 136 length 17 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 59 users: Matched entry DEFAULT at line 156 modcall[authorize]: module "files" returns ok for request 59 rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(uid=anonymous)' radius_xlat: 'ou=People,ou=Accounts,o=MyOrg' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=People,ou=Accounts,o=MyOrg, with filter (uid=anonymous) rlm_ldap: object not found or got ambiguous search result rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns notfound for request 59 modcall: leaving group authorize (returns updated) for request 59 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 59 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept:failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca rlm_eap_tls: SSL_read failed inside of TLS (-1), TLS session fails. In SSL Handshake Phase In SSL Accept mode rlm_eap: SSL error error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure rlm_eap_tls: BIO_read failed in a system call (-1), TLS session fails. eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 59 modcall: leaving group authenticate (returns reject) for request 59 auth: Failed to validate the user.
I don't understand the message about unknown_ca in the log below either because I am acting as my own CA and this same cacert.pem seems to be happy on the Windows system I imported it on and I've been using it for a bunch of other daemons.
It probably wants cacert.der. Ivan Kalik Kalik Informatika ISP
On Sun, 2008-11-23 at 00:24 +0100, tnt@kalik.net wrote:
I don't understand the message about unknown_ca in the log below either because I am acting as my own CA and this same cacert.pem seems to be happy on the Windows system I imported it on and I've been using it for a bunch of other daemons.
It probably wants cacert.der.
OK - that quiets the notification but I still can't figure out the issue where I can authenticate RRAS, Macintosh and iPod clients against radius via LDAP using mschapv2 but even with the certificates on Windows XP clients, with the 'xpextensions' they always try to authenticate as 'uid=anonymous' and never ask me for name/password credentials to supply for authentication. Thus since my Default Auth Type = LDAP (in users), these clients always fail authentication. While I probably would agree that the certificates should be enough and not need the user/password authentication, I can't figure out how to tell radiusd to accept those with the certificates. Either way I would be happy...getting windows clients to provide username/password or getting radius to accept a client with the certificate. Craig
Craig White wrote:
OK - that quiets the notification but I still can't figure out the issue where I can authenticate RRAS, Macintosh and iPod clients against radius via LDAP using mschapv2 but even with the certificates on Windows XP clients, with the 'xpextensions' they always try to authenticate as 'uid=anonymous' and never ask me for name/password credentials to supply for authentication.
Then the supplicant is misconfigured.
While I probably would agree that the certificates should be enough and not need the user/password authentication, I can't figure out how to tell radiusd to accept those with the certificates.
No. PEAP does MS-CHAP for username/passwd authentication. If you want authentication via client certs, use TLS.
Either way I would be happy...getting windows clients to provide username/password or getting radius to accept a client with the certificate.
There's something else in your windows configuration that is making it *not* ask you for the username/password. Maybe it's cached in the registry. Alan DeKok.
On Sun, 2008-11-23 at 02:59 -0600, Alan DeKok wrote:
Craig White wrote:
OK - that quiets the notification but I still can't figure out the issue where I can authenticate RRAS, Macintosh and iPod clients against radius via LDAP using mschapv2 but even with the certificates on Windows XP clients, with the 'xpextensions' they always try to authenticate as 'uid=anonymous' and never ask me for name/password credentials to supply for authentication.
Then the supplicant is misconfigured.
While I probably would agree that the certificates should be enough and not need the user/password authentication, I can't figure out how to tell radiusd to accept those with the certificates.
No. PEAP does MS-CHAP for username/passwd authentication. If you want authentication via client certs, use TLS.
Either way I would be happy...getting windows clients to provide username/password or getting radius to accept a client with the certificate.
There's something else in your windows configuration that is making it *not* ask you for the username/password. Maybe it's cached in the registry.
HLCU\Software\Microsoft doesn't even have an EAPOL entry at all. fixed the cert issue but still it's trying to authenticate as anonymous ;-( I realize that freeradius has little control over the supplicant but I'm wondering if it's something in my setup of tls that the authentication should/shouldn't be part of the tunnel because it just assumes a login of anonymous instead of the Windows User/Password or never asks me for a User/Password... rad_recv: Access-Request packet from host 192.168.1.250:2054, id=168, length=161 User-Name = "anonymous" NAS-IP-Address = 192.168.1.250 NAS-Port = 0 Called-Station-Id = "00-21-29-E3-D1-84" Calling-Station-Id = "00-04-23-62-BD-3D" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x026300061900 State = 0x7de5407f2f55958f61578bc598c219a9 Message-Authenticator = 0x0682bd2213fba7b19656a91ac1454267 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 46 modcall[authorize]: module "preprocess" returns ok for request 46 modcall[authorize]: module "chap" returns noop for request 46 modcall[authorize]: module "mschap" returns noop for request 46 rlm_realm: No '@' in User-Name = "anonymous", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 46 rlm_eap: EAP packet type response id 99 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 46 users: Matched entry DEFAULT at line 156 modcall[authorize]: module "files" returns ok for request 46 rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(uid=anonymous)' radius_xlat: 'ou=People,ou=Accounts,o=MyOrg' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=People,ou=Accounts,o=MyOrg, with filter (uid=anonymous) rlm_ldap: object not found or got ambiguous search result rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns notfound for request 46 modcall: leaving group authorize (returns updated) for request 46 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 46 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Received EAP-TLS ACK message rlm_eap_tls: ack handshake fragment handler eaptls_verify returned 1 eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module "eap" returns handled for request 46 modcall: leaving group authenticate (returns handled) for request 46 Sending Access-Challenge of id 168 to 192.168.1.250 port 2054 EAP-Message = 0x0164040619400355040b130b4d61696e204f6666696365311a3018060355040313117777772e6d756c6c656e6164762e636f6d3121301f06092a864886f70d01090116126372616967406d756c6c656e70722e636f6d301e170d3038313132333030333435375a170d3138313132313030333435375a3081b8310b30090603550406130255533110300e060355040813074172697a6f6e613110300e0603550407130750686f656e69783130302e060355040a13274d756c6c656e204164766572746973696e6720616e64205075626c69632052656c6174696f6e7331143012060355040b130b4d61696e204f6666696365311a301806035504031311 EAP-Message = 0x7777772e6d756c6c656e6164762e636f6d3121301f06092a864886f70d01090116126372616967406d756c6c656e70722e636f6d30819f300d06092a864886f70d010101050003818d0030818902818100dbda8f2450e25378824b7184fd522e7bd89605a45bd721b4bb16b0d7dc11d400ffa95b3e42cb4f561e99889ccc81b680084d3d6384d4db7157422627750cecd3ec4df2237bf1ca639680ea420bdfe578e63c14e7a840086771b3b5f5e7669b16d89adead0b5a5be27df7b75a91e4767f47c395b1aaddbb592427ed1998fbbb590203010001a382011930820115301d0603551d0e0416041481223bdff5d466a37f81d26e04deec9fe039fbe2 EAP-Message = 0x3081e50603551d230481dd3081da801481223bdff5d466a37f81d26e04deec9fe039fbe2a181bea481bb3081b8310b30090603550406130255533110300e060355040813074172697a6f6e613110300e0603550407130750686f656e69783130302e060355040a13274d756c6c656e204164766572746973696e6720616e64205075626c69632052656c6174696f6e7331143012060355040b130b4d61696e204f6666696365311a3018060355040313117777772e6d756c6c656e6164762e636f6d3121301f06092a864886f70d01090116126372616967406d756c6c656e70722e636f6d820100300c0603551d13040530030101ff300d06092a8648 EAP-Message = 0x86f70d010104050003818100768e3a090efeb6defd2310b970964f5b50dd48dd7d740d5f90784cc29688818dd3df60d71a7c06cd9a6c08ac0690df4102b1168ad2c73433558b66f96f1fcee9fd465028e75309c207400f6f7628de7917667c71472930176924b2078cf0b9e007698319fa93199d76c5c69f25936a232a3258e01f99a23798297dfd196ef37b160301010d0c0001090040bcd70764bd8eeff9e536574ff3b2f404043cc23d501c99a5b93d5edd5a8330c40b6e1bb3b2418f455d6511b978ae7e142b35bbf17e9dde8ae088b6bd5770253f00010500409f8a29eea3c97af2ee158cbabf6f536272a84e548678d53c4711c721cedda7c143 EAP-Message = 0x7f47f869ba7025d999bf4a37469dd40ec3cc Message-Authenticator = 0x00000000000000000000000000000000 State = 0x28ab70e596615ccdfa8d83b1787bc31e
Craig White wrote:
I realize that freeradius has little control over the supplicant but I'm wondering if it's something in my setup of tls that the authentication should/shouldn't be part of the tunnel because it just assumes a login of anonymous instead of the Windows User/Password or never asks me for a User/Password...
Because you've likely configured an anonymous outer identity, and it's not proceeding to the inner session. So it's not asking for the username or password. Alan DeKok.
On Tue, 2008-11-25 at 10:06 +0100, Alan DeKok wrote:
Craig White wrote:
I realize that freeradius has little control over the supplicant but I'm wondering if it's something in my setup of tls that the authentication should/shouldn't be part of the tunnel because it just assumes a login of anonymous instead of the Windows User/Password or never asks me for a User/Password...
Because you've likely configured an anonymous outer identity, and it's not proceeding to the inner session. So it's not asking for the username or password.
OK perhaps I am just looking in the wrong place and I'm using an older version of freeradius (part or RHEL/CentOS 5) but eap.conf, in peap section only has these options and I haven't found any combination that works... copy_request_to_tunnel = yes use_tunneled_reply = yes # proxy_tunneled_request_as_eap = yes proxy_tunneled_request_as_eap = no and I have the ttls section commented out. Am I in the right place? Am I missing something really obvious? Craig
OK - that quiets the notification but I still can't figure out the issue where I can authenticate RRAS, Macintosh and iPod clients against radius via LDAP using mschapv2 but even with the certificates on Windows XP clients, with the 'xpextensions' they always try to authenticate as 'uid=anonymous' and never ask me for name/password credentials to supply for authentication.
Thus since my Default Auth Type = LDAP (in users), these clients always fail authentication.
Then there must be a setting in the supplicant that changes user name to anonymous for the outer tunnel negotiation. If you upgrade to 2.1.1. you can leave anonymous as it is and enable ldap only for inner-tunnel virtual server (where true user name will be used). Ivan Kalik Kalik Informatika ISP
participants (3)
-
Alan DeKok -
Craig White -
tnt＠kalik.net