I''m guessing this is a common use case, but I wasn''t able to
find
anything in the site FAQ. We''re looking at using Puppet on about 100
servers to control which user groups have access to which servers.
The use case is as follows:
We have Groups of servers, for example:
CUSTOMERservers (serverA, serverB, ...,serverK)
ADMINISTRATIVEservers (serverL,server, serverM, ...,serverP)
DATABASEservers (serverQ, serverR,, ..., serverZ)
We have groups of users:
ITusers (user1, user2, ... user11)
CUSTOMERSUPPORTusers (user12,user13, ..., user14)
DBAuser (user15,user16)
We would to be able to say:
on servergroup {CUSTOMERservers} ensure usergroup {ITusers,
CUSTOMERSUPPORTusers} are present.
on servergroup {DATABASEservers} ensure usergroup {DBAuser,
ITusers} are present.
Currently, our solution, is to constantly rewrite the site.pp file, and
for each of the nodes, come up with something like:
node serverA
{
include cssn_group
include cssn_userITusers
include cssn_ssh
include cssn_sudo
#include cssn_revokeuser
}
node serverA
{
include cssn_group
include cssn_userICUSTOMERSUPPORTusers
include cssn_ssh
include cssn_sudo
#include cssn_revokeuser
}
...
node serverQ
{
include cssn_group
include cssn_userDBAuser
include cssn_ssh
include cssn_sudo
#include cssn_revokeuser
}
node serverQ
{
include cssn_group
include cssn_userITuser
include cssn_ssh
include cssn_sudo
#include cssn_revokeuser
}
...
Is there any form of inheritance, inclusion, group definition, or other
meta-architecture that would allow us to avoid having to create node
entries for every single server/user group combination?
What I would KILL for, would be the concept of:
nodeGroup - which could contain multiple nodes,
userGroup - which could contain multiple users.
Anybody hack something like that up, or should we start scripting the
big ol'' site.pp file generator? Are these files typically
autogenerated
to thousands of line long?
We ran into problems when we tried to do this:
node serverQ
{
include cssn_group
include cssn_userITuser
include cssn_userDBA
include cssn_ssh
include cssn_sudo
#include cssn_revokeuser
}
When we had users in both group userITuser and group userDBA - puppet
reallly didn''t like the duplicate lines.
How do other people manage the "many users to many servers in many
combinations" matrix of providing access to servers?
Thanks so much in advance,
g.
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
>How do other people manage the "many users to many servers in many >combinations" matrix of providing access to servers?I don''t have quite the same needs you do, but I do need user login restrictions on particular servers, and consistent uids. Here''s the basics of what I do: 1. Uids are kept consistent with a pre-existing Active Directory and Samba''s winbindd. If you don''t have this, I assume you have ldap or some other wide-ranging directory service that would be equivalent. 2. Puppetmaster generates a users.conf for each server class by concatenating lists of usernames in a users.conf.d folder. 3. The pam_listfile module ensures that the only users allowed to access the server are the ones listed in the server''s users.conf. That users.conf is grabbed from the puppetmaster. This is basically documented at http://tinyurl.com/24o9kq , but I may have missed a detail or three. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research 931 372-3601 / Tennessee Technological University
I''m going to second Mike''s approach. In this case, LDAP is definitely your friend. I''m currently working on generating the pam_listfile configuration file for each host from defined host attributes in LDAP. Unfortunately, I haven''t had that much time to work on it and thus haven''t been able to post anything, but I will if I get some time some day. Trevor On 03 Dec 2007 21:45:00 -0600, Mike Renfro <renfro@tntech.edu> wrote:> >How do other people manage the "many users to many servers in many > >combinations" matrix of providing access to servers? > > I don''t have quite the same needs you do, but I do need user login restrictions on particular servers, and consistent uids. Here''s the basics of what I do: > > 1. Uids are kept consistent with a pre-existing Active Directory and Samba''s winbindd. If you don''t have this, I assume you have ldap or some other wide-ranging directory service that would be equivalent. > > 2. Puppetmaster generates a users.conf for each server class by concatenating lists of usernames in a users.conf.d folder. > > 3. The pam_listfile module ensures that the only users allowed to access the server are the ones listed in the server''s users.conf. That users.conf is grabbed from the puppetmaster. > > This is basically documented at http://tinyurl.com/24o9kq , but I may have missed a detail or three. > > -- > Mike Renfro / R&D Engineer, Center for Manufacturing Research > 931 372-3601 / Tennessee Technological University > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
"How do other people manage the "many users to many servers in many combinations" matrix of providing access to servers?" We use Vintela - it lets you utilize Active Directory (AD) to manage user access to ''unix'' platforms. There is also a module in version 3 that allows you mediate access to Apache but I have not fooled around with that (yet). The basic idea (at least here) was that we have AD - and it''s not going away - so we might as well utilize it. We had been using NIS+ but ... frankly this is easier. http://www.vintela.com/ In the context of Puppet what I''m going to do is create a manifest to control the service and package and drop the license file onto the server. Brian Dunbar Systems Administrator Plexus Desk: (920) 751-3364 Cell: (920) 716-2027 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
We use kerberos and nis to manage all the accounts, then use puppet to control access to various groups of servers. Mainly through /etc/security/access.conf. I know others do a similar thing with ldap. It''s certainly much easier (and cleaner IMO) to manage all your users in one centralized place and then only use puppet to manage access for given users (groups of users etc) C On 12/4/07, Brian Dunbar <Brian.Dunbar@plexus.com> wrote:> > "How do other people manage the "many users to many servers in many > combinations" matrix of providing access to servers?" > > We use Vintela - it lets you utilize Active Directory (AD) to manage user > access to ''unix'' platforms. There is also a module in version 3 that allows > you mediate access to Apache but I have not fooled around with that (yet). > The basic idea (at least here) was that we have AD - and it''s not going away > - so we might as well utilize it. > > We had been using NIS+ but ... frankly this is easier. > > http://www.vintela.com/ > > In the context of Puppet what I''m going to do is create a manifest to > control the service and package and drop the license file onto the server. > > Brian Dunbar > Systems Administrator > Plexus > Desk: (920) 751-3364 > Cell: (920) 716-2027 > > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users > >-- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
<Geoff.Newell@barclayscapital.com>
2007-Dec-04 17:15 UTC
Re: Using puppet to manage user access to servers.
I have worked with several working approaches: 1) LDAP for authentication and host base access control. 2) LDAP for authentication and netgroups for access to servers also via LDAP. 3) Active Directory for all of the above. RHEL 5.1 has native AD support. No need for Vintela. Geoff Newell. ________________________________ From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Chris MacLeod Sent: 04 December 2007 17:06 To: Puppet User Discussion Subject: Re: [Puppet-users] Using puppet to manage user access to servers. We use kerberos and nis to manage all the accounts, then use puppet to control access to various groups of servers. Mainly through /etc/security/access.conf. I know others do a similar thing with ldap. It''s certainly much easier (and cleaner IMO) to manage all your users in one centralized place and then only use puppet to manage access for given users (groups of users etc) C On 12/4/07, Brian Dunbar <Brian.Dunbar@plexus.com> wrote: "How do other people manage the "many users to many servers in many combinations" matrix of providing access to servers?" We use Vintela - it lets you utilize Active Directory (AD) to manage user access to ''unix'' platforms. There is also a module in version 3 that allows you mediate access to Apache but I have not fooled around with that (yet). The basic idea (at least here) was that we have AD - and it''s not going away - so we might as well utilize it. We had been using NIS+ but ... frankly this is easier. http://www.vintela.com/ In the context of Puppet what I''m going to do is create a manifest to control the service and package and drop the license file onto the server. Brian Dunbar Systems Administrator Plexus Desk: (920) 751-3364 Cell: (920) 716-2027 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users -- stickm@gmail.com -==< Stick >==- ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------ _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Gordon H. Shephard
2007-Dec-04 19:01 UTC
Re: Using puppet to manage user access to servers.
Thanks Trevor and Mike. I read through "authentications-servers-the-next-generation", and it looks like it requires a "central authentication server" for credential validation instead of pushing the credentials out to the end servers. Our goal is to stop relying on network services (DNS, NIS, LDAP, Active Directory) as much as possible on our production servers for both security, scalability, and reliability reasons. Unlike an end-user system, our production systems have (or can have) almost absolute knowledge of the hosts and users that they want to communicate with, so the advantages of a remote directory (NIS, DNS) is less useful. What is useful, of course, is the consistency one gets from a "source of truth" directory. Our goal is to use Active Directory, which we already have deployed and keep up to date religously (it is the alpha and omega of everyone''s existence in the organization), to generate the puppet configuration files, and from there, keep all of the remote systems up to date with the users they should have on them, both removing and adding users as they come into active directory (and the respective groups on AD) as well as pushing new SSH keys when they change on the source. It will look something like this: Active Directory + Policy File ---> Puppet Configuration Files ---> Remote Servers. With Active Directory supplying the: UID Groups Usernames And the Policy File supplying: User Groups that belong on each server. I''ve done this in other organizations (using LDAP as the source of truth), and it usually involves a significant amount of script foo to make sure that the user accounts (and associated ssh authorized_keys) are present on the appropriate servers. Is this a reasonable use of puppet? I''m beginning to suspect that without the concept of "User Groups" and inheritance, plus the issues that puppet has with the duplicate usernames identified previously, we''re going to have to generate some pretty lengthy/verbose site.pp files. Right now we only have a hundred servers, but I could see it growing to several hundred over the next year, particularly with vmware. Internally we''re happy with NIS MAPs for configuring passwd, auto mounts, etc..., but I''d like to avoid using NIS in the DMZ and on our secure compartments. Does this sound like a reasonable use of puppet, or is it a case of wrong tool for the job?> -----Original Message----- > From: puppet-users-bounces@madstop.com > [mailto:puppet-users-bounces@madstop.com] On Behalf Of Trevor Vaughan > Sent: Tuesday, December 04, 2007 4:33 AM > To: Puppet User Discussion > Subject: Re: [Puppet-users] Using puppet to manage user > access to servers. > > I''m going to second Mike''s approach. > > In this case, LDAP is definitely your friend. > > I''m currently working on generating the pam_listfile configuration > file for each host from defined host attributes in LDAP. > > Unfortunately, I haven''t had that much time to work on it and thus > haven''t been able to post anything, but I will if I get some time some > day. > > Trevor > > On 03 Dec 2007 21:45:00 -0600, Mike Renfro <renfro@tntech.edu> wrote: > > >How do other people manage the "many users to many servers in many > > >combinations" matrix of providing access to servers? > > > > I don''t have quite the same needs you do, but I do need > user login restrictions on particular servers, and consistent > uids. Here''s the basics of what I do: > > > > 1. Uids are kept consistent with a pre-existing Active > Directory and Samba''s winbindd. If you don''t have this, I > assume you have ldap or some other wide-ranging directory > service that would be equivalent. > > > > 2. Puppetmaster generates a users.conf for each server > class by concatenating lists of usernames in a users.conf.d folder. > > > > 3. The pam_listfile module ensures that the only users > allowed to access the server are the ones listed in the > server''s users.conf. That users.conf is grabbed from the puppetmaster. > > > > This is basically documented at http://tinyurl.com/24o9kq , > but I may have missed a detail or three. > > > > -- > > Mike Renfro / R&D Engineer, Center for Manufacturing Research > > 931 372-3601 / Tennessee Technological University > > > > > > > > _______________________________________________ > > Puppet-users mailing list > > Puppet-users@madstop.com > > https://mail.madstop.com/mailman/listinfo/puppet-users > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
I would strongly advise against building any dependencies against non-free bits like Active Directory. While I can appreciate the goals that have been outlined here, I have to seriously question the wisdom of building such ties to software that is written for the sole purpose of creating and maintaining vendor lock-in. In a nutshell, this problem can be solved so many ways with Free Software like OpenLDAP that no sound justification exists for enslaving an environment to the EULA that governs AD. As for maintaining the client''s ldap/nss configs, I''d say puppet is the perfect tool for the job. Best, Adam Gordon H. Shephard wrote:> Thanks Trevor and Mike. > > I read through "authentications-servers-the-next-generation", and it > looks like it requires a "central authentication server" for credential > validation instead of pushing the credentials out to the end servers. > > Our goal is to stop relying on network services (DNS, NIS, LDAP, Active > Directory) as much as possible on our production servers for both > security, scalability, and reliability reasons. > > Unlike an end-user system, our production systems have (or can have) > almost absolute knowledge of the hosts and users that they want to > communicate with, so the advantages of a remote directory (NIS, DNS) is > less useful. > > What is useful, of course, is the consistency one gets from a "source of > truth" directory. > > Our goal is to use Active Directory, which we already have deployed and > keep up to date religously (it is the alpha and omega of everyone''s > existence in the organization), to generate the puppet configuration > files, and from there, keep all of the remote systems up to date with > the users they should have on them, both removing and adding users as > they come into active directory (and the respective groups on AD) as > well as pushing new SSH keys when they change on the source. > > It will look something like this: > > Active Directory + Policy File ---> Puppet Configuration Files ---> > Remote Servers. > > With Active Directory supplying the: > UID > Groups > Usernames > > And the Policy File supplying: > User Groups that belong on each server. > > I''ve done this in other organizations (using LDAP as the source of > truth), and it usually involves a significant amount of script foo to > make sure that the user accounts (and associated ssh authorized_keys) > are present on the appropriate servers. > > Is this a reasonable use of puppet? I''m beginning to suspect that > without the concept of "User Groups" and inheritance, plus the issues > that puppet has with the duplicate usernames identified previously, > we''re going to have to generate some pretty lengthy/verbose site.pp > files. > > Right now we only have a hundred servers, but I could see it growing to > several hundred over the next year, particularly with vmware. > > Internally we''re happy with NIS MAPs for configuring passwd, auto > mounts, etc..., but I''d like to avoid using NIS in the DMZ and on our > secure compartments. > > Does this sound like a reasonable use of puppet, or is it a case of > wrong tool for the job? > > >> -----Original Message----- >> From: puppet-users-bounces@madstop.com >> [mailto:puppet-users-bounces@madstop.com] On Behalf Of Trevor Vaughan >> Sent: Tuesday, December 04, 2007 4:33 AM >> To: Puppet User Discussion >> Subject: Re: [Puppet-users] Using puppet to manage user >> access to servers. >> >> I''m going to second Mike''s approach. >> >> In this case, LDAP is definitely your friend. >> >> I''m currently working on generating the pam_listfile configuration >> file for each host from defined host attributes in LDAP. >> >> Unfortunately, I haven''t had that much time to work on it and thus >> haven''t been able to post anything, but I will if I get some time some >> day. >> >> Trevor >> >> On 03 Dec 2007 21:45:00 -0600, Mike Renfro <renfro@tntech.edu> wrote: >>>> How do other people manage the "many users to many servers in many >>>> combinations" matrix of providing access to servers? >>> I don''t have quite the same needs you do, but I do need >> user login restrictions on particular servers, and consistent >> uids. Here''s the basics of what I do: >>> 1. Uids are kept consistent with a pre-existing Active >> Directory and Samba''s winbindd. If you don''t have this, I >> assume you have ldap or some other wide-ranging directory >> service that would be equivalent. >>> 2. Puppetmaster generates a users.conf for each server >> class by concatenating lists of usernames in a users.conf.d folder. >>> 3. The pam_listfile module ensures that the only users >> allowed to access the server are the ones listed in the >> server''s users.conf. That users.conf is grabbed from the puppetmaster. >>> This is basically documented at http://tinyurl.com/24o9kq , >> but I may have missed a detail or three. >>> -- >>> Mike Renfro / R&D Engineer, Center for Manufacturing Research >>> 931 372-3601 / Tennessee Technological University >>> >>> >>> >>> _______________________________________________ >>> Puppet-users mailing list >>> Puppet-users@madstop.com >>> https://mail.madstop.com/mailman/listinfo/puppet-users >>> >> _______________________________________________ >> Puppet-users mailing list >> Puppet-users@madstop.com >> https://mail.madstop.com/mailman/listinfo/puppet-users >> > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Gordon H. Shephard
2007-Dec-04 19:31 UTC
Re: Using puppet to manage user access to servers.
I was a Technical Editor for "Understanding and Deploying LDAP (2nd Edition)", worked at Netscape, Oblix, etc... I get and love open directories and despise AD as much as you do. :-) But: "Corporation" => Execs => "Blackberries" + Enterprise Calendaring => Microsoft Exchange => Active Directory. Ugly cycle that I''d like to break, but can''t until someone comes up with a reasonable alternative to Microsoft Exchange for Calendaring. Sometimes I think the entire Microsoft Empire is built on their calendaring solution. :-) Anyways, this is all orthogonal to Puppet, because I pull the information out of Active directory with: ldapsearch -h ADserver -b "cn=users, dc=silverspringnet, dc=com" .... And the back end can be replaced with my choice of LDAP servers. So, Adam, I couldn''t agree with you MORE, and dream of the day I can junk the vendor lock in that I despise with every day I have to deal with it. The nice thing is that I''m not making any native AD calls, it''s all ASN.1 BER on Port 389. :-) We''re still faced with problem of how to figure out how to generate these site.pp files. I''m just wondering if anyone else has ever done this? g.> -----Original Message----- > From: puppet-users-bounces@madstop.com > [mailto:puppet-users-bounces@madstop.com] On Behalf Of Adam Kosmin > Sent: Tuesday, December 04, 2007 11:15 AM > To: Puppet User Discussion > Subject: Re: [Puppet-users] Using puppet to manage user > access to servers. > > I would strongly advise against building any dependencies against > non-free bits like Active Directory. While I can appreciate the goals > that have been outlined here, I have to seriously question > the wisdom of > building such ties to software that is written for the sole > purpose of > creating and maintaining vendor lock-in. > > In a nutshell, this problem can be solved so many ways with Free > Software like OpenLDAP that no sound justification exists for > enslaving > an environment to the EULA that governs AD. > > As for maintaining the client''s ldap/nss configs, I''d say > puppet is the > perfect tool for the job. > > Best, > Adam > > > > Gordon H. Shephard wrote: > > Thanks Trevor and Mike. > > > > I read through "authentications-servers-the-next-generation", and it > > looks like it requires a "central authentication server" > for credential > > validation instead of pushing the credentials out to the > end servers. > > > > Our goal is to stop relying on network services (DNS, NIS, > LDAP, Active > > Directory) as much as possible on our production servers for both > > security, scalability, and reliability reasons. > > > > Unlike an end-user system, our production systems have (or can have) > > almost absolute knowledge of the hosts and users that they want to > > communicate with, so the advantages of a remote directory > (NIS, DNS) is > > less useful. > > > > What is useful, of course, is the consistency one gets from > a "source of > > truth" directory. > > > > Our goal is to use Active Directory, which we already have > deployed and > > keep up to date religously (it is the alpha and omega of everyone''s > > existence in the organization), to generate the puppet configuration > > files, and from there, keep all of the remote systems up to > date with > > the users they should have on them, both removing and > adding users as > > they come into active directory (and the respective groups on AD) as > > well as pushing new SSH keys when they change on the source. > > > > It will look something like this: > > > > Active Directory + Policy File ---> Puppet Configuration Files ---> > > Remote Servers. > > > > With Active Directory supplying the: > > UID > > Groups > > Usernames > > > > And the Policy File supplying: > > User Groups that belong on each server. > > > > I''ve done this in other organizations (using LDAP as the source of > > truth), and it usually involves a significant amount of > script foo to > > make sure that the user accounts (and associated ssh > authorized_keys) > > are present on the appropriate servers. > > > > Is this a reasonable use of puppet? I''m beginning to suspect that > > without the concept of "User Groups" and inheritance, plus > the issues > > that puppet has with the duplicate usernames identified previously, > > we''re going to have to generate some pretty lengthy/verbose site.pp > > files. > > > > Right now we only have a hundred servers, but I could see > it growing to > > several hundred over the next year, particularly with vmware. > > > > Internally we''re happy with NIS MAPs for configuring passwd, auto > > mounts, etc..., but I''d like to avoid using NIS in the DMZ > and on our > > secure compartments. > > > > Does this sound like a reasonable use of puppet, or is it a case of > > wrong tool for the job? > > > > > >> -----Original Message----- > >> From: puppet-users-bounces@madstop.com > >> [mailto:puppet-users-bounces@madstop.com] On Behalf Of > Trevor Vaughan > >> Sent: Tuesday, December 04, 2007 4:33 AM > >> To: Puppet User Discussion > >> Subject: Re: [Puppet-users] Using puppet to manage user > >> access to servers. > >> > >> I''m going to second Mike''s approach. > >> > >> In this case, LDAP is definitely your friend. > >> > >> I''m currently working on generating the pam_listfile configuration > >> file for each host from defined host attributes in LDAP. > >> > >> Unfortunately, I haven''t had that much time to work on it and thus > >> haven''t been able to post anything, but I will if I get > some time some > >> day. > >> > >> Trevor > >> > >> On 03 Dec 2007 21:45:00 -0600, Mike Renfro > <renfro@tntech.edu> wrote: > >>>> How do other people manage the "many users to many > servers in many > >>>> combinations" matrix of providing access to servers? > >>> I don''t have quite the same needs you do, but I do need > >> user login restrictions on particular servers, and consistent > >> uids. Here''s the basics of what I do: > >>> 1. Uids are kept consistent with a pre-existing Active > >> Directory and Samba''s winbindd. If you don''t have this, I > >> assume you have ldap or some other wide-ranging directory > >> service that would be equivalent. > >>> 2. Puppetmaster generates a users.conf for each server > >> class by concatenating lists of usernames in a users.conf.d folder. > >>> 3. The pam_listfile module ensures that the only users > >> allowed to access the server are the ones listed in the > >> server''s users.conf. That users.conf is grabbed from the > puppetmaster. > >>> This is basically documented at http://tinyurl.com/24o9kq , > >> but I may have missed a detail or three. > >>> -- > >>> Mike Renfro / R&D Engineer, Center for Manufacturing Research > >>> 931 372-3601 / Tennessee Technological University > >>> > >>> > >>> > >>> _______________________________________________ > >>> Puppet-users mailing list > >>> Puppet-users@madstop.com > >>> https://mail.madstop.com/mailman/listinfo/puppet-users > >>> > >> _______________________________________________ > >> Puppet-users mailing list > >> Puppet-users@madstop.com > >> https://mail.madstop.com/mailman/listinfo/puppet-users > >> > > _______________________________________________ > > Puppet-users mailing list > > Puppet-users@madstop.com > > https://mail.madstop.com/mailman/listinfo/puppet-users > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On 12/4/2007 1:01 PM, Gordon H. Shephard wrote:> Thanks Trevor and Mike. > > I read through "authentications-servers-the-next-generation", and it > looks like it requires a "central authentication server" for credential > validation instead of pushing the credentials out to the end servers.Could be one, could be several. Usernames, UIDs, and GIDs are handled with winbind. Passwords are ultimately handled via Kerberos.> Unlike an end-user system, our production systems have (or can have) > almost absolute knowledge of the hosts and users that they want to > communicate with, so the advantages of a remote directory (NIS, DNS) is > less useful.Not sure how you''ll handle passwords. If all you need is ssh, and everyone has a pre-exchanged authorized_keys file, then it should be a non-issue. In our case, we needed Samba, ssh, HTTP Basic, ESMTP, and IMAP, so we needed somewhere to look up actual passwords.> It will look something like this: > > Active Directory + Policy File ---> Puppet Configuration Files ---> > Remote Servers. > > With Active Directory supplying the: > UID > Groups > Usernames > > And the Policy File supplying: > User Groups that belong on each server.That should still be workable. You''d still need something running on puppetmaster to update a list of users in the groups, and you''d possibly need something in each server''s manifest to pull new authorized_keys files from wherever. As a short example, I have the following in our puppetmaster''s manifest: concatenated_file { "/etc/puppet/files/apps/pam_listfile/users.conf.default": dir => "/etc/puppet/files/apps/pam_listfile/users.conf.d"; "/etc/puppet/files/apps/pam_listfile/users.conf.ch204b": dir => "/etc/puppet/files/apps/pam_listfile/users.conf.ch204b.d"; } this in the central file server''s manifest: exec { "/usr/local/sbin/add-new-accounts": subscribe => File["/etc/security/users.conf"], refreshonly => true } and this in an active-directory-member class that the fileserver includes: "/etc/security/users.conf": source => [ "puppet:///files/apps/pam_listfile/users.conf.$hostname", "puppet:///files/apps/pam_listfile/users.conf.default" ]; All of that reruns add-new-accounts anytime users.conf gets updated. add-new-accounts is simply #!/bin/bash for name in `cat /etc/security/users.conf`; do if [ ! -d /home/CAE/$name ]; then mkdir /home/CAE/$name rsync -a /etc/skel/ /home/CAE/$name chown -R $name:users /home/CAE/$name fi done and could be extended fairly easily to expire old accounts that no longer were in users.conf. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Kosmin wrote:> I would strongly advise against building any dependencies against > non-free bits like Active Directory. While I can appreciate the goals > that have been outlined here, I have to seriously question the wisdom of > building such ties to software that is written for the sole purpose of > creating and maintaining vendor lock-in. > > In a nutshell, this problem can be solved so many ways with Free > Software like OpenLDAP that no sound justification exists for enslaving > an environment to the EULA that governs AD. >There are lots of justifications for this - some of them even sound. The issue is broader than ''one technology is more elegant than another technology'' and most organisations don''t make technology selection decisions based on that criteria. Other criteria like commercial, economies of scale, integration, duplication of infrastructure, policy, standardisation, and the ever popular politics all also factor in. But more importantly, many of us work in environments where said enslavement is a forgone conclusion and the result of corporate policy. The reality of the situation is that for identity management a huge number of shops use AD as the primary directory/repository for user credentials. Solutions, especially open source ones, hence have to be flexible enough to support this model - as unpleasant as many of us might find the model. Regards James Turnbull * * = Not a Microsoft employee but rather a pragmatist. - -- James Turnbull <james@lovedthanlost.net> - --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) - --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVbe59hTGvAxC30ARArTYAJ466//GceFXD/bIlYUzlk3sSiUccgCfdfNP AbVorQtA2gNfWPakVFgxtf0=GnW3 -----END PGP SIGNATURE-----