Since 389 DS version 1.3.1.2, there is an option to disable keeping track of clear text user passwords in the main replication changelog - Bugzilla RFE.
This option defaults to on and is needed for winsync. However, this option should be turned to nolog for the FreeIPA default and only enabled on servers having winsync replication agreement.
on
nolog
As we found out, this option needs to be set on all FreeIPA servers when winsync is enabled. So this calls for some topology plugin based solution, if we decide that the topology plugin should also serve selected cn=config attributes.
cn=config
Discussed with simo, adding the functionality to Topology plugin would be rather a feature creep we want to avoid. We may eventually end with other plugin distributing cn=config values or simply letting admins enable the option if they want to use winsync.
We should revisit this problem with next version.
Metadata Update from @mkosek: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @frenaud: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1591895 (was: todo)
Issue linked to Bugzilla: Bug 1591895
See also 389-ds issue 49789: By default, do not manage unhashed password 389-ds plans to set the attribute to OFF by default, which means that freeipa installer should force it to NOLOG in the general use case, and ON when winsync is used.
When set to ON, we could at least encrypt the changelog
Metadata Update from @frenaud: - Issue close_status updated to: None
Metadata Update from @frenaud: - Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.5 backlog)
Metadata Update from @tbordaz: - Issue assigned to tbordaz (was: someone)
Metadata Update from @tbordaz: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1639644 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1591895)
@frenaud I think that a big question needs to be asked which is what is the threat that you are trying to protect from in encryption of the chagelog? Given the decryption material is in the same filesystem, it's not like encryption of the changelog does anything in a meaningful way unless you also prompt-for the nss-db pw every startup.
It's all to tempting to say "ohh here is something throw encryption on it", but we have to ask why are we encrypting it, to protect it from who and what? How could someone attempt to decrypt it?
For example, most security advice would state that once someone is on the domain controller, then they have the kerberos master key anyway. Let alone in IPA the existance of the ipaNTHash, or even the ability to read the passwords during ldap binds or other. So is changelog encryption really protecting us from anything?
@firstyear My proposal to encrypt is not targeted at attacks only, but also in order to avoid unneeded exposure to clear text password when the admin is calling dbscan -f on the cldb. Let's imagine a sysadmin with good intentions, debugging a replication issue, and using cldb to check the most recent CSN available in the retro changelog. He doesn't want to spy on but nevertheless is able to see unhashed#user#password in clear. Sure, even with encryption, he would be able to decrypt it but IMHO it's making a huge difference: encryption would protect from unwanted exposure.
Metadata Update from @tbordaz: - Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/2935 (was: 0)
master:
Metadata Update from @frenaud: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1639644, https://bugzilla.redhat.com/show_bug.cgi?id=1639647 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1639644)
ipa-4-6:
ipa-4-7:
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.