Compte d'installation sur l'ad

Bonjour,

Le sujet est vaste donc je pense qu'il est préférable de commencer par faire un petit point de certains aspects et termes.

Compte Admin: dans l'univers Windows il n'y en a que deux type
- Admin local du poste
- Admin du domaine

Ces deux types de comptes doivent, comme tu l'as fait remarquer, être limité en nombre et en usage.
Cela ne veut pas dire pour autant qu'il ne doit y en avoir qu'un seul de chaque.

Pour les comptes admin du poste il y a deux cas de figure les comptes locaux (minimum un compte créé à l'installation) et les comptes de l'AD auxquels ont donne les droits en local sur les postes.

Par défaut un compte admin du domaine est admin de tous les postes du domaine.

A partir de là, il faut prendre en compte les groupes et là encore il y a les groupes locaux et ceux de l'AD/Domaine.

Maintenant il faut commencer à réfléchir à l'usage des comptes:
- les comptes individuels: associé à une personne et à son seul usage
- les comptes génériques: utilisés par un groupe d'utilisateur de manière contrôlée (auto-logon, process/tache spécifique comme la masterisation d'un poste...)
- les comptes de services: usage restreint à une application, un service, un process automatique, accès à une ressource... et ne doit jamais être utilisé pour une session interactive (ouverture de session sur le bureau du poste)

Une fois c'est différent éléments techniques assimilés il faut se pencher sur un concept qui lui n'est pas technique: la ségrégation.

Il est nécessaire de définir les types d'usages, les niveaux de droit, les catégories/population d'utilisateurs correspondant à la réalité de l'entreprise (c?est bien souvent le plus difficile).

Personnellement je suis adepte de quelques règles:
- aucun comptes utilisateurs bureautique administrateur (la règle la plus difficile à faire appliquer)
- au mieux donner le niveau de droit power users qui permet de faire déjà beaucoup de chose sans pour autant être administrateur
- différencier les droits serveurs et postes de travail
- faire simple
- utiliser des groupes pour donner des droits plutôt que donner des droits à un utilisateur en particulier: si quelqu'un d'une équipe à besoin d'un type de droit alors les autres aussi, sinon cela veut dire que les catégories usages sont mal définis
- ne pas avoir d'exception (reviens sur la règle précédente), si une exception doit être gérer alors elle doit l'être dès le départ et n'est donc plus une exception.
- ne pas mélanger les usages: typiquement les informaticiens; un compte bureautique comme n'importe qui et un compte avec pouvoir pour les tâches informatiques (perso j'ai un compte bureautique pour mon poste de travail, un compte avec pouvoir qui me permet de gérer au quotidien les systèmes et un compte administrateur de domaine que je n'utilise que lorsque c'est vraiment nécessaire)
- pas d'accès internet pour les comptes d'administration (les comptes bureautiques sont là pour ça)

Je vais terminer ce poste sur ce dernier point et j'en ferais un second plus tard pour traiter de l?application concrète de ces règles.

En espérant que cela t'aide déjà à appréhender le sujet.

Comme je l'écrivait précédemment, le sujet est vaste donc je vais essayer d'apporter des réponses en ne traitant qu'un point à la fois.

Aujourd'hui: le changement de mot de passe d'un compte local sur l'ensemble d'un parc

Ce genre d'opération rentre dans la catégorie "il faut absolument que tous les postes soient bien mis à jour sinon ça devient vite n'importe quoi".

Les deux principaux moyen d'y parvenir sont:
- intervention en direct sur l'ensemble du parc: lourd et chronophage mais efficace si bien géré
- utilisation d'une solution centralisée: pratique mais sans garantie de toucher tout le parc si ce n'est pas possible par GPO

Ici nous allons bien évidemment essayer d'éviter la première solution, celle-ci ayant de surcroit l'inconvénient de mettre en présence deux espèces antagonistes: l'informaticien et l'utilisateur. Elle est d'autant moins intéressante si il est nécessaire de recommencer régulièrement la man?uvre.

Les GPOs: nativement celles-ci ne permettent pas de modifier le mot de passe d'un compte en particulier pas même celui du compte administrateur local. Toutefois, mettons les de côté elles peuvent servir plus tard.

Les scripts:
- le logon script permet de garantir l?exécution systématique à l'ouverture de session d'une action il suffit donc d'attendre que toutes les machines se mettent à jour au fil du temps. Inconvénient, cela impose la répétition d'une action qui n'a besoin d'être effectuée qu'une fois, et souvent les scripts sont accessibles par tout le monde ce qui pose un problème quant à la présence d'un mot de passe en clair.
- le script qui cible des machines en fonction d'une liste que l'on réduira au fur et à mesure que l'on atteint les machines, cela nécessite d'avoir un inventaire de son parc à jour et de lancer les actions nécessaires pour toutes les atteindre (WoL, communication utilisateurs...).

La solution miracle; les GPP (Group Policy Preference):
il s'agit d'une extension des GPO qui apportent une grande souplesse à celle-ci telle que:
- appliquer un paramètre par défaut sans pour autant empécher l'utilisateur de le modifier à sa guise (exemple mettre un fond d'écran par défaut)
- agir sur des paramètres autres que ce qui est gérable par GPO (donc modification de la base de registre) ET OUI modifier le mot de passe d'un compte locale rentre dans cette catégorie !!!
- remplacer quasiment tout ce qui peut être fait par script
- fournir une interface graphique plutôt que des lignes de commande
- ...

Dans la pratique comment si prendre?

Pour un script (quel qui soit):
Il est possible d'utiliser la commande NET USER mais il y a d'autres outils plus souple/puissant/appropriés tels que PsPassword de l'indispensable SysInternals Suite ainsi que le PowerShell.

Pour cibler tout un parc à distance j'utilise un script type que j'adapte en fonction du besoin mais la structure est toujours là même:

Je pars d'une liste exhaustive des machines à cibler dans un fichier texte (TARGET.TXT).
Pour chacune d'elle je regarde si elle est présente dans un fichier de machine OK.TXT (vide au départ) et je rempli une liste de machine à traiter TODO.TXT (elle sera équivalente à la liste des machines à cibler lors du premier lancement).

Pour chaque entrée de TODO.TXT, je la ping pour garder une trace dans un log.
Si la machine est en ligne alors j?exécute l'action (ici modifier le mot de passe) et je log le résultat
Si le résultat est OK alors je rempli OK.TXT avec le nom de la machine.

Je recommence jusqu'à ce que OK.TXT soit complet et que TODO.TXT soit vide en prenant soin de faire démarrer les machines éteintes entre temps.

Pour les GPP:
il y a certains pré-requis car celle-ci ont été introduites à partir de Vista/2008:
CSE (Client Side Extension - KB943729) à installer sur les clients suivant:
Windows Vista RTM et suivant
Windows XP SP2 et suivant
Windows Server 2003 SP1 et suivant

XMLLite:
Windows XP SP2
Windows Server 2003 SP1

Attention, il n'est pas nécessaire de mettre à jour son AD en 2008 pour en profiter !!!

Il faut également un poste d'administration en Vista ou + ou en 2008 pour pouvoir utiliser la console GPMC et accéder aux préférence dans une GPO.

Lorsque tout ceci est disponible il faut lancer GPMC pour éditer une GPO ce qui ressemble à ceci:



Lorsque l'on ajoute une action utilisateur les paramètres suivants sont disponible:



Le second onglet permet d'agir au niveau du comportement de l'action que l'on définit:



Je reste volontairement générique dans les explications pour les raisons suivantes:
- il faut mettre les mains dedans pour s'approprier ce genre de connaissance
- chaque environnement étant unique il faudrait que je connaisse tous les détails de ton environnement pour faire du "clé en main"
- cela permet de généraliser les principes abordés et donc de les réutiliser à d'autres usages
- j'ai la flemme de faire plus

Encore une fois, j'insiste sur le fait que chaque environnement à ses spécificités qui font qu'une solution est plus ou moins adaptée. Ce que je décris peut correspondre à ton besoin ou au contraire être complètement inapplicable à cause d'un point bien spécifique de ton environnement.

Donner le droit à un compte (ou à un groupe) de pouvoir ajouter des machines dans un domaine:
Par défaut, il faut au minimum faire partie du groupe Accounts Operator.
L'inconvénient principal est que cela ne se limite pas aux comptes machines mais donne également les droits de gestion des comptes utilisateurs.

Une solution pour gérer cela est de déléguer des droits au niveau du domaine.

Et là il y a déjà une chose à laquelle il faut faire très attention: doit on déléguer à tout le domaine ou seulement sur certaines OU?
En fonction de cela et de la structure de l'AD, les choix seront:
- déléguer à la racine et à tout les objets enfants (le plus simple, pas le plus "secure")
- déléguer au niveau d'une seule OU qui regrouperait toutes les machines avec éventuellement avec des sous OU (solution idéale si il en est)
- déléguer OU par OU à cause de la structure qui l'impose (implique une gestion plus complexe donc plus de rigueur dans le temps)

Concrètement, il est possible d'utiliser l?assistant de délégation ou d'aller directement modifier les droits sur l'OU concernée (onglet sécurité des propriétés de l'OU).

Avec l'assistant, cela ressemble à ceci:

Lancement de l'assistant (bouton droit sur l'OU)


Sélection des comptes/groupes auxquels on veux donner des droits


Certains droit/rôles sont accessibles directement malheureusement pas celui qui nous intéresse, il faut donc choisir tâche personnalisée


Le type d'objet sur lesquels les droits doivent être donnés est Objets Ordinateur et il est possible de ne donner que le droit de créer sans pour autant donner celui de supprimer


Cette dernière fenêtre permet d'agir avec plus de finesse sur certaines propriétés mais ici ce n'est pas utile.

Coucou,

Déja merci pour ton "exposé", on sent la ferveur la dedans

Effectivement tu es resté générique, la possibilité de faire des masters est prévu à terme, donc GPO, powershell inclus comme tu peux le citer. Je peux aussi tout à fait utiliser uniquement un compte admin en atelier pour pouvoir passer les postes sur le réseau en attendant.

La solution du compte local n'est pas mal pour l'installation et résolution de soucis lier au soft, mais j'aurai souhaité un compte dont on peut changer le mdp, car j'ai l'utilisateur au dessus de l'épaule. un compte local va rester fixe d'une manière générale car comme tu le dis aussi chiant à modifier post masterisation. D'ou l'interet d'avoir un compte passe partout pour avoir des pouvoirs restreins qui ne soit pas critique si découvert. Et je but toujours sur ce point

EDIT : Tu as continuer pendant que j'écrivais mon poste, tu m'intéresses avec les délégations de droits je n'ai pas osé aller plus loin que cela avec étant donné que c'est assez dangeureu, dans le sens ou tu peux faire une mmc du serveur pour avoir la main dessus si je ne me trompe pas ?
Edité le 26/02/2013 à 14:05

Comme je le disais, ta problématique est plus vaste que le simple problème de changement de mot de passe donc j'essaie de tout balayer mais sujet par sujet pour ne pas tout mélanger (et encore j'ai du mal).

Pour la ferveur, c'est aussi parce que ça me permet de faire l'effort poser par écrit ce genre de chose et donc d'éclaircir certaines choses pour moi-même

Gutchi a écrit:

Effectivement tu es resté générique, la possibilité de faire des masters est prévu à terme, donc GPO, powershell inclus comme tu peux le citer. Je peux aussi tout à fait utiliser uniquement un compte admin en atelier pour pouvoir passer les postes sur le réseau en attendant.

La solution du compte local n'est pas mal pour l'installation et résolution de soucis lier au soft, mais j'aurai souhaité un compte dont on peut changer le mdp, car j'ai l'utilisateur au dessus de l'épaule. un compte local va rester fixe d'une manière générale car comme tu le dis aussi chiant à modifier post masterisation. D'ou l'interet d'avoir un compte passe partout pour avoir des pouvoirs restreins qui ne soit pas critique si découvert. Et je but toujours sur ce point

Le prochain point que je veux aborder c'est justement comment utiliser différents comptes dans le cadre de la masterisation, de la maintenance ...

Gutchi a écrit:

EDIT : Tu as continuer pendant que j'écrivais mon poste, tu m'intéresses avec les délégations de droits je n'ai pas osé aller plus loin que cela avec étant donné que c'est assez dangeureu, dans le sens ou tu peux faire une mmc du serveur pour avoir la main dessus si je ne me trompe pas ?

La je ne comprends pas trop.
MMC signifie Microsoft Management Console qui fournis un standard d'interface utilisé entre autres pour les modules d'administration (GPO, Utilisateurs et Ordinateurs...) au format msc.
Certains logiciel tiers fournissent d'ailleurs des modules basé sur ce standard.

L'utilisation de ces modules ne donnent aucun droits par eux-même si le compte utilisé ne les a pas en premier lieu.

Il est par conséquent tout fait possible d'utiliser ce genre de console à partir d'un poste client ou d'un serveur membre sans pour autant créer un faille de sécurité
Edité le 26/02/2013 à 16:36

Koin-Koin a écrit:

L'utilisation de ces modules ne donnent aucun droits par eux-même si le compte utilisé ne les a pas en premier lieu.

Tout à fait, si on te capte un compte et que tu sais l'utiliser.

Sinon avec tout ce que tu m'as fait, tu m'as fait penser à un truc, faire une GPO pour dire que tel groupe d'utilisateur est par défaut admin du poste, ca me permet de ne pas avoir de session admin sur serveur et accès aux ressources, et de pouvoir faire ce que j'entends sur les machines clientes, ajouter des comptes, pourquoi pas stagiaire etc. Ma prochaine étape va être de faire des UO pour les postes clients

Tit lien utile
Groupe locaux depuis un domaine
Edité le 26/02/2013 à 19:33

Gutchi a écrit:

Tout à fait, si on te capte un compte et que tu sais l'utiliser.

Donc si tu as peur de la compromission du compte auquel tu as délégué le droit sur les comptes machines, l'usage de la console ne change rien, c'est juste le droit du compte qui permet éventuellement de faire autre chose que prévu.
D?où l'intérêt de ne donner que le droit nécessaire et que sur les objets concernés.

Gutchi a écrit:

Sinon avec tout ce que tu m'as fait, tu m'as fait penser à un truc, faire une GPO pour dire que tel groupe d'utilisateur est par défaut admin du poste, ca me permet de ne pas avoir de session admin sur serveur et accès aux ressources, et de pouvoir faire ce que j'entends sur les machines clientes, ajouter des comptes, pourquoi pas stagiaire etc. Ma prochaine étape va être de faire des UO pour les postes clients

C'est bien l'idée

Ce que je recommande:
- séparer les comptes matériels des comptes utilisateurs dans l'AD
- séparer également les serveurs des postes de travail

Ex 1:
Racine\
\Utilisateurs
\Machines\
\Serveurs
\Postes de Travail

Ex 2:
Racine\
\Utilisateurs
\Serveurs
\Postes de Travail


Appliquer les droits admins locaux par des groupes (par GPO):
- Domaine\AdminServeurs membre de AdminLocal sur tous les serveurs
- Domaine\AdminPostes membre AdminLocal sur tous les postes de travail

Ainsi il est possible d'avoir plusieurs populations avec plusieurs niveau de droit:
- IT Niveau 1 membres de Domaine\AdminPostes
- IT Niveau 2 membres de Domaine\AdminPostes et Domaine\AdminServeurs

Cela permet de ne jamais utiliser le compte admin local pour la maintenance (sauf impossibilité absolue).
Par contre il faut bien sensibiliser les personnels IT des avantages que cela apporte.

Il faut bien garder à l'esprit que dans tous les cas de figures, l'usage un compte admin local est inévitable dans la vie d'un ordinateur puisqu'il faut au moins aller jusqu'à la jonction du domaine pour pouvoir utiliser un compte de domaine.

Il faut donc s'assurer que le compte et le mot de passe ne traine pas dans des scripts ou à minima que ceux-ci ne soit pas accessible par un utilisateur.

Il est également possible de séparer les rôles en fonction des actions à faire durant la vie d'une machine.
Par exemple, la masterisation peut-être entièrement être réalisé avec le compte admin local et utiliser un compte de domaine avec le minimum de droit pour tout ce qui y est lié (joindre domaine + accès en lecture au partage des sources et c'est tout) afin que même si le compte est connu/partagé/compromis cela n'ouvre pas pour autant une brèche béante dans les systèmes.