The same user should be able to login from multiple clients at the same time so as long as the gids and uids on your file system are consistent across the board that's a non issue.
But a word of advice DO NOT PUT THE USERS FOR YOUR SERVICES IN AD OR ANY OTHER LDAP SERVER!!!!
Its a horrible idea because if you loos LDAP connectivity and th SSD cache fails you server turns into a paperweight. That and the nature of how file system lookup of gid uid maps and acls work on Linux and Unix weren't designed with remote authentication in mind so every file access generates a lookup query SSD alleviates this but again if SSD fails you will fall back to doing a DOS attack on your LDAP server. This is one of the old common problems people had with nscd the default tuning options were optimized for local file based lookups and not for nss or LDAP so it would get over welmed and would either crash or worse get into a loop where its trying to answer expired requests delivered via the memory mapped file instead of the socket. By the way that memory mapped file default setting instead of using the socket was the actual cause of most of the issues but I digress.
Only use LDAP for users that actually login and never for root.
-- Sent from my HP Pre3
On Mar 27, 2013 3:56 PM, James M. Pulver <jmp...@cornell.edu> wrote:
So we're working along our SL6 and AD Server 2008R2 integration, using SSSD for authentication and such. We've realized that AD won't allow groups and users to have the same name. For common software like puppet and quemu that has this setup, what do you do? Change the program configuration to use a different group name? Do some hackery with OUs and sAMAccountNames and have it use gids (do the right things do this)? Technet says sAMAccountName must be unique and cannot be munged...
--
James Pulver
LEPP Computer Group
Cornell University
