[email protected]
[Top] [All Lists]

Re: help with cfengine for account management in very large environments

Subject: Re: help with cfengine for account management in very large environments
From: Frank Ranner
Date: Tue, 06 Jun 2006 23:02:12 +1000
Newsgroups: gnu.cfengine.help, comp.os.linux.security
Aaron wrote:
> I work for a company with a large deployment of cfengine managed
> servers, 1000 or more systems in total. The problem is that the way
> things were initially put together has turned into a huge mess in terms
> of user account management. There's maybe 50-100 separate passwd and
> shadow files for the entire production environment...all in cfengine.
> Adding and removing accounts is a clumsy operation of running different
> scripts on various cfengine master servers. As a result, it takes
> forever to add or modify individual accounts and there also isn't
> enough control over who has accounts on which systems.
> I guess I'm looking for suggestions on how to deal with the mess. It
> seems like the obvious solution is migrating to LDAP or some kind of
> equivalent. That seems daunting because I don't know how I would ever
> manage a seamless transition on such a complex production network where
> extended downtime is unacceptable. Perhaps after consolidating all of
> the cfengine passwd files, I could enter everything into an LDAP server
> and then export from LDAP to a few distinct passwd files (based on
> security requirements) and then push those out with cfengine. You can
> probably tell I'm grasping at straws here.
> I'm also wondering about the idea of having just a few accounts on the
> individual systems such as dba, admin, etc. but I don't know how I
> would be able to tell who had performed what actions with such a setup
> (not that I really can now but at least I can see who logged in and
> when a particular user sudo'd to a privileged account).
> Any suggestions are greatly appreciated.
> Thanks,
> -Aaron

ldap is probably the only solution, and may not be as daunting as you 
think. For a start, you can run ldap in parallel with your 'file' based 
system simply by having entries like:

passwd: files ldap

in /etc/nsswitch.conf. This means you can create a test user in ldap 
that doesn't have an entry in /etc/passwd+shadow and get the system 
working for that single user on a couple of test servers. Eventually you 
move users from file entries into ldap.

You will need to consider what users gain access to what servers. You 
create profiles for your different server types which contain the search 
query that locates a user. Normally it is simple such as 'uid=%user' 
where %user is the name supplied by the login process. Since you may not 
want all users to log into all servers you might have the filter for 
oracle servers set like '&((uid=%user)(memberOf=oracleDBA))'. A user 
record may look like:

dn: uid=robertc,ou=people,dc=example,dc=com
objectclass: person (+ other objectclasses)
uid: robertc
memberOf: oracleDBA
memberOf: lotusnotesDBA

The profile refered to above would also be stored in ldap. Each ldap 
client would have an ldap.conf file which would contain the address of 
the ldap server, a proxy dn that the client can log in as to search the 
directory, and the profile for that client. The ldap.conf would be 
distributed or created by cfengine for each system with the appropriate 
profile entry.

Your other idea of populating files from ldap also has merit. Since each 
server can have ldap client software, you simply run a script that 
periodically issues 'ldapsearch', selecting person records for people 
that are in the appropriate group for the server. The ldif output from 
ldapsearch can easily be massaged into passwd/shadow format and 
concatenated with the fixed system accounts. When you change the master 
record in ldap, all the hosts will recreate their files in due course. 
This system can serve as a stop gap system until a full migration takes 

If you have implemented a 'gold' server as your cfengine master, it can 
also be the read/write ldap master. Allocate a few read-only replicas, 
(which can be set up by cfengine) to help carry the load. If your 
servers are geographically dispersed, put a replica in each region.

In case you're wondering, I'm in the process of implementing ldap 
myself, although I have far less systems than you. However I have the 
added wrinkle of providing ldap access to network devices, using 
freeradius. My systems are mainly Solaris, and ldap support is, well, 
not a walk in the park.

have fun.
regards, Frank Ranner
Help-cfengine mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>