#4812 Switch nsslapd-unhashed-pw-switch to nolog
Closed: fixed by frenaud. Opened by mkosek.

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.


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.

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:

  • 67490acb045697302cc16d34cac3a81bc1f909ba Switch nsslapd-unhashed-pw-switch to nolog

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:

  • 200fcbc285249cfc8c3564ee444173186d4a0c9f Switch nsslapd-unhashed-pw-switch to nolog

ipa-4-7:

  • eec9655393e550f8ee4b4c0eb2da624c4dae9267 Switch nsslapd-unhashed-pw-switch to nolog

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata