On Aug 27, 2:05 pm, Kyle Mallory <jesuswasir...@gmail.com> wrote:
> We have a policy that requires all user passwords to expire after 90
> days. We also use puppet for managing all users on our machines. Our
> hope was, when our passwords expire, we could update the puppet
> manifest which would propogate to all our servers, thus updating all
> our passwords.
It seems a bit strange to me that you are managing users' passwords
for them in the first place. It is usually users' responsibility to
manage their own passwords. If you really do want to manage passwords
centrally, however, then why do you need a password expiration policy
in the first place? Instead, just change the passwords on whatever
schedule you choose. The point of enforcing an expiration policy is
to protect against users failing to change their passwords, so it
gains you nothing if users are not responsible for managing their
passwords in the first place. Just turn it off.
It sounds like you may be trying to use Puppet to cobble together a
single sign-on infrastructure. If so, then I recommend that you
instead use real SSO tools such as directory service authentication
(i.e. LDAP, Active Directory), or even NIS authentication.
> The problem is, the User type (w/ manage_passwords enabled and ruby-
> shadow installed) will only set the password in /etc/shadow, but it
> doesn't manage any of the other shadow parameters, namely the
> sp_lstchg parameter). As a result, after our 90-day period, all of
> our passwords have updated, but the individual machines still think
> that the passwords have expired, and refuses to let us log in.
>
> This seems a bug in the User type, in that if the password changes
> from the previous password, it should also reset the last-changed
> field as well. Ideally, if the User type is supporting passwords, it
> would be nice if there were properties to also specify the other
> shadow parameters, such as min, max, warn, expire, etc.
I agree that puppet failing to update the last-changed shadow field
looks like a bug in the User type (more specifically, in one of its
Providers). I, too, had a look at the code, but it is not at all
obvious where the password update code is, or by what path it is
invoked. (Obgrumble: Puppet code is extremely difficult to follow.)
John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
