> Tech > Evénement détecté – Et après ?

Evénement détecté – Et après ?

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

A noter que tous les codes d'événements résultants en 565 indiquent que le rôle Schema Master a été réattribué. Par conséquent, le script doit ensuite déterminer l'identité du Schema Master. Si le rôle Schema Master n'a pas été réattribué, le script ne fait rien.
En utilisant Microsoft Active Directory Service

Evénement détecté – Et après ?

Interfaces (ADSI), la
fonction IsSchemaMaster dans le code
au renvoi B détermine si la réattribution
a eu lieu. La fonction commence
par se lier à  la classe RootDSE, une
étape nécessaire pour naviguer dans le
namespace AD (Active Directory) et
extraire le DN (distinguished name) courant pour le schéma. La classe
RootDSE, qui fait partie de l’Active
Directory Provider de WMI, vous permet
d’obtenir des informations sur les
serveurs LDAP (Lightweight Directory
Access Protocol). Après s’être lié au
conteneur de schéma courant, la fonction
extrait la propriété fSMORole-
Owner pour déterminer l’identité de
l’actuel possesseur du rôle de schéma.
La fonction utilise ensuite la valeur de
propriété fSMORoleOwner extraite
(c’est-à -dire, un DN) pour se lier à  l’objet
nTDSDSA. En utilisant la méthode
Parent d’ADSI (une méthode de l’interface
centrale de l’IAD), la fonction
trouve que le serveur a attribué le rôle
Schema Master. Se lier à  ce serveur et
obtenir la propriété dnsHostName termine
la navigation au travers du namespace
AD. La dernière tâche de la
fonction consiste à  donner à 
IsSchemaMaster la valeur de la propriété
dnsHostName.
Si la fonction IsSchemaMaster renvoie
une valeur qui est différente du
possesseur de rôle Schema Master original,
la procédure ResetSchemaRole()
au renvoi C réattribue le rôle au possesseur
approprié. Cette procédure
compte sur ADSI pour se lier à 
RootDSE puis utilise les méthodes Put
et SetInfo d’ADSI (contenues dans l’interface
centrale des IAD) pour réattribuer
et sauvegarder le rôle Schema
Master à  son emplacement approprié.
La méthode Put utilise l’attribut opérationnel
becomeSchemaMaster pour réattribuer
le rôle.
Comme je l’ai déjà  dit, une fois que
vous comprenez ce script, il est facile
de réattribuer les autres rôles. Ainsi,
becomeDomainMaster est l’attribut
opérationnel qui réattribue le rôle
Domain Naming Master.
La simple réattribution du rôle ne
suffit pas. Il faut informer quelqu’un
(un administrateur, par exemple) de la
réattribution. En utilisant le composant
CDONTS (Collaborative Data
Objects for Windows NT Server), la
procédure InformAdmin() au renvoi D
s’occupe de ce détail en informant quelqu’un par e-mail de la réattribution.
La procédure fournit des détails
dans le corps du message e-mail afin
que le destinataire sache à  quel serveur
le rôle a été incorrectement attribué, et
quand. Cette procédure s’en remet au
service SMTP pour informer quelqu’un
par courrier électronique de l’événement.
Donc, vous devez vous assurer
que le service SMTP est actif soit sur le
serveur qui maintient le rôle Schema
Master, soit sur un autre serveur capable
de relayer des messages pour le
compte du DC.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010