CentOS - Jun 2015 - managing logins for different classes of servers

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?

Matt Garman wrote:
> 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?
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. <g>

        mark

We use group membership and ?AllowGroups? in /etc/ssh/sshd_config
We define which group(s) can go on which machines in our puppet manifest
and let puppet enforce the ssh_config content accordingly.

For the machines not connecting to our LDAP server for authorization, we
tell puppet which users to create on which machines. It?s still complex
but at least we don?t rely on manual config based on an excel sheet.


Val?re Binet [C]
IT Security Administrator
Kelly Government Solutions On-Site at the NIH
NIH / NIA / IRP
Tel : 410 558 8013
mailto:  binetv at nia.nih.gov

NCTS performance comments and survey at:
https://niairpkiosk.irp.nia.nih.gov/content/ncts-user-survey






On 6/4/15, 3:34 PM, "m.roth at 5-cent.us" <m.roth at 5-cent.us>
wrote:
>Matt Garman wrote:
>> 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?
>
>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. <g>
>
>        mark
>
>_______________________________________________
>CentOS mailing list
>CentOS at centos.org
>http://lists.centos.org/mailman/listinfo/centos