Wifi RADIUS authentication with LDAP on ClearOS 5.2
This guide will help you setup WPA Enterprise authentication using the RADIUS functionality built into ClearOS 5.2.
The tutorial on the ClearOS wiki page is a good starting point to get radius authenticating off of the LDAP user directory, however it stops short of setting up RADIUS encryption which is required when using WIFI.
Preconditions
Please ensure that you have ClearOS 5.2 installed and have completed the guide at http://www.clearfoundation.com/docs/howtos/setting_up_radius_to_use_ldap.
Throughout this guide, it is assumed that ClearOS can be accessed at http://localhost:81. If you are connecting from a remote machine, please updated your url accordingly.
Generating Certificates
Navigate to https://localhost:81/admin/certificates.php.
When initially setting up ClearOS a Certificate Authority should have been created by default. If this isn’t the case, checkout the ClearOS docs for more information.
We are going to be generating a Secure Server Certificate for use with the RADIUS server.
The default Certificate parameters should work, just be sure to include a proper email address in the email field.
After clicking generate, a new certificate should be visible, click view to review the contents of the certificate. Be sure to note the filename as we will be needing that in a moment. Mine is “/etc/ssl/usr-1-cert.pem”
Now that we have the certificates generated, we are going to softlink them into the radius certs folder and update the permissions so the daemon can read them.
cd /etc/raddb/certs
#softlink the generated certificate
ln -s /etc/ssl/usr-1-cert.pem usr-1-cert.pem
#softlink the generated private key
ln -s /etc/ssl/private/usr-1-key.pem usr-1-key.pem
#update the file ownership
chown nobody:radiusd usr-1-cert.pem usr-1-key.pem
RADIUS Configuration
Now that we have the certificates generated, its time to modify the RADIUS configuration files. Remember, the files should have already been modifed as per the wiki article.
/etc/raddb/eap.conf
In the eap.conf file we will be wanting to enable TLS (using our generated certs) and PEAP.
So un-comment out tls and fill in the corresponding information.
The private key file should be set to the key-file softlinked to the /etc/ssl/private directory. (No password is required)
private_key_file = ${raddbdir}/certs/usr-1-key.pem
The certificate file is the cert file softlinked to the /set/ssl/ directory
certificate_file = ${raddbdir}/certs/usr-1-cert.pem
The Trusted root CA list should be the CA certificate for our server
CA_file = /etc/ssl/ca-cert.pem
Additinally, be sure to un-comment the dh_file and the random_file.
tls {
# private_key_password = whatever
# private_key_file = ${raddbdir}/certs/cert-srv.pem
private_key_file = ${raddbdir}/certs/usr-1-key.pem
# If Private key &; Certificate are located in
# the same file, then private_key_file &;
# certificate_file must contain the same file
# name.
# certificate_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/usr-1-cert.pem
# Trusted Root CA list
# CA_file = ${raddbdir}/certs/demoCA/cacert.pem
CA_file = /etc/ssl/ca-cert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
# fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
# include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash <;CA certs&CRLs Directory>'.
# 'c_rehash' is OpenSSL's command.
# 3) Add 'CA_path=<;CA certs&CRLs directory>'
# to radiusd.conf's tls section.
# 4) uncomment the line below.
# 5) Restart radiusd
# check_crl = yes
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the cerficate verification will fail,
# rejecting the user.
#
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
# check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
# cipher_list = "DEFAULT"
}
Setting up peap is easy: just uncomment the directives
peap {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
default_eap_type = mschapv2
# the PEAP module also has these configuration
# items, which are the same as for TTLS.
copy_request_to_tunnel = no
use_tunneled_reply = no
# When the tunneled session is proxied, the
# home server may not understand EAP-MSCHAP-V2.
# Set this entry to "no" to proxy the tunneled
# EAP-MSCHAP-V2 as normal MSCHAPv2.
proxy_tunneled_request_as_eap = yes
}
/etc/raddb/ldap.attrmap
This file needs an additional line added. Directly before the checkItem $GENERIC$ … line, add
checkItem User-Password userPassword
so the file now looks like:
checkItem User-Password userPassword
checkItem $GENERIC$ radiusCheckItem
replyItem $GENERIC$ radiusReplyItem
checkItem Auth-Type radiusAuthType
checkItem Simultaneous-Use radiusSimultaneousUse
checkItem Called-Station-Id radiusCalledStationId
checkItem Calling-Station-Id radiusCallingStationId
checkItem LM-Password sambaLMPassword
checkItem NT-Password sambaNTPassword
checkItem SMB-Account-CTRL-TEXT sambaAcctFlags
checkItem Expiration radiusExpiration
checkItem NAS-IP-Address radiusNASIpAddress
replyItem Service-Type radiusServiceType
replyItem Framed-Protocol radiusFramedProtocol
replyItem Framed-IP-Address radiusFramedIPAddress
replyItem Framed-IP-Netmask radiusFramedIPNetmask
replyItem Framed-Route radiusFramedRoute
replyItem Framed-Routing radiusFramedRouting
replyItem Filter-Id radiusFilterId
replyItem Framed-MTU radiusFramedMTU
replyItem Framed-Compression radiusFramedCompression
replyItem Login-IP-Host radiusLoginIPHost
replyItem Login-Service radiusLoginService
replyItem Login-TCP-Port radiusLoginTCPPort
replyItem Callback-Number radiusCallbackNumber
replyItem Callback-Id radiusCallbackId
replyItem Framed-IPX-Network radiusFramedIPXNetwork
replyItem Class radiusClass
replyItem Session-Timeout radiusSessionTimeout
replyItem Idle-Timeout radiusIdleTimeout
replyItem Termination-Action radiusTerminationAction
replyItem Login-LAT-Service radiusLoginLATService
replyItem Login-LAT-Node radiusLoginLATNode
replyItem Login-LAT-Group radiusLoginLATGroup
replyItem Framed-AppleTalk-Link radiusFramedAppleTalkLink
replyItem Framed-AppleTalk-Network radiusFramedAppleTalkNetwork
replyItem Framed-AppleTalk-Zone radiusFramedAppleTalkZone
replyItem Port-Limit radiusPortLimit
replyItem Login-LAT-Port radiusLoginLATPort
replyItem Reply-Message radiusReplyMessage
/etc/raddb/radiusd.conf
I found that in the default configuration, the Auth-Type LDAP appeared before the eap in the authenticate section. As a result, the server would cast the request as an LDAP auth type, and fail to parse it as an eap, which would cause the encrypted request from the WIFI access point to fail.
To fix this, I simply swapped the order of the two values, so if the server can’t match against any auth type, it will default to ldap, but most importantly, it will try EAP first.
So the authentication part of the file should look like the following:
authenticate {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
Auth-Type PAP {
pap
}
#
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
}
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
# digest
#
# Pluggable Authentication Modules.
# pam
#
# See 'man getpwent' for information on how the 'unix'
# module checks the users password. Note that packets
# containing CHAP-Password attributes CANNOT be authenticated
# against /etc/passwd! See the FAQ for details.
#
unix
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
#Auth-Type LDAP {
# ldap
#}
#
# Allow EAP authentication.
eap
Auth-Type LDAP {
ldap
}
}
/etc/raddb/users
Comment out the DEFAULT Auth-Type and fallthrough directive, so we aren’t always trying to default to ldap:
DEFAULT LDAP-Group != "radius_users", Auth-Type := Reject
#DEFAULT Auth-Type := LDAP
# Fall-Through = 1
In Conclusion
You should run service radiusd stop && radiusd -X -A to do your testing with the debug log, as suggested on the ClearOS Wiki.
I found that the radtest still worked as well as authentication from wireless clients using PEAP with MSCHAPv2.
You may want to distribute the usr-1-cert.pem that was generated in the certificates step to wireless clients, however, since we are using password authentication this isnt strictly necessary.
Please let me know in the comments if I have included any redundant or unnecessary steps.