In the message dated: Mon, 25 Nov 2013 16:57:31 -0800,
The pithy ruminations from Adam Compton on
<Re: [lopsa-discuss] Opinions on integrating Linux machines with AD?> were:
=> The way we do this at $WORK is roughly the following:
=>
=> * Each Linux host has an /etc/krb5.conf that tells it about the AD realm
Same here.
=> * We run a script that queries AD via LDAP for all of the user and group
=> data and crafts /etc/passwd and /etc/group accordingly (retaining system
=> service accounts, etc.)
In our environment, only selected users (about 150 out of ~5K+ in the
enterprise) have access to our Linux servers, so authorization is done
locally, in the form of entries in /etc/{passwd,shadow}.
Login names are identical to AD.
Authentication is handled entirely by AD.
=> * sshd is configured with "GSSAPIAuthentication yes"
=> * We instruct users to use "GSSAPIAuthentication yes" in their ssh
=> .config files, and to run "kinit" at appropriate intervals or
=> automatically on login, etc.
Hmmm...something to consider for desktop Linux machines. I wonder if that
would give us SSO for users who authenticate via AD on their desktop to login
(via SSH, with GSSAPIAuthentication) to our cluster.
[SNIP!]
=> configuration has some more features on top of this (UIDs are derived
=> from the RID in AD, so they're consistent for that user across all
We create UIDs and GIDs locally.
=> "loginShell" AD attribute is respected; disabled accounts are disabled,
Same here, if the account is disabled in AD, the user cannot login.
=> The downside of this configuration is that logins will not function if
=> AD is unavailable or if a user can't get a TGT for whatever reason; we
=> maintain system accounts with known SSH authorized_keys so specially
=> selected ops people can log in to troubleshoot things.
Same.
=>
=> This is a pretty unique setup; I don't know of anybody else who has
=> their AD integration organized in this way. Most people I've seen either
[Raises hand]
I don't know if it's all that unique...
[SNIP!]
=> get comprehensive group membership and authorization for basically free,
=> and users can be members of both AD-derived and system-native groups
=> trivially (which is sometimes tricky with the other solutions). I don't
Yes. We don't rely on any AD-derived groups (the enterprise doesn't store
group info with enough granularity for us), but we use local groups very
heavily.
Mark
=> have the ability to publish the script but I'd be happy to explain in
=> greater detail if anybody likes.
=>
=> - Adam
=>
--
Mark Bergman
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
