Inspired by M.Kondrin's letter.

May be it will make the sense of the setup design more evident,
if I try to describe a hypothetical but totally sane setup, based on Coda:

- clients have pam_aware login, which uses pam_something module
  to check if a certain user "name" knows her password

- another pam module tells if a certain user "name"
  may use the relevant host

  Note, pam_something can be (Kerberos, NIS, anything) based, but it is always
  one and only function "name" => YES or NO
  YES == ("is who she pretends to be" AND "is allowed to use this host")

if YES:
- the login program just PICKS UP THE NEXT UNUSED UID (it does not matter
  which uid, just let it be unused until then and afterwards, with 2^64
  uids it is more or less infinite)
  of course it logs which name corresponds to the uid, to be able
  to identify processes afterwards.
  it may create a corresponding new /etc/passwd entry, and even reuse it
  at new logins with the same name.
  only the numeric uid and user "name" are relevant there,
  and can be lost without any harm (as long as the uids never are reused)
  To be clear, uids make sense inside each host,
  no reason to synchronize between hosts.

- the login program looks up (may be by some pam_somethingelse) the
  homedir path corresponding to the user "name"

- the login program extracts the Coda realm from the homedir path
  and asks the user for the corresponding Coda password
  (it may as well try the one supplied at login)
  and authenticates against that Coda realm (presumably by pam_codasomething)
  and runs /bin/sh "homedir"/.profile as the allocated uid

  The rest is responsibility of the user and her helpdesk,
  to provide a .profile which starts a nice environment,
  from Coda (not hypothetical, see /coda/konvalo.org)

Note that as the Workstations Administrator you have to make very clear
choices and take some actions, but not more than:

- have an authentication database which can securely check if a person
  knows the password for some "name". Kerberos does it well.

- have an algorithm to decide _after_ _successful_ authentication
  if _that_ "name" is allowed to run on _this_ host,
  it is doable say by pam_list combined with a cfengine distributing
  the list of allowed users (differing possibly on different hosts)

- have an algorithm to map "name" => "homedir",
  which can be done statically or be distributed along with
  the allowed-users list
  (only 2 fields, "name" and "homedir")

- have a working Coda client on each host

- force all users into having their homedirs on Coda

Then as a Filespace Administrator you can decide how to grant Coda file
space to your users and how to protect their data.

It is here you will manage volumes, Coda groups and acls.
Totally independently of the client hosts administration above,
except for adding new user names in both places.
Don't care of allocating uids, Coda uids are used only for Coda
internal bookkeeping, it will reserve new ones as needed.

Done.

As you see, no per-user information
except a bit "allowed" and a string "homedir"
is necessary on any workstation.

No software is necessary locally either :)

It's like the above I am running my workstations,
and I hope it helps to see the essential properties and distinguish them
from the (broken) traditionally accepted design...

One "problem" with the above will be that ls -l will not show anything
reasonable as "owner" or "group", but it is ok, as that is totally
irrelevant on Coda.

Happy Coda-ing,
--
Ivan