PI Services

Le blog des collaborateurs de PI Services

Windows Server 2012 R2 – Ajout d’un poste au domaine avec un RODC en DMZ

Contexte

L’intégration d’un poste à un domaine Active Directory nécessite un contrôleur de domaine “writable”. Dans le cas où les postes se trouvent avec le RODC dans un site local et que les DC sont dans un site central (via un MPLS sans filtrage réseau par exmple) l’intégration au domaine fonctionne normalement.

Mais dans le cas où le RODC est dans une DMZ (ou un réseau isolé) qui bloque les flux AD depuis le poste vers le DC “writable” il est alors impossible d’ajouter le poste de façon classique au domaine.

Solution

L’ajout du poste à travers le RODC se fait en quatre étapes.

1ère étape :

Il est tout d’abord nécessaire de créer le compte ordinateur sur un DC en lui spécifiant un mot de passe. Pour cela utiliser la commande PowerShell suivante :

1: New-ADComputer -Name <Nom du poste> -AccountPassword (Read-Host -AsSecureString "Password?") -SAMAccountName <Nom du poste> -Enabled $true

2014-01-17_103759

2ème étape :

Ensuite il faut ajouter le poste dans un groupe qui est autorisé à répliquer les mots de passe avec le RODC (par défaut le groupe Allow RODC Password Replication Group).

2014-01-17_103835

3ème étape :

Sur le compte ordinateur du RODC, Propriétés et dans l’onglet Password Replication Policy, cliquer sur Advanced... Ensuite cliquer sur Prepopulate Passwords… et ajouter le compte ordinateur du poste.

2014-03-14_111138 2014-01-17_104040

Il faut maintenant attendre que la réplication se fasse entre le DC et le RODC.

4ème étape :

Il faut maintenant lancer le script disponible à cette adresse http://technet.microsoft.com/fr-fr/library/dd728035(v=ws.10).aspx en indiquant les paramètres suivant :

1: joinscript.vbs /domain <nom du domaine > user <utilisateur> password <mot de passe> /dc <FQDN du RODC> /readonly /machinepassword <mot de passe du compte ordinateur> 

Une fois le script terminé, il faut redémarrer le poste. Au redémarrage il sera intégré au domaine.

Windows Server 2012 R2 – Plantage d’un DC lors d’une modification d’objet AD

Contexte

Lors de la modification d’un objet dans l’Active Directory (exemple : modification sur l’objet KRBTGT lors de l’installation d’un RODC), le Domain Controller redémarre automatiquement de manière inopinée et non planifiée avec ce message d’erreur :

2014-01-03_102252

A la suite du redémarre, les erreurs suivantes se trouvent dans l’Event Viewer :

Application – Wininit – Error 1015 : A critical system process, C:\Windows\system32\lsass.exe, failed with the status code c00000005. The machine must now be restarted.

2014-01-03_102418

Application – Application Error – Error 1000 : Faulting application name: lsass.exe

2014-01-03_102354

Cause

L’erreur est due à un paramètre de l’Audit object access. Ce problème est vraisemblablement un bug de Windows Server 2012 R2.

Solution

Pour résoudre ce problème, il faut désactiver (ou a minima de ne pas inspecter) la journalisation des accès aux objets dans le Local Security Group ou dans une GPO.

Ce paramètre se trouve dans Computer Configuration, Policies, Windows Settings, Security Settings, Local policies, Audit Policy.

2014-01-03_102510

Windows 2012 Server Manager: Ajout “basique” d’un serveur a gérer.

 

Windows 2012 est clairement orienté Gestion a distance.

Voici comment ajouter rapidement un serveur dans la liste des serveurs gérés

image

Cliquez en haut a droite de la console sur Manage – Add Servers

image

Assurez vous que le nom du serveur a ajouter est bien résolu, ou bien renseignez son IP

image

Une fois découvert, ajoutez le a la sélection de droite, puis OK.

image

Aïe! un message ‘'”Refresh Failed” vous indique que le client WinRm n’a pas pu exécuter la requête.

image

Ouvrez un fenêtre de commande et exécutez la commande:

winrm set winrm/config/client @{TrustedHosts="mcsaw2k12srv1"}

Ceci pour ajouter la machine cible a la liste des serveurs autorisés dans la configuration du client WinRM.

image

Fermez les notification précédentes et réitérer l’ajout du serveur.

Il apparait a présent dans la liste

image

Faites un clic-droit sur le nom et sélectionnez Manage As… si le serveur distant doit être géré avec un compte diffèrent.

image

image

Orchestrator : Requête de l’état des dernières instances de job.

 

Voici une requête a exécuter sur l’instance SQL de votre serveur orchestrator pour récupérer l’état de la dernière exécution d’une liste de runbooks

Vous pouvez de-commenter (—) la clause WHERE pour exclure certain nom de runbook ou encore choisir une des clauses ORDER BY pour choisir un critère de tri.

USE ORCHESTRATOR SELECT RL.Name as RunbookName, MAX(RI.CompletionTime)as dernieredate INTO MyTableau FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId --WHERE RL.Name NOT LIKE '%TEST%' GROUP BY RL.Name ORDER BY RL.Name; --ORDER BY MAX(RI.CompletionTime) DESC, RL.Name --ORDER BY LastStatus DESC SELECT RunbookName, dernieredate as Derniere_date_Execution, RI.Status FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId INNER JOIN MyTableau ON MyTableau.RunbookName=RL.Name and dernieredate = RI.CompletionTime; GO DROP TABLE MyTableau

Comment créer un cloud privé et sécurisé?

Pour créer un espace de stockage dans le cloud, tout le monde à tendance à utiliser OneDrive de Microsoft ou encore Dropbox. Ca fonctionne très bien, ca fait ce qu’on demande : stocker des données dans le cloud de manière à y accéder depuis n’importe quel endroit et depuis n’importe quelle plateforme.

Le gros point noir de ces solutions pour une entreprise, c’est de ne pas maitriser le stockage et la sécurité des données. En effet, qui peut empêcher un utilisateur de déposer des fichiers sensibles sur Dropbox ? **Là j’entends un gros silence…**

Pour répondre à cette problématique, la société Varonis à créer le logiciel DatAnywhere. ce serveur va vous permettre de créer un cloud chez vous et de surcroit, sécurisé.

La solution étant installée chez vous, vous avez la main sur les données, les droits d’accès et la sécurité. Voici comment reprendre le contrôle de vos données qui partent dans le cloud !

Fonctionnalités du produit

Espaces de travail

  • Gestion des version de fichiers
  • Expérience de drag ’n drop pour les postes clients
  • Possibilité de synchroniser des données avec différents appareils et/ou utilisateurs
  • Créer des liens pour le partage de fichiers

Sécurité

  • Toutes les données transitent via la protocole SSL
  • Contrôle des accès, suivi des abus
  • Authentification via Active Directory ou LDAP
  • Possibilité de gérer les dossiers/utilisateurs pouvant synchroniser à distance
  • Gestion des dates d’expiration pour le partage des données

Stockage

  • Possibilité de déployer des serveurs par zone géographique
  • Supporte la mise en cache et la déduplication
  • Stockage sur votre infrastructure existante

Accéder à vos données

Pour accéder a son espace de stockage dans le “cloud”, voici les différents moyens pour y accéder :

    • Windows
    • Mac OS
    • iOS
    • Androïd
    • Interface web

Conclusion

Maintenant vous savez qu’il est possible d’avoir un cloud privé, sécurisé et comment gérer les données qui y sont. Plus d’excuses pour ne pas sécuriser vos données.

Contactez nous pour que nous puissions vous aider à mettre en place la solution qui va vous permettre à reprendre le contrôle de vos données à l’exterieur de votre société.

Desired State Configuration (Partie 3) : Configuration du mode pull (via smb)

Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Après avoir montré la configuration du mode Push, cette troisième partie est consacrée au mode Pull et plus particulièrement lorsqu'on l'utilise conjointement à un partage de fichier Samba.

Ainsi, j'expliquerai comment fonctionne le mode Pull ainsi que les différentes étapes de configuration.

Fonctionnement

Pour rappel, DSC fonctionne de la manière suivante :

  • Récupération de la configuration
  • Application de la configuration

Ces deux étapes se répètent indéfiniment selon le temps d'actualisation qui a été défini pour chacune d'entre elles.

La principale différence entre les modes Pull et Push concerne la récupération de la configuration. Le mode Pull utilise le principe inverse du mode Push. Au lieu de transmettre les modifications de configurations à nos serveurs, ces derniers vont interroger eux-même un "dépôt" central (appelé serveur Pull) qui contiendra l'ensemble des configurations gérées par DSC. Le serveur appliquant sa configuration et donc aussi à l'origine de la connexion pour vérifier s'il y a une nouvelle version de sa configuration. Lors de la récupération d'une nouvelle version, le fichier MOF récupéré est vérifié via un fichier checksum présent sur serveur Pull. Ci-dessous un schéma récapitulatif des deux modes (Pull et Push) :

image 

En mode Pull, nous n'avons plus à nous préoccuper de savoir si un de nos serveurs possède la bonne configuration (si elle lui a bien été transmise). Concernant le mode Pull, il existe actuellement deux types de dépôts pour centraliser les fichiers de configurations :

  • Un partage de fichier (expliqué dans cet article)
  • Un web service (son fonctionnement sera détaillé dans la partie 4 de ce guide sur DSC).

Ceux-ci seront interrogés par les serveurs utilisant DSC.

Comme pour le mode Push, il est nécessaire de configurer la ressource LocalConfigurationManager qui définira les différents paramètres de fonctionnement de DSC sur les machines clientes.
L'un des principaux paramètres configuré est le ConfigurationId. Il s'agit d'un GUID utilisé pour reconnaître le bon fichier de configuration à télécharger depuis le serveur Pull. Ce GUID est inscrit dans le nom du fichier de configuration (exemple : 6c7544f9-4fa9-4a62-a715-04aebfd70b85.mof).

La configuration du mode Pull s'effectue en différentes étapes :

  • Configuration de la ressource LocalConfigurationManager. Un fichier .meta.mof est créé par serveur pour appliqué la nouvelle configuration de la ressource sur chaque serveur.
  • Génération des fichiers de configuration des serveurs : il s'agit des fichiers .MOF contenant les configurations des serveurs utilisant DSC (un fichier par serveur).
  • Copie des fichiers sur le partage (serveur Pull).
  • Renommage des fichiers MOF avec le GUID de chaque machine concerné.
  • Création des fichiers checksums afin de vérifier l'intégrité des fichiers MOF lors de la récupération d'une configuration par un client (fichier .mof.checksum).

Dans la suite de cet article, je fournis des scripts pour automatiser l'ensemble de ces étapes. Certaines fonctions sont inspirés par l'article de Johan Akerström (http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/) sur le sujet. Les scripts présents en fin d’article sont compatibles avec Windows 7/2008R2 car ils n'utilisent pas les nouvelles Cmdlet Powershell 3.0 et 4.0 uniquement disponibles sur Windows 8/2012 et supérieur. Cela permet de mettre en place un environnement DSC sur une infrastructure ne possédant pas les toutes dernières version des systèmes d'exploitation Microsoft. Avec ces scripts, il est possible de déployer un serveur Pull via DSC, d'automatiser la configuration de DSC sur les serveurs à gérer ainsi que la génération des fichiers de configuration.

Ressource LocalConfigurationManager

La ressource LocalConfigurationManager est expliquée dans la Partie 2 ; je vous invite donc à vous y référer en complément des paramètres liés au mode Pull.

  • RefreshMode : C’est le mode de fonctionnement du client DSC, la valeur attendue est Pull (pour que cela soit fonctionnel les paramètres DownloadManager et DownloadManagerCustomData sont obligatoire)
  • DownloadManager : Les valeurs possibles sont WebDownloadManager ou DSCFileDownloadManager. Lorsque l'on utilise le mode Pull en mode fichiers (et non web service) alors il faut choisir DSCFileDownloadManager.
  • DownloadManagerCustomData : Il s'agit ici d'indiquer dans un hashtable (via la clé SourcePath), le chemin d'accès aux fichiers MOF.
  • RefreshFrequencyMins : C'est le temps de refresh du fichier de config à partir de la source (ici SMB)).
  • ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
  • ConfigurationId : Un GUID pour récupérer les bons fichiers de configurations. La machine n'appliquera que le .MOF portant son ConfigurationID.
  • RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.
  • ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect (voir partie 2 pour l'explication).

Exemple de reconfiguration du LocalConfigurationManager pour le mode Pull via partage SMB :

NB : Pour appliquer cette configuration, le remote Powershell doit être activé sur les machines clientes (actif par défaut sur Windows 2012/R2)

Partage SMB

Le partage SMB est crucial car il contiendra l'intégralité des fichiers MOF et des fichiers checksums. A partir de Windows 8/2012 est supérieur, il existe un module permettant de gérer simplement les partages SMB (création avec New-SMBShare). Voici une méthode en WMI pour les postes n'ayant pas ce module. Cette dernière ajoute aussi les permissions de partage de contrôle total pour le groupe Everyone.

Ensuite, il est nécessaire d'appliquer des permissions NTFS en lecture et exécution pour le groupe Everyone :

ConfigurationID

Le GUID attendu par le paramètre ConfigurationId peut être généré automatiquement :

On peut aussi utiliser le GUID de l'ordinateur dans Active Directory comme l'explique Johan Akerström dans son article sur DSC : http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/

1 2 3 4 5 6 7 8 9 10 11 12 13 14
# Define Get Computer GUID Function
# Credit: Johan Åkerström
# http://blog.cosmoskey.com/powershell/desired-state-configuration-in-pull-mode-over-smb/
 
Function Get-ComputerGuid {
param(
[Parameter(Mandatory=$true)]
[string]$ComputerName
)
 
process {
([guid]([adsisearcher]"(samaccountname=$ComputerName`$)").FindOne().Properties["objectguid"][0]).Guid
}
}

On peut ensuite copier tous nos fichiers MOF de configuration sur le partage en changeant leurs noms avec le GUID.

Checksum des fichiers MOF

Depuis Powershell 4, il existe une cmdlet permettant de généré un hash : "Get-FileHash". L'algorithme à choisir est SHA256 (celui par défaut).Voici le lien vers la documentation :
http://technet.microsoft.com/en-us/library/dn520872.aspx

Il nous suffit ensuite de créer les fichiers checksum contenant ce hash.

Scripts

Deux scripts sont accessibles via les liens ci-dessous.

Configuration du serveur Pull avec DSC : ici

Librairie de fonctions nécessaires au serveur Pull : ici

L'outil permet de déployer un serveur DSC en mode PULL via DSC. Toutes les étapes sont automatisées. Les fichiers de configurations des clients sont automatiquement générés (copy et renommage avec le guid, création des fichiers checksum, création de tous les fichiers .meta.mof contenant la configuration du LocalConfigurationManager avec la commande Set-DSCLocalConfigurationManager). Il n'y a plus qu'à déployer les ressources LocalConfigurationManager sur les clients (avec un compte possédant les droits nécessaires). Voici les différentes étapes réalisées par le script par ordre d’exécution (chacune d’entre elles nécessite la réussite de la précédente via le paramètre de ressource DSC  DependsOn) :

  1. Un dossier contenant le partage avec les configurations est créé.
  2. La permission NTFS "ReadAndExecute" est ajouté au group everyone ainsi que la permission "FullControl" pour le compte ordinateur du serveur Pull. En effet, il va créer des dossiers et générer des fichiers. C'est ce compte qui exécute les fichiers de configuration dans DSC.
  3. Un partage est généré.
  4. Sur ce partage, le groupe everyone possède la permission "Change". Le compte ordinateur du serveur Pull a des droits "FullControl".
  5. Une arborescence de dossier est généré :
        image Il y a un dossier contenant les configurations créées par l'administrateur (OriginalConfiguration). Un second répertoire (Configuration) a les même configurations renommées avec le GUID de l'ordinateur (pré requis du mode Pull pour que le client récupère sa configuration, voir explication sur le ConfigurationId). Ce dernier contient aussi un fichier checksum pour chaque fichier de configuration .MOF. Un script de librairie est présent dans un troisième dossier (Scripts). Enfin, un répertoire nommé LCM possède tous les fichiers ".meta.mof" de configuration de la ressource LocalConfigurationManager des machines clients.
  6. Le script Powershell contenant les fonctions suivantes est copié dans le répertoire des scripts du serveur Pull :
    • Récupération d'ordinateurs sans module Active Directory (via adsisearcher)
    • Génération automatique des fichiers checksum à partir d'un fichier .MOF
    • Récupération du GUID d'un ordinateur
    • Configuration de la ressource LocalConfigurationManager
  7. Les fichiers de configuration de la ressource LocalConfigurationManager sont générées pour chaque machine client via le filtre qui a été convenu. Il est possible de sélectionner des ordinateurs par unité d'organisation ou par groupe Active Directory suivant les paramètres entrées lors de la génération du fichier de configuration MOF du serveur Pull.
  8. Copie des fichiers de configurations créer par l'utilisateur sur le répertoire contenant les .MOF renommés avec un GUID ; ainsi que création des fichiers checksum associés pour que les clients vérifient l'intégrité de la configuration récupérée. Gràce à cette étape dès qu'une nouvelle configuration ou une modification de l'une d'entre elles a lieu, elle est automatiquement mis à jour avec un une regénération du fichier checksum.

Les étapes 1,2,3,4,5,7,8 sont des ressources DSC de types "script" tandis que l'étape 6 est de type "file".

NB : DSC possède son propre journal d'événements pour vérifier son bon fonctionnement : Applications and Services Logs / Microsoft / Windows Desired State Configuration. Ce dernier permet de superviser DSC lorsqu’on ne déploie plus les configurations manuellement (en mode Push).

Exchange 2013 SP1 : Retour du rôle Edge

Introduction

Depuis la sortie d’Exchange 2013, le rôle n’avait pas été porté dans cette nouvelle version d’Exchange. Ce qui oblige les entreprises à faire l’upgrade vers Exchange 2013 en conservant les serveurs Exchange Edge en version 2010. Pour rappel, le rôle Edge est apparu avec Exchange 2007.

Depuis février 2014, Microsoft à publier le SP1 d’Exchange 2013 et réintroduit le rôle Edge ! Vous allez maintenant pouvoir mettre à jour vos infrastructures.

Pour rappel, la principale fonctionnalité du rôle Edge est de protéger votre infrastructure de messagerie des spam et virus grâce aux différents agents présent sur le serveur Edge.

Il faut noter qu’avec la version 2013 d’Exchange, la console Exchange de management telle qu’on la connaissait avec Exchange 2010, n’existe plus. La console est remplacée par le portail web ECP. Ce portail n’existe pas sur le serveur Edge. Un serveur Edge 2013 devra donc être administrer uniquement en PowerShell.

Installation

Sur le serveur Edge, quand vous exécutez l’installation, vous pouvez maintenant choisir le rôle Edge. Les outils de gestion s’installent automatiquement ainsi que les prérequis.

image

Installation et configuration

Voici le lien de téléchargement du service pack 1 : http://www.microsoft.com/en-us/download/details.aspx?id=41994.

Une fois que le rôle est installé et le serveur redémarré, vous devez effectuer deux actions : Installer la clé du produit et faire l’abonnement Edge (il est possible de se passer de cette étape)

Installation de la clé produit :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

Set-ExchangeServer <NomDuEdge> –ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Pour vérifier l’application de la clé, on peut lancer la cmdlet : Get-ExchangeServer

Créer l’abonnement Edge vers vos serveurs Exchange 2013 :

Sur le serveur Edge, dans la console Exchange Management Shell, saisir la cmdlet :

New-EdgeSubscription -FileName "C:\EdgeSubscriptionInfo.xml"

Sur un serveur Exchange, dans une console Exchange Management Shell, après avoir copié le fichier XML issu du serveur Edge :

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeSubscriptionInfo.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site"

Maintenant que le serveur Edge est en place, il faut le configurer, voici les principales commandes qui vont vous intéresser :

  • Get-IPBlockListProvidersConfig – Pour spécifier un fournisseur de blacklist
  • Get-SenderFilterConfig – Pour bloquer des expéditeurs
  • Get-RecipientFilterConfig – Bloquer des destinataires
  • Get-ContentFilterConfig – Bloquer du contenu dans les mails

Je vous laisse le soin d’aller voir sur Technet (http://technet.microsoft.com/en-us/library/jj218660(v=exchg.150).aspx) pour savoir comment utiliser ces cmdlets et en découvrir bien d’autres.

Conclusion

Grâce à ce service pack 1 d’Exchange 2013, vous pouvez mettre à jour votre serveur Edge vers la dernière version de manière à avoir un niveau de version homogène.

Nous pouvons vous accompagner dans la mise à jour de votre infrastructure de messagerie Exchange, n’hésitez pas à nous consulter pour un éventuel projet.

Créer une machine virtuelle dans Microsoft Azure

Nous allons voir ici comment créer une machine virtuelle dans le cloud de Microsoft, Azure.

Il est intéressant de migrer vers la plateforme Azure car Microsoft offre beaucoup d’avantages. Notamment pour bénéficier des performances d’un Datacenter sans vous soucier de sa gestion et en ne payant que ce que vous consommez.

Voici les différentes étapes à suivre pour créer une machine virtuelle. Dans mon exemple, je vais créer une VM avec Windows Server 2012 R2.

Création

Dans un premier temps, il faut ouvrir le portail de gestion : https://manage.windowsazure.com/.

Cliquez sur “Nouveau” en bas à gauche :

image Choisissez “Calcul” –> “Machine virtuelle” –> “A partir de la galerie” :

image L’assistant démarre. Choisissez une image Windows Server. Ici vous pouvez choisir la version et l’édition. Cliquez sur suivant en bas à droite.

imageSaisissez le nom de la machine virtuelle, la taille (voir la grille de prix) ainsi que le compte d’administration et le mot de passe. Cliquez sur suivant.

image Choisissez ici le nom DNS public de la machine, l’abonnement associé et l’emplacement de la VM (zone du datacenter Microsoft). Cliquez sur suivant.

image Cliquez sur valider.

image Patientez quelques minutes pendant la création de la VM. Une fois fini vous devez avoir ce message :

image Dans le tableau de bord, on peux voir la VM :

image

Gestion

Pour gérer votre serveur à proprement parler, il faut pouvoir se connecter dessus. Pour cela, plusieurs méthodes nous sont offertes. Avant tout, il faut aller dans les paramètres de la VM de la console Azure, puis configurer les points de terminaison.

image

On voit ici qu’il y’a le RDP et le PowerShell actif par défaut. Il est possible de changer les ports public pour l’administration ainsi que de rajouter d’autres protocoles, tel que SSH, HTTPS, MSSQL, suivant vos besoins.

En RDP

Il suffit d’ouvrir le bureau à distance et de saisir l’adresse du serveur et le port public.image Il faut saisir le compte d’administration renseigné lors de la création de la VM. Attention à bien saisir le login sous la forme NomVM\NomUtilisateur.

image Nous voici connectés au bureau de la VM !

image

En Powershell

Il faut installer les outils Powershell pour Windows Azure (lien : http://go.microsoft.com/fwlink/p/?linkid=320376&clcid=0x409) ensuite ouvrir la console “Windows Azure Powershell”.

Il faut commencer par se connecter a son compte Azure avec la cmdlet “Add-AzureAccount”.

Ensuite, petite subtilité, il faut bien choisir l’abonnement utilisé pour créer la VM, voici un exemple :

image

Il est possible d’obtenir toutes les informations de la VM, de manière identique à un déploiement HyperV sur site, mais avec les particularités Azure (InstanceSize, DNSName,…).

image 

Conclusion

 

Vous pouvez maintenant gérer vos machines virtuelles Azure. Il est aussi possible, bien sûr, de démarrer, arrêter les VM mais aussi en créer: de quoi automatiser vos déploiements.

Powershell / Exchange : Erreur 9323 - Certificat expiré sur un objet AD

Introduction

Cet article permet de montrer la gestion des certificats via Powershell au travers d'un problème concret rencontré sur une infrastructure Exchange. Une solution basée sur un script Powershell sera détaillée.

Erreur rencontrée

Contexte : Infrastructure Exchange 2010 avec plusieurs dizaine de milliers de contacts Active Directory importés et mis à jour par un outil tierce.

Dans l’observateur d’événements de nombreux événements 9323 apparaissent.

9323

Ces derniers sont liés à la génération de l'OAB. Exchange détecte un utilisateur dont un certificat est expiré. Ces événements n'apparaissent que sur des objets de type "Contact"  La solution doit contrôler tous les objets Active Directory de ce type.

Solution

La soluton proposée pour purger les certificats invalides des contacts Active Directory se base sur un script Powershell V2. Ce dernier analyse l'attribut UserCertificate (il s'agit d'une liste de certificat).

Avec le type d'objet "System.Security.Cryptography.X509Certificates.X509Certificate2", il est possible d'obtenir des informations sur les certficats contenus dans cet attribut sous forme lisible (et non pas un tableau de bytes ou de valeur hexadécimal comme sur la console Active Directory Users and Computers).

Ci-dessous, un exemple de données récupérées sur les certificats d'un objet Active Directory (ici, il n'y a qu'un seul certificat et la variable $User est un utilisateur Active Directory).

Certificate

On remarque qu'on accède à des renseignements comme l'émetteur ou le sujet. Les informations qui nous interessent (dates de validité du certificat) sont aussi présentes. Il suffit donc de comparer la date d'expiration contenue dans l'attribut "notAfter" avec la date du jour en cours pour détecter les certificats expirés.

Grâce à la cmdlet "Set-ADObject", il sera ensuite possible de supprimer les certificats qui ne sont plus valides.

Script

En amont de ce script, un transcript est lancé afin de loguer toute les opération effectuées. Une vérification de la présence du module ActiveDirectory ainsi que son chargement sont ensuite réalisées.

Le script appelle une fonction créée pour traiter tout objet AD (ou tableau d'objets AD) qui lui est passé. Pour ma part, je transmets en paramètre tous les contacts présents dans Active Directory. Cependant cette fonction peut très bien être utilisée avec des utilisateurs. Voici l'algolrithme mis en place dans la fonction Test-CertExpiration :

  1. Filtrage des objets pour ne conserver que ceux ayant au moins un certificat présent dans l'attribut userCertificate.
  2. Boucle ForEach sur tous les utilisateurs :
    1. Boucle For sur tous les certificats de l'utilisateur (pas de ForEach afin d'être certain de la position du certificat dans l'attribut userCertificate)
    2. Analyse de la date d'expiration
    3. Si le paramètre DeleteExpired est présent alors on supprime le certificat dans Active     Directory s'il n'est plus valide.
    4. Si le paramètre DeleteExpired n'est pas présent alors deux attributs sont ajoutés à l'objet     AD :
      1. CertExpired : contient les index des certificats expirés dans le tableau de l'attribut userCertificate
      2. CertValid : contient les index des certificats valides dans le tableau de l'attribut userCertificate
  3. Si le paramètre Export et ExportPath ont été renseigné alors le tableau d'objet AD est exporté sous format CSV avec la liste des index des certificats valides et expirés.

Ci-dessous, vous trouverez le script intégralement commenté. A noter, que le compte exécutant ce script doit posséder les droit suffisants à la modifications des objets AD concernés (via une délégation par exemple).

Ici, la fonction Test-CertExpiration, est utilisée en mode suppression, cependant il est aussi possible de se servir du mode Export pour n'effectuer qu'un simple audit (logué dans un fichier) des objets concernés via la commande suivante :

$ADObjets est un tableau d'objets Active Directory.

Il est enfin possible de ne donner qu'un tableau d'objets AD à traiter sans spécifier le mode export ou suppression :

Dans ce cas, un tableau d'objets AD est retourné. Pour chaque objet, les attributs CertExpired et CertValid sont ajoutés.

Quelques points clés du fonctionnement de la fonction Test-CertExpiration :

Les paramètres Export et DeleteExpired sont de type switch et ne peuvent apparaître ensemble. Le paramètre ExportPath est dynamique et n'est disponible que si le paramètre Export a été choisi.

Pour information, il n'est pas nécessaire de paralléliser le processus de contrôle du certificat. Après un test effectué sur plus de 90000 contacts Active Directory, il s'avère que ce dernier a duré moins de 5 minutes. Utiliser du multi thread (workflow ou job Powershell) alourdirai le script et ralentirai le processus au lieu de l'accélérer.