|
Notes |
|
|
(0007421)
|
|
NickH
|
|
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. |
|
|
|
(0007441)
|
|
NickH
|
|
2018-04-16 07:29
|
|
Two more issues:
In /etc/raddb/sites-available/clearos-inner-tunnel, change:
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
# Pluggable Authentication Modules.
to:
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
# For old names, too.
#
mschap
#
# 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
to:
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. |
|
|
|
(0007451)
|
|
NickH
|
|
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
# } |
|
|
|
(0007461)
|
|
NickH
|
|
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. |
|
|
|
(0007481)
|
|
user2
|
|
2018-04-19 08:30
|
|
|
Doh! Bumped due to the time required to migrate to GitLab. |
|
|
|
(0007971)
|
|
NickH
|
|
2018-09-20 09:46
|
|
For a final write up after getting Radius working, please see https://docs.google.com/document/d/1vIt8tfkn-3FLyZx6HenDIu-xEOphJPevS92lHKPK7Uc/edit?usp=sharing. [^]
Also note that because of https://tracker.clearos.com/view.php?id=21401 [^] 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. |
|
|
|
(0010041)
|
|
dloper
|
|
2019-02-23 20:18
|
|
|