[Freeipa-users] freeRADIUS?

[Dmitri Pal]

On 10/05/2011 10:28 AM, John Dennis wrote:
> On 10/05/2011 09:44 AM, Dmitri Pal wrote:
>> On 10/04/2011 11:14 AM, John Dennis wrote:
>>> On 10/04/2011 10:50 AM, Jimmy wrote:
>>>> I've been searching and see a few references to freeRADIUS used with
>>>> FreeIPA, but I don't see any substantial information on the
>>>> subject. Is
>>>> there a procedure to use FreeIPA with freeRADIUS? I have a standalone
>>>> openldap/freeradius server that I would like to eliminate if possible.
>>>
>>> Integrating FreeRADIUS with IPA is on the long term roadmap. It's not
>>> as easy as one might imagine. The fundamental problem is that many of
>>> the RADIUS authentication methods require access to the user's
>>> cleartext password or hashes we feel are insecure. This presents a
>>> design issue for us to resolve, as such it has been pushed out.
>>>
>>> Refer to this chart for more information:
>>>
>>> http://deployingradius.com/documents/protocols/compatibility.html
>>>
>>>
>> OK. This could have created a wrong impression the freeRADIUS can't be
>> used now with IPA. This is wrong. There is no tight integration but IPA
>> for sure can act as an "authentication oracle" for freeRADIUS.
>> http://deployingradius.com/documents/protocols/oracles.html
>>
>> You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and
>> configure freeRADIUS to do bind operation against IPA as if it is an
>> LDAP server (or you can use pam for that if you want, with SSSD you
>> might get offline caching if you connection between RADIUS host and IPA
>> might be disrupted, but if they are on the same box or connection is
>> reliable it might make sense to use direct ldap bind rather than use the
>> PAM stack) .
>> How to do all this can be found in the RADIUS manual. If you find some
>> interesting gotchas related to IPA or SSSD in this setup please share
>> with us. Also if you find this information not sufficient let us know
>> and we will try to help you find the right documentation.
>>
>
> Sure, but the typical stumbling block is that in the majority of cases
> the goal is transparent wireless authentication by supplicants in
> their default configuration. It's usually difficult to get users to
> properly configure their supplicants and for some versions of Windows
> it may not be possible at all without installing a different
> supplicant. Then there is is the issue of getting the radius CA cert
> into each client or telling users to disable cert validation which is
> not something we should be doing. In short, there are logistical
> problems which may not meet real world needs. It's hard to know a
> prori if the above will meets the needs or not, perhaps it will so
> it's good Dmitri posted the suggestion.
>
It really depends what is the RADIUS client. It can be a VPN case or it
can be Wireless. VPN usually uses the setup that I defined above. For
the Wireless case one has to use a different scheme. It really depends
on the capabilities of the supplicant so one should start by looking at
what supplicants are in use.
Then the approach is pretty simple:
* Use tunneling that your supplicant supports. It can be PEAP or
EAP-TTLS which does not require client side certificate which is great. 
I have not been in this space for 4 years so I do not know if anything
new and exciting happened and new more usable methods emerged
* Inner methods can be different. Most popular are PAP and EAP-GTC. One
usually uses OTP tokens for wireless access so EAP-GTC as an inner
method should be used in this case. If it is just password it can be
PAP. IN both cases you have a cleartext credential on the RADIUS server
side that you can turn around and sent for authentication to IPA.
Unfortunately IPA does not support native 2FA yet. It will within couple
years.






-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/