Archives de catégorie : Core

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

Un challenge fait de CERTREQ, CERTUTIL, NETSH et APPCMD

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.

C’est en relisant le billet de mon collègue Alexandre GIRAUD sur la demande de certificats sous IIS 7.0, que je me suis rendu compte du parcours accompli par Microsoft. C’est devenu si simple de demander un certificat qu’on ne se rends plus compte de comment cela fonctionne en dessous.

A quoi cela sert-il de le savoir? Et bien par exemple à savoir comment se débrouiller sous Windows Server 2008 Core ou de faire un pied de nez à mon collègue Alexandre GIRAUD qui a présenté la chose de manière graphique (la honte!).

Je prend donc le pari de refaire le même billet que mon collègue mais uniquement en ligne de commande (Les Core-Septiques peuvent aller directement à la fin du billet).

Pré-requis

Tout comme mon collègue, je considère que la PKI est opérationnelle (installée avec ADCS, en mode entreprise).

Création du fichier de demande

C’est la première étape, c’est un peu ce que l’assistant de IIS 7.0 nous cache. Le contenu ci-dessous constitue un fichier de demande de certificat.

[Version]

Signature= »$Windows NT$”

[NewRequest]
Subject = « CN=nom pleinement qualifié du site web »
Exportable = FALSE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = « Microsoft RSA SChannel Cryptographic Provider »
ProviderType = 12
SMIME = FALSE
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[RequestAttributes]
CertificateTemplate= WebServer

 

Le tout est sauvegardé dans un fichier INF nommé “SSL.INF”. Pour l’instant, ce n’est que du texte brut (mais cela va changer!).

la ligne “Subject” désigne le nom pleinement qualifié du site web Internet pour lequel on désire obtenir un certificat. Pour des raisons de sécurité, l’export de la clé privée n’est pas demandé, donc, il ne sera pas possible de l’exporter (par exemple pour mettre en place du NLB pour le site web sur le second nœud). A noter qu’il est possible d’utiliser un caractère wildcard (*.siteweb.com).

La ligne KeySpec indique l’échange de clés. Quant à la ligne “KeyUsage”, la valeur indiquée correspond aux usages nécessaires des certificats de site web, à savoir Digital Signature et Key Encipherment.

Très important, la ligne “MarchineKeySet = True” pour indiquer que le certificat obtenu devra être placé dans le magasin de l’ordinateur pour que IIS puisse y accéder (sinon je suis bon pour l’asile de fou!).

Pour les derniers, c’est du standard. Le plus important, c’est la dernière ligne, indiquant le modèle de certificat que l’on désire demander. C’est donc normal de voir figurer “WebServer”.

Génération du fichier de requête

On va transformer notre simple fichier texte en fichier correctement formaté pour une demande de certificat.

clip_image001

Histoire de valider que tout s’est bien passé, une seconde commande CERTUTIL.EXE devrait nous confirmer que tout s’est bien passé.

clip_image002

 

Histoire de voir à quoi ressemble une demande de certificat encodée, on peut consulter le contenu. La ligne d’entête nous confirme bien que c’est une demande de certificat.

clip_image003

 

Soumission la demande

Notre demande de certificat doit encore être soumise à notre autorité de certification. Etant donné que celle-ci est de type “Entreprise”, elle est publiée dans l’annuaire Active Directory. On peut donc soumettre la demande en ligne, tout comme le propose l’assistant de IIS. Si on ne peut réaliser la demande en ligne, ce sera donc la même commande mais exécutée directement sur l’autorité de certification (avec le fichier de demande qui va avec).

clip_image004

 

Etant donné que mon autorité de certification est de type entreprise et qu’en tant qu’administrateur du domaine, j’ai le droit de soumettre une demande pour ce gabarit de certificat, alors, la demande est automatiquement acceptée. Et pour preuve :

clip_image005

 

Il ne reste plus qu’à intégrer le certificat dans le magasin personnel de l’ordinateur.

clip_image006

 

On peut même s’en assurer avec l’exécution de la commande suivante :

clip_image007

 

Finissons en avec notre demande de certificat en acceptant son usage par la commande suivante :

clip_image008

 

A ce stade, notre certificat est utilisable dans la console IIS. Donc on pourrait faire le binding SSL immédiatement. Cependant, on continue en ligne de commande.

APPCMD et les certificats : Un truc de fou!

Avec IIS, cela se complique un peu (juste un peu). APPCMD.EXE qui permet de gérer IIS en ligne de commande est bien capable de configurer un site web pour répondre en HTTPS mais pour le certificat, c’est pas dans IIS que cela se passe mais à l’étage en dessous (HTTP.SYS). Nous voila donc dans les sous-sols de IIS, plus précisément dans l’antre de NETSH.EXE, la boite à outil pour tout ce qui sort de l’ordinaire dans le réseau Windows. Mais avant d’en arriver à NETSH, on va avoir besoin de récupérer quelques informations sur le certificat importé :

clip_image009

 

Globalement, j’ai besoin de deux choses. Le CertHash (logique) mais aussi le Simple Container Name. Plus précisément la partie après “CertReq-WebServer-“ (J’ai prévenu, on entre dans l’asile de fou!).

Welcome to the NETSH HELL!!. Depuis IIS 6.0, le moteur HTTP a été dissocié de IIS. Toute la gestion des certificats passe donc par NETSH. Dans le cas qui nous occupe, on va associer un certificat à une adresse IP et un port donné (toutes les adresses IP dans mon cas en HTTPS s’il vous plait) pour un certificat stocké dans le magasin ordinateur, identifié par son Hash pour un usage qui sera celui de son Key Container (Ne pas me demander pourquoi, ça marche comme cela, c’est fou non?). On peut même constater que c’est bien fait avec une seconde commande NETSH (bien plus simple cette fois) :

clip_image010

 

Après être descendu aux enfers, on va remonter un étage au dessus avec APPCMD.EXE pour lui demander d’ajouter le protocole HTTPS pour le site web par défaut, avec le certificat identifié par son Hash (C’est toujours à couper au couteau!) :

clip_image011

 

Je peux même prouver que cela a bien marché en affichant la nouvelle configuration du site web par défaut :

clip_image012

 

Pour les septiques de la ligne de commande, on peut constater que le résultat est bien celui attendu, à l’exception peut être du retrait de HTTP.

clip_image013

 

Un dernier tout de magie avec APPCMD pour faire disparaitre le protocole HTTP :

clip_image014

 

Et oui, seul le protocole HTTPS subsiste (J’ai gagné mon pari!)

clip_image015

 

A quoi cela sert-il?

Déjà, à ceux qui sont arrivé jusqu’ici sans ferme le navigateur chapeau. C’est vrai, a quoi cela sert-il de demander der certificats en ligne de commande?

  • Automatiser la configuration d’une ferme de serveurs Web
  • Configurer un serveur web sous Windows Server 2008 Core
  • Automatiser l’installation de serveurs SCCM (le mode natif, …)
  • A relever un pari à la con, aussi, …

Benoîts – Simple by Design (Besoin de vacances + Arrêter le café)

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.

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.

Capture de traces réseau sous Core

C’est le chalenge que j’ai eu chez un client cette semaine. Comment faire une capture de trace sur un serveur Windows 2008 R2 installé sous Core. Mon premier réflexe a été de dire Facile : NETSH TRACE START CAPTURE=YES TRACEFILE=c:\CAPTURE.ETL. C’est simple et en plus cette méthode permet de collecter un grand nombre d’informations complémentaires qui peuvent nous aider à comprendre ce qui se passe au niveau du système d’exploitation. Manque de bol, sous Core, c’est pas implémenté!

0

 

Bon ben on va installer le Network Monitor sous Core. Une fois installé, on constatera qu’il est possible de réaliser la capture à l’aide de l’outil NMCAP.EXE

1

 

Avec un peu de recherche, on verra qu’il est possible de mettre en place un filtre pour capturer uniquement le trafic recherché.

2

 

La grande surprise, c’est qu’il est réellement possible d’utiliser le Network Monitor dans une installation de Windows Server 2008 R2 Core. Il semble donc qu’il subsiste en beaucoup de composants de l’interface graphique sous Core. C’est toujours bon à savoir.

3

 

Par contre autre chalenge, comment désinstaller le Network Monitor. Microsoft livre un exécutable et non un package Windows Installer. Avec un peu de recherche, on découvre qu’il est possible de décompresser l’exécutable pour retrouver les packages Windows Installer. Reste plus qu’à désinstaller avec la commande “MSIEXEC.EXE /X”.

4

 

A noter qu’il y a deux packages Windows Installer à désinstaller.

5

 

Chalenge relevé

 

Benoits – Simple and Secure by Design but Business compliant.

SQL Server en Core!

Le mode d’installation “Core” est une avancée importante pour les systèmes d’exploitation de Microsoft puisqu’en n’installant pas certains composants, il n’est plus nécessaire d’installer les correctifs qui vont avec. Le problème, c’était que jusqu’à maintenant, aucune application phare de Microsoft ne s’était penché sur la question (exception faite d’Hyper-V).

 

Certes, l’absence du Framework Dot.Net était un point de blocage important, mais Windows 2008 R2 avait résolu le problème. La prochaine version de SQL Server dite “Denali” fonctionnera sous Core.

 

Pour ceux qui veulent en savoir plus, une seule adresse : http://www.microsoft.com/sqlserver/en/us/product-info/future-editions.aspx

 

Benoits – Simple and Secure by Design but Business compliant.