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@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@5-cent.us" m.roth@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@centos.org http://lists.centos.org/mailman/listinfo/centos