[Freeipa-users] FreeRadius and FreeIPA

[Arthur Fayzullin]

Thank for such good explanation! that has pointed my search.
 I have succeed in integration freeradius with freeipa by help of
William Brown and his blog. Thanks to Him :-)
Links to related articles in his blog:
first part: https://firstyear.id.au/entry/22
second part: https://firstyear.id.au/entry/45

with a little difference taken from this guide:
http://www.freeipa.org/page/Using_FreeIPA_and_FreeRadius_as_a_RADIUS_based_software_token_OTP_system_with_CentOS/RedHat_7
I additionally defined
base_dn =
server =
parameters in /etc/raddb/mods-enabled/ldap file.

everything works fine. now it would be fine to define different admin
level for different users on different network devices.
But anyway everything works!!! Thanks to all!

1 little question left: what does
ipa radiusproxy-add
command do? what is its purpose? why everything works without it?

14.12.2015 15:12, 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.
>