Managing Logins For Different Classes Of Servers

Home » CentOS » Managing Logins For Different Classes Of Servers
CentOS 2 Comments

Our environment has several “classes” of servers, such as
“development”, “production”, “qa”, “utility”, etc. Then we have all our users. There’s no obvious mapping between users and server class. Some users may have access to only one class, some may span multiple classes, etc. And for maximum complexity, some classes of machines use local (i.e. /etc/passwd, /etc/shadow) authentication, others use Kerberos.

With enough users and enough classes, it gets to be more than one can easily manage with a simple spreadsheet or other crude mechanism. Plus the ever-growing risk of giving a user access to a class he shouldn’t have.

Is there a simple centralized solution that can simplify the management of this? One caveat though is that our “production” class machines should not have any external dependencies. These are business-critical, so we try to minimize any single point of failure
(e.g. a central server). Plus the production class machines are distributed in multiple remote locations.

Any thoughts?

2 thoughts on - Managing Logins For Different Classes Of Servers

  • Matt Garman wrote:

    I agree completely with your manager: nobody but the production admins, and the “system owners”, should be allowed on the machine, unless you want to allow selected sr. people to be able to get on in the event that something that’s just gone into production has just broken, to see if it can be a quick fix, or whether you need to roll it back.

    Likewise, neither developers nor “ordinary users” should be allowed on the q/a systems, which ought to be clones of production, with the exceptions of the new releases.

    I’m not sure whether “ordinary users” should be allowed on dev systems, unless they need to look in on what’s going on.

    In a true professional environment, only the admins get to move things to prod; dev can promote in the VCS, and the testers can bring that in, then promote so that the admins can roll that out during a prearranged maintenance window.

    All of this is easily done. We have the organization-wide AD (sigh), which authenticates, and allows single sign-on, single password. Then there’s authorization…. We have a large /etc/password, but if you’re not allowed on, your shell is /bin/noLogin.