Puppet User Administration, set password only at creating of user-accounts

[house_mann]

HI their,

i'm very new to puppet and can't find an solutions to get this up and running...
User creation works well. But when the user "devop" (or all others) change his password, it will overwrite after next 'puppet-run' to the hardcoded-one.
Correctly, because there is no setup/config to prevent this, when users exists on the node.
Is there a simple setup for this case? Only set password for non-existing users!?

Thanks.
ako

[Dan White]

This is a bash script I use on Red Hat 5 systems.
------------------------------------
#!/bin/bash
# Looking for "!!" in the second field of the user's shadow information
# This says that the password has never been set

rc=`/bin/grep $1 /etc/shadow | awk -F":" '($2 == "!!")' | wc -l`

if [ $rc -eq 0 ]
then
    exit 1
else
    exit 0
fi
------------------------------------
In my manifest, is this resource:
------------------------------------
            exec { "${username}-password":
                path    => ['/bin','/usr/bin'],
                command => "mkpasswd -l 30 -C 5 -d 5 -s 5 ${username}",
                require => User[$username],
                onlyif  => "/etc/puppet/scripts/checkShadow.bash ${username}",
            }
----------------------------------------------
"mkpasswd" is a nice little utility in the "expect" package.

Hope this halps

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

[Jose Luis Ledesma]

Would be nice to have something like 'initial_password' in the user resource.

Perhaps a solution could be create a custom fact with all the users of the server, and set an 'if' statement before the user resource.

Hth

[Darin Perusich]

I filed a feature request for this about a year ago.

https://tickets.puppetlabs.com/browse/PUP-1331
https://projects.puppetlabs.com/issues/15037
--
Later,
Darin

> --
> 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/bc2b23e8-2020-47e9-a103-794ef3f5cc8b%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[house_mann]

Ygor, thanks to the scripting. I'll try this later, looks good.

And thanks to those other hints and opinions...

ako

[William Thomas]

Is there an issue with using subscribe?  So in my virtual resource definition I have:

define accounts::virtual ($uid,$realname,$pass) {

  user { $title:

    ensure            =>  'present',

    uid               =>  $uid,

    gid               =>  $title,

    shell             =>  '/bin/bash',

    home              =>  "/home/${title}",

    comment           =>  $realname,

#    password          =>  $pass,

    password_max_age => '90',

    password_min_age => '0',

    groups     => ['sudo'],

    managehome        =>  true,

    require           =>  Group[$title],

  }

  group { $title:

    gid               =>  $uid,

  }

  exec { "/usr/sbin/usermod -p \'$pass\' $title":

    refreshonly => true,

    subscribe => User[$title],

    #    logoutput => true,

  }

...

...

...

And this is starting from Scott Lowe's blog:
http://blog.scottlowe.org/2012/11/25/using-puppet-for-account-management/

I guess the only gotcha I see is if something changes and causing the user to get updated, it will reset the password to the "default" 

[jcbollinger]

Just so.  Imagine a user changing their default shell via chsh, and then not only having it changed back, but also having their password unexpectedly reset.  Or imagine changing the secondary groups or password aging properties declared in that accounts::virtual definition, and having everyone's password reset.  I wouldn't want to be you.

An "initial_password" parameter might be a convenience for some people, and probably not hard to implement; on that basis I think it could be a worthy enhancement to Puppet.  Nevertheless, I cannot think of a usage mode that would satisfy any but the most lax security policy.  Although I don't think it's the tool's job to dictate policy to its users, I can understand giving low priority to a request for such a feature.

Admins looking in this direction would in most cases be better served by a bona fide centralized user DB, such as LDAP or even NIS.


John