Archives de catégorie : ADDS

Architecture WAP – Design infrastructure Active Directory

Ça semble tellement simple qu’on se demande pourquoi il faudrait se poser la question. Si simple vous dites? Entrez, on va discuter, … On va effectivement commencer avec un AD pour le cœur de notre infrastructure. On va donc y raccorder :

  • L’infrastructure ADFS
  • Notre infrastructure Windows Azure Pack (partie privilégiée)
  • Notre infrastructure Windows Azure Pack (partie locataire)
  • L’infrastructure SCOM (management Server et Dataware House Server)
  • L’infrastructure Service Manager Automation / Orchestrator
  • L’infrastructure SCVMM avec son Service Provider Foundation

Etrange, je n’ai pas cité les clusters Hyper-V? C’est normal car on va faire les choses correctement. Tous les produits cités précédemment constituent le Fabric Management de notre infrastructure Windows Azure Pack. Une bonne pratique est d’isoler ces composants dans une forêt d’administration dont l’accès sera limité aux seuls exploitants de la plateforme. Maintenant, parlons des Clusters Hyper-V. On va distinguer :

  • Les clusters Hyper-V utilisés pour héberger le Fabric Management
  • Les Clusters hyper-V utilisés pour héberger les workloads de nos futurs locataires

 

Pour le Fabric Management, il est logique de les raccorder à la forêt d’administration. Au passage, c’est dans ce domaine que sera réalisé la préparation de domaine pour stocker les secrets de SCVMM. Pour rappel, lors de l’installation de SCVMM on doit décider si on veut stocker les clés de SCVMM localement ou dans l’Active Directory. C’est ce dernier choix qui sera le bon. Ces clés sont essentielles car sans elles on ne peut pas accéder à la base de données de SCVMM. Je vous laisse deviner ce qui se passerait si on avait retenu de les stocker localement et qu’on ait perdu le serveur physique ou virtuel. Comme une petite piqure de rappel ne fait jamais de mal, autant, quelques lectures saines :

clip_image001

Maintenant attaquons nous au problème des clusters Hyper-V prévus pour héberger les workloads de nos futurs locataires. Doit-on les raccorder à la forêt d’administration? La réponse est dans la question. Il faut une claire séparation entre les usages. On va donc avoir une second forêt que je nomme « hosting.local » qui disposera d’une relation d’approbation unidirectionnelle (sécurité oblige). On y placera les clusters Hyper-V qui hébergeront les workloads de nos locataires. Si tout était si simple ce serait bien. Nous n’avons pas encore parlé de l’infrastructure WebSites. Pour rappel, elle comprend les rôles suivants :

  • Management Server
  • Controller
  • Database
  • Publisher
  • File Server
  • Web Worker
  • Frond-End

L’infrastructure Azure Pack Web Sites présente l’avantage de pouvoir fonctionner indépendamment des domaines avec des machines en Workgroup. Sur le papier, c’est pas mal. Le problème, c’est que cela rend cette infrastructure plus compliquée à exploiter. Essayons de raisonner différemment. Quels sont les rôles qui assurent la gestion de l’infrastructure et quels sont ceux qui sont consommés par les locataires :

  • Management : Participe à la gestion de l’infrastructure
  • Controller : Participe à la gestion de l’infrastructure
  • Database : Participe à la gestion de l’infrastructure
  • Publisher : Participe à la gestion de l’infrastructure
  • File Server : Participe à l’usage par les locataires
  • Web Worker : Participe à l’usage par les locataires
  • Frond-End : Participe à la gestion de l’infrastructure

On comprend que bon nombre de rôles sont liés à la gestion de l’infrastructure. Les instances de ces rôles seront donc déployées sur des machines virtuelles raccordées au domaine d’administration. Il ne nous reste que File Server et Web Worker. Ces deux rôles sont directement liés aux locataires :

  • File Server : Stockage et dépôt des packages WebDeploy des locataires et donc repository des sources pour alimenter les instances Web Worker
  • Web Worker : Consommation des packages Web Deploy en mode cohabitation ou isolé

Pour ces deux rôles, la recommandation est effectivement de les raccorder au domaine « hosting.local ». Pour conclure, voilà les bases de notre infrastructure Active Directory posées :

clip_image002

Avec deux Datacenters, je commence par poser deux zones réseau distinctes pour bien séparer les deux forêt Active Directory qui vont être mises en place. Dans chaque Datacenter, les contrôleurs de domaine de chaque forêt seront hébergés sur des clusters Hyper-V distincts. Nous aurons donc :

  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine WindowsAzurePack.Local
  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine hosting.local

De cette manière, chaque Datacenter est indépendant de l’autre. La défaillance d’un Datacenter n’aura donc aucun impact sur le service Active Directory et ce pour les deux forêts.

Remarques :

  • J’ai volontairement exclus le choix Workgroup pour l’infrastructure Web Sites de Windows Azure Pack. Ce mode de fonctionnement nous interdit de proposer à nos locataires une authentification Windows intégrée dans leurs sites web. S’interdire de proposer du service à nos futurs locataires est un non-sens
  • Les contrôleurs de domaine sont nécessairement des serveurs physiques, Pas de concession sur ce point.
  • J’ai volontairement exclus de parler des RODC. Pour la forêt d’administration, il n’y a pas de besoin vu que c’est une forêt isolée. Pour la forêt dédiée aux locataires, ça peut avoir un sens mais uniquement pour le rôle Front-end

Alors, toujours un simple Active Directory posé sur un coin de table?

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Active Directory recycle bin (re publication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

 

Pour ce billet, un sujet que j’ai eu à traiter plusieurs fois : La restauration d’objets AD. La mise en œuvre d’un annuaire Active Directory ne pose pas de problème particulier en terme de conception. Par contre quand un exploitant viens vous demander comment on peut restaurer un utilisateur supprimé, là, cela devient sportif.

Pour ceux qui n’ont pas pratiqué ce sport au moins une fois, il faut savoir que :

  • L’objet supprimé reste dans l’annuaire Active Directory pendant un certain temps (dépend du système d’exploitation et du niveau de Service Pack), c’est la notion de TombStone
  • L’objet est dépouillé d’un certain nombre de ces attributs, donc en particulier l’appartenance aux groupes

La restauration d’un utilisateur ne pose pas de problème particulier, par contre, son appartenance à d’éventuels groupes implique de savoir à quel(s) groupes il appartenait. Le sujet se corse quand on sait que l’appartenance à un groupe est un attribut du groupe et non de l’utilisateur. L’attribut “MembeOf” de l’objet utilisateur n’est qu’un attribut calculé. Autre problème, si on restaure l’utilisateur et les groupes, on risque de repositionner des membres qui devraient ne plus l’être.

Maintenant que les règles de ce sport sont clairement établies, voyons comment traiter cette problématique  :

Etant donné que Windows Server 2008 R2 fait la part belle à PowerShell avec des cmdlets dédiées à Active Directory, il était donc tout naturel de faire le tour du propriétaire avant de s’attaquer à la restauration d’un objet utilisateur et de son appartenance à un groupe sans restaurer le groupe en question (challenge!).

Mise en place de la cible

Objectif, tout faire en Powershell, en premier lieu, créer un conteneur organisationnel dans lequel on va créer le compte qui sera supprimé. La commande utilisée est “New-ADOrganizationalUnit” :

clip_image001

Une fois le conteneur créé, on peut afficher toutes ses caractéristiques à l’aide de la commande “Get-ADOrganizationalUnit” :

clip_image002

 

Remarque : On peut constater la présence de l’attribut “ProtectedFromAccidentalDeletion”, une des nouveautés de Windows Server 2008 qui permet de positionner des permissions empêchant un administrateur de supprimer un conteneur sans réfléchir!

Une fois le conteneur créé, passons à l’utilisateur avec la commande “new-ADUser” tel qu’illustré ci-dessous :

clip_image003

 

Vérifions que notre utilisateur existe bien dans le conteneur. Comment? Simplement avec l’aide du provider “AD:”, c’est comme se balader dans une structure de répertoire :

clip_image004

 

Passons à la suite avec la création de notre groupe global avec la commande “New-ADGroup” :

clip_image005

 

Et le plus important, le positionnement de notre utilisateur comme membre de ce groupe avec la commande “Add-ADGroupMember” :

clip_image006

 

Histoire de vérifier, voyons la liste des membres de ce groupe avec la commande “Get-ADGroupmember” :

clip_image007

 

Tout est maintenant prêt pour notre démonstration, à l’exception de l’Active Directory Recycle Bin qui n’est pas activée par défaut.

Mise en place de l’Active Directory recycle Bin

Avant de commencer, il faut respecter un certain nombre de pré-requis :

  • Tous les contrôleurs de domaine de la forêt en Windows Server 2008 R2
  • Augmenter le niveau de forêt à “Windows Server 2008 R2”

Le décors est posé. Maintenant la pièce de résistance! Celle-ci est une fonctionnalité optionnelle d’Active Directory qu’il faut activer à l’aide de la commande “Enable-ADOptionalFeature, tel qu’illustré ci-dessous :

clip_image008

 

Pour vérifier que c’est bien fait, on peut demander la liste des fonctionnalités Active Directory actuellement installées dans notre environnement avec la commande “Get-ADOptionalFeature” :

clip_image009

Tout peter comme il disait commandant Sylvestre!

Et toujours en PowerShell :

clip_image010

 

Pour s’en assurer, on peut lister le contenu du conteneur avec le provider “AD:”

clip_image011

***, je vais me faire engueuler!

Une fois l’objet supprimé, il est six pieds sous terre. Pour pouvoir le restaurer, encore faut-il pouvoir le retrouver parmi les objets supprimés avec la commande “Get-ADObject” sur un conteneur bien précis “Deleted Objects” en n’oubliant pas de préciser d’inclure les objets supprimés :

clip_image012

 

A ce stade, on n’est pas plus avancé qu’avant. L’objet est supprimé. Une simple restauration autoritaire de l’objet (pourvu qu’on dispose d’une sauvegarde récente!) ne restaurera pas les appartenances aux éventuels groupes.

C’est là que l’Active Directory Recycle Bin change tout. La commande “Restore-ADObject” à laquelle on précise le GUID de l’objet à restaurer (d’ou l’intérêt de lister préalablement les objets supprimés et les attributs) va nous permettre de restaurer non seulement l’utilisateur mais aussi ses appartenances à un ou plusieurs groupes sans pour autant effectuer une restauration de ces groupes :

clip_image013

 

On peut s’assurer que l’objet est bien restauré en affichant le contenu du conteneur organisationnel à l’aide du provider “AD:” et même afficher la liste des membres du groupe.

clip_image014

 

L’utilisateur restauré est de nouveau membre du groupe.

Dans cette démonstration, j’ai supprimé un user mais j’aurai tout aussi bien pu supprimer l’intégralité du conteneur. L’opération aurait juste été un peu plus complexe dans la mesure où il faut penser à restaurer le conteneur parent d’un objet avant de pouvoir restaurer celui-ci.

Voila une fonctionnalité de Windows Server 2008 R2 qui est plus qu’intéressante pour les exploitants. Quand on sait que les extensions Active Directory de PowerShell reposent sur un Web Service, donc plus besoin de RPC pour administrer des contrôleurs de domaine!

Pour plus d’informations sur la restauration d’objets Active Directory, un excellent article de Technet Magazine de l’époque, bien plus digeste que la KB.

 

BenoîtS – Simple by Design

DFSRMIG & SYSVOL (Republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Lors de la mise à niveau d’une infrastructure Active Directory, la mise à niveau des contrôleurs de domaine vers Windows Server 2008 doit être finalisée par une migration de NTFRS vers DFS-R. En effet, même avec des contrôleurs de domaine sous Windows Server 2008, c’est toujours NTFRS qui est utilisé pour répliquer le contenu de SYSVOL (sauf si on a pas migré). DFS-R présente un certain nombre d’avantages dont :

  • Une meilleure fiabilité dans les environnements complexes comprenant de nombreux contrôleurs de domaine
  • La possibilité de répliquer au niveau des changements opérés dans les fichiers (Remote Differential Compression)
  • Une meilleure sécurisation du contenu de SYSVOL sur les RDOC.
  • Jusqu’à seize transferts de fichiers simultanément, au lieu de quatre
  • Une gestion asynchrone des transferts
  • Une reconstruction automatique suite à un arrêt brutal du serveur

Pour bénéficier de ces avantages et de beaucoup d’autres, il est nécessaire de migrer  SYSVOL vers DFS-R. Ce processus doit être réalisé sur l’ensemble des contrôleurs de domaine de chaque domaine. le processus de migration est intégralement piloté au travers d’un seul et unique outil : “DFSRMIG.EXE”.

Pré-requis

  • La migration vers DFS-R n’est possible que dès lors que le mode de domaine est “Windows Server 2008”. Ceci implique que tous les contrôleurs de domaine de version antérieurs ont bien été migrés. Pour rappel, cette opération sera irréversible. Il ne sera plus possible de promouvoir des serveurs membre en contrôleurs de domaine pour les systèmes d’exploitation antérieur à Windows Server 2008.
  • Chaque contrôleur de domaine reportera son état de migration ainsi que son avancement dans des objets créés pour l’occasion dans l’annuaire Active Directory. Il est donc impératif que la réplication d’annuaire Active Directory soit opérationnelle. De ce fait, on peut tout de suite poser la règle suivante : “C’est la vitesse de propagation des mises à jour Active Directory qui donne le tempo de la migration et impose la durée globale de l’opération” (Commandant Sylvestre s’abstenir!).
  • Le processus de bascule vers DFS-R va reprendre le contenu du partage SYSVOL actuel. Il est donc impératif de s’assurer qu’il n’y a pas de problème à ce niveau. Par exemple qu’il y a bien cohérence entre la version de la GPO inscrite dans l’annuaire Active Directory et son contenu dans le partage SYSVOL.

Démarche

La démarche de l’outil DFSRMIG.EXE repose sur quatre phases :

  • Phase “Start” : DFSRMIG.EXE va mettre en place les moyens nécessaires au suivi de la migration pour chaque contrôleur de domaine. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Prepared” : DFSRMIG.EXE va mettre en place un nouveau répertoire SYSVOL et alimenter son contenu. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • phase “Redirected” : DFSRMIG.EXE va continuer à maintenir l’ancien répertoire SYSVOL  mais rediriger le partage vers le nouveau répertoire SYSVOL. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Eleminated” : Lors de cette dernière phase, NTFRS sera démantelé. Seul DFS-R sera utilisé pour répliquer le contenu de notre nouveau partage SYSVOL.

 

Il est à noter que l’ensemble du processus sera intégralement pilote depuis le contrôleur de domaine hébergeant le rôle de maitre d’émulateur principal de domaine (PDCE). De plus, le processus de migration est réversible (possibilité de revenir à l’état précédent ou de tout annuler) sauf pour la dernière étape. On peut donc considérer que la migration ne présente pas de risque majeur pour l’infrastructure.

Dans quel état suis-je?

C’est la phase d’initialisation. L’objectif de cette phase est de mettre en place les moyens nécessaire au suivi de la migration. D’un point de vue technique, chaque contrôleur de domaine devra reporter son état de migration dans l’annuaire Active Directory toutes les cinq minutes. C’est grâce à cela que l’on va consolider les informations et déterminer l’avancement de la migration. Pour déterminer dans quel état se trouve la migration, on dispose de la commande DFSRMIG.EXE /GetGlobalState tel qu’illustré ci-dessous :

clip_image001

 

Dans le cas illustré ci-dessous, le processus de migration n’a pas encore commencé. Pour ma démonstration, mon environnement comprend un domaine composé de trois contrôleurs de domaine opérant sous Windows Server 2008, dans un seul site Active Directory.

Initialiser la migration : Phase “Start”

Pour passer d’un mode à un autre, on dispose de l’argument “/SetGlobalState” auquel on associe une valeur. Dans le cas présent, la valeur “0” pour initialiser la phase “Start”. tel qu’illustré ci-dessous :

clip_image002

 

On peut immédiatement s’assurer que la commande a bien été prise en compte avec une nouvelle exécution de la commande “DFSRMIG.EXE /GetGlobalState” tel qu’illustré ci-dessous :

clip_image003

 

On peut même obtenir un peu plus de précision avec l’argument “/GetMigrationState” :

clip_image004

 

Pour plus d’informations, on dispose même d’un journal d’exécution de chaque commande “DFSRMIG.EXE” dans le répertoire “C:\Windows\Debug” sur chaque contrôleur de domaine. A ce stade, rien n’a encore changé, on a juste initié le processus de migration.

Préparer la migration : Phase “Prepared”

Entrons dans le vif du sujet. Le passage à la phase “Prepared” va engendrer la création d’un répertoire “SYSVOL_DFSR” sur chaque contrôleur de domaine. Son contenu sera recopié à l’aide de ROBOCOPY.EXE.

clip_image005

 

L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 1” indique que chaque contrôleur de domaine devra procéder à la création de son propre répertoire”SYSVOL_DFSR”. Pour accélérer les choses, on peut  forcer nos contrôleurs de domaine à travailler un peu plus rapidement avec la commande : “DFSRDIAG.EXE POLLAD” :

clip_image006

 

De cette manière, on force notre contrôleur de domaine à prendre en considération le changement d’état au lieu d’attendre cinq minutes. Avant de pouvoir continuer, il faut s’assurer que chaque contrôleur de domaine a bien pris en charge le changement d’état avec la commande “DFSRMIG.EXE /GetMigrationState”.

clip_image007

 

L’illustration ci-dessous nous indique que le contrôleur de domaine “DC2” n’a pas encore réaliser la première réplication initiale. Il n’est donc pas encore possible de passer à la suite.

clip_image008

 

Avec un peu de patience, tous les contrôleurs de domaine ont fini par créer leur propre répertoire “C:\Windows\SYSVOL_DFSR”. Pour s’en assurer, on trouvera même le journal d’exécution de la commande “Robocopy.Exe” dans le répertoire “C:\Windows\Debug”. On pourra y constater que l’opération à consister en une copie locale des données. On comprend donc pourquoi il est important que le contenu de SYSVOL soit cohérent entre tous les contrôleurs de domaine :

clip_image009

 

Un peu plus tôt dans ce billet, j’ai indique que chaque contrôleur de domaine reportait son état individuel de migration dans l’annuaire Active Directory. Chaque contrôleur de domaine va créer un conteneur “DFSR-LocalSettings” tel qu’illustré ci-dessous pour y référencer son état dans l’attribut msDFSR-Flags :

clip_image010

 

La valeur “16” indique un état “Prepared”. Voila donc un moyen fiable de suivre l’avancement de chaque contrôleur de domaine.

Une petite subtilité pour les RODC. Chaque contrôleur de domaine est censé maintenir son état en créant le conteneur et en renseignant l’attribut. Pour eux, ils ont besoin d’un petit coup de pouce avec la commande “DFSRMIG.EXE /CreateGlobalObjects” pour créer le conteneur à leur place. Les RODC maintiendront leur état en actualisant l’attribut directement sur le PDCE.

 

Redirection : Phase “redirected”

Jusqu’à maintenant, SYSVOL est toujours SYSVOL, il n’a pas changé. Pour s’en assurer, rien de mieux qu’une commande “NET SHARE” :

clip_image011

 

L’objectif de cette phase est de remplacer le répertoire partagé pour SYSVOL, tout en continuant à maintenir la réplication NTFRS, ce qui nous permet de toujours revenir en arrière, voire même d’annuler toute l’opération. Et bien basculons avant la commande “DFSRMIG.EXE /SetMigrationState 2” tel qu’illustré ci-dessous :

clip_image012

Lors de cette phase, chaque contrôleur de domaine va de nouveau effectuer un Robocopy entre son répertoire “SYSVOL” et “SYSVOL_DFSR” pour s’assurer qu’il dispose bien des fichiers les plus récents. Ici encore, on peut suivre chaque migration avec les fichiers de journalisation générés dans le répertoire “C:\Windows\Debug” ou bien plus globalement tel qu’illustré ci-dessous :

clip_image013

 

Si on va plus vite que la réplication, la commande “DFSRMIG.EXE /GetMigrationState” nous indiquera que nos contrôleurs de domaine n’ont pas encore commencé l’opération. Avec un peu de patience (ou à la méthode “Commandant Sylvestre”  : DFSRDIAG.EXE POLLAD + REPADMIN /SYNCALL /E = *** j’ai le réseau qui lag!), on arrive au résultat suivant :

clip_image014

 

Petite remarque, il serait opportun de “figer” les modifications réalisées sur “SYSVOL” avant de passer à la phase “Redirected” pour s’assurer que chaque contrôleur de domaine dispose bien des fichiers les plus récents.

L’avancement individuel de la migration peut être constaté en consultant la valeur de l’attribut msDFSR-Flags” qui doit être passé à 32 :

  clip_image015

 

Ou bien plus simplement avec une commande “NET SHARE”:

clip_image016

 

On constate donc que les partages “NETLOGON” et “SYSVOL” désignent maintenant un sous-répertoire différent. A ce stade, il est toujours possible de revenir en arrière, voire d’annuler toute la migration. Pour s’en convaincre, chaque contrôleur de domaine de dispose toujours de sa propre copie du répertoire SYSVOL, toujours maintenue :

clip_image017

 

Elimination: Phase “Eliminated”

L’ultime étape, celle qui est irréversible (merci de maintenir les commandants sylvestre à l’écart). L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 3” va supprimer le répertoire “SYSVOL” ainsi que les souscriptions FRS de chaque contrôleur de domaine :

clip_image018

 

Comme toujours, on peut constater l’avancement avec la commande “DFSRMIG.EXE /GetMigrationState”

clip_image019

 

Une fois l’opération terminée :

clip_image020

Et dans l’annuaire Active Directory :

clip_image021

Le service NTFRS est arrêté et n’est plus considéré comme un service dépendant pour le démarrage de l’annuaire Active Directory.

Encore une fois, petite subtilités pour les RODC. Ils ne pourront supprimer les abonnements FRS eux même. Ils ont besoin d’aide avec la commande “DFSRMIG.EXE /DeleteRoNtfrsMember”

 

Rollback ?

Oui, c’est possible mais uniquement jusqu’à la phase “redirected”. Il suffit juste d’exécuter la commande “DFSRMIG.EXE /SetGlobalState’ avec le numéro de l’état correspondant.

 

Conclusion

C’est simple, transparent pour l’utilisateur final, sans risque majeur pour l’infrastructure. En plus, cela permettra d’éviter qu’un “commandant Sylvestre” auquel on aura accordé le privilège d’administrer un RODC de supprimer le contenu de son partage SYSVOL et par extension de répliquer son erreur sur l’ensemble de l’infrastructure. DFSR détectera la problématique et procèdera automatiquement à une restauration autoritaire du contenu du partage. La migration DFSR est donc impérative dès lors que notre infrastructure comprend des RODC.

BenoîtS – Simple by Design

Créer un trust unidirectionnel en Powershell facile non? (republication)

Le jour où j’ai vu Windows Core la première fois, je me suis dit que ce sera parfait quand toutes les applications Microsoft seront compatibles avec. C’était au moment des premières Beta de Windows 2008. Aujourd’hui avec Windows Server 2012, on peut dire que le rêve est devenu réalité, les principales applications Microsoft sont maintenant utilisables sur plateforme Windows sans interface graphique ou presque, …

Cette vision serait même parfaite si on pouvait tout administrer depuis un langage unifié : PowerShell. Pourquoi dis-je serait? Avec Windows Server 2012 et Power ShellPowerShell V3 on peut tout faire en PowerShell? Y a donc forcément une commande PowerShell pour créer un trust dans le commandlet ActiveDirectory?

Et là, c’est le drame. Recherche rapide sur le Technet pour découvrir que dans PowershellV3, il n’y a qu’une seule commande en relation avec les relations d’approbation : Get-ADTrust, nada pour en créer ou les gérer. Etrange mais pas dramatique, il reste la méthode “Old school”. On peut encore se rabattre sur le vieux NETDOM.EXE, faudra juste parser son retour pour savoir si la commande s’est bien déroulée. Bizarrement, ça se passe pas comme prévus (ça marche pas), et pour cause, l’aide de la commande “NETDOM.EXE” est très claire :

clip_image002

 

Même Microsoft recommande d’utiliser l’interface graphique, c’est un comble. A ce stade, ça se corse car je dois effectivement mettre en place une relation d’approbation entre deux forêts. Donc exit la méthode “Old School”. Va falloir ruser.

PowerShell, c’est aussi Dot.Net. Je passe donc du côté obscur de l’IT et me plonge dans le MSDN à la recherche d’une solution. Oh miracle, il existe une méthode Forest.CreateTrustRelationship. Il faut juste pouvoir l’appeler en PowerShell. Après quelques tâtonnements, cela donne cela :

clip_image004

 

Concrètement, je me positionne sur un contrôleur de domaine du domaine approuvant pour exécuter ce script et cela va automatiquement mettre en place ma relation d’approbation unidirectionnelle dans les deux domaines :

clip_image006

 

On peut vérifier dans le domaine approuvé avec la commande Powershell Get-ADTrust (il faut bien qu’elle serve à quelque chose) et on obtient le résultat ci-dessous :

clip_image008

 

La relation d’approbation unidirectionnelle entre mes deux forêts est donc opérationnelle.

Conclusion, Windows Core, c’est bien, Powershell aussi mais pour pouvoir réellement se passer des outils d’administration classiques, il faudra encore attendre car sur un serveur Windows Server 2012, on a bien l’aide de Powershell (si on a pensé à la télécharger dans son intégralité) mais il n’y a pas d’équivalent pour avoir le MSDN de la même manière.

Simple and Secure by design but Business compliant.

Petite KB pour les upgrade de domaine W2K3 vers W2K12 R2

Back to basics. C’est la saison des projets d’upgrade des infrastructures basées sur Windows 2003. l’OS a presque dix ans. Dans le cadre d’un projet de mise à niveau des infrastructure d’annuaire, nous aurons donc des contrôleurs de domaine Windows 2003 qui devront coexister avec des contrôleurs de domaine Windows Server 2012 R2. Selon le technet, cela ne devrait pas poser de problème.

Pourtant, l’équipe en charge du support Active Directory avait publié ce billet en Juillet 2014 : It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers. La coexistence entre les deux générations de contrôleurs de domaine posait problème au niveau de Kerberos. D’un coté Windows Server 2012 R2 ne supporte plus DES (par défaut) et Windows Server 2003 ignore les nouveaux algorithmes proposés par Windows Server 2012 R2. Bref, on avait une certaine cacophonie au niveau de Kerberos qui pouvait conduire à l’impossibilité de changer le mot de passe des systèmes raccordés au domaine. Pour adresser cette problématique, Microsoft proposait une méthode de contournement (en attendant de finaliser le démantèlement des contrôleurs de domaines Windows 2003).

Depuis fin Aout, la méthode de contournement proposé par Microsoft n’est plus d’actualité puisqu’un correctifs est enfin disponible : KB2989971 – Can’t log on after changing machine account password in mixed Windows Server 2012 R2 and Windows Server 2003 environment. A installer sur tous vos contrôleurs de domaine Windows Server 2012 R2.

 

benoîtS – Simple and Secure by Design but Business compliant

Créer un trust unidirectionnel en Powershell facile non?

Le jour ou j’ai vu Windows Core la première fois, je me suis dit que ce sera parfait quand toutes les applications Microsoft seront compatibles avec. C’était au moment des premières Beta de Windows 2008. Aujourd’hui avec Windows Server 2012, on peut dire que le rêve est devenu réalité, les principales applications Microsoft sont maintenant utilisables sur plateforme Windows sans interface graphique ou presque, …

Cette vision serait même parfaite si on pouvait tout administrer depuis un langage unifié : PowerShell. Pourquoi dis-je serait? Avec Windows Server 2012 et Powershell V3 on peut tout faire en Powershell? Y a donc forcément une commande PowerShell pour créer un trust dans le commandlet ActiveDirectory?

Et là, c’est le drame. Recherche rapide sur le Technet pour découvrir que dans PowershellV3, il n’y a qu’une seule commande en relation avec les relations d’approbation : Get-ADTrust, nada pour en créer ou les gérer. Etrange mais pas dramatique, il reste la méthode “Old school”. On peut encore se rabattre sur le vieux NETDOM.EXE, faudra juste parser son retour pour savoir si la commande s’est bien déroulée. Bizarrement, ça se passe pas comme prévus (ça marche pas), et pour cause, l’aide de la commande “NETDOM.EXE” est très claire :

TECHNETNETDOM

Même Microsoft recommande d’utiliser l’interface graphique, c’est un comble. A ce stade, ça se corse car je dois effectivement mettre en place une relation d’approbation entre deux forêts. Donc exit la méthode “Old School”. Va falloir ruser.

Powershell, c’est aussi Dot.Net. Je passe donc du coté obscur de l’IT et me plonge dans le MSDN à la recherche d’une solution. Oh miracle, il existe une méthode Forest.CreateTrustRelationship. Il faut juste pouvoir l’appeler en Powershell. Après quelques tâtonnements, cela donne cela :

SCRIPT

 Concrètement, je me positionne sur un contrôleur de domaine du domaine approuvant pour exécuter ce script et cela va automatiquement mettre en place ma relation d’approbation unidirectionnelle dans les deux domaines :

CREATETRUST0

On peut vérifier dans le domaine approuvé avec la commande Powershell Get-ADTrust (il faut bien qu’elle serve à quelque chose) et on obtient le résultat ci-dessous :

CREATETRUST1

La relation d’approbation unidirectionnelle entre mes deux forêts est donc opérationnelle.

 

Conclusion, Windows Core, c’est bien, Powershell aussi mais pour pouvoir réellement se passer des outils d’administration classiques, il faudra encore attendre car sur un serveur Windows Server 2012, on a bien l’aide de Powershell (si on a pensé à la télécharger dans son intégralité) mais il n’y a pas d’équivalent pour avoir le MSDN de la même manière.

 

Simple and Secure by design but Business compliant.

Creating a AD user without knowing it’s initial password

That’s a tricky question. Every user we create in active Directory require an initial password that user will use to connect for the first time. At this step, user account can (and should be configured) to enforce a password change.

From a security point of view there might have some problems with this initial password. It must be communicated to the end-user. If someone have access to the initial password and user identity, he can perform operation on behalf of someone else. To avoid such a situation, one solution can be to disable this account until user contact the help-desk and required activation. Unfortunately this solution may lead to complex situations (eg, email address is not generated for disabled users, …).

 

Another approach is to be sure that the newly created user cannot be used because nobody know the password. With a random generated password this should be fine. I found an elegant way to respond to this problem with a single PowerShell command : New-ADUser. The trick is to enforce the Smartcard at logon as illustrated bellow :

NEWUSER0

Enabling the ‘Smartcard is required for interactive logon’s checkbox’ have multiple side effects :

  • Resetting it’s password with a random complex password
  • Enable the ‘User Must change password at Next Logon’

 

Because I enabled the Smart card enforcement, a password has been generated and allow me to use the ‘PasswordNotRequired’ parameter configured to ‘$True’. At last we can check, my newly created user exists and is enabled.

NEWUSER1

 

At this stage, the user identity exists and I can use it in my Tenant provisioning process for a Private cloud. Because there is no certificate associated to the user and because no one know the initial password, I’m sure that my tenant administrator account cannot be used by someone else.

 

BenoîtS – Simple and Secure by Design but Business compliant

Un digne successeur pour replmon.Exe

Pour ceux qui comme moi ont connu Windows 2000, on avait un outil nommé REPLMON.EXE qui nous permettait d’avoir une vue globale de la réplication Active Directory. Cet outil avait disparu avec l’arrivée de Windows Server 2008. La raison invoquée était que REPLMON.EXE avait été développé par les équipes support et non le groupe produit.

 

Heureusement, une équipe au sein de Microsoft a repris le flambeau avec le AD Replication Status Tool disponible sur le Download Center de Microsoft.

ADREPLSTATUS

 

En ce qui me concerne, c’est que du bon. En plus, c’est à la page en terme d’interface graphique et prêt pour Windows Server 2012. Personnellement, je ne pense pas que cela remplace une véritable supervision d’Active Directory mais au moins on a déjà de quoi travailler pour comprendre les problèmes de réplication d’annuaire.

 

Pour raison de modernité, le produit repose sur le Framework Dot.Net 4.0. Penser donc à l’installer avant. Pour les nostalgiques, la solution n’a pas été testée avec Windows 2000 et de toute façon, elle ne serait pas supportée.

 

Simple and Secure by design but Business compliant

GPO tip for lazy admins

During my DirectAccess deployments projects, I have to deal with security group membership for computer accounts. Restarting my DirectAccess clients to update the computer Kerberos ticket takes times. Waiting for the tickets to be renewed takes too much time. There might have an alternate solution. Let’s have a look at the great tools of Mark RUSSINOVICH available at this location.

 

Let start with the initial state of my DirectAccess computer. The GPRESULT.EXE command result indicates that the computer is not already member of the “Lazy Admin group”. I don’t want to restart the computer!

0

 

First SysInternalTool : LOGONSESSIONS.EXE that provides information about sessions opened on the DirectAccess client computer. We can see that the computer account have a Kerberos Ticket. The local System account SID is : S-1-1-18 :

1

 

We now have the LogonID of the Computer account. Let’s have some additional information about this session with the KLIST.EXE command line.

2

 

We have Kerberos tickets negotiated by the computer account. Let’s purge these tickets.

3

 

An force the computer to obtain new Kerberos tickets with a simple GPUPDATE.EXE /FORCE command.

4

 

Does my computer negotiate new Kerberos tickets? Yes! Let’s look at  the GPRESULT.EXE results. And surprise, the computer is now member of a new security group and apply a new GPO.

5

 

It is simple by design. SysInternal Tools are best friends of the lazy admins.

 

BenoitS – Simple and Secure by design but Business compliant.

Une KB pour les contrôleurs de domaine sous Windows 2008 R2

Depuis Windows 2000, le fait de pouvoir créer un objet dans un annuaire Active Directory impose de disposer d’un identifiant unique. Dans chaque domaine, un contrôleur de domaine est responsable d’assigner des pools de RID aux autres contrôleurs de domaine. En temps normal, chaque contrôleur de domaine dispose d’un certain nombre de pools de RID d’avance (en fait deux par défaut), cela permet de palier à une indisponibilité temporaire du maitre d’attribution des RID.

 

Microsoft vient de mettre à disposition la KB2618669 :  An update is available to detect and prevent against too much consumption of the global RID pool on a domain controller that is running Windows Server 2008 R2 qui s’adresse uniquement aux contrôleurs de domaine Windows 2008 R2. L’objectif est de détecter les situations de surconsommation de pools de RID.

 

 

Benoits – Simple and Secure by Design but business compliant