D'ailleurs, root ne pourrait que prendre l'identité d'un compte qui existe localement (qui a un UID/GID local). Il ne peut, dans le cas d'un annuaire LDAP, le faire que si le compte LDAP s'est déjà connecté (et que ça a abouti à la création d'un UID quelque part dans le système), soit parce que l'UID est accessible en lecture pour le compte root ou le système. Dans le cas contraire, je pense qu'il y a un message d'erreur indiquant "no such uid". Idem pour une authentification avec Kerberos.

Je ne suis pas sûr : pour moi, root va pouvoir prendre l'identité de n'importe quel utilisateur défini dans getent passwd (sachant que getent passwd prend un login et fournit un uid/gid en échange, en cherchant dans toutes les bases configurées : /etc/passwd, LDAP, NIS, …).
Bien sûr, on ne parle que de la fourniture d'identité par LDAP (via getent), pas la fourniture de mot de passe (même si les deux généralement stockés au même endroit dans LDAP, ça pourrait être deux LDAP différents).
Si l'utilisateur en question ne s'est pas connecté, root n'aura pas de credentials à voler et donc il ne pourra pas monter les partages réseau (par exemple son home) — à nouveau, sauf si le serveur de fichier n'est pas un gros trou de sécurité à lui tout seul.

En revanche, je ne suis pas d'accord sur l'uid quelque part dans le système : si ton utilisateur n'est que dans le LDAP (solution propre) et que tu coupes le LDAP (et le magnifique cache de nslcd/nscd), tu n'auras aucune trace de l'association login/uid dans le système et tu vas te retrouver avec des fichiers orphelins qui appartiennent à un uid inconnu.

Contrairement à LDAP (qui fait à la fois fournisseur d'identité ET validation de mot de passe), Kerberos ne fait que l'authentification : tu peux très bien n'avoir que des utilisateurs définis dans /etc/passwd et avoir tout de même une authent' Kerberos (testé et approuvé ^^) -> l'authentification Kerberos ne fonctionnera que si ton utilisateur existe localement et que le serveur est d'accord (mot de passe correct, par exemple).

Flan > Il y a énormément de situations où le UID/GID n'existe que sur l'annuaire et pas localement (ce que tu appelles "de secours") - sauf pour root, évidemment, mais avoir un compte root dans l'annuaire LDAP est sujet à risques - mais il faut que les mécanismes de création de compte dans l'annuaire LDAP interdisent la création d'un compte avec l'uid root (je crois qu'il y a des cas documentés de pourrissage du système avec genre un Robert Oot, qui devient un compte "root", mais sans uid 0, ce qui perturbe le système).

Oui, bien sûr : ce n'est qu'une possibilité, et c'est très risqué en local pour la base des uid/gid (il suffit d'avoir un uid/gid différent dans le LDAP et le /etc/passwd pour avoir des bugs « rigolos »).
De façon générale, il faut être sûr de ne jamais avoir un même username dans deux sources différentes, sauf en étant absolument sûr que les uid/gid sont identiques… et encore, même dans ce cas il vaut mieux éviter
Après, ce sont des bonnes pratiques, comme préfixer ou suffixer les administrateurs par "-admin" ou les utilisateurs locaux de /etc/passwd par "-local" ^^

Je voulais simplement souligner
- d'une part que la base uid/gid était simplement la concaténation de plusieurs sources (dont le LDAP et le /etc/passwd) et qu'il suffisait que le login soit défini dans l'une de ces sources,
- d'autre part que l'authentification était également la concaténation de plusieurs sources (dont LDAP, /etc/passwd, carte à puce, Kerberos, Kerberos via carte à puce),
- et pour finir, que les deux sont totalement orthogonales ^^

mais bon, fondamentalement, je pense qu'on est d'accord

Au final, c'est plutôt pas mal fichu sur Linux, ça permet beaucoup de souplesse — le problème se trouve plutôt dans nslcd/nscd et dans les interfaces graphiques de login qui ont du mal à accepter autre chose que du login/mot de passe bidon.
Je ne connais pas assez Windows du côté admin sys, mais en tant qu'utilisateur c'est bien mieux fichu en tout cas (pour l'interface graphique, justement).