puppet facter for password hashing algorithm on a per OS basis

[Warron French]

Hello, I was hoping someone could help with answering this question, for the following scenario.

On our network we have some OLD ( I mean 1/06, up to 1/09) Solaris 10 SPARC servers and workstations along with newer Solaris 10 SPARC servers (running even the lastest revisions, like 1/13); and we have CentOS servers and workstations.

The password hashing algorithm is different between the OLD Solaris 10 SPARC servers and workstations versus the newer recently rebuilt Solaris 10 1/13 SPARC servers and workstations; the older ones run with MD5 for password hashing, we don't want that.  Even some of the Solaris 10 machines that running the newer Solaris 10 1/13 (build a couple of years ago) might be running with the MD5 hashing algorithm.  All of our CENTOS systems though, thank goodness, are running with the sha-512 (yay!).

Anyway, we have a potential project to use puppet to populate/generate LOCAL (not AD/LDAP) accounts across all of our systems and want our passwords for each of the accounts added to be the same; but of course, if the 

password attribute given to the user resource in the puppet code is of an incorrect hash-type, then that account will not work properly.

That is why I am asking for help, to achieve this particular goal.

Thank you in advance,

Warron 

[Garrett Honeycutt]

On 2/10/16 8:38 AM, Warron French wrote:
> Hello, I was hoping someone could help with answering this question, for
> the following scenario.
>
> On our network we have some OLD ( I mean 1/06, up to 1/09) Solaris 10
> SPARC servers and workstations along with newer Solaris 10 SPARC servers
> (running even the lastest revisions, like 1/13); and we have CentOS
> servers and workstations.
>
> The password hashing algorithm is different between the OLD Solaris 10

> SPARC servers and workstations versus the newer *recently
> rebuilt* Solaris 10 1/13 SPARC servers and workstations; the *older ones
> *run with *MD5*for password hashing, we don't want that. Even some of

> the Solaris 10 machines that running the newer Solaris 10 1/13 (build a
> couple of years ago) might be running with the MD5 hashing algorithm.

> *All* of our CENTOS systems though, thank goodness, are running with

> the sha-512 (yay!).
>
>
> Anyway, we have a potential project to use puppet to populate/generate

> *LOCAL *(not AD/LDAP) accounts across all of our systems and want our

> passwords for each of the accounts added to be the same; but of course,
> if the

> /password/ attribute given to the *user* resource in the puppet code is

> of an incorrect hash-type, then that account will not work properly.
>
> That is why I am asking for help, to achieve this particular goal.
>
> Thank you in advance,
> Warron
>

Hi Warron,

Supporting many OS's, I often hit this problem and solve it through
Hiera. There you can specify different password hashes based on a
mixture of facts such as osfamily and operatingsystemmajrelease.

While the hashes are not plain text, they can still easily be cracked.
Suggest taking a look at hiera-eyaml[1] to encrypt them.

[1] - https://github.com/TomPoulton/hiera-eyaml

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[John Warburton]

Warron

Use the operatingsystemrelease fact and decide the hash to use based on that.

It will spit out something like 10_u9 by reading /etc/release. This isn't too bad, but if you patch a server built as u9 with a current patch set, the actual OS will be u11 no matter what /etc/release says, so beware

You can look at projects.puppetlabs.com/issues/11082 you can see the mapping between 1/06 (I hear ya) and the update number. There is a link to the Oracle document that maps that out too

John

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ccd6ba2d-6f0e-45b7-9946-e99ec9cd78fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
John Warburton
Ph: 0417 299 600
Email: jwarb...@gmail.com

[warron.french]

John/Garret, thanks but the hash-type isn't specific to os&release, it is manually defined/altered by the sysadmin.

Does that help any?

To be more detailed, I might have something like the following:

CentOS-6.X. 12 nodes all hash=sha-512,
Solaris 10u6 13 nodes all hash=bsdmd5, but...
Solaris 10u6 4 nodes all hash=sha-512, AND
Solaris 10u11 8 nodes all hash=bsdbf, but...
Solaris 10u11 3 nodes all hash=sha-512.

I can see where you might say, then patch and augment all up to Solaris 10u11 with hash=sha-512; I work in a secured VERY BUSY environment so it's not quite that simple.

Thank you both,

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAJLFxXmSU-H20DhyUTxRYwWT56nHVbJLd1qkGYfx4GB-8AWHQ%40mail.gmail.com.

[John Warburton]

Ah manual changes...

Ok you need some way to identify which hosts use which hash type and classify them as such. 

We have an external node classifier, and we would set a parameter for the host to say hash_type => 'bsdmd5' for example. You could default if osfamily is Redhat to not even look for the parameter as all Centos nodes will be the same

No node classifier? Not sure how you would do this? A custom fact interrogating the hash type?

John

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJdJdQkwh4Xcq%3DJPBf6vNyebNKNj-UjuiKMDuK0mp6o1%3DriGYg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Garrett Honeycutt]

On 2/10/16 9:33 PM, John Warburton wrote:
> Ah manual changes...
>
> Ok you need some way to identify which hosts use which hash type and
> classify them as such.
>
> We have an external node classifier, and we would set a parameter for
> the host to say hash_type => 'bsdmd5' for example. You could default if
> osfamily is Redhat to not even look for the parameter as all Centos
> nodes will be the same
>
> No node classifier? Not sure how you would do this? A custom fact
> interrogating the hash type?
>
> John
>
> On Thursday, 11 February 2016, warron.french <warron...@gmail.com

> <mailto:warron...@gmail.com>> wrote:
>
> John/Garret, thanks but the hash-type isn't specific to os&release,
> it is manually defined/altered by the sysadmin.
>
> Does that help any?
>
> To be more detailed, I might have something like the following:
>
> CentOS-6.X. 12 nodes all hash=sha-512,
> Solaris 10u6 13 nodes all hash=bsdmd5, but...
> Solaris 10u6 4 nodes all hash=sha-512, AND
> Solaris 10u11 8 nodes all hash=bsdbf, but...
> Solaris 10u11 3 nodes all hash=sha-512.
>
> I can see where you might say, then patch and augment all up to
> Solaris 10u11 with hash=sha-512; I work in a secured VERY BUSY
> environment so it's not quite that simple.
>
> Thank you both,
>
> On Feb 10, 2016 7:13 PM, "John Warburton" <jwarb...@gmail.com

> <javascript:_e(%7B%7D,'cvml','jwarb...@gmail.com');>> wrote:
>
> Warron
>
> Use the operatingsystemrelease fact and decide the hash to use
> based on that.
>
> It will spit out something like 10_u9 by reading /etc/release.
> This isn't too bad, but if you patch a server built as u9 with a
> current patch set, the actual OS will be u11 no matter what
> /etc/release says, so beware
>
> You can look at projects.puppetlabs.com/issues/11082

> <http://projects.puppetlabs.com/issues/11082> you can see the

> mapping between 1/06 (I hear ya) and the update number. There is
> a link to the Oracle document that maps that out too
>
> John
>
> On Thursday, 11 February 2016, Warron French
> <warron...@gmail.com

> <javascript:_e(%7B%7D,'cvml','warron...@gmail.com');>> wrote:
>
> Hello, I was hoping someone could help with answering this
> question, for the following scenario.
>
> On our network we have some OLD ( I mean 1/06, up to 1/09)
> Solaris 10 SPARC servers and workstations along with newer
> Solaris 10 SPARC servers (running even the lastest
> revisions, like 1/13); and we have CentOS servers and
> workstations.
>
> The password hashing algorithm is different between the OLD
> Solaris 10 SPARC servers and workstations versus the newer

> *recently rebuilt* Solaris 10 1/13 SPARC servers and

> workstations; the *older ones *run with *MD5*for password

> hashing, we don't want that. Even some of the Solaris 10
> machines that running the newer Solaris 10 1/13 (build a
> couple of years ago) might be running with the MD5 hashing

> algorithm. *All* of our CENTOS systems though, thank

> goodness, are running with the sha-512 (yay!).
>
>
> Anyway, we have a potential project to use puppet to

> populate/generate *LOCAL *(not AD/LDAP) accounts across all

> of our systems and want our passwords for each of the
> accounts added to be the same; but of course, if the

> /password/ attribute given to the *user* resource in the

> puppet code is of an incorrect hash-type, then that account
> will not work properly.
>
> That is why I am asking for help, to achieve this particular
> goal.
>
> Thank you in advance,
> Warron
>
> --
> You received this message because you are subscribed to the
> Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/ccd6ba2d-6f0e-45b7-9946-e99ec9cd78fe%40googlegroups.com

> <https://groups.google.com/d/msgid/puppet-users/ccd6ba2d-6f0e-45b7-9946-e99ec9cd78fe%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> John Warburton
> Ph: 0417 299 600
> Email: jwarb...@gmail.com

> <javascript:_e(%7B%7D,'cvml','jwarb...@gmail.com');>

>
> --
> You received this message because you are subscribed to the
> Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to puppet-users...@googlegroups.com

> <javascript:_e(%7B%7D,'cvml','puppet-users%2Bunsu...@googlegroups.com');>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/CAAJLFxXmSU-H20DhyUTxRYwWT56nHVbJLd1qkGYfx4GB-8AWHQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAAJLFxXmSU-H20DhyUTxRYwWT56nHVbJLd1qkGYfx4GB-8AWHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to puppet-users...@googlegroups.com

> <javascript:_e(%7B%7D,'cvml','puppet-users%2Bunsu...@googlegroups.com');>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/CAJdJdQkwh4Xcq%3DJPBf6vNyebNKNj-UjuiKMDuK0mp6o1%3DriGYg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQkwh4Xcq%3DJPBf6vNyebNKNj-UjuiKMDuK0mp6o1%3DriGYg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> John Warburton
> Ph: 0417 299 600

> Email: jwarb...@gmail.com <mailto:jwarb...@gmail.com>
>

Hello,

On your EL systems you can support multiple hash types. Not sure how
Solaris handles that. As John mentioned, you could use an ENC if you
want to dictate what to use as opposed to having the system figure it
out. You could use Hiera as I mentioned if you want the system to
determine the hashing method based on some fact. Going that route, you
could create a custom fact to aid in that approach.

Another approach would be to use plain text passwords (though still
encrypted in the Hiera data with heira-eyaml) and write a function that
takes the arguments of the password and the hashing type or use
generate() and call openssl, which would return the password hash
generated with the hashing algorithm you specified.

[warron.french]

John, thank you.  I don't know how to write that kind of code yet; but at least now I have something to research.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAJLFxWk8DYUiCB3nKVGRLmH398m46_DYDkdkT-W2OxzqgSp9g%40mail.gmail.com.