On 03/25/2017 03:03 PM, Boylan, Ross wrote:
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.
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 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.
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.
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.
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.
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

Reply via email to