Bug 1057836
| Summary: | Password Policy Improvement for IPA | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Andrew N <anelson> |
| Component: | ipa | Assignee: | Martin Kosek <mkosek> |
| Status: | CLOSED DUPLICATE | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | dpal, rcritten |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-06 14:55:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andrew N
2014-01-25 05:30:30 UTC
I suspect you're leaving out some detail. What is the problem creating the registration user and properly setting the password on it? It is then capable of registering any host and is independent of the cloud and it is a one-time operation. A user's password a a host one-time password are completely independent things. I do not think you are doing it correctly. You should not use user account for provisioning rather use host or service account for that matter or if you prefer user do not use password but rather a keytab. This is the way how we successfully integrate with different orchestration and provisioning systems. Here is an example: http://projects.theforeman.org/projects/foreman/wiki/RealmJoinIntegration Please let us know if you see any problems with this approach. Rob, When you create a user and assign a password to it, the password is flagged as needing to be changed by the user, meaning the account cannot be used until the user changes it directly. What I'm trying to do is create something akin to a service account, one that has narrowly defined privileges. In such a situation it would be desirable for the administrator to set the password directly and not have it flagged as needing to be changed by the user. In addition since I'm looking for "Service Accounts" it would be beneficial for such accounts to not have posix attributes. If this capability is already there, I apologise but it wasn't easy to find. Dimitri, Unfortunately the link you mentioned has one step available which is not available in the use case I'm up against, that is the ability to tell IPA about the host being configured. Unless I write some CGI or similar script on an infrastructure box which then performs the actions you mention on behalf of the client. In a way I'm looking for a way to register a host to IPA via kickstart, without having to rely on an external system to proxy the registration to IPA, but rather directly register to IPA from within the provisioning script. You can create service accounts in IPA but they will not be kerberos accounts, just ldap with no POSIX. If this is what you are looking for here is an example: http://www.freeipa.org/page/EJabberd_Integration_with_FreeIPA_using_LDAP_Group_memberships#Create_Bind_account_in_FreeIPA This bug is a bit stale. I see Dmitri and Rob provided suggestions, I hope they helped. To me, it seems that the whole discussion revolves around system accounts with non-expiring passwords. I plan to link this bug to upstream tickets deadling with system accounts: https://fedorahosted.org/freeipa/ticket/4082 https://fedorahosted.org/freeipa/ticket/2801 Moving to 7.0 product and linking to ticket 4082. I will merge this request with Bug 1199524 as it would be done under this RFE. *** This bug has been marked as a duplicate of bug 1199524 *** |