> Tech > Appliquer une sécurité rigoureuse et contrôler l’attribution des rôles

Appliquer une sécurité rigoureuse et contrôler l’attribution des rôles

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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

Guide Adobe Firefly, l’IA générative dédiée aux équipes créatives

Guide Adobe Firefly, l’IA générative dédiée aux équipes créatives

Depuis plus d’une décennie, Adobe exploite l’intelligence artificielle (IA) pour proposer des solutions toujours plus performantes et innovantes aux équipes créatives. Comment le nouveau moteur d’IA générative Adobe Firefly permet-il aux entreprises de développer leurs capacités créatives et de tirer, dès à présent, tout le profit de l'IA générative ?

Tech - Par iTPro.fr - Publié le 24 juin 2010