[RADIATOR] How to configure Radiator to Support both PEAP/MSCHAPv2 and TTLS/PAP?
Amândio Antunes Gomes Silva
amandio at scom.uminho.pt
Tue Oct 7 06:28:49 CDT 2008
Hi all!
I've been trying to configure Radiator to both authenticate clients with TTLS/PAP (which works fine for several years) and PEAP/MSCHAPV2). The scenario we have here at University of Minho (Portugal) is as follows:
Server: Radiator 4.3.1 running on Linux (CentOS 5.2)
TTLS Authentication (PAP) is done against an LDAP server (in fact, it's an LDAP gateway to an ActiveDirectory).
PEAP Authentication is configured to be proxied to an IAS server.
All our AP's are configured to authenticate against this Radiator server, but, for testing, I'm using an AP that authenticates directly to an IAS server, which accesses directly the same Active Directory that is used by the LDAP gateway.
University of Minho is part of the eduroam project, which means that it belongs to an hierarchy of RADIUS servers that is working fine.
The tests were made with a PC with Fedora Core 7, using wpa_supplicant (this way I have absolute control on which AP the PC associates to).
When testing PEAP authentication with an AP that's configured to use the IAS server directly, PEAP authentication succeeds. Here are the wpa_supplicant's config and log, and the IAS' log of the successful authentication:
#Associated wpa_supplicant config:
network={
ssid="eduroam"
bssid=00:17:5a:8f:bc:10
proto=WPA
key_mgmt=WPA-EAP
pairwise=TKIP
group=TKIP WEP104 WEP40
auth_alg=OPEN
eap=PEAP
identity="f1023 at scom.uminho.pt <mailto:f1023 at scom.uminho.pt> "
password="**************"
ca_cert="/etc/ssl/certs/UMinhoRootCA.cer"
phase2="auth=MSCHAPV2"
priority=1
disabled=1
}
wpa_supplicant log (successful):
Trying to associate with 00:17:5a:8f:bc:10 (SSID='eduroam' freq=2452 MHz) Associated with 00:17:5a:8f:bc:10 CTRL-EVENT-EAP-STARTED EAP authentication started TLS - SSL error: error:0B07C065:x509 certificate routines:X509_STORE_add_cert:cert already in hash table CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
WPA: Key negotiation completed with 00:17:5a:8f:bc:10 [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:17:5a:8f:bc:10 completed (reauth) [id=2 id_str=]
IAS server log:
User f1023 was granted access.
Fully-Qualified-User-Name = UMINHO\f1023
NAS-IP-Address = 172.16.45.233
NAS-Identifier = apb-scom-testes-glt
Client-Friendly-Name = AP_temp
Client-IP-Address = 172.16.45.233
Calling-Station-Identifier = 000e3585f1d3
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 317
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = ap_temp
Authentication-Type = PEAP
EAP-Type = Secured password (EAP-MSCHAP v2)
When testing PEAP authentication with an AP that's configured to use Radiator, which proxies the request to the same IAS server, the authentication fails. Here are the configs and logs of Radiator and wpa_supplicant, and also the log from the IAS server. (once it's not useful and they're working fine on TTLS/PAP, I didn't put here the realm's config nor the AuthBy LDAP2 used by that handler).
<AuthBy RADIUS>
Host 192.168.62.100
Secret **********
AuthPort 1812
AcctPort 1813
EAPType PEAP,TTLS,TLS,MSCHAPV2,MSCHAP-V2,
Description PEAP no SAPIA
Identifier PEAPnoSAPIA
Retries 5
RetryTimeout 30
AddToReply Tunnel-Type=VLAN, Tunnel-Medium-Type=Ether_802, Tunnel-Private-Group-ID=247, Class=funcionarios
</AuthBy>
<Handler ConvertedFromEAPMSCHAPV2=1>
AuthLog peaplog
StripFromRequest ConvertedFromEAPMSCHAPV2
<AuthBy FILE>
Filename /etc/radiator/users
EAPType PEAP,TTLS,TLS,MSCHAP-V2
# AutoMPPEKeys
# EAPAnonymous %0
# AddToReply Tunnel-Type=VLAN, Tunnel-Medium-Type=Ether_802, Tunnel-Private-Group-ID=248
# </AuthBy>
AuthBy PEAPnoSAPIA
# AuthBy Auth-SAPIA
</Handler>
<Handler TunnelledByPEAP=1>
RewriteUsername s/^([^@]+).*/$1/
# AuthBy PEAPnoSAPIA
<AuthBy FILE>
# Dont really need this
# Filename %D/users
# This tells the PEAP client what types of inner EAP requests
# we will honour
EAPType MSCHAP-V2
# This flag tells EAPType MSCHAP-V2 to convert the inner EAP-MSCHAPV2 request into
# an ordinary Radius-MSCHAPV2 request and redespatch to to a Handler
# that matches ConvertedFromEAPMSCHAPV2=1 (see above)
EAP_PEAP_MSCHAP_Convert 1
</AuthBy>
</Handler>
#Associated wpa_supplicant config:
network={
ssid="eduroam"
bssid=00:0e:d7:cd:e5:e0
proto=WPA
key_mgmt=WPA-EAP
pairwise=TKIP
group=TKIP WEP104 WEP40
auth_alg=OPEN
eap=PEAP
anonymous_identity="f1023 at scom.uminho.pt <mailto:f1023 at scom.uminho.pt> "
identity="f1023 at scom.uminho.pt <mailto:f1023 at scom.uminho.pt> "
password="**************"
ca_cert="/etc/ssl/certs/UMinhoRootCA.cer"
phase2="auth=MSCHAPV2"
priority=1
disabled=1
}
Radiator log is attached. As you can see, the requested Access isn't considered TunnelledByPEAP at first: Radiator tries to first use the <Handler Realm=/uminho.pt$> and just after some attempts Radiator considers the packet TunnelledByPEAP.
As you can see, when handling the request with the Handler 'ConvertedFromEAPMSCHAPV2=1', the result is IGNORE, but the IAS server rports the following:
# IAS Log for unauthenticated attempt
User f1023 was granted access.
Fully-Qualified-User-Name = UMINHO\f1023
NAS-IP-Address = <not present>
NAS-Identifier = <not present>
Client-Friendly-Name = roamer-b
Client-IP-Address = 193.137.17.5
Calling-Station-Identifier = <not present>
NAS-Port-Type = <not present>
NAS-Port = <not present>
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = eduroam
Authentication-Type = MS-CHAPv2
EAP-Type = <undetermined>
Although the IAS server grants the access, Radiator rejects the access for some reason I can't figure why, that's why I'm asking for help.
I may say that I've also tried to handle the PEAP request configuring the Handler to use the authenticator identified as PEPAnoSAPIA, without converting it to a Radius MSCHAP, but the results were the same: unsuccessful.
Another aspect the I suppose is relevant is that users in roaming at our University that use PEAP/MSCHAPV2 are authenticated without any problem.
If you need any more info, please let me know.
Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20081007/875a3a8a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 6529 bytes
Desc: image001.jpg
URL: <http://www.open.com.au/pipermail/radiator/attachments/20081007/875a3a8a/attachment-0001.jpe>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20081007-f1023-PEAP-log.txt
URL: <http://www.open.com.au/pipermail/radiator/attachments/20081007/875a3a8a/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Am?ndio Antunes Gomes da Silva.vcf
Type: text/x-vcard
Size: 2775 bytes
Desc: Am?ndio Antunes Gomes da Silva.vcf
URL: <http://www.open.com.au/pipermail/radiator/attachments/20081007/875a3a8a/attachment-0001.vcf>
More information about the radiator
mailing list