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. 

Administrer ses utilisateurs

Voici le premier article d’une série de 5 articles sur la gestion des comptes d’utilisateurs Active Directory, Lync et Exchange depuis un point central d’administration.

  • Dans cet article nous parlerons de l’environnement servant de base à cette suite d’article.
  • Le second article parlera de la création et de la modification de comptes d’utilisateurs AD délégué et via PowerShell.
  • Le troisième article sera sur la création et gestion de la messagerie.
  • Le quatrième article pour la gestion des comptes Lync en Enterprise Voice.
  • Le cinquième article conclura la série par un script reprenant tous ces éléments pour générer un compte d’utilisateur complet (création d’un utilisateur avec copie des droits, Mailbox Exchange, mot de passe, homefolder et compte Lync Enterprise Voice)

Objectif de cette suite d’articles

Nous allons partir sur un exemple simple qui reste un exemple concret de délégation des droits dans un domaine « classique »:

  1. Je suis l’Administrateur, utilisant mon compte Administrateur_IT, possédant les droits
    1. Domain Admins pour la gestion de mon domaine et ses serveurs
    2. CSAdministrator (Lync) pour la gestion des serveurs Lync
    3. Organization Management (Exchange) pour la gestion des serveurs Exchange
  2. Je souhaite déléguer les tâches suivantes a un utilisateur nommé Mon_Esclave_IT
    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.
    3. Création/Modification/Suppression d’utilisateurs Lync, y compris leur numéro de téléphone
    4. Création/Modification/Suppression d’utilisateurs Exchange, y compris leur mailbox et leur appartenance à des groupes de distribution.

L’objectif étant d’arriver le plus vite possible à cette fin, en utilisant principalement PowerShell.

La tâche sera effectuée le plus rapidement possible, avec le minimum d’action de configuration.

Lire la suite

Contrôler le numéro affiché sur Lync Phone Edition

Après quelques tests de votre plateforme Lync, vous vous apprêtez à mettre en production cette dernière avec un PBX tierce partie.

Hors ce PBX « old school » vous impose d’utiliser un format de ligne avec extension dans votre LineURI tel que :

tel:+33123456789123;ext=123 (Ici nous avons bien le format E164 avec l’extension clairement identifiée.)

Oui mais, regardons nos superbes téléphones Lync Phone Edition, et que voyons nous comme numéro de téléphone ?

+33123456789123;ext=123

Lire la suite

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?