The Unix system UID and login name problem
Once upon a time, most every Unix system (or at least most every Unix system descended from Berkeley Unix) had a set of system logins and groups that looked more or less identical and had more or less identical UIDs and GIDs. This made it possible for fileserver environments to more or less have a single, global password and group file that was used on all of your machines.
Those days are long over. In fact, things have swung to drastically different system logins and groups, with complete anarchy not just between Unixes or between different distributions of Linux, but even between machines of the same Unix (or Linux distribution) with different package sets installed. The most pernicious problem is that you can wind up with the same login and group on multiple systems but with different UIDs and GIDs assigned for it, and local files owned by those UIDs and GIDs.
(This happens because packages often want to create some system logins and groups when installed and they don't necessarily have a fixed, preassigned UID and GID for their stuff; instead they just ask for the next free system UID or GID. The result is that the UID they get varies depending on what else the system has installed and even the order that the packages were installed in.)
The net result is that it is now somewhere between very difficult
and completely impossible to have a completely common and global
/etc/group in your fileserver environment, even if
you are running the same version of the same Unix (or Linux) on all
of your machines. Instead, you really need to design your password
propagation system around the assumption that you will have both
per-machine local accounts and environment-wide global accounts.