#4812 Switch nsslapd-unhashed-pw-switch to nolog
Closed: fixed 2 months ago by frenaud. Opened 4 years ago 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

2 years ago

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

a year 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

a year ago

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

a year ago

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

4 months 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)

4 months 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?

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

2 months ago

master:

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

ipa-4-6:

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

ipa-4-7:

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

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

2 months ago

Login to comment on this ticket.

Metadata