help with cfengine for account management in very large environments - Security

This is a discussion on help with cfengine for account management in very large environments - Security ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

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

  1. help with cfengine for account management in very large environments

    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


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

    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

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

    Thanks for all the replies. Using LDAP and then exporting to a flat
    passwd file sounds promising but also kind of silly. There's probably
    some really good GUIs that will help you deal with LDAP easily
    though...that would probably be a plus. Also, a friend sent me this
    link today:

    href="http://www-128.ibm.com/developerworks/linux/library/l-road10.html?ca=dgr-lnxw03devcfperl">User
    management with cfperl


+ Reply to Thread