On 4 Feb 2019, at 17:07, Zarko D <zarko(a)etcfstab.com> wrote:
Thanks for reply William, I believe I restored db with command "ipa-restore -d
--data /path/ipa-data-2018-12-30-20-12-00" but 389ds still fails to start .
<snip>
ns-slapd[3533]: [03/Feb/2019:22:55:04.336762406 -0800] attrcrypt - All prepared ciphers
are not available. Please disable attribute encryption.
ns-slapd[3533]: [03/Feb/2019:22:55:04.346874658 -0800] attrcrypt - attrcrypt_unwrap_key:
failed to unwrap key for cipher AES
ns-slapd[3533]: [03/Feb/2019:22:55:04.347913178 -0800] attrcrypt - attrcrypt_cipher_init:
symmetric key failed to unwrap with the private key; Cert might have been renewed since
the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key
value.
ns-slapd[3533]: [03/Feb/2019:22:55:04.350743010 -0800] attrcrypt - attrcrypt_unwrap_key:
failed to unwrap key for cipher 3DES
ns-slapd[3533]: [03/Feb/2019:22:55:04.351680066 -0800] attrcrypt - attrcrypt_cipher_init:
symmetric key failed to unwrap with the private key; Cert might have been renewed since
the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key
value.
ns-slapd[3533]: [03/Feb/2019:22:55:04.352567754 -0800] attrcrypt - All prepared ciphers
are not available. Please disable attribute encryption.
systemd[1]: dirsrv(a)x-COM.service start operation timed out. Terminating.
systemd[1]: Failed to start 389 Directory Server x-COM..
systemd[1]: Unit dirsrv(a)x-COM.service entered failed state.
systemd[1]: dirsrv(a)x-COM.service failed.
_______________________________________________
So this looks like an issue in the IPA restore tool. attrcrypt is deeply tied to the *nss
database* in /etc/dirsrv/slapd-x-COM, however, most people fundamentally misunderstand and
think it relates to the *certificates* (apparently no one listens to me :) ). I would
hazard a guess the ipa backup tool dumps certs from the db but doesn’t backup the
secmod.db file, which has caused this problem on restore.
So as a result, it looks like when you restored the IPA from backup, it probably
re-built/removed/changed the nss db content which has effectively erased your attribute
encryption key.
Now I think attribute encryption does very little to protect from real threats anyway, but
I don’t control the IPA project, so I don’t know why they thought it was reasonable to
enable it.
In this case, you need to use your *latest* nss db from /etc/dirsrv/slapd- (IE from BEFORE
you started the restore process …), and put it back into the location. I think you need
key3.db, cert8.db and secmod.db files to fix this. Provided you can copy those back in,
then it “should” startup ….
Alternately, if you want to do this “the DS way”, you could on another master ipa server
do “db2ldif -r” (-r is important!), then on the restoring master in this state, do an
ldif2db. There are some attr encryption parameters to check. I think you need to just
disable attribute encryption in db2ldif -r call, and then it “should work” on the import.
Finally, another option is to disable attribute encryption, and then do a full-reinint via
the replication process, but given this is IPA there are lots of possible edgecases that I
don’t understand here, and I don’t know the ipa tools well enough to tell you how to
trigger the replication re-init. The above db2ldif process is basically the same thing
anyway :)
Otherwise, I’m sorry, but the best advice is to remove the IPA replica and rebuild it. I’m
really really sorry, but it looks like IPA’s assumptions around attrcrypt here may have
really hurt you :(
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs