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. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project