ClearFoundation Tracker - ClearOS
View Issue Details
0019821ClearOSapp-radius - RADIUS Serverpublic2018-04-11 08:452019-02-23 20:18
8.0.0 Beta 1 
0019821: app-radius-core deploy install script incorrect
The upstream packaging of freradius appears to have changes a while back - prior to the installation on my server in 2016, and the /usr/clearos/apps/radius/deploy/install script now has a problem.

Freeradius have now moved most scripts into /etc/raddb/mods-available and they are enabled because of a line "$INCLUDE mods-enabled/" in /etc/raddb/radiusd.conf and then by putting a symlink to them in /etc/raddb/mods-enabled. This includes eap.conf, now renamed to just eap.

Unfortunately in the deploy/install script there is:
CHECK=`grep "^[[:space:]]*.INCLUDE[[:space:]]*eap.conf" /etc/raddb/radiusd.conf 2>/dev/null`
if [ -n "$CHECK" ]; then
    logger -p local6.notice -t installer "app-radius-core - adding clearos-eap.conf configlet"
    cp -a /etc/raddb/radiusd.conf /var/clearos/radius/backup/radius.conf.$TIMESTAMP
    sed -i -e 's/^[[:space:]]*\$INCLUDE[[:space:]]*eap.conf/\t\$INCLUDE clearos-eap.conf/' /etc/raddb/radiusd.conf

The initial check fails as there is no line "$INCLUDE eap.conf" so the rest of that bit of the script does not execute so no pointer is created to /etc/raddb/clearos-eap.conf which is unreferenced anywhere.

This can be fixed using the old way by adding a line to the bottom of /etc/raddb/radiusd.conf:
$INCLUDE clearos-eap.conf

Or by the newer way of putting a symlink in /etc/raddb/mods-enabled pointing to /etc/raddb/clearos-eap.conf

***but*** at the same time the symlink /etc/raddb/mods-enabled/eap needs to be removed.

At the same time it may be worth reviewing the file locations of the clearos-specific conf files because of the new packaging. Also the /etc/raddb/mods-available/eap is a little different from /etc/raddb/mods-available/eap and the differences perhaps should be reviewed.
No tags attached.
Issue History
2018-04-11 08:45NickHNew Issue
2018-04-11 09:18user2Assigned To => user2
2018-04-11 09:18user2Statusnew => confirmed
2018-04-11 09:19user2Prioritynormal => high
2018-04-11 09:19user2Target Version => 7.4.0 Updates
2018-04-13 03:33NickHNote Added: 0007421
2018-04-16 07:29NickHNote Added: 0007441
2018-04-17 03:36NickHNote Added: 0007451
2018-04-17 06:37NickHNote Added: 0007461
2018-04-19 08:30user2Note Added: 0007481
2018-04-19 08:30user2Target Version7.4.0 Updates => 7.5.0 Updates
2018-09-20 09:46NickHNote Added: 0007971
2018-09-24 10:45user2Assigned Touser2 =>
2018-10-25 09:03user2Target Version7.5.0 Updates => 8.0.0 Beta 1
2019-02-23 20:18dloperNote Added: 0010041
2019-02-23 20:18dloperStatusconfirmed => closed
2019-02-23 20:18dloperAssigned To => dloper
2019-02-23 20:18dloperResolutionopen => suspended

2018-04-13 03:33   
There is a further issue. In /etc/raddb/clearos-eap.conf the use of CA_file is deprecated and should now be ca_file. If the change is not made radiusd will not start.

Useful for diagnosing this was the prestart command in the unit file with an X appended:
/usr/sbin/radiusd -CX

I am waiting feedback from the customer to see if these changes are enough to fix the domain sign-in issue.
2018-04-16 07:29   
Two more issues:
In /etc/raddb/sites-available/clearos-inner-tunnel, change:
    # MSCHAP authentication.
    Auth-Type MS-CHAP {

    # Pluggable Authentication Modules.

    # MSCHAP authentication.
    Auth-Type MS-CHAP {

    # For old names, too.

    # Pluggable Authentication Modules.

Also the server certificate is not being created with the proper extended key usage (EKU) set and generates an error 0x80420101 when validating Windows devices. This can be corrected by changing the deploy/install script from:
openssl ca -batch -keyfile ca.key -cert ca.pem -in server.csr -key `grep output_password $SSL_CONF | sed 's/.*=//;s/^ *//'` -out server.crt -config $SSL_CONF 2>/dev/null

openssl ca -batch -keyfile ca.key -cert ca.pem -in server.csr -key `grep output_password $SSL_CONF | sed 's/.*=//;s/^ *//'` -out server.crt -config $SSL_CONF -extensions xpserver_ext -extfile ../certs/xpextensions 2>/dev/null

I have a feeling we have created a number of our own problems and it would be worth considering sticking to a more standard config and using the freeradius certificate management (see /etc/raddb/certs/README for "make ca.pem" and "make "server.pem", perhaps linking them to the ClearOS ca-cert as an extra)

The /etc/raddb/clearos-eap.conf and /etc/raddb/mods-available/eap seem very similar. I think the key differences are the locations of the certificates and /etc/raddb/clearos-eap.conf calls 'virtual_server = "clearos-inner-tunnel"' instead of 'virtual_server = "inner-tunnel"' but the files are laid out a bit differently so need checking. If we revert to the standard certificates, the certificate location issue goes away.

The key difference in clearos-inner-tunnel and inner-tunnel seems to be in the "authorize" section where clearos-inner-tunnel calls "unix" instead of "filter_username". inner-tunnel also seems to call a couple of other files which may be irrelevant. This could be simply covered in an installation script.

If we revert to a more stock installation, /etc/raddb/clearos-eap.conf would not be needed and have to be referenced in /etc/raddb/radiusd.conf, we would not have hit the CA-file bug, the certificate creation bug or the /etc/raddb/sites-available/clearos-inner-tunnel bug.

I still don't have domain authentication working yet but I've got the ClearOS radius installation going.
2018-04-17 03:36   
It looks like the change in /etc/raddb/sites-available/clearos-inner-tunnel of "ldap" to "-ldap" is necessary so we can't stick with the totally standard file. There may be a further requirement to uncomment the three lines:
# Auth-Type LDAP {
# ldap
# }
2018-04-17 06:37   
It does not matter what I do, but I cannot seem to be able to get any "user\DOMAIN" stripped down to "user" and domain so that only "user" gets passed to LDAP. There is something I am missing in the configs to to this and I am often seeing errors in "radiusd -X":

(9) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
(9) ldap: --> (uid=test/MINI-1.CLEARSYSTEM)
(9) ldap: Performing search in "dc=howitts,dc=co,dc=uk" with filter "(uid=test/MINI-1.CLEARSYSTEM)", scope "sub"

I believe the "Striped-User-Name" should be passed through to LDAP and not the original User-Name, but I can't find the function doing the stripping.
2018-04-19 08:30   
Doh! Bumped due to the time required to migrate to GitLab.
2018-09-20 09:46   
For a final write up after getting Radius working, please see [^]

Also note that because of [^] we may have to regenerate out sys-0-cert.pem certificate with an extra EKU attribute. This attribute is the same one needed by Win10 for radius authentication which otherwise forces us to use the built in radius certificate routings for radius certificates. If the issue is fixed for OpenVPN, we could use our certificates again instead of the radius generated ones and copy them into the /etc/raddb/certs/ folder with the correct names. There would be no point in using the /etc/raddb/clearos-certs/ as this creates complications during installation.
2019-02-23 20:18   
Migrated to: [^]