[Freeipa-users] FreeRadius and FreeIPA

[Randy Morgan]

Thanks Alexander, that was an excellent explanation with some very 
helpful information.  We will look over our configs and see if we can 
work this out.

Randy

Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

On 12/14/2015 3:12 AM, Alexander Bokovoy wrote:
> 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.
>