[Freeipa-devel] How we should be integrating RADIUS

[John Dennis]

Andrew Bartlett wrote:
> You miss my point.  The Samba part of this would be targeted at IPA
> (Samba as a DC against LDAP), not AD, and will handle MSCHAPv2 for
> FreeRADIUS.  In all other respects, the configuration would be
> identical, as in both cases winbindd handles the details. 

When samba is integrated with IPA as a DC we can do this but thats not 
the case today for v1.

FWIW, a lot of the current IPA radius work has little to do with 
specific authentication methods but rather management of users and 
clients, that infrastructure has to be in place first. This is staged 
development, mschap is down the road.

>> One of the challenges of integrating radius into IPA is the fact radius 
>> is best thought of as a toolkit with multiple ways of setting it up 
>> tailored to the needs of the site. 
> 
> Sure, but shouldn't the role of IPA be to provide all the backend
> configuration, already completed?

I'm afraid I don't follow what you mean by having all the backend 
configuration completed.

>> I think we're going to end up with a 
>> handful of pre-canned configurations that IPA supports, mschap/ntlm will 
>> will certainly be one of them in order to support Windows clients. 
>> Figuring out how we're going to handle mschap/ntlm is on hold till V2.
> 
> If it's any different to that HOWTO I'll be very surprised, but I look
> forward to it.

Yes you're right, for that one case it will look similar. What will be 
different from the HOWTO is all the places in the HOWTO where it says 
hand edit such and such, or where it fails to talk about the management 
of NAS devices or the management of per user NAS attributes, all of that 
infrastructure is getting automated as part of the v1 work. When that's 
done we can apply the HOWTO receipe. The initial goal is to avoid any 
direct manipulation of service configuration and the data the service 
needs to access, the HOWTO glosses over those issue with the presumption 
a human sys admin is actively involved in managing it. That's why mschap 
is slated for v2 not v1.


-- 
John Dennis <jdennis at redhat.com>