Délégation et Powershell

Cette article traite de la délégation de droits via Powershell et fait suite à l’article Administrer ses utilisateurs – Partie 1.

Outils utilisés

ActiveRoles Management Shell

Pour la gestion des comptes d’utilisateurs, nous utiliserons les CMD-LET publiées par Quest: http://www.quest.com/powershell/activeroles-server.aspx

Ces outils sont gratuits et simplifient grandement la gestion du domaine en PowerShell, principalement en renvoyant la totalité de l’objet utilisateur AD et non une partie seulement lors des requêtes.

Appel des CMDLET Quest

Une fois installées, les CMDLET Quest doivent être importées via Add-PSSnapin en Powershell:

  • Add-PSSnapin Quest.ActiveRoles.ADManagement


Les CMDLET quest sont maintenant disponibles, tel que:
GET-QADPermission (pour voir les droits positionnés)
SET-QADPermission (pour modifier ces droits)
NEW-AQDGroup (pour créer les groupes nécessaires à la délégation)

Préparation du domaine
Nous souhaitons déléguer les droits de gestion des utilisateurs a notre utilisateur Mon_Esclave_IT (cf. article précédent)
Les meilleurs pratiques conseillent de ne jamais distribuer de droits a un utilisateurs directement, mais de toujours passer via des groupes pour cela.
Ce principe, nommé AGDLP ou AGUDLP est décrit dans l’article suivant:

http://technet.microsoft.com/en-us/library/bb742592.aspx (à partir de la section Creating Groups)

  • Nous créons donc un groupe d’utilisateur dans l’OU Groupes de l’OU Administration
    • New-QADGroup GG_Support_L1 -ParentContainer « OU=Groupes,OU=Administration,OU=Enterprise,DC=Client,DC=LU » -GroupType « Security » -GroupeScope « Global » -SamAccountName GG_Support_L1


Explications:

  • GG_Support_L1 car un groupe doit indiquer rapidement sa portée, ici Global Group (On attribue de droits qu’à des groupes de domain local en suivant AGDLP), décrit ses membres qui sont du Support, et L1 décrit les droits attribués par ce groupe (support level 1)
  • Conteneur parent Groupes dans Administration.

    Pourquoi pas directement dans Groupes mais dans Administration\Groupes?

    Et bien si je stock mes groupes de droits sur l’AD dans une OU sur laquelle je distribue des droits, alors ceux qui reçoivent les droits peuvent les utiliser pour en obtenir plus.

    Imaginez que je donne le droit d’ajouter des membres a un groupes dans une OU contenant « Domain Admins », a votre avis combien de temps avant que le service desk s’ajoute lui-même dans ce groupes?

  • Puis nous ajoutons notre utilisateur Mon_Esclave_IT a ce groupe:
    • ADD-QADGroupMember -Identity GG_Support_L1 -Member Mon_Esclave_IT

      Rien de très particulier lors de cette étape.

  • Les droits devant être géré au niveau du domain local et non via des groupes globaux, nous créons alors un groupe de DL ayant comme membre le groupe GG_Support_L1:
    • New-QADGroup DL_Support_L1 -ParentContainer « OU=Groupes,OU=Administration,OU=Enterprise,DC=Client,DC=LU » -GroupType « Security » -GroupeScope « DomainLocal » -SamAccountName DL_Support_L1
    • ADD-QADGroupMember -Identity DL_Support_L1 -Member DL_Support_L1

Résumé:

Nous avons créé un groupe GG_Support_L1 contenant l’utilisateur Mon_Esclave_IT dans l’OU Groupes de Administration

Ce groupe est membre du groupe DL_support_L1 auquel nous allons appliquer des droits.



Ajout des droits

Il ne reste donc plus qu’à ajouter les droits suivants

  1. Création/Modification/Suppression d’utilisateurs uniquement dans l’OU « Mes utilisateurs » de mon domaine
  2. Possibilité de forcer le changement de mot de passe d’un utilisateur.

Pour la première partie, l’usage de la CMDLET ADD-QADPermision sur l’OU Utilisateurs du domaine, pour créer et effacer les objets de type « User »

  • Add-QADPermission « OU=Utilisateurs,OU=Enterprise,DC=Client,DC=LU » -Account « Client\DL_Support_L1 » -Rights CreateChild,DeleteChild -ApplyTo All -ChildType User


Pour la seconde partie, l’usage du paramétre User-Change-Password est passé avec le commutateur ExtendedRight

  • Add-QADPermission « OU=Utilisateurs,OU=Enterprise,DC=Client,DC=LU » -Account « Client\DL_Support_L1 » -ExtendedRight User-Change-Password -ApplyTo ChildObjects -ApplyToType User


Ceci est un exemple des droits positionnables via PowerShell dans le cadre d’une délégation automatisée de droits, ce qui est très pratique pour standardiser les différentes tâches entre différents domaines. 

Créer une alerte sur les modifications de votre Active Directory

Nous savons tous que les administrateurs sont des personnes dignes de confiance, et que tout le monde aiment remplir des pages après pages du rapport sur le tout nouvel utilisateur, qu’ils ont créé.

Alors que se passer quand vous voulez faire rapport sur ces travaux s’ils ne transmettent pas ces informations ?

La première chose à faire est de transmettre depuis les contrôleurs de domaine les événements vers un ordinateur de confiance. Pour ce faire vous pouvez suivre cet article : http://technet.microsoft.com/en-us/library/cc749140.aspx

Mais cela n’est valable que si vous avez effectivement le temps de lire ces événements.

Alors voilà une solution pour vous : Soyez alertés, par email, sur des événements spécifiques. Cet article suppose qu’événement audit est activé et configuré sur votre contrôleur de domaine, et prend par exemple que cherchez « Quand et par qui est créé un compte d’utilisateur? ».

Première étape: Identifier les événements à collecter

Soit vous les connaissez par coeur, soit vous avez la liste officielle ici  (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3a15b562-4650-4298-9745-d9b261f35814), mais le plus simple est de générer l’événement de création d’un utilisateur soit même 🙂

Puis regarder l’observateur d’événement et chercher l’événement.

Ici nous avons:

Category:
User Account Management

ID: 4720

Clic-droit: Attach Task to this event

Cela ouvre l’assistant
Basic Task creation wizard.

Donnons un nom à cette tâche.

Next. Puis “When an event is logged » (grisé par défaut, mais puisque les paramètres sont déjà correctes ce n’est pas grave)

Action: Display a message

Next > Summary > Finish

Deuxième étape: Personnalisation du message

Ok, maintenant nous avons une nouvelle tâche générant un superbe pop-up contenant le message ci-dessus.

Mais cela ne nous aides pas à savoir le « quand et où ».

Il faut donc obtenir les données de l’événement et générer un message personnalisé à partir de l’événement.

Réouvrir l’événement utilisé dans l’étape précédente et regardons les détails de la tâche (Onglet Details)

Notez les noms des champs que vous réutiliserez dans votre tâche, ici j’ai séléctionné:

Dans System – Computer
Dans EventData – TargetUserName
Dans EventData – SubjectUserName
Dans EventData – UserPrincipalName

Prochaine étape, exporter la tâche créée en étape un au format XML pour pouvoir la modifier librement (clic-droit > Export).

Ouvrez le fichier XML de la tâche (ici dans Notepad++) et inserrez le code XML surligné suivant dans la section EventTrigger :

La section ValueQueries et ses valeurs Value data seront à signaler comme indiqué ci-dessous :

Notez bien que les valeurs récupérées de la section SYSTEM sont traitées en utilisant le code suivant:

<Value name= »nom_de_votre_variable »>Event/System/_source_</Value>

Alors que les valeurs récupérées de la section EventData ont un format assez différent comme le montre le format suivant:

<Value name= »nom_de_votre_variable »>Event/EventData/Data[@Name=’_source_‘]</Value>

Enregistrez le fichier modifié, puis importez la tâche dans le task scheduler (note: la tâche précédente doit être supprimée si vous voulez réutiliser le même nom)

Maintenant que les champs de données de l’événement sont importés dans des variables de la tâche, nous pouvons les utiliser dans notre petit pop-up.

Editez la tâche, et aller à l’onglet Action.

Changer l’action « Display a message » en utilisant le code montré ci-dessous:

Comme on peut le voir, c’est assez facile à relire tant que vous utiliser un nom de variable lisible:

$(nom_de_votre_variable) est ici le contenu du champ en rose de la capture d’écran de code XML, que nous utilisons ici directement comme code de type chaîne de charactère.

Pour test on génére un nouvel utilisateur et un pop-up apparaitra immédiatement comme celui-ci :

Il ne reste plus qu’à modifier l’action pour remplacer l’envois de pop-up par un email.

A chaque nouvel utilisateur créé par un admin, vous recevrez un email avec le nom du compte de l’administrateur et le nom du compte créé.

Il ne reste plus qu’à étendre ce principe à toutes les tâches critiques (modification de l’appartenance aux groupes par exemple.)

N’est il pas super ce planificateur de tâches?

Report user creation by mail, with a trigger

We all know that Administrators are trustworthy people, and that they all love to fill pages after pages of report about the whole new user they’ve created.

So what happen when you want reporting on their work event if they don’t want to?

First thing is to forward Domain Controllers event to a trusted computer you manage, and for achieve this you can follow this article to achieve this: http://technet.microsoft.com/en-us/library/cc749140.aspx

But this is only good for you if you have time to read those events..

So here is a solution for you : Get alerted, by mail, about specific collected events.
This article assume that event auditing is activated/configured  on your DC, and take from example that you want to know “When and by who a user account is created?”.

First step: Identify the events you need to get report about.

Or you know the event by heart, or you read the official list here (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3a15b562-4650-4298-9745-d9b261f35814), or you just generate the message you want by creating a new user 🙂

Then look at your event viewer and search for it.

Here its Category: User Account Management, ID: 4720

Right-click: Attach Task to this event

This open a new Basic Task creation wizard.

Now it’s time to name this task

Next. Then “When an event is logged » (greyed out, but default parameters are just fine)

Action : Display a message

Next > Summary > Finish

Second step: Task fine tunning

Ok, now we have a nice whole new task generating a superb pop-up message

But we have no clue about the “when and who”.
So we have to get the event data inside our task and generate a custom message from here.

Open the event you used at the “Attach a Task To This Event” in the event viewer, and look upon the Details pane.

Note the field name you want to use in your task , here I will use the following fields:

System – Computer
EventData – TargetUserName
EventData – SubjectUserName
EventData – UserPrincipalName

Next step, export the new task from the task scheduler to a XML file (right-click > Export).

Then open the XML task file (here I used Notepad++) and insert the following XML
entry in the EventTrigger section :

ValueQueries section and its Value data as shown in the picture bellow :

Note that data from SYSTEM is imported using

<Value name= »your_variable_here »>Event/System/_source_</Value>

But from EventData it’s a little different format so you have to use:

<Value name= »your_variable_here »>Event/EventData/Data[@Name=’_source_‘]</Value>

Save, and import the taks in the task scheduler (note: you need to delete the
previous task if you want to update it)

Now that our event fields are updated in the task variable, we can use them in our
pop-up message.

Edit the task, and go to the Action pane

Modify the « Display a message » action

As you can see, it’s pretty straightforward : $(your_variable_here) will use the
variable filled from the event data as a string.

Just generate a new user and you will have a pop-up like this one :

Now just add a new Action to your task to send an email.

You will have an email each time a new user is generated by your admins, with the admin account and the new user name.
Isn’t this Task Scheduler great?