A froid première idée : paramètre LocalAccountTokenFilterPolicy dans la registry du W10.
D'autre part avec ta phrase "La protection des partages par mot de passe est désactivée " ; est ce que ça sous entends que le compte utilisé sur chaque station a un mot de passe vierge ? ou login automatique sur le W10?
Si c'est le cas alors c'est tout à fait normal.
Les partages administratifs fonctionnent par contre par défaut si le PC est dans un domaine AD, et que vous utilisez un compte Admins du domaine apparemment, pour cela qu'en entreprise c'est transparent
Tu sais si les admin réseau sont bloqués aussi de la même façon ?
et si il y a une stratégie de groupe pour modifier à grande échelle, parce que passer par le bureau à distance, c'est bof.
En environnement Pro, donc dans un domaine Active Directory, on utilise des comptes de domaine et non des comptes locaux - en règle générale.
Lorsqu'on utilise un compte de domaine, qui a des droits d'admins locaux sur la dite station (OS desktop ou server), le comportement n'est pas le même.
Le token utilisé lors de l'accès aux admins shares est automatiquement en mode "elevated - élevé" - donc tu ne verras pas ce problème d'accès refusé lorsque tu utilises des comptes de domaine.
Je cite la KB de MS :
Domain user accounts (Active Directory user account) :
A user who has a domain user account logs on remotely to a Windows Vista computer. And, the domain user is a member of the Administrators group. In this case, the domain user will run with a full administrator access token on the remote computer, and UAC will not be in effect.
-
En env. Pro, l'UAC est -généralement- désactivé ; qui par la même occasion "résout" cette problématique lorsqu'on utilise des comptes locaux. (qui existe depuis Vista)
On peut effectivement désactiver l'UAC par GPO - sinon ça se fait dans le master à la source des installs des machines.
-
Je ne sais pas si je réponds à la question ... si besoin on étoffe.
Pile Poil,
c'est tout à fait ce que je voulais savoir,
en disant admins réseau, je pensais bien sûr au groupe administrateurs du domaine,
j'ai lu un peu trop en diagonale (ça m'arrive souvent) ton lien.
Je ne savais pas qu'on pouvait désactiver l'UAC par GPO, mais au final c'est logique, vu que ça n'est qu'une clé.
par contre, le problème là ce n'est pas l'UAC à la base, il est là aussi sous seven, mais le fait que la politique des accès a changé depuis 8.1, si j'ai tout compris.
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.
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".
Ok,
ça c'est complet au moins .
j'étais plutôt dans l'idée d'une structure moyenne avec un ou deux admin domaine, qui sont par défaut admin local sur toutes les machines du domaine ;-)
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 ;-)
Du coup,
j'ai perdu mes oreilles aussi: le peu d'amin que j'ai faite, c'était toujours avec un compte admin du domaine, mais un autre compte ordinaire pour le reste.
Mais c'est vrai qu'il vaut mieux créer des groupes et leur affecter les autorisations à la carte.
Pour le post, je pense que c'est intéressant aussi ce qu'on raconte là, mais ça concerne beaucoup moins de monde, c'est sûr.
En même temps, à part les admin réseau, je pense que pas grand monde, heureusement, utilise les partages administratifs.
A ce propos, il faudrait voir sur CCM si il n'y a pas un article à mettre à jour. ah, le voili Hop, c'est fait.
https://support.microsoft.com/fr-be/help/947232/error-message-when-you-try-to-access-an-administrative-share-on-a-wind
Les partages administratifs fonctionnent par contre par défaut si le PC est dans un domaine AD, et que vous utilisez un compte Admins du domaine apparemment, pour cela qu'en entreprise c'est transparent