Locked/Unlocked states in user module

[Romeo Theriault]

Would a patch that adds two new states, locked and unlocked, be accepted into the user module?

My use case is this: I have a lot of machines with lots of different users that have access to different machines. (i.e. It's not known ahead of time all of the machines a user has access to.) A user quits/retires/gets fired and I need to lock their account across all of the machines.

I currently have a play book that checks if they exist on a given machine and then if they do locks their account. While not critical I think it would be nice to do this with the user module. Something like this:

name: lock joes account

user: name=joe state=locked

Which would check if they exist and if they do lock the account (if not already locked). The unlock state would obviously do the opposite. 

--

Romeo

[Michael DeHaan]

Absolutely, that sounds great.

I would believe we don't need 'unlocked', as 'present' should be
unlocked, just 'locked'.

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

[Romeo Theriault]

On Sun, Feb 24, 2013 at 4:24 AM, Michael DeHaan <michael...@gmail.com> wrote:

Absolutely, that sounds great.

Cool, I'll work on it.

 

I would believe we don't need 'unlocked', as 'present' should be
unlocked, just 'locked'.

How would one unlock the account now that it's locked?

--

Romeo

[Romeo Theriault]

On Sun, Feb 24, 2013 at 9:13 AM, Romeo Theriault <romeo.t...@maine.edu> wrote:

I would believe we don't need 'unlocked', as 'present' should be
unlocked, just 'locked'.

How would one unlock the account now that it's locked?

Guess I should add to this, I've not had a real-life use case for the 'unlock' feature like I have for 'lock' but I can imagine a possible need to temporarily lock a users account and then unlock it at a later date. An example might be, the security team could ask us to temporarily lock their account while they undergo an internal investigation.

I'm not super concerned if you don't want the unlock, but it seems, to me anyway, to make sense to have.

--

Romeo

[Erick Tapia]

Has this feature been implemented? 

[Romeo Theriault]

No, I never got around to implementing it. I don't *think* it's been implemented in the modules by anyone else either. I haven't checked recently though. I usually just run a command like "passwd -l <user>" or "passwd -u <user>" to do the deed.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/303b526c-7c16-4e67-aa9e-ae4ff103ee15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Romeo

[Brian Coca]

user expiration was the last thing implemented IIRC, this and password
expiration are the 2 things missing from the module.




--
Brian Coca

[Alan Harkleroad]

Are we able to do this yet?

As we create new users across our network, by default their accounts are locked on creation for security until they are unlocked for initial use. Is there a way to use ansible to unlock the same user account across multiple machines with one playbook or ad hoc command?

[enri....@gmail.com]

As Micheal DeHaan answers we don't need unlock, because present is the same.

For locking, just type two exclamation marks in the password field, for example:

- name: add admin user

  user:

    state: present

    uid: 1001

    name: example

    comment: Example User

    password: !!

---

Enri Peters

Op zondag 24 februari 2013 10:42:51 UTC+1 schreef Romeo Theriault:

[enri....@gmail.com]

I only tested this on CentOS 7.5

Op woensdag 30 mei 2018 09:02:51 UTC+2 schreef enri....@gmail.com: