Un Module PowerShell pour Centrify DirectControl
Voici un Module PowerShell très utile pour gérer les données stockées par Centrify dans Active Directory. En effet, si vous avez des modifications à apporter et ceci de façon répétitive (implémentation de Design AD, importation de compte utilisateurs Unix dans AD, importation de définitions de privilèges Sudo vers DirectAuthorize, etc.), il est fort utile de pouvoir scripter tout ceci. Si Centrify fournissait un SDK avec les version 3.x et 4.x de DirectControl, celui-ci ne permettait guère plus que l’utilisation du VB script et plus intéressant la possibilité de créer ses propres dll (mais là on rentre dans du développement lourd).
Cela fait un moment que je discute avec Centrify de l’intérêt de fournir des Cmdlets PowerShell, parce qu’à chaque fois que la gestion des données stockées de l’AD sera effectuée par des équipes Windows, l’utilisation de PowerShell est aujourd’hui plus séduisante que des scripts VB !
Voici donc ma contribution aux outils fournis par Centrify, leur succès sur site fait que les Cmdlets PowerShell seront intégrés prochainement dans la Suite Centrify (probablement à partir de la 5.1).
Je posterai plusieurs exemples de scripts aidant à la gestion de Centrify ou aidant la migration des données depuis Unix vers AD, mais en attendant…
Bon scripting ^^
Visiter la page dédiée : Centrify PowerShell Module
ADInit : un script PowerShell pour déployer une organisation dans AD
Quand il s’agit de déployer une organisation complète dans un annuaire Active Directory (OU, Groupes, délégations, etc.), il est souvent impensable de faire ça à la main dans la console d’administration AD de la MMC ou autre navigateur LDAP. Et à moins d’embaucher des chinois dans un cave, pour créer les quelques centaines d’objets dans AD, la solution passe généralement par un script.
Oui mais voilà, généralement on créé des structures relativement identiques, et si on pouvais disposer d’un script suffisamment générique pour créer tout ça ?
Eh bien oui c’est possible, voilà donc un script PowerShell à base de PS 2.0, qui reçoit en entrée un fichier texte décrivant les opérations à faire dans l’annuaire AD de son choix. Ce script m’a été inspiré par un script VBS que j’ai eu l’occasion d’utiliser il y a bientôt deux ans dans un grand groupe international, merci à l’auteur de ce premier script dont j’ai malheureusement complétement oublié le nom Oo.
J’ai créé une page dédiée à ce script, n’hésitez pas à l’utiliser et à me faire part de vos remarques ^^
La page du script ADInit : ADInit
La page de téléchargement : ADInit Download
Protéger un objet des suppressions accidentelles avec PowerShell
Lorsque l’on utilise PowerShell pour créer des objets dans ActiveDirectory, il peut être intéressant dans le cas d’une OU ou d’un container d’appliquer le paramètres de Protection de l’objet des suppressions accidentelles, comme le fait si bien la case à cocher disponible dans la MMC.
Bon, une case à cocher c’est très bien, mais quand on viens de faire un joli script qui nous créé en une seule passe les 150 OU de notre organisation AD, quand viens le moment de cocher 150 cases il viens comme une envie de se pendre (surtout qu’avant d’atteindre la case à cocher il aura fallu malmener sérieusement le clic gauche de la souris -_-)
En réalité, derrière cette case à cocher se cache trois ACE très simples, l’octroi du refus pour le groupe Builtin « Tout le monde » sur l’objet en question:
- Delete
- DeleteChild
- DeleteTree
Maintenant il ne me reste plus qu’à vous montrer comment appliquer des ACE sur un objet de l’AD avec un script PowerShell.
Comment manipuler simplement une SecureString en PowerShell
Lorsque l’on écrit un script PowerShell il y a toujours un moment où l’on préfèrera demander une authentification utilisateur par prompt plutôt que de mettre un mot de passe en dur dans le code (sisi c’est mieux 
)
Sauf que lorsque l’on veut demander un mot de passe à l’utilisateur il n’y a pas dix mille façon de le faire proprement : il faut le stocker dans une chaîne de type System.Security.SecureString
Ok… C’est super… Mais comment faire pour ensuite donner ce mot de passe en paramètre à des fonctions ou actions puisque le contenu de ce chaîne est haché ?
Et bien pour effectuer un reverse du hash il existe une classe : System.Runtime.InteropServices.Marshal
Sauvegarde et restauration de la configuration d’un serveur FIM Service
Microsoft fournit des Cmdlets Powershell permettant d’exporter et d’importer la configuration d’un serveur FIM Service. Ces commandes sont inclus dans le module FIM Automation pour Powershell et sont fort utile pour : sauvegarder la configuration, restaurer la configuration, migrer la configuration, ou encore exporter et importer des ressources dans le portail FIM.
Les Cmdlets disponibles sont les suivants :
| Compare-FIMConfig | : Compare les attributs de ressources FIM et retourne une liste des changements à effectuer. |
| ConvertFrom-FIMResource | : Sérialise une ressource FIM et l’exporte sous forme d’un fichier XML (converti une ressource en XML). |
| ConvertTo-FIMResource | : Désérialise une ressource FIM depuis un fichier XML donné (converti des données XML en une ressource). |
| Export-FIMConfig | : Exporte les ressources FIM de configuration depuis FIM Service (appel au Web Service FIM). |
| Import-FIMConfig | : Importe une liste de changement dans FIM Service en utilisant le Web Service. |
| Join-FIMConfig | : Joint deux listes d’objets de type ressource FIM en utilisant un ou plusieurs critères de rapprochement. |
Grâce à ces Cmdlets il est possible de faire une sauvegarde de la configuration de FIM Service ou de restaurer cette configuration. Il est possible également de migrer la configuration d’un serveur vers un autre, par exemple pour appliquer des changements effectués sur un serveur de développement sur un serveur de production.
Vous trouverez des exemples de script que j’ai écrit sur la page code source de ce site. Notamment les scripts s’inspirant des exemples du Technet et s’intitulant : Backup-FIM-Configuration et Restore-FIM-Configuration
Vous trouverez également de nombreux exemples sur les différents liens du technet et sur la FIM Scriptbox du Forum FIM :
Migration de domaine AD et Zones Centrify
Lors d’une migration de domaine Active Directory vers un nouveau domaine, par exemple dans le cadre d’une migration de Windows 2003 à Windows 2008, il est nécessaire de planifier la migration des applications tierces impliquées avec Active Directory.
Centrify utilise l’annuaire Active Directory comme annuaire de stockage des identités Unix de votre environnement afin d’intégrer vos serveurs et postes clients non Windows à un domaine AD (grâce à Centrify DirectControl produit de base de la suite Centrify). Lorsque vous migrez d’un domaine AD à un autre avec ADMT (ou un produit s’appuyant sur ADMT tel que Quest Migration Tool ou Ideal Migration), il vous faut également migrer manuellement les Zones Centrify contenant les profils Unix. Les serveurs et postes de travail seront simplement retirés de l’ancien domaine pour être intégrés au nouveau domaine, une fois les informations de comptes et de groupes Unix préalablement migrées.
Techniquement, les profils Unix sont stockées dans l’annuaire sous la forme de serviceConnectionPoint (objet natif de l’AD depuis le schéma Windows 2000, ce qui ne nécessite aucune extension de schéma dans le cadre de l’utilisation de la suite Centrify). Ces profils sont stockés dans des Zones Centrify, représentées par des containers (autre objet natif bien connu de l’AD), et pointent vers les comptes utilisateurs AD et groupes AD correspondant (Centrify enrichi les identités AD existante en permettant de créer un ou plusieurs profils Unix pour chacun).
Afin de faciliter la migration des Zones Centrify, j’ai écrit un script PowerShell dont la tâche et de migrer l’ensemble des Zones Centrify d’un domaine AD source vers un domaine AD cible. La suite Centrify doit être installé dans le nouveau domaine et le container par défaut des Zones Centrify avoir été crée avec la console DirectManage. Ce script est disponible dans la page code source, et s’intitule Migrate-Centrify-Zones. Ce script migre également les profils Unix des utilisateurs et des groupes contenus dans les Zones Centrify.
Lorsque vous migrez des comptes et groupes AD avec ADMT, il est fortement recommandé d’inscrire le SID des objets (attribut objectSid) dans l’attribut sIDHistory, ceci afin de conserver une trace de l’identité des comptes une fois l’ancien domaine décommissionné. Les profils Unix Centrify conserve le SID des objets auxquels ils sont associés dans une valeur appelée parentLink. Une fois les Zones Centrify migrées (que ce soit avec le script précédemment cité ou par un autre moyen), les comptes sont orphelins : en effet les comptes AD et groupes AD migrés n’ont plus le même SID dans le ne nouveau domaine. J’ai donc également écrit un script PowerShell permettant de rétablir la valeur parentLink des profils orphelins en cherchant dans le sIDHistory des comptes et groupes du nouveau domaine AD. Ce script est disponible dans la page code source, et s’intitule Fix-Centrify-Orphan-Unix-Profile-SID.
Bonne migration 
En savoir plus sur Centrify : www.centrify.com
Powershell Activity pour FIM 2010
Carol Wapshere, connue aussi sous le nom de Miss MIIS, à publier sur son blog un article très intéressant sur une activité de workflow permettant d’invoquer des scripts Powershell. Ces scripts peuvent être exécutés localement ou sur des machines distantes, ce qui donne des possibilités vraiment énormes en terme de personnalisation !
Plus d’info sur le site de Carol : Lire l’article