Bug 464903 - Update to support centralized authentication server
Update to support centralized authentication server
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 239055
  Show dependency treegraph
 
Reported: 2008-10-01 05:46 EDT by Tomas Mraz
Modified: 2014-09-08 20:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tomas Mraz 2008-10-01 05:46:46 EDT
Add support for the new centralized authentication server.

Three use cases:
 
1) An IPA server is available and can be detected automatically. Authconfig proposes that server as one of the options. The user selects, modification is possible.
2) The user points authconfig to a IPA server. - Similar to the existing KRB and LDAP setups, but integrated as one IPA tab with only one entry line.
3) Either of those but with an automated kickstart installation.
 
Requirements
The requirements from that should be pretty straight forward:
* Add an additional tab for IPA to authconfig, selecting it deactivates the LDAP/KRB ones (are there others?).
* Have an "detect automatically" botton that fills the entry fields or let's the user select if multiple servers results. This calls out and uses DNS to find IPA realm (given on user input, as appropriate DNS client configuration may not always be already given)
* ipa client code is called to make RHEL a member of the IPA realm
* Integrate with kickstart to allow automatic configuration / selection.

After that authconfig should verify connection to the IPA server, register (if that is needed / already implemented) and provision the required / available certificates and keys. If there is value in using only parts of the IPA features, it should allow selecting which features to use.

Again, if there are additional options, they should be integrated with kickstart.
Comment 3 Stephen Gallagher 2008-10-01 16:03:27 EDT
Tomas, I'd be happy to work with you on this. Here are a few starting points. I will describe the current state (v1.1) and give some comments on the future plans (v2).

1) Autodetection in FreeIPA v1.1 (the current version in Fedora 8,9,10b) is limited to special DNS entries. Examples of how to set up DNS is available at http://www.freeipa.com/page/IpaConcepts#IPA_and_DNS

2) IPA v1.1 provides only three services right now.
  a. LDAP - IPA provides authentication by using nss_ldap, the same way that configuring LDAP authentication in authconfig works now.
  b. Kerberos 5 - IPA provides Kerberos 5 authentication exactly as done in authconfig right now.
  c. NTP - IPA configures the client to use the IPA server as the authority for NTP synchronization, for the benefit of Kerberos authentication.

3) IPA v2 will have a number of new services and change the way that authentication is handled.
  a. The client machine itself will be enrolled in IPA and be given a kerberos keytab as well as service principals
  b. New PAM and NSS modules will be included to handle authentication/authorization.
As such, IPA v2 will drastically change the needs of authconfig.


Recommendations:
I am assuming that authconfig is being run after the package ipa-client is available, along with its dependencies.
1) Query the DNS for the existence of _kerberos._tcp.domain.com SRV and _ldap.domain.com SRC. This is the same way that the ipa-client-install tool discovers an IPA server.
2) Make use of the ipa-client-install tool. It can be called with the following syntax to directly enroll a PC into IPA:
/usr/sbin/ipa-client-install -U [--domain=example.com] [--server=ipamaster.example.com] [--realm=EXAMPLE.COM]

If --domain, --server and --realm are omitted, these fields will be populated by the following algorithm:
The longest DNS suffix of the hostname that satisfies a lookup of _SERVICE.domain.com (so host.sub.domain.com would check _ldap.sub.domain.com and then _ldap.domain.com)

where SERVICE is ldap._tcp, kerberos and kerberos._udp, respectively.

If you have any other questions, please feel free to ask.

Note You need to log in before you can comment on or make changes to this bug.