par Ethan Wilansky - Mis en ligne le 17/11/2003
Comment contrôler l'attribution des rôles de Schema Master
Bien que Win2K
Server utilise un modèle de réplication
multimaître, certains rôles concernant
l'ensemble de la forêt, particulièrement
les rôles Schema Master et Domain Naming Master, doivent résider
sur un DC (domain controller)
dans une forêt.Gérez-vous un réseau d'entreprise
qui contient une forêt de domaines
Windows 2000 ? Est-il important de
protéger votre réseau Win2K ? Si vous
avez répondu oui à ces deux questions,poursuivez la lecture. Bien que Win2K
Server utilise un modèle de réplication
multimaître, certains rôles concernant
l'ensemble de la forêt, particulièrement
les rôles Schema Master et Domain Naming Master, doivent résider
sur un DC (domain controller)
dans une forêt.
Win2K offre une infrastructure de
sécurité permettant de contrôler efficacement qui peut réattribuer ces
rôles spéciaux. Cependant, un utilisateur
muni de privilèges administrateur
dans un domaine enfant peut trouver
le moyen de réattribuer un rôle
concernant l'ensemble de la forêt à un
DC dans un domaine enfant. De telles
réattributions menacent la sécurité
parce que, à moins de contrôler les
rôles touchant à l'ensemble de la forêt,
un domaine Win2K n'est pas vraiment
une frontière sûre : la forêt l'est. Je ne
traite pas de la réattribution fautive des
rôles concernant l'ensemble de la forêt,
mais je vous donne une solution de
script pour affronter ce genre d'événement.
Le script SchemaControl.vbs, illustré
dans le listing 1 impose ce que
j'aime à appeler une sécurité stricte.
SchemaControl.vbs détecte la réattribution
du rôle Schema Master, redéfinit
le rôle à son emplacement original
et envoie un message électronique
pour informer quelqu'un de l'événement.
D'une certaine façon, ce script
fait adhérer ce rôle important à son
emplacement original. Je mets en lumière
le rôle Schema Master parce
qu'un administrateur dans le domaine
auquel ce rôle est réattribué peut endommager
le schéma de façon irréparable.
Dans le pire scénario, il faudra
alors reconstituer toute la forêt.
Toutefois, quand vous aurez compris le
fonctionnement de SchemaControl.
vbs, vous pourrez modifier le
script pour détecter la réattribution
des autres rôles, comme le rôle
Domain Naming Master. Pour exécuter
le script, vous devez posséder l'autorisation
de changement de rôle appropriée.
Pour transformer le rôle Schema
Master, vous devez avoir l'autorisation
Change Schema Master, octroyée par
défaut au groupe Schema Admins.
Appliquer une sécurité rigoureuse et contrôler l’attribution des rôles
SchemaControl.vbs utilise WMI
(Windows Management Instrumentation)
pour superviser le journal
d’événements Security. Plus précisément, la méthode Exec-
NotificationQuer y de l’objet
SWbemServices recherche dans le
journal d’événements Security, l’événement
ID 565. La réattribution des
schémas est une raison pour laquelle
ce code d’événement est journalisé.
Event ID 565 est un code d’événement
d’accès aux objets activé quand l’accès
est accordé avec succès à un type d’objet
existant. Pour activer cet événement
dans le journal d’événements Security,
il faut activer le paramètre de policy
Audit directory service access. Vous
pouvez l’activer dans n’importe quel
GPO (Group Policy Object). Cependant,
je suggère d’activer le paramètre
dans l’un de ces deux endroits :
- dans le GPO Default Domain
Controller du domaine dans lequel le
rôle Schema Master est attribué - dans le GPO local du DC sur lequel le
rôle Schema Master est attribué
Pour activer le paramètre dans le
GPO Default Domain Controller, ouvrez
le GPO dans le snap-in Microsoft
Management Console (MMC) Group
Policy puis naviguez jusqu’au noeud
Computer Configuration\Windows
Settings\Security Settings\Local
Policies\Audit Policy. Dans le panneau
des détails, double-cliquez sur Audit directory
service access. Puis cochez la
case Define these policy settings et décochez
la case Failure. Ne décochez
pas la case Success.
Dans le GPO local, cette tâche s’effectue
un peu différemment. L’une des
méthodes consiste à ouvrir l’option
Local Security Policy dans Administrative
Tools puis à naviguer jusqu’au
noeud Security Settings\Local Policies\Audit Policy. Dans le panneau des détails,
double-cliquez sur Audit directory
service access , puis cochez la case
Success qui apparaît dans la boîte de
dialogue Local Security Setting.
Le fait d’attribuer ce paramètre policy
dans le GPO Default Domain
Controller l’applique à tous les DC présents
dans le domaine. Le fait d’attribuer
le paramètre policy dans le GPO
local l’applique au DC spécifique qui
possède le rôle Schema Master – le DC
que SchemaControl.vbs supervise.
Le code au renvoi A du listing 1 met
en évidence la fonction Check-
ForEvent() qui détermine si un objet a
été ouvert, se traduisant par l’enregistrement
de l’Event ID 565 dans le journal
d’événements Security. Quand la
requête réussit, la méthode NextEvent
de l’objet SWbemEventSource extrait
l’événement et, comme résultat, la
fonction CheckForEvent() renvoie
true.
Téléchargez cette ressource
État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
