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
* 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.)
* 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.
With this configuration, users can connect with SSH and authenticate
with their Kerberos TGT, and the list of groups is pulled directly from
AD. Further, the script that builds /etc/passwd can be configured to
limit the users it configures to only the members of one or more
specific groups, so users in AD who are not in those groups are never
even configured on the box and cannot possibly log in. Our actual
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
machines and the entire lifetime of that account object; the
"loginShell" AD attribute is respected; disabled accounts are disabled,
etc.), but that's essentially the idea.
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.
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
use winbind or pam_ldap, but both of those were a little bit too flaky
for our taste (particularly in that, if the service connection is
interrupted for a moment, uid lookups can block or fail entirely and
cause crazy undefined behavior). With this mechanism, we get the
benefits of centralized user and group management, without (most of) the
drawbacks of being tied to a centralized server for user data. Plus, we
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
have the ability to publish the script but I'd be happy to explain in
greater detail if anybody likes.
- Adam
On 11/25/13 4:19 PM, Peter Loron wrote:
Hola. At $WORK we have an Active Directory domain that we would like
to use for authentication and authorization for some Linux boxes
(primarily CentOS 6.4). We don't need anything fancy as far as pushing
out group policy, etc. Just logins and groups.
I've done a bit with using LDAP + Kerberos, but am wondering about
going further and using winbind to actually join the machines to the
domain. Also, there are some commercial products (some have free
versions) which play in this space.
My experience with winbind from several years ago was that it was
flaky and temperamental...possibly changed now?
Does anybody have experiences to share here?
Thanks!
-Pete
_______________________________________________
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/
_______________________________________________
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/
