[Freeipa-users] FreeRadius and FreeIPA

[Alexander Bokovoy]

On Wed, 09 Dec 2015, Randy Morgan wrote:
>Hello,
>
>We are setting up our wireless to authenticate against FreeRadius and 
>FreeIPA.  I am looking for any instructions on how to integrate radius 
>with IPA.  We can get them talking via kerberos, but when we have a 
>wireless client attempt to authenticate against them, the password 
>gets stripped out and only the username gets passed on, resulting in a 
>failed logon attempt.
>
>As we have studied the problem we have identified the communication 
>protocols used by wireless to pass on the user credentials to radius.  
>Wireless uses EAP as it's primary protocol.  We are running Xirrus 
>wireless APs and from what we can learn, they act only as a pass 
>through conduit for the client.  Ideally we would like them to speak 
>PEAP TTLS, this would allow kerberos to process from the client to the 
>IPA server, we are still researching this.
>
>Are there any instructions on how to integrate FreeRadius 3.0.10 with 
>FreeIPA 3.3.5?  Any help would be appreciated.
We see this question asked periodically. What we ask always prior to
answering it is what it would be used for? What authentication
mechanisms RADIUS is supposed to provide to its clients?

FreeRADIUS authenticating against IPA is easy. However, depending on
what authentication mechanisms are required it will be either not
possible to achieve or will definitely degrade security of the setup.

A general approach is to use following setup to use PAP authentication:
  1. Installing the 'freeradius-ldap' rpm from yum
  2. chmod 775 /etc/raddb/certs (so radiusd can write cert files)
  3. Change your 'authorize' and 'authenticate' sections of
  /etc/raddb/radiusd.conf to:
       authorize {
        ldap
  }
  authenticate {
        Auth-Type LDAP {
                ldap
        }
  }

During PAP a plaintext password is passed to the RADIUS server
(encrypted with a weak MD5 shared secret).

When the RADIUS server receives the users plaintext password in the
conventional configuration it simply compares the received password with
the stored password. The issue with IPA is there is no stored plaintext
password to compare to, therefore you cannot use conventional PAP with
IPA.

But FreeRADIUS permits you to do other things with PAP besides just
comparing the received password against the stored password for the
user. You can instruct FreeRADIUS to use what they call an
"authentication oracle", or at the risk of loose terminology to "proxy"
the authentication to another authentication server (not to be confused
with radius proxy where the radius transaction is proxied to another
radius server).

There are two authentication oracles FreeRADIUS can use

* LDAP
* Kerberos

In this scenario the plantext password received by the RADIUS server is
used to authenticate against the oracle. For LDAP it does a simple bind.
For Kerberos it does a kinit. If the authentication succeeds the RADIUS
server ACK's the PAP. The thing to note here is this is still occurring
with PAP but no password comparison is being performed.

There is a third "oracle" FreeRADIUS can utilize, namely Active
Directory, but in this case the protocol is not PAP, the ntlm_auth
helper from Samba is used instead with the RADIUS server communicating
with ntlm_auth which communicates with AD.

The suggestion of using strong passwords is always a good idea. The
password transmission between the client and the radius server only
enjoys weak protection so a strong password is especially important.
Communication between the RADIUS server and it's oracles can be quite
strong and is generally not a concern if things are configured properly.

Now, there is an issue if you would want to authenticate Windows clients
using MS CHAPv2 because that implies that FreeRADIUS would want to fetch
a weak NTLM hash to do negotiation on its own side.

To achieve that, one would need to give up the hashes to FreeRADIUS
instance. We consider them weak as they can be used to brute force
decryption of the passwords (trivially these days!) so a certain care
should be done to limit who can access them. We strongly not
recommending use of this but sometimes you are forced to provide
authentication for WiFi networks to Windows clients that only support

 0. Run ipa-adtrust-install to configure IPA to generate NTLM hashes.
    Make sure you'll run the task to generate SIDs, ipa-adtrust-install
    will ask about it.

 1. You need to create a system account for FreeRADIUS to acces the LDAP
    server. Let's say, it is
    uid=freeradius,cn=sysaccounts,cn=etc,dc=example,dc=com

 2. Make the DN above a member of cn=adtrust agents,cn=sysaccounts,dc=example,dc=com
    Use the DN as in FreeRADIUS configuration.

 3. For each user that needs to get NTLM hashes, a password change is
    required to regenerate all hashes. We currently have no means
    to generate them otherwise.

If you use ldap auth I'd suggest the connection either be SSL or on the
loopback to prevent snooping. Missing from instructions above is the
configuration of the ldap server FreeRADIUS will connect to.

This is done in /etc/raddb/mods-available/ldap and you'll need to make a
symlink to it in /etc/raddb/mods-enabled to activate it. The ldap config
file has lots of comments that explains all the options, like most
things in FreeRADIUS the doc is in the config files.

It's not possible to use any RADIUS authentication mechanism that
requires the RADIUS server to lookup a cleartext password, refer to this
chart:

http://deployingradius.com/documents/protocols/compatibility.html

If you do step 0 from above and enable NTLM hashes you can utilize
column 2 from above because the server can lookup up the NTLM hash. The
attribute will be named ipaNTHash, so you would need to remap password
attribute for that in the ldap configuration.

It is currently not possible to configure rlm_ldap module to do LDAP
authentication by SASL GSSAPI instead of using a system account in IPA
because while FreeRADIUS tries to search for SASL-enabled LDAP API, it
doesn't use it at all and always uses LDAP simple bind. This is
something we need to fix --- I'm unable right now to find out the reason
why previously supported SASL GSSAPI authentication is removed from
FreeRADIUS.

-- 
/ Alexander Bokovoy