Centrify propose un livre blanc sur le BYOD en entreprise
Oui j’ai dit BYOD soit Bring Your Own Device et pas BYOB (que les fêtards connaissent déjà). Bref, avec le Cloud et la multiplication des périphériques intelligents que sont les tablettes et smartphones, beaucoup d’entreprises demandent ou autorisent leur employés a utiliser leur propres périphériques pour le travail. Mais alors se posent de nouveaux problèmes de sécurité. Comment faire pour gérer un périphérique qui n’est pas fourni par l’entreprise ?
Centrify propose un livre blanc sur les bonnes questions a se poser lorsque l’on évoque le BYOD, et répond a plusieurs de ces questions en présentant sa solution de gestion des périphériques dans le Cloud (pour l’instant iOS et Android).
Pour demander ce Livre Blanc, suivre le lien suivant: Request White Paper
Centrify supporte MacOS 10.8 a sa sortie
Centrify annonce le support de Mountain Lion, la version 10.8 de MacOS X et ce des la sortie de cette nouvelle version de l’OS. Parmi tous les partenaire d’Apple, Centrify est le seul a fournir une solution d’integration complete a Active Directory qui soit supportee sur Mountain Lion. Enjoy !
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.
Guide des bonnes pratiques des Stratégies de Groupes ou les GPO chez MS
Après le guide sur la fédération d’identité voici le tour des Stratégies de Groupes. Microsoft utilise évidement un grand nombre de GPO en interne pour des besoins diverses et variés, mais comment gérer efficacement des GPO pour un société internationale de cette taille ?
Par exemple en suivant un ensemble de bonnes pratiques (et également avec une bonne dose de rigueur ^^).
Si vous aussi vous cherchez à instaurer des bonnes pratiques pour la mise en place de vos GPO, et quelques soit vos besoins, voici un livre blanc fourni par un ami décrivant les bonnes pratiques en place chez MS pour leur gestion des GPO.
Télécharger le pdf ici : GPO_Best Practices_How MSdoit
Utiliser les GPO de préférence pour personnaliser l’affichage Explorer
Si comme moi vous en avez marre, à chaque fois que vous utilisez une nouvelle VM d’un serveur Windows ou d’une station, de systématiquement modifier les paramètres d’affichage de l’Explorateur et de modifier ces foutus paramètres d’Economiseur d’écran qui vous mettent en pause les machines : alors voici LA solution pour personnaliser l’Explorer par GPO.
En effet si l’utilisateur lambda n’a aucune envie de voir les fichiers cachés du système, ni les extensions de fichiers, mon sang de Geek m’oblige à aller paramétrer tout ca à chaque fois que je me fait une VM Windows (et d’ailleurs ces pareils pour les machines physiques dans l’absolue). Lorsque l’on travaille au quotidien sur des environnement de démo ou de qualification, il est pénible de reparamérter tout ca à chaque fois.
Voici donc une astuce pour le faire ue bonne fois pour toute pour un environnement AD, et le tout par GPO évidement 
Créer des certificats SAN avec une CA Windows
Lorsque l’on a besoin de certificats pour authentifier un serveur windows ou linux lors d’une connexion SSL ou un autre service, et que l’on dispose d’une CA Windows, par défaut on ne peut déclarer d’alias DNS (ou nom secondaires) lors de la demande de certificat. Que l’on utilise l’assistant présent dans la console d’administration IIS ou le site Web d’inscription de la CA Windows (certserv), le constat est le même, l’option n’est pas disponible.
Pire encore, par défaut une CA Windows ne prend pas en compte le champs SAN (Subject Alternative Name) lors de l’émission d’un certificat.
Pour émettre un certificat SAN avec une CA Windows il est donc nécessaire de procéder comme suit.
Centrify élu Gold Partner Ubuntu par Canonical
Quel surprise hier soir quand j’ai mis à jour quelques paquets sur ma Maverick (Ubuntu 10.10), je découvre dans les liens partenaires Canonical (Société privée Sud Africaine qui pèse beaucoup dans le succès de la distribution Ubuntu et d’autres projets Opensource) rien moins que le paquet Centrify Express ! J’ai donc fait quelques rapides recherche sur le sujet et voici un résumé d’un article trouvé sur le blog de Tom Kemp en personne (CEO Centrify).
Canonical et Centrify ont annoncé un partenariat en novembre dernier ce qui permet à Canonical de distribuer la solution gratuite d’interopérabilité avec Active Directory, nommée Centrify Express, via son dépôt partenaire officiel. Pour rappel Centrify Express permet l’intégration rapide et complète des systèmes Ubuntu (mais également Unix, Linux en général et Macintosh) dans Active Directory permettant ainsi l’authentification et le SSO avec un compte Active Directory sur les systèmes joints à un domaine Windows. Canonical est tellement convaincu de l’efficacité de la solution Centrify Express qu’ils ont certifiés la solution pour sa simplicité et son efficacité et ont élu Centrify comme Gold Partner Ubuntu. Quand on sait qu’il existe seulement 6 partenariats entre Canonical et des éditeurs et que les autres sont des noms tels que Adobe ou Skype, cela prouve la validité de ce choix.
Si vous voulez lire l’article de Tom Kemp sur le sujet : Lire l’article…
Pour voir le Webinar sur les raisons de ce partenariat : Voir le webinar…
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