|
On 03/25/2017 03:03 PM, Boylan, Ross
wrote:
Not entirely true, NFSv4 has the ability to map uid/gid between systems with the rpc.idmapd program, which uses the idmapd.conf configuration files.The problem is that I can't convert to using a shared directory when different systems assign different uids to the same named user. In other words, to get to the shared accounts solution I must already have solved the problem of mismatching ids. What is the issue of unsynchronized system ids? Are you allowing login of these system ids? Are they also sharing a filesystem (NFS, CIFS, etc) for these system ids? My assumption is that when you say shared directory you are talking about $HOME for a normal user. If that's not the case then it sounds like you are using an old technique where many systems mount shared filesystems to /usr, /usr/share, /opt, etc. I haven't seen that in years as disks are quite large enough to handle the space needed for these directories.The problems are mostly with system users, and I've seen some advice indicating such users don't normally go in LDAP. So excluding would reduce the problem, for LDAP, but also leave lots of unsynchronized ids. Mismatched ids in NFSv4 will result in a uid/gid of -1, which translates to something like 4294967295 (I don't think that's the exact number but it's close to 2^32) when you run an ls -l on the NFS mount point.I'm not sure how much a problem it the mismatches are for NFSv4; I believe it allows user/kerberos based authentication, but I'm not sure what that means for the uids of the files. LDAP is my go to solution for synchronized authorization and central account management (I do not use it for authentication, but that is my own personal preference). I advocate it, but I know some people prefer simpler solutions depending on the situation. A company of 10 systems can easily avoid all of the management, hardware, upkeep, etc of LDAP and use something like NIS, Puppet, etc or use no central management at all. I guess I'm not understanding the core problem. I never put system ids (including root) into LDAP, only user's ids. Typing this out, it occurred to me that I am assuming you mean a system id is an id of >1000 (in Debian). If you are talking about some generic account that is not an actual system ID, but is not used by a specific user, then yes you have to find a way to synchronize and/or transfer the account. I would simply create the account in LDAP and then transfer all ownership of processes and files to that new account (as you already stated). Thanks, Joshua Schaeffer |