#4812 Switch nsslapd-unhashed-pw-switch to nolog
Opened 4 years ago by mkosek. Modified 3 days ago

Since 389 DS version, 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

2 years ago

Metadata Update from @frenaud:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1591895 (was: todo)

10 months ago

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

10 months ago

Metadata Update from @frenaud:
- Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.5 backlog)

10 months ago

Metadata Update from @tbordaz:
- Issue assigned to tbordaz (was: someone)

a month ago

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)

a month ago

@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?

Login to comment on this ticket.