With ipa-server 4.5.0-21, ipa-replica-prepare fails to prepare a replica file when the passwordHistory is enabled. In order to reproduce:
Install ipa master in domain-level 0
$ ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $APASSWORD --setup-dns --auto-forwarder --auto-reverse --domain-level 0 -U
Modify the password policy in order to enable password history
$ kinit admin Password for admin@IPADOMAIN.COM $ ipa pwpolicy-mod --history=5 Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 5 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
Create a replica file for replica1, the cmd is successful:
$ ipa-replica-prepare replica1.ipadomain.com Directory Manager (existing master) password: Preparing replica for replica1.ipadomain.com from master.ipadomain.com Creating SSL certificate for the Directory Server Creating SSL certificate for the dogtag Directory Server Saving dogtag Directory Server port Creating SSL certificate for the Web Server Exporting RA certificate Retrieving CA certificates Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-replica1.ipadomain.com.gpg The ipa-replica-prepare command was successful
Create a replica file for replica2, the command fails with:
$ sudo ipa-replica-prepare replica2.ipadomain.com Directory Manager (existing master) password: Preparing replica for replica2.ipadomain.com from master.ipadomain.com Constraint violation: Password reuse not permitted The ipa-replica-prepare command failed.
The logs show that ipa-replica-prepare is performing a password modify extended operation that is failing:
conn=25 op=0 BIND dn="cn=directory manager" method=128 version=3 conn=25 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" ... conn=25 op=3 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="IPA Password Manager" conn=25 op=3 RESULT err=19 tag=120 nentries=0 etime=0
In debug mode the output is the following:
ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 321, in run self.copy_ds_certificate() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 358, in copy_ds_certificate self.update_pki_admin_password() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 586, in update_pki_admin_password api.Backend.ldap2.modify_password(dn, self.dirman_password) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 390, in modify_password self.conn.passwd_s(str(dn), old_pass, new_pass) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 975, in error_handler raise errors.DatabaseError(desc=desc, info=info) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: DatabaseError: Constraint violation: Password reuse not permitted ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint violation: Password reuse not permitted ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The ipa-replica-prepare command failed.
The tool ipa-replica-prepare is trying to update the password for the entry uid=admin,ou=people,o=ipaca with the current password of cn=directory manager. The entry uid=admin,ou=people,o=ipaca was created with the same password as cn=directory manager, hence the password mod operation is trying to replace the password with the same value and the password plugin makes the operation fail because of password history.
According to 389-ds documentation, the password policy should be bypassed when the op is done by directory manager: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy
Warning When using a password administrator account or the Directory Manager (root DN) to set a password, password policies are bypassed and not verified. Do not use these accounts for regular user password management. Use them only to perform password administration tasks that require bypassing the password policies.
Is there a workaround for this? I tried setting the history size to 0, but I continued to get the error:
Constraint violation: Password reuse not permitted The ipa-replica-prepare command failed.
You may try to delete the passwordHistory attribute of uid=admin,ou=people,o=ipaca, it should allow you to run ipa-replica-prepare.
Thanks frenaud - I can confirm that this solved the problem for me. The modify operation was carried out as follows:
Create the file "ipa-pwhist-remove":
dn: uid=admin,ou=people,o=ipaca changetype: modify delete: passwordHistory -
Execute: ldapmodify -D "cn=directory manager" -W -f ipa-pwhist-remove
ldapmodify -D "cn=directory manager" -W -f ipa-pwhist-remove
Following this action the replica file can be prepared without issue. Thnak you!
Metadata Update from @rcritten: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1545755
Issue linked to Bugzilla: Bug 1545755
Metadata Update from @rcritten: - Issue priority set to: normal - Issue set to the milestone: FreeIPA 4.8
An actual issue seems to be a bug in ipa-pwd-extop in ipapwd_pre_mod():
ipa-pwd-extop
.... /* if krb keys are being set by an external agent we assume password * policies have been properly checked already, so we check them only * if no krb keys are available */ if (has_krb_keys == 0) { ret = ipapwd_CheckPolicy(&pwdop->pwdata); if (ret) { errMesg = ipapwd_error2string(ret); rc = LDAP_CONSTRAINT_VIOLATION; goto done; } }
this check is done without taking into account a is_root variable which holds information whether we are a directory manager. Note that PKI CA admin user has no Kerberos identity, thus the check applies here.
is_root
Metadata Update from @abbra: - Issue assigned to abbra
Pull request: https://github.com/freeipa/freeipa/pull/2106
master:
Failed to apply patches onto origin/ipa-4-6. Manual backport is needed.
ipa-4-8:
ipa-4-6:
ipa-4-7:
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @abbra: - Custom field changelog adjusted to FreeIPA password checking plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, integrated CA administrator account during replica deployment.
Metadata Update from @abbra: - Custom field changelog adjusted to FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, integrated CA administrator account during replica deployment. (was: FreeIPA password checking plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, integrated CA administrator account during replica deployment.)
Metadata Update from @abbra: - Custom field changelog adjusted to FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, an integrated CA administrator account during deployment of more than one replica in some cases. (was: FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, integrated CA administrator account during replica deployment.)
Metadata Update from @abbra: - Custom field changelog adjusted to FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes by Directory Manager or a password synchronization manager. This issue affected, among others, an integrated CA administrator account during deployment of more than one replica in some cases. (was: FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes. This issue affected, among others, an integrated CA administrator account during deployment of more than one replica in some cases.)
Metadata Update from @abbra: - Custom field changelog adjusted to FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes by the Directory Manager or a password synchronization manager. This issue affected, among others, an integrated CA administrator account during deployment of more than one replica in some cases. (was: FreeIPA password policy plugin in 389-ds was extended to exempt non-Kerberos LDAP objects from checking Kerberos policy during password changes by Directory Manager or a password synchronization manager. This issue affected, among others, an integrated CA administrator account during deployment of more than one replica in some cases.)
Login to comment on this ticket.