Best Practice - replacing /etc/passwd and +@netgroups

[Betsy Schwartz]

We're running primarily RHEL6, and Puppet Enterprise 3.2

In our non-puppetized world, we make heavy use of netgroups (stored in ldap, entered in /etc/passwd) to control access to servers.

There's been much discussion and some confusion about the best way to control user access going forwards. The ldap netgroups are also used for sudoers permissions.

It feels like this is a very "vanilla" way to use password files and netgroups. Does someone here have a good way to manage this, or a better idea?

The primary puppet programmer in our group starting working with the forge accounts module, but fell down a rathole because RHEL6 default system accounts have multiple users with the same home directory and the forge module wouldn't accommodate that.  I don't want to spend a huge amount of time and effort coding around accommodating RHEL system user accounts that never, ever, change. My gut instinct is that we should find some way (Augeas?) to assemble /etc/passwd accounts from a default set of text entries plus some custom lines for each server. 

If we don't come up with a better idea we're going to end up pushing password files out as *files*, which I understand is not the DevOps Puppet Way but it's better than what we're doing now.

Is this, indeed, a Solved Problem? What is everyone else doing?
thanks Betsy

[Matt Zagrabelny]

On Sun, Jul 13, 2014 at 3:01 PM, Betsy Schwartz
<betsy.s...@gmail.com> wrote:

> Is this, indeed, a Solved Problem? What is everyone else doing?
> thanks Betsy

Disclaimer:

I am not doing this. Yet.

Have you looked at FreeIPA?

-mz

[Betsy Schwartz]

Hi Matt,

I've heard of FreeIPA, but that feels like a longer project (and would probably get tied into AD integration and another project we have going to combine multiple business units)

For Phase One  we're hoping to centralize and automate something close to what we have now.


Thanks Betsy

-mz

--
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/CAOLfK3W6wqS3QRwLHwCauXF59Oez2goRmDH5mZF%3DzTsf2u7g6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan Dietrich]

On So, 2014-07-13 at 16:01 -0400, Betsy Schwartz wrote:
> We're running primarily RHEL6, and Puppet Enterprise 3.2
>
> In our non-puppetized world, we make heavy use of netgroups (stored in
> ldap, entered in /etc/passwd) to control access to servers.

Would pam_access work for your use case?
Instead of adding the netgroups to passwd, you configure this
in /etc/security/access.conf.
There are also some modules on Puppet Forge, which allow management of
this file.

Btw. Augeas can not parse /etc/passwd, if you add the +@netgroup lines.

Regards,
Stefan

[Betsy Schwartz]

Thank you! pam access may well be the right direction to go for us.

I'm still sort of boggled that nobody seems to be using puppet for /etc/passwd. That always seemed to us to be the *first* thing we'd want to get under centralized control.

I understand that centralized control reduces the need for direct logins, but I'd think people would still need dba's on db machines and devs on dev machines and such

--
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/1405320731.4976.8.camel%40clarkdale.desy.de.

[Christopher Wood]

Um, why? There are more regularized methods of RBAC than touching /etc/passwd. For my part I'd rather keep hosts as similar as possible and have authentication controlled elsewhere. That way I have complex manifests about user authentication on a subset of hosts, and simplified auth client manifests everywhere else.

> an email to [2]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [3]https://groups.google.com/d/msgid/puppet-users/1405320731.4976.8.camel%40clarkdale.desy.de.
> For more options, visit [4]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 [5]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [6]https://groups.google.com/d/msgid/puppet-users/CAAVLHR2zcB1yAGUT6NK6N6xJv8e_TfwHrB78V7hfCF1TOatEXw%40mail.gmail.com.
> For more options, visit [7]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:stefan....@desy.de
> 2. mailto:puppet-users%2Bunsu...@googlegroups.com
> 3. https://groups.google.com/d/msgid/puppet-users/1405320731.4976.8.camel%40clarkdale.desy.de
> 4. https://groups.google.com/d/optout
> 5. mailto:puppet-users...@googlegroups.com
> 6. https://groups.google.com/d/msgid/puppet-users/CAAVLHR2zcB1yAGUT6NK6N6xJv8e_TfwHrB78V7hfCF1TOatEXw%40mail.gmail.com?utm_medium=email&utm_source=footer
> 7. https://groups.google.com/d/optout

[Matt Zagrabelny]

> On Wed, Jul 16, 2014 at 10:24:26AM -0400, Betsy Schwartz wrote:
>> I'm still sort of boggled that nobody seems to be using puppet for
>> /etc/passwd. That always seemed to us to be the *first* thing we'd want to
>> get under centralized control.

We use nsswitch.

% man nsswitch.conf

% aptitude -F '%p' search '^libnss-'
libnss-cache
libnss-db
libnss-extrausers
libnss-gw-name
libnss-ldap
libnss-ldapd
libnss-lwres
libnss-mdns
libnss-myhostname
libnss-mysql
libnss-mysql-bg
libnss-pgsql1
libnss-pgsql2
libnss-rainbow2
libnss-sss
libnss-winbind
libnss-wrapper

-mz

[jcbollinger]

On Wednesday, July 16, 2014 9:24:35 AM UTC-5, Betsy Schwartz wrote:

Thank you! pam access may well be the right direction to go for us.

I'm still sort of boggled that nobody seems to be using puppet for /etc/passwd. That always seemed to us to be the *first* thing we'd want to get under centralized control.

Of course people use Puppet to manage /etc/passwd.  That's what the built-in User resource type is for (on systems that use /etc/passwd for their user database).  Puppet has had that forever.

The accounts module your guy was trying to use is probably trying to manage user home directories and/or their contents, not anticipating that multiple users would have the same home directory.  In fact, that could be ok for managing ordinary users, but it should be avoided for system and service accounts anyway.  There may be a way to make it behave better for system accounts (extra parameters to set, for example).  Otherwise, ordinary User resources very likely can do everything you need to do for system accounts.

John