After installation this password is not needed anymore with dogtag10 and DS instances integration so we should remove the password from the file.
Should IPA do it? This is an internal PKI configuration, not sure if we should mess with it. CC-ing Nathan to advise.
Replying to [comment:1 mkosek]:
Yes, this is something we should change and test. Simo, Ade, and I discussed this issue on IRC. The Directory Manager password is used for a newly created Dogtag instance, but the IPA installer then makes the changes necessary to use client certificate authentication instead. The Directory Manager password is left behind, but it's not used anymore. The password should be removed as a part of switching over to client certificate authentication.
Nathan or Rob, are you sure that the password should be removed? When working on http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password, I found out that this value is used both for the described DM password change procedure and in ipa-replica-manage, see patch in #3594.
ipa-replica-manage
After discussion with Ade, he confirmed that it should be safe to remove the internaldb password.
I understand that it may be safe from PKI side, but how should ipa-replica-manage operate then when it needs this password to run the PKCS12Password (see http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password)?
Moving unfinished November tickets to January.
Martin, AFAICT this affects ipa-replica-prepare, not manage, and it uses the internal value which is the NSS database password, not internaldb which is the DM password. So I think this should be ok.
Hmm, right. Maybe I was overcautious and this indeed can be removed. I had concerns because I saw that internaldb has effect on running PKI and had to be updated when DM password changed, see for example https://bugzilla.redhat.com/show_bug.cgi?id=1050212#c6.
internaldb
But this was Dogtag 9, things might have changed in Dogtag 10. When I now tried to remove internaldb, restart PKI and prepare a replica file, everything worked.
Moving stabilization tickets that do not affect FreeIPA 4.0 release usability in any significant way to 4.0.1 stabilization milestone.
FreeIPA 4.0.1 was released, moving to next bugfixing release milestone.
This needs a fix in Dogtag: https://fedorahosted.org/pki/ticket/1142
The fix will be in Dogtag 10.2; if we want it in 10.1 (f20) Ade can open a ticket for that version.
Internal change, no clone
ipa-4-1:
master:
Related Dogtag issue: https://fedorahosted.org/pki/ticket/1142
Metadata Update from @simo: - Issue assigned to jcholast - Issue set to the milestone: FreeIPA 4.1
Login to comment on this ticket.