Please fix the image so that it does not store passwords in clear text

[siddjain]

This image stores passwords as clear text. Could this be fixed please so that passwords are stored as {SSHA}?

fwiw we modified the config to add olcPasswordHash: {SSHA} per this but it does not have any effect.

before:

$ cat config/cn=config/olcDatabase={-1}frontend.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 caf1c0c0
dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
structuralObjectClass: olcDatabaseConfig
entryUUID: 315ac7fd-f18d-4dae-bad4-a4bb13bdac67
creatorsName: cn=config
createTimestamp: 20190429193904Z
entryCSN: 20190429193904.019284Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190429193904Z

after:

bash-4.4# cat /etc/openldap/slapd.d/'cn=config'/'olcDatabase={-1}frontend.ldif'
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 648305b0
dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
structuralObjectClass: olcDatabaseConfig
entryUUID: b5e993b8-588e-4442-8b6e-184bc4b83544
creatorsName: cn=config
createTimestamp: 20190430195010Z
olcPasswordHash: {SSHA}
entryCSN: 20190430204532.177131Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20190430204532Z

but passwords continue to be stored in clear text (base64 encoded).

[siddjain]

[1] is another link we came across on how to enable password hashing. The steps are quite different so we are not sure whether this is more correct or [2].

Is it possible that there is some module or something that needs to be enabled in the Dockerfile configuration for olcPasswordHash to take effect?

[tiredofit]

I'll have to take a look at this in a few days as I'm a bit a) under the weather b) have a few work related things on the go that are burning. I'm considering wrapping this into the image as a container startup routine based on an environment variable. I think that would be our best and easiest option to target most users.

[tiredofit]

I just took a quick peek at my running configuration and it seems I have already had it set, likely a manual setting, which is perhaps why you are not seeing these hashed results. I import the ppolicy.schema from /etc/openldap/schema on container init but based on your link that would need to be added to the overlay in the config database. I can't say for sure as I wasn't involved in the heavy migration of our systems to this container, just involved in the building.

To err on the side of caution, I'm thinking of if some var ie HASH is other than plaintext then apply it both to the olc config as per 2 and then also apply that as per 1. It'll be a few days as I mentioned above.

[siddjain]

Thanks Dave.

The other thing I can think of is - did we add the olcPasswordHash entry to the right file?

where is the code that is importing the ppolicy.schema from /etc/openldap/schema on container init?

when we looked at ppolicy.schema file, it looks like it just contains policies like password length, what characters it should have, when it should expire and so on. It doesn't contain anything pertaining to hashed passwords at all.

[tiredofit]

I would be line 408 - 411 of 10-openldap which does that. But you are correct, that schema looks very strange. Since it's an overlay schema it simply provides the possibility of supporting those values, however doesn't create any ppolicies in itself. If you take a peek at your raw filesystem inside config you'll see where the entries actually reside. A quick grep on my system came up with this:

grep -R Hash
olcDatabase={-1}frontend.ldif:olcPasswordHash: {SHA}
olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyHashCleartext: TRUE

[siddjain]

this is what we get when we do a grep of Hash:

bash-4.4# grep -R Hash
schema/corba.schema:#        RMI:ClassName:HashCode[:SUID]
schema/corba.schema:#    "java.lang.String"). "HashCode" is the object's hash code (that is,
slapd.d/cn=config/olcDatabase={-1}frontend.ldif:olcPasswordHash: {SSHA}

so I think we added the entry to the right file. we do not see any

olcDatabase={1}mdb/olcOverlay={2}ppolicy.ldif:olcPPolicyHashCleartext: TRUE

this is what we have:

bash-4.4# ls 'olcDatabase={1}mdb'
'olcOverlay={0}memberof.ldif'  'olcOverlay={1}refint.ldif'

[siddjain]

also we don't see any line 408 - 411 in 10-openldap. there is just one file in that directory - this and it has only 12 lines

[tiredofit]

OK that would do it - Would need to setup Ppolicy. I think I know where my Ppolicy came from, which is from my openldap-fusiondirectory container which sets it up automatically.

Lines 260 -274 of that repo has this:

	cat <<EOF > /tmp/04-fusiondirectory-ppolicy.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy

dn: olcOverlay=ppolicy,olcDatabase={1}${BACKEND},cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPpolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicies,${BASE_DN}
olcPPolicyUseLockout: TRUE
olcPPolicyHashCleartext: TRUE
EOF

And I'm adding it with this: ldapadd -Y EXTERNAL -H 'ldapi:///' -Q -f /tmp/04-fusiondirectory-ppolicy.ldif

[tiredofit]

Sorry with regards to the 10-openldap - I am meaning /install/etc/cont-init.d/10-openldap which is where all the container setup is, the s6/services/10-openldap/run is simply a run script to allow restarts/graceful shutdowns.

[siddjain]

Thanks Dave. Lines 260 -274 fixed it.