Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057836 - Password Policy Improvement for IPA
Summary: Password Policy Improvement for IPA
Keywords:
Status: CLOSED DUPLICATE of bug 1199524
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-25 05:30 UTC by Andrew N
Modified: 2015-03-06 14:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-06 14:55:48 UTC


Attachments (Terms of Use)

Description Andrew N 2014-01-25 05:30:30 UTC
Description of problem:
At present within IPA there is no way to reset a password and not have it expired.  I have read the document which outlines the reasons for this ( http://www.freeipa.org/page/NewPasswordsExpired ), however there are real world scenarios where setting a password in IPA and not have it expired is desirable.

One such example is an automated client registration in rapidly changing environments, such as cloud.  If I create a registration user and give it the appropriate permissions to enroll a host and then use the account name and password as a parameter to ipa-client-install with the unattended option, the error message returned is completely useless "Unable to read password".  Enabling debug mode actually shows the problem.

I agree with the primary reasons for the policy but there needs to be a way to override it for specific use cases, either via a password policy or some other means during the password reset process.

Given this situation the existing one time password host registration process was unsuitable because the host name is dynamic and based on DHCP which is externally controlled (such as Amazon Web Services), unless one pre-configures all possible host entries in a subnet.

Version-Release number of selected component (if applicable):
[root@idm1 ~]# rpm -qa | grep ipa
ipa-python-3.0.0-37.el6.x86_64
libipa_hbac-1.9.2-129.el6_5.4.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-admintools-3.0.0-37.el6.x86_64
ipa-server-3.0.0-37.el6.x86_64
ipa-client-3.0.0-37.el6.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-37.el6.x86_64
libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
python-iniparse-0.3.1-2.1.el6.noarch


How reproducible:
Always

Steps to Reproduce:
See description

Actual results:
Frustration and mild anger

Expected results:
It works (tm)

Comment 2 Rob Crittenden 2014-01-26 02:33:23 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.

Comment 3 Dmitri Pal 2014-01-27 02:45:18 UTC
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.

Comment 4 Andrew N 2014-01-28 19:02:13 UTC
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.

Comment 5 Dmitri Pal 2014-01-28 19:39:41 UTC
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

Comment 6 Martin Kosek 2014-02-06 12:31:04 UTC
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

Comment 7 Martin Kosek 2014-02-11 12:44:40 UTC
Moving to 7.0 product and linking to ticket 4082.

Comment 8 Martin Kosek 2015-03-06 14:55:48 UTC
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 ***


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