All passwords generated for a particular agent have the same salt about puppet-openldap HOT 5 CLOSED

There are a few ways to deal with this.

One option is to modify openldap_password to take additional values to use when generating the salt. Another option is to modify openldap_password to take a salt directly and require the user to handle salt generation (maybe with fqdn_rand_string, assuming that gets accepted into stdlib). I'm not particularly fond of those solutions, though.

The best option, IMO, is to get rid of openldap_password entirely and fold it into the openldap_database type, since as far as I can tell that's the only place it's useful (please correct me if I'm wrong here). Since the types have access to the current hash values, if provided with plaintext passwords, they can check to see if the current hash is valid for the password by writing a custom insync? method. If not, the plaintext password can be hashed with a salt generated using SecureRandom#random_bytes(4). Printing of the salts to the log can be prevented by writing custom is_to_s and should_to_s methods. See the user type for an example of this. Another parameter could be added to indicate what sort of hash to generate, maybe hash_type, which I recommend only supporting the values SSHA and none, the latter being provided if the user wanted to provide their own pre-hashed password for whatever reason.

Thoughts?

from puppet-openldap.

Pinging @mcanevet to make sure my comment was seen. Sorry if you already read this.

from puppet-openldap.

Integrating this into the provider seems like a good idea to me.

from puppet-openldap.

@elyscape looks like a good idea. I may not have much time to code this in the nexts few days, so a PR would be great.

from puppet-openldap.

I'm a bit busy myself, but I'll take a look and see what I can do. In the meantime, it might be a good idea to push out a point release reverting the 4b2f0b2.

from puppet-openldap.