I developed a solution to the problem where you might have systems setup w/ winbind mapping GIDs and UIDs, NSS, and PAM setup so windows users can login, but winbind maps possible different UIDs/GIDs from system to system preventing unified UIDs/GIDs in your environment.
I tried having one box setup with NSS winbind / PAM etc. plus I made that system an NIS master w/ a script to periodically pull the windows UIDs and GIDs into passwd and group maps. The NIS clients did NIS in nsswitch.conf with PAM windbind auth and winbind doesn't map UID/GIDs but rather rely on NIS. This almost worked except NIS didn't deal with blanks in the group names -- an NIS API call for group info would get hosed (the IDs were ok, but the names would be inconsistent). So I wrote a client / server daemon pair where the one host doing UID/GID mapping w/ winbind would periodically build passwd and group style compressed files of the mapped users and groups (using simple getent calls). The clients would periodically connect and download the passwd/group files if anything changed since the last time the connected. The server would also only obviously generate new passwd/group data when something changes. The clients would then install the mapped passwd / group entries in /etc/passwd and /etc/group. The proper pwent locking is done during /etc file update by the client to prevent other applications from getting inconsistent pwent calls during an update. The clients can do winbind PAM, but simply use files in nsswitch.conf -- it works great. It may not scale as well as pure NIS or LDAP backends etc., but it's pretty easy to setup and it's been a great solution for my office environment. It puts very minimal load on my network -- the PDC or BDC on the local network gets some bursty traffic once in a while from the server, but otherwise it's left alone. If each box was doing winbind mapping along with authentication, I would imagine it would be more traffic than the setup I'm doing. I'm sending this mail to see if anyone is interested using my setup. If so, I'll put up a section on my website w/ source code and simple instructions to implement this. If there's a better way to do it, let me know -- I couldn't find anything so I rolled my own and I'd like to offer back the solution to anyone else who needs it. I'm aware that perhaps in the future Samba will use an algorithm based UID to GID mapping making this setup unnecessary. I've seen reports of slowness when NSS calls are being made when there's lots of large groups in the windows domain -- I've seen that on my machine that does the mappings. On the client machines, the problem is solved because is uses local /etc files that are populated by the client side daemon -- it's great since only one machine (the master server) has the potential slowness and in my situation that machine doesn't need to be fast -- it's job is mainly to do the mappings. -- Eric Malkowski -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba