Partages administratifs Windows 10

Il faut aussi créer la clé LocalAccountTokenFilterPolicy, comme l'a dit kelux .....

Il ne m'a pas dit de la créer, ni quoi en faire, ni où la créer

On la crée dans quoi ? quelle branche ?

C'est indiqué ici :
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction

https://forums.commentcamarche.net/forum/affich-32650131-partages-administratifs-windows-10#13

Je vais apporter quelques précisions.

je dénommais le groupe "Administrateurs", or ce n'est pas le groupe "admins du domaine" dont il est question ici ( Et d'ailleurs il ne faut pas "administrer" avec des comptes faisant partie de ce groupe, c'est très dangereux )

Je parlais du groupe "administrateurs" qui est local à chaque station. Mon utilisateur de domaine "DOMAIN\kelux" est ajouté au groupe local "administrateurs" de la station en question (que l'on appelle Client1).
Je suis connecté sur ma station (admin1) avec mon compte "DOMAIN\kelux" et je vais accéder à la station "Client1" via \\Client1\c$ ; et bien je n'aurai pas le souci évoqué ici ; néanmoins je ne suis pas non plus "admin du domaine" pour autant.

-

Concernant l'UAC, le paramètre évoqué ici "LocalAccountTokenFilterPolicy" ne désactive pas l'UAC.
Il y a beaucoup plus de paramètres pour désactiver complètement l'UAC.
Tu auras quelques infos ici sur la partie gérée via GPO : https://www.techrepublic.com/blog/the-enterprise-cloud/disable-uac-for-windows-servers-through-group-policy/

-

Cela m'amène sur une bonne pratique : on utilise les groupes restreints (fonctionnalité de GPO) pour gérer les administrateurs locaux des machines dans un domaine, sans utiliser le groupe "Admins du domaine" qui dispose de trop de droits.

Imaginons que je créé 2 groupes de sécurité dans Active Directory (pour le scope Domain Local ou Global, il faut voir selon l'infra - on prends du global sinon ) :
- Admins_Workstations : définit les administrateurs des stations desktop/laptop (les postes clients en gros).
- Admins_Servers : les admins des serveurs.

On peut aller plus loin et être plus fin en fonction des périmètres et des services (admin_servers_SQL, etc ...) ; le but étant de donner juste les droits suffisants aux personnes devant administrer tel ou tel périmètre. Je ne vais pas donner des droits d'administration sur des serveurs à des administrateurs de postes clients...

Ensuite je créé une GPO "Delegation Admins postes clients", je la lie sur une OU qui contient les postes clients (ou sur une arborescence plus haute qui contient les postes clients, et uniquement les postes clients, pas les serveurs) ; comme cela la GPO ne s'appliquera que sur des postes clients et non sur des serveurs.

Je paramètre un groupe restreint dans cette GPO, ça va donner : on ajoute le groupe de domaine "DOMAIN\Admins_Workstations" au groupe local "BUILTIN\Administrators".

Chaque machine qui aura cette GPO : verra comme membre du groupe Admin local le groupe de domaine "DOMAIN\Admins_Workstations".

Ensuite chaque compte utilisateur membre de "DOMAIN\Admins_Workstations" se verra administrateur des machines impactées par la GPO.
Ceci étant il n'aura pas de droits administrateurs "ailleurs", et encore moins de droits admins du domaine.

Même procédé pour les serveurs avec une seconde GPO qui cible uniquement les serveurs et le groupe "Admins_Servers".

On dérive du sujet initial certes, mais le point que tu soulèves Brupala est très très important. (je fais la guerre aux admins du domaine - quand je fais de l'audit AD pour des clients, je tire des oreilles beaucoup trop souvent)

-

J'ai vu énormément d'administrateurs utiliser un compte à fort privilèges (domain admin) pour des opérations courantes sur des postes de travail ; ce qui est le mal absolu !!! - c'est un peu comme nous a dit notre grand mère, on ne lance pas son serveur X avec Root ... ;-)

Pour ma part j'ai évolué dans de gros environnements, 250 contrôleurs de domaine, 150 sites, plus de 30 domaines, des centaines d'administrateurs - j'ai rarement eu besoin d'avoir les droits "domain admins" dans chaque domaine pour faire le boulot.
C'est plutot difficile de faire comprendre ce point, même aux équipes techniques, ils ont l'impression qu'on leur enlève du "pouvoir" sur leur job ou d'être moins importants quoi ..., ce qui est totalement faux et absurde.

Bref, on s'est écarté du sujet, désolé si cela a pourri un peu le post ;-)