[CentOS] managing logins for different classes of servers

Thu Jun 4 20:28:04 UTC 2015
Binet, Valere (NIH/NIA/IRP) [C] <binetv at nia.nih.gov>

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
Tel : 410 558 8013
mailto:  binetv at nia.nih.gov

NCTS performance comments and survey at:

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