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 place. 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 Help-cfengine@cfengine.org http://cfengine.org/mailman/listinfo/help-cfengine
