ClearOS Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0019821ClearOSapp-radius - RADIUS Serverpublic2018-04-11 08:452019-02-23 20:18
Assigned Todloper 
PlatformOSOS Version
Product Version7.4.0 
Target Version8.0.0 Beta 1Fixed in Version 
Summary0019821: app-radius-core deploy install script incorrect
DescriptionThe 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
NickH (developer)
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.
NickH (developer)
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.
NickH (developer)
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
# }
NickH (developer)
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.
NickH (developer)
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.
dloper (administrator)
2019-02-23 20:18

Migrated to: [^]

- Issue History
Date Modified Username Field Change
2018-04-11 08:45 NickH New Issue
2018-04-11 09:18 user2 Assigned To => user2
2018-04-11 09:18 user2 Status new => confirmed
2018-04-11 09:19 user2 Priority normal => high
2018-04-11 09:19 user2 Target Version => 7.4.0 Updates
2018-04-13 03:33 NickH Note Added: 0007421
2018-04-16 07:29 NickH Note Added: 0007441
2018-04-17 03:36 NickH Note Added: 0007451
2018-04-17 06:37 NickH Note Added: 0007461
2018-04-19 08:30 user2 Note Added: 0007481
2018-04-19 08:30 user2 Target Version 7.4.0 Updates => 7.5.0 Updates
2018-09-20 09:46 NickH Note Added: 0007971
2018-09-24 10:45 user2 Assigned To user2 =>
2018-10-25 09:03 user2 Target Version 7.5.0 Updates => 8.0.0 Beta 1
2019-02-23 20:18 dloper Note Added: 0010041
2019-02-23 20:18 dloper Status confirmed => closed
2019-02-23 20:18 dloper Assigned To => dloper
2019-02-23 20:18 dloper Resolution open => suspended