Bug 239055
Summary: | Update to support centralized authentication server | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Brian Stevens <bstevens> |
Component: | authconfig | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.0 | CC: | bstein, dpal, gdeschner, jfenal, sgallagh, sghosh, sgrubb, ssorce |
Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-09-08 08:45:46 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 464903 | ||
Bug Blocks: | 239054, 246164 |
Description
Karl MacMillan
2007-05-04 17:42:16 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Since this bugzilla is in a component that is not approved for the current release, it has been closed with resolution deferred. You may reopen this bugzilla for consideration in the next release. 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. This bugzilla has Keywords FutureFeature or HardwareEnablement and thus does not meet the release criteria for FasTrack. This FasTrack request has been denied. This bugzilla must be addressed in a minor release. Given IPA can have a complex configuration setup, what we should aim at is building a simple interface in authconfig that calls out an ipa provided script for the actual configuration. The idea is to provide a minimal set of parameters needed by the script and sufficient for it to connect to the ipa server and automatically configure the client based on information retrieved from the server. I think there are 1 necessary fields to provide and 3 optional. Necessary field: IPA REALM Optional fields: Admin username Admin password IPA Server FQDN The realm is necessary to be bale to try and find the ipa server through DNS queries, if that fails the IPA Server FQDN becomes necessary. The Admin credentials are optional because the admin may already have a valid kerberos ticket. The Admin username should be prepoluated by checking the credential cache, if there is no credential cache username and password become necessary options, if a credential cache exists the username is prefilled (the user must be able to change it and add an optional password in case the ticket found is not that of a privileged admin. The good thing about this design is that it could be used unchanged also to configure samba/winbindd I think. The amount of information needed would be the same. If autodiscovery of credentials caches etc.. is too complex for a first release it is perfectly fine to require admin username and password in a first implementation, and not make them options. Simo. This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". The support for adding/removing pam_sss and nss_sss to the configuration files is already there. Backporting the full support from RHEL-6 would be too intrusive. |