User creation, passwords, and expiration

[Ben Hosmer]

Synopsis:

You need to create user accounts from user names listed in pillar, set a default password, and then force that password to be changed next time they log in.

This is how I've been doing it:

pillar/users.sls:

sys-users:

  - joe

  - mike

  - sally

salt/users/init.sls

{% for users in pillar['sys-users']  %}

{{users}}:

  user.present:

    - shell: /bin/bash

    - home: /home/{{users}}

    - password: $1$wrYj9xuAmZyAzt7YPqhVk.

    - require_in: chage -d 0 {{users}}

{% endfor %}

{% for users in pillar['sys-users'] %}

chage -d 0 {{users}}:

  cmd:

    - run

{% endfor %}

I also realize I could have used the shadow module. 

Am I making it harder than it is? Is there a better way that I am missing?

Would it make sense to have an option in the user state to expire the password to force this change?

[Colton Myers]

Well, the biggest problem that I see is that this isn't very "stateful".  When you next run this state, it's going to change the users back to that default password and once again force them to change their passwords.  So I definitely wouldn't have this state in my highstate (top.sls), but would run it using `state.sls`.  I'm not really sure if there's a "stateful" way to do this, so that might just be your best bet.

--

Colton Myers

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

[Tim O'Guin]

What if he defined a "default_password_hash" option in pillar, then maybe a conditional in the state to only set the hash if it's a new user without an existing password? Not sure how the exact syntax would work on this, but it seems doable.

[Colton Myers]

That's true.  Because you have access to execution module in jinja (via the `salt` dictionary) you should be able to write an if clause to only include the hash if the user doesn't exist.

Definitely workable.

--

Colton Myers

[Luminous Salt]

On 2013-09-12 14:41, Colton Myers wrote:
> Well, the biggest problem that I see is that this isn't very
> "stateful".  When you next run this state, it's going to change the
> users back to that default password and once again force them to
> change their passwords.  So I definitely wouldn't have this state in
> my highstate (top.sls), but would run it using `state.sls`.  I'm not
> really sure if there's a "stateful" way to do this, so that might just
> be your best bet.
>

a key ``user:reset_password`` as a boolean would also be an interesting
way to take better control of this situation.

[Ben Hosmer]

Yeah, I am running it with state.sls. It is meant to be a one-off configuration for a common stack that I build along with common user accounts. I could have each user generate a hash and then send it to me.

[Ben Hosmer]

In the user state?

[Sam Lai]

Not if you set enforce_password: False on the user state
(http://docs.saltstack.com/ref/states/all/salt.states.user.html#module-salt.states.user).
The password is then only set if the user doesn't exist or no password
has been set.

Also, you'll need to change the cmd.run state to a cmd.wait state, and
then change the require_in directive in the user state to a watch_in
directive. That way the 'chage -d 0 {{users}}' command is only
executed if a change occurs in the user state.

[Ben Hosmer]

Sam, thanks for jarring my memory about this. I hadn't even considered it.