Bug 743604

Summary: Create a writeup on how to configure FreeRADIUS with IPA
Product: Red Hat Enterprise Linux 6 Reporter: Dmitri Pal <dpal>
Component: doc-Identity_Management_GuideAssignee: Deon Ballard <dlackey>
Status: CLOSED WONTFIX QA Contact: ecs-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: jdennis, mheslin
Target Milestone: rcKeywords: Documentation, FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-03 17:45:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Dmitri Pal 2011-10-05 13:58:09 UTC
IPA can be used as an authentication oracle for freeRADIUS but the setup is tricky. 

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. 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. Also the ntlm method might be usable when we  are done with Cross Realm Kerberos Trust in v3. 
http://deployingradius.com/documents/protocols/oracles.html
http://deployingradius.com/documents/protocols/compatibility.html

It would be nice to have a "drop replace" configuration, i.e. if you switch RADIUS server from AD to IPA. In this case you migrated or synced your users to IPA from AD and then you should be able to easily tweak the RADIUS config to point to IPA.
We should have something like this (but I do not think we need samba it seems that it should be simpler):
http://deployingradius.com/documents/configuration/active_directory.html
This part needs to be investigated. And not a high priority.

Comment 1 RHEL Program Management 2012-01-03 17:45:15 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.