PI Services

Le blog des collaborateurs de PI Services

Chargement du Module PowerShell SCCM 2012 R2

Vous avez installé les outils admins sur un serveur mais vous ne trouvez pas le module Configuration Manager PowerShell.

Il y a une petite subtilité, celui ci est présent mais dans les binaires de l’application:

le fichier à importer se trouver dans le répertoire c:\program files (x86)\Microsoft Configuration Manager\AdminConsole\bin et se nomme ConfigurationManger.psd1

 

Avant import

image

 

Après import

image

Identification du noeud SQL actif en PS

Vous êtes dans un contexte de database mirroré, et vous avez besoin de connaitre l’actuel serveur principal.

 

Voici une fonction qui va vous permettre de l’identifier.

 

Function Test-SQLConn ($Server)
{
    $connectionString = "Data Source=$Server;Integrated Security=true;Initial Catalog=master;Connect Timeout=2;"
    $sqlConn = new-object ("Data.SqlClient.SqlConnection") $connectionString
    trap
    {
    Write-host "Closed";
    continue
    }
    $sqlConn.Open()
    if ($sqlConn.State -eq 'Open')
    {
        $sqlConn.Close();
        "Opened successfully."
    }
}

 

image

SCOM 2012 - Des bugs dans le MP DHCP 2012

Malgré des mises à jour relativement suivies, le Management Pack DHCP conserve des erreurs y compris dans sa version la plus récente à ce jour (6.0.7301.0).

Deux problèmes en particulier me semblent particulièrement récurrents :

- Une alerte “Power Shell Script failed to run” caracterisée par sa description : “System.Management.Automation.RuntimeException: Method invocation failed because [System.String[]] doesn't contain a method named 'Item'.
At line:65 char:20
+ $OS = $CurrVer.Item <<<< (0) + "." + $CurrVer.Item(1) »

- Une absence de retour en Healthy du moniteur DHCP IPv4 Runtime Active Directory Availability Monitor.

Attardons nous donc sur ces deux problèmes.

Dans le premier cas, le message d’erreur nous indique qu’il s’agit de l’échec de l’exécution de la découverte Microsoft.Windows.DHCPServer.2012.R2.ClusterServer.Discovery. Cette dernière permet, comme son nom l’indique, de découvrir les clusters DHCP 2012 R2 et elle utilise pour ce faire le script powershell DiscoverDHCPClusterServer2012R2.

Cette découverte est ciblée sur la classe Virtual Server, c’est-à-dire tous les clusters Windows (et pas uniquement ceux sous Windows 2012), mais le script de découverte vérifie bien la version de Windows dont il s’agit en début d’exécution à l’aide du code suivant :

$CurrOS = Get-WmiObject -Namespace "root\cimv2" -Query "select Version from Win32_OperatingSystem"
$OSVer = $CurrOS.Version
$CurrVer = $OSVer.Split(".")
$OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1)
if ($OS -ne $TargetOSVersion)
{
Write-Host "$SCRIPT_NAME - No Target Operating System"
$discoveryData
exit
}
else
{ exécution de la découverte }

On retrouve dans ce bloc de code la commande indiquée dans la description de l’erreur, $OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1) .

La raison de cette erreur est assez simple : Powershell v2 ne supporte pas la méthode Item, comme l’indique clairement le message d’erreur « Method invocation failed because [System.String[]] doesn't contain a method named 'Item’ ». L’exécution du script échoue donc sur tous les serveurs Windows 2008 ou antérieurs pour lesquels powershell n’a pas été mis à jour !

La résolution est aussi plutôt évidente, il suffit d’utiliser la syntaxe suivante (compatible avec toutes les versions de powershell) à la place :

$OS = $CurrVer[0] + "." + $CurrVer[1]

Passons maintenant au second problème.

Le moniteur est de type Event Reset, c’est-à-dire qu’il doit revenir en Healthy lorsqu’un événement indiquant un retour à la normal apparaît dans le journal d’événement ; par défaut l’événement 1048.

Il semble toutefois que cet événement soit incorrect, ou en tout cas qu’il ne soit pas le seul qui puisse être généré. Dans le cas de l’environnement où j’ai constaté le bug, cet événement n’est jamais généré mais par contre un événement 1044 qui semble valider le même retour à la normal est lui bien présent.

Il faut donc rajouter cet événement au moniteur.

Malheureusement, pour nos deux problèmes, il s’agit d’un management pack scellé. Il est donc impossible de modifier directement le script de la découverte ou la configuration du moniteur.

La solution consiste alors à créer un management pack correctif, qui implémentera donc les bonnes versions de ces workflows et désactivera les versions d’origines erronées.

Et pour ceux qui ne se sentent pas l’âme d’un développeur, un tel Management Pack réalisé par mes soins est disponible ici : Microsoft.Windows.DHCPServer.Fix.xml

Note : ce management pack a été testé dans un environnement spécifique, rien ne garantit qu’il fonctionnera ou qu’il ne posera aucun problème dans le vôtre. Prenez donc le temps de le valider avant de le déployer en production !

Windows Server 2008 R2 : Impossible d'activer la découverte réseau

Vous est il déjà arrivé de ne pas réussir à activer la découverte réseau sur votre serveur ? 

Pas d'inquiétude cela peut arriver si certains services ne sont pas démarrés.

Contexte

Voici ce que l'on trouve lorsque l'on se rend dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés"

 

Ici lorsque l'on coche la case "Activer la découverte de réseau" puis "Enregistrer les modifications"

 

 

Si l'on retourne dans le menu "Paramètres de partage avancés" nous nous apercevons que dans le profil que nous venons juste de modifier, la case "Activer la découverte de réseau" n'est pas sélectionné et que celle qui l'est n'est autre que "Désactiver la découverte de réseau"

 

 

Solution

Ce phénomène est lié au fait que certains services ne sont pas démarrés, voici la marche à suivre.

Lancez la console "services.msc" et démarrez les services suivants:

  1. Découverte SSDP -->  Pour les OS Anglais (SSDP Discovery)
  2. Hôte de périphérique UPNP -->  Pour les OS Anglais (UPnP Device Host)

 

Maintenant vous pouvez retourner dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés" et enfin activer la découverte de réseau, elle ne changera plus.

 

Powershell : Découverte des postes en DHCP et IP fixes

Qui n'a jamais été confronté à un conflit d'adresse IP dans son réseau?

Le plus énervant quand cela arrive c'est de déterminer qui a une IP fixe sur sa machine alors que l'ensemble du parc est censé être en DHCP.

Afin de se se faciliter la tâche et de ne pas devoir passer sur chaque poste voici un script qui va vous permettre de savoir quels postes sont éteints, quels postes sont en DHCP et surtout lesquels ne le sont pas et avec quelle adresse IP (ou plutôt l'ensemble des configurations de chaque carte réseau).

Les Outils :

Pour ce faire vous aurez besoin d'un fichier texte avec les informations suivantes:

  • La première ligne doit s'appeler "Ordi"
  • le reste du fichier contient le nom de vos machines

Exemple :

Dans mon cas le fichier s'appelle DHCP.txt (le nom sera réutilisé dans le Script)

Une fois que le fichier est créé passons à la seconde partie le script:

Dans votre cas il suffira de modifier les lignes:

  • 3
  • 10
  • 17
  • 18
  • 19 
# Script pour détecter l'état des cartes réseaux

$CSV = "C:\Users\XXX\Documents\DHCP.txt"  # Ici on déclare le chemin d'accès au fichier créé plus tôt

# Import du fichier
Import-Csv -Path $CSV | ForEach-Object {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt

# Test de connexion afin de vérifier que le poste est démarré
If ((Test-connection $Postes -count 2 -Quiet) -eq "True") {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt
$Poste_DHCP = "C:\Users\XXX\Documents\Audit\OK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes en DHCP
$Poste_Off = "C:\Users\XXX\Documents\Audit\NOK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes éteints

# Récupération des paramètres de la ou des cartes réseaux
Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | ForEach-Object {
$IP = $_.IPAddress
$DHCP = $_.DHCPEnabled
if (($DHCP -eq $False) -and ($IP -ne $null)) {Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | Select-Object -Property ServiceName,Description,DHCPEnabled,IPEnabled,IPAddress | fl | Out-File $Destination}
Elseif (($DHCP -eq $True) -and ($IP -ne $null)) {Write-Output "Le poste $Postes est en DHCP" | Add-Content -Path $Poste_DHCP}
}
}
Else {
Write-Output "Le poste $Postes est éteint" | Add-Content -Path $Poste_Off
}}

 

En espérant que cela vous servira.

Azure Stack - TP2 v2, VPN et Windows 7

 

La sortie il y a quelques jours de la seconde version de la TP2 d’Azure Stack (dite “refresh”) a enfin été pour moi l’occasion de tester ce produit qui s’annonce très prometteur (pour rappel, il s’agit de la possibilité de déployer Azure dans votre Datacenter).

Je ne reviendrais pas ici sur le détail de son déploiement, il existe déjà de nombreux articles à ce sujet.

Notez simplement que cette seconde édition de la TP2 apporte le support du PaaS (par exemple pour déployer des bases SQL) ainsi qu’un script de déploiement amélioré : j’ai pu réaliser l’installation du début à la fin sans erreur, alors qu’une précédente tentative avec la TP2 d’origine s’était avérée nettement plus réticente. Cette nouvelle version nécessite une réinstallation complète du POC (il n’est pas possible de mettre à jour depuis la TP2 d’origine) et est disponible ici : https://azure.microsoft.com/en-us/blog/new-azure-paas-services-available-for-azure-stack-technical-preview-2-tp2/

Attention cependant, une étape manuelle reste nécessaire à la fin du déploiement si vous avez utilisé une IP statique, autrement votre infrastructure deviendra inutilisable au bout de 10 jours : https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=AzureStack&announcementId=f35560ea-b0d2-4be0-b407-e20fe631d9fe

Une fois déployée, vous avez deux possibilités pour accéder au portail web Azure Stack :

- Vous connecter à la VM console (mas-con01) via la console Hyper-V ou en Bureau à distance depuis votre serveur hôte puis ouvrir le raccourci « Microsoft Azure Stack Portal » qui se trouve sur le bureau

- Créer une connexion VPN vers votre infrastructure Azure Stack afin d’y accéder directement depuis votre poste client.

Cette seconde possibilité est évidemment la plus pratique, mais je me suis heurté à un problème : la procédure proposée sur Technet ( https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-connect-azure-stack chapitre « connect with VPN ») ne fonctionne pas sous Windows 7, même en ayant installé Powershell 5, en raison de l’absence des cmdlet powershell dédiés au VPN.
Comme je ne disposais que d’un poste sous Windows 7 dans l’environnement où a été réalisé ce déploiement de test, j’ai eu recours à une solution de contournement :

Dans le centre réseau et partage, cliquez sur Configurer une nouvelle connexion ou un nouveau réseau :

clip_image002

Sélectionnez Connexion à votre espace de travail :

clip_image004

Sélectionnez Utiliser ma connexion Internet (VPN) :

clip_image006

Indiquez l’adresse IP de votre réseau de la VM MAS-BGPNAT01. Il s’agit de l’IP indiquée dans le paramètre -NatIPv4Address si vous avez réalisé un déploiement avec une adresse statique. Indiquez également un nom explicite, AzureStack par exemple, et cochez la case Ne pas me connecter maintenant (il faudra faire des modifications à la configuration par défaut avant qu’elle puisse fonctionner).

clip_image008

Indiquez les détails du compte azurestack\azurestackadmin puis cliquez sur créer :

clip_image010

Rouvrez maintenant les propriétés de cette connexion VPN :

clip_image012

Dans l’onglet Gestion de réseau, sélectionnez Propriétés internet version 4, cliquez sur Propriétés. Cliquez sur Avancé dans la fenêtre qui s’ouvre, puis décochez Utiliser la passerelle par défaut :

clip_image014

A l’aide de la commande route print, récupérez le numéro de l’interface réseau AzureStack :

clip_image016

Ajoutez les deux routes statiques suivantes (où « XX » est le numéro récupéré juste avant) :

route add 192.168.105.0 mask 255.255.255.224 192.168.200.225 IF XX -p

route add 192.168.102.0 mask 255.255.255.224 192.168.200.225 IF XX -p

Enfin, si votre navigateur (Internet Explorer vivement recommandé, le portail fonctionne assez mal avec Firefox et Chrome ! ) passe par un proxy pour accéder à internet, pensez à en exclure toutes les url du domaine azurestack.local et de ses sous-domaines (*.azurestack.local ), autrement vous ne pourrez pas charger (ou pas complètement) le portail !

clip_image018

 

Voilà, vous pouvez maintenant vous connecter au VPN, puis ouvrir votre navigateur à l’adresse http://portal.azurestack.local et commencer à découvrir Azure Stack!

SCOM - La console plante depuis les patchs de sécurité d’Octobre

Quoi de plus frustrant pour reprendre le travail que de se retrouver face à son outil préféré devenu soudain inutilisable?

Si depuis quelques jours, votre console SCOM fait des siennes et plante à chaque fois que vous tentez d’accéder à une vue de type “état” (telle que Windows Computers par exemple), avec l’erreur suivante :

image

Et qu’en même temps, vous retrouvez un message d’erreur similaire au suivant dans votre journal d’évènements Application :

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1177, time stamp: 0x5697e092 Faulting module name: ntdll.dll, version: 6.3.9600.18438, time stamp: 0x57ae642e Exception code: 0xc0000374 Fault offset: 0x00000000000f1b70 Faulting process id: 0xfac Faulting application start time: 0x01d2254a42863351 Faulting application path: <C:\Program Files\Microsoft System Center 2012 R2 \Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Le coupable est tout trouvé, il s’agit des patchs de sécurité Windows du mois d’Octobre, en particulier MS16-118 et MS16-126 (concernant Internet explorer notamment), comme le confirme la KB suivante : https://support.microsoft.com/en-us/kb/3200006

Il ne vous reste plus qu’à appliquer sur les machines hébergeant vos consoles SCOM (serveurs SCOM, postes d’administration, serveurs Citrix…) le hotfix proposé.

Attention, ce hotfix n’est pas spécifique à SCOM et sa dénomination dans le catalogue Microsoft peut donc être trompeuse : il s’agit par exemple de “Mise à jour pour Internet Explorer 11 pour Windows Server 2012 R2 (KB3200006) “ dans le cas du hotfix pour Win 2012 R2.

L’installation de ce hotfix ne nécessite normalement pas de redémarrage, mais si le problème persiste après l’installation cela aidera à le résoudre définitivement.

FIM Synchronization Service Partie 7 : Création d'une règle d'extension de la metaverse (provisioning)

Introduction

La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :

  • d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
  • d'éviter les erreurs humaines de manipulations
  • de réduire les tâches d'exploitation
  • de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …) 

Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompagny" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server)  vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.

Ces articles vont s'articuler de la façon suivante :

Lors de cette septième et dernière partie, je vais vous présenter le second type de DLL que l'on peut développer pour le service de Synchronization FIM. Il s'agit des règles d'extension de la métaverse. Celles-ci permettent de créer des objets dans le connector space lorsque celui-ci n'existe pas. Lors d'une opération d'export, ces nouveaux objets seront aussi créés dans le système connecté. Dans notre cas, la règle d'extension de la métaverse prendra en charge la création des comptes utilisateur n'existant pas dans l'annuaire Active Directory (provisioning). Comme pour le précédent article, je vais d'abord vous présenter comment créer ce type de projet depuis la console d'administration de FIM Synchronization Service puis les différentes méthodes que l'on peut configurer avant de terminer sur un exemple d'implémentation.

NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.

Création d'une règle d'extension de la métaverse

Comme pour les règles d'extension des Managements Agents, celle de la métaverse repose sur une DLL (nous utiliserons également le C# et Visual Studio pour la créer). Néanmoins, il n'est possible de créer qu'une seule règle d'extension de la métaverse par environnement de FIM Synchronization Service. Pour réaliser cette opération, il suffit de se rendre dans le menu Tools de la console de gestion de FIM Synchronization Service. Il faut ensuite cliquer sur Options.

Image

Un assistant apparaît. Pour activer la règle d'extension de la métaverse, il faut cocher la case Enable metaverse rules extension. Il est ensuite nécessaire de définir le nom de la DLL. Cette dernière sera située dans le même répertoire que les règles d'extensions (par défaut C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions). Afin que le provisioning soit traité par la règle d'extension, il convient de cocher la case Enable Provisioning Rules Extension. Aussi comme dans l'article précédent, on peut générer le squelette de la règle d'extension (un projet Visual Studio) via le bouton Create Rules Extension Project.

NB : La case Enable Synchronization Rule Provisioning n'est pas utile dans cette série d'articles. Cette dernière permet de gérer le provisioning au travers de la syntaxe déclarative utilisée par FIM Service / Portal. Pour rappel cette dernière simplifie la customisation des flux de synchronisation en outrepassant la nécessité de réaliser le développement d'une DLL. Néanmoins, elle nécessite le déploiement de FIM Service et FIM Portal et donc l'achat des CALs associés.

Image

Enfin, si vous créez le projet, vous retrouver le même assistant que dans la partie 6. Ce dernier vous demande les informations nécessaires à la création du projet Visual Studio. Ce dernier sera composé de plusieurs fichiers dont une classe (fichier avec l'extension .cs portant le nom de la règle d'extension) contenant différentes méthodes qu'il faudra compléter pour définir les règles de provisioning/deprovisioning.

Image

Notions

Généralités

Contrairement aux règles d'extensions des Management Agent, il n'est pas possible de choisir quand une dll d'extension de la métaverse est appelée. En effet, celle-ci est automatiquement exécutée lorsqu'un objet de la métaverse est modifié. Cela peut intervenir lors des actions suivantes :

  • Une règle d'import modifie un attribut d'un objet.
  • Un objet d'un connector space réalise une jointure (manuelle via l'outil Joiner ou automatique).
  • Un objet d'un connector space réalise une projection.
  • Un objet d'un connector space  a été déconnecté alors que l'objet de la métaverse n'a pas été supprimé.
  • Une synchronisation complète est exécutée.

Contrairement à une règle d'extension d'un Management Agent, la règle de provisioning n'intervient pas en fonction d'une configuration dans FIM.

Méthodes

Initialize et Terminate

Ces dernières fonctionnent de la même façon que dans les règles d'extension d'un Management Agent (veuillez-vous référer à la partie 6 : LIEN).

ShouldDeleteFromMV

Cette méthode contrôle le comportement de suppression d'un objet dans la métaverse. Cela correspond à la configuration que nous avons abordé lors de la partie 5 (Object Deletion Rule). Ainsi, si les choix disponibles via l'interface graphique ne vous conviennent pas, il est possible d'indiquer un comportement particulier pour décider de la suppression d'un objet de la métaverse.

Image

Pour rappel, les règles de suppression d'objets se configurent pour chaque type d'objet. La fonction ShouldDeleteFromMV ne s'appliquera donc sur un objet que si vous activez la suppression via règle d'extension pour son type.

Provision

Provision est la méthode permettant de gérer notamment le provisioning / deprovisioning via la création d'un objet dans un connector space (ce dernier est ensuite créé dans le système connecté lors de la prochaine opération d'export).

Aussi, grâce à celle-ci il est possible d’effectuer d’autres opérations comme les déplacements d'objets.

Ordre d'application

Enfin, après avoir vu toutes les étapes de synchronisation au travers des différents articles, il est temps de faire un récapitulatif sur l'ordre d'application dans lequel elles interviennent. Lors d'une synchronisation, il existe deux phases :

  1. Synchronisation entrante : depuis le connector space vers la métaverse
  2. Synchronisation sortante : depuis la métaverse vers le connector space

Lors de la première étape, voici les règles qui s'appliquent :

  1. Object Deletion rule
  2. Conntor Filter rule
  3. Join Rule
  4. Projection rule
  5. Import Attribute Flow rule

Durant la synchronisation sortante, l'ordre d'application est le suivant :

  1. Provisioning rule
  2. Deprovisioning Rule
  3. Export Attribute flow rule

Exemple

NB : Pour cet exemple, j'intègre aussi l'implémentation de la méthode Initialize qui va être en charge de récupérer une configuration au travers d'un fichier XML. Ce dernier contient uniquement l'unité d'organisation dans laquelle les utilisateurs doivent être créés. 

L'objectif de cet exemple est de créer des utilisateurs dans l'annuaire Active Directory. Pour effectuer cette opération, il faut créer un nouveau connecteur dans le Management Agent Active Directory. Pour ce faire, on récupère les connecteurs existants liés à l'objet dans la métaverse (en spécifiant le nom du Management Agent concernés) :

Il suffit ensuite de s'assurer qu'il n'en existe aucun en les comptant.

La création d'un nouveau connecteur s'effectue avec la méthode StartNewConnector (voir la code complet ci-dessous) en indiquant le type d'objet à créer dans le connector space en paramètre.

Il est ensuite nécessaire de peupler les attributs de l'objet. Il faut notamment créer le distinguishedName de l'objet. Cela s'effectue en concaténant le common name avec l'emplacement dans l'annuaire Active Directory (récupéré via le fichier de configuration XML). Les méthodes Concat et EscapeDNComponent sont ici utilisées pour la concaténation des chaînes et la transformation de celles-ci en type ReferenceValue.

Enfin, on peut sauvegarder le nouveau connecteur avec la méthode CommitNewConnector. Il est à noter que cette logique a été incluse dans une boucle incrémentant le common name avec un chiffre si un objet du même nom existe déjà dans l'unité d'organisation indiquée (une erreur du type ObjectAlreadyExistsException est alors retournée).

Voici le code complet de la règle d'extension de la métaverse :

Enfin, on remarque qu'il est possible de procéder au déplacement d'un objet dans l'annuaire Active Directory en changeant la valeur de l'attribut DN. Cette opération peut s'effectuer lorsqu'on détecte un connecteur existant.

Conclusion

De nombreuses personnalisations sont possibles au travers des règles d'extensions. Elle permettent de gérer tout les cas qui ne le sont pas au travers de l'interface graphique. De nombreux aspects de FIM Synchronization Service ont été abordés durant cette série d'articles. Néanmoins, il est possible de mettre en œuvre de nombreuses autres configurations en fonction du type de Management Agent déployé (et donc des sources de données) ainsi que des personnalisations à effectuer sur ceux-ci.

DirectAccess / Authentification forte : Ouvertures de session longues

Contexte

Le problème décrit ci-dessous a été rencontré dans le cadre d'une infrastructure DirectAccess sous Windows Server 2012 R2. Celui-ci peut se produire lorsque l'authentification forte (par carte à puce ou OTP) est activée avec des clients Windows 7.

Problème rencontré

Lorsque des lecteurs réseaux sont montés à l'ouverture de la session, cela peut empêcher cette dernière de s'ouvrir correctement et laisser l'utilisateur bloqué sur la page de “Bienvenue” pendant plusieurs minutes voir plusieurs dizaines de minutes.

Analyse

Pour rappel, la connectivité DirectAccess est composée de deux tunnels :

  • Le tunnel infrastructure utilisé notamment pour l'authentification et les stratégies de groupes.
  • Le tunnel utilisateur qui permet d'accéder à des ressources d'entreprise (partages, applications, site web) en fonction des autorisations de la personne connectée.

Ce problème est une conséquence de l'activation de l'authentification forte. En effet, tant que cette dernière n'a pas eu lieu, le tunnel utilisateur n’est pas créé. Les lecteurs réseaux étant des ressources liés à l’utilisateur, elles sont accédées par ce tunnel. Le système d’exploitation tente de monter les lecteurs réseaux et il faut attendre un timeout de cette opération avant que la session ne s’ouvre.

Solution

Toutes les solutions présentées ici sont des contournements permettant d'éviter le problème mais présentant toutes des inconvénients (à voir selon le cas, celle qui est le plus acceptable pour vous).

1/ Authentification forte pendant l'ouverture de session

Demander l’authentification forte lors de l’ouverture de session permet de déclencher la création du tunnel utilisateur. Ainsi, les lecteurs réseaux peuvent être montés. Cependant, cette méthode implique deux inconvénients :

  • Elle ne fonctionne que lorsque la méthode d’authentification forte utilisée est la carte à puce. En cas d’usage d’un OTP, cela ne peut être opérationnelle puisque DirectAccess à un processus propre pour gérer ce type d’authentification décorrélé de celui de l’ouverture de session. Pour plus d’informations, je vous invite à lire cet article : https://blog.piservices.fr/post/2015/11/23/DirectAccess-Deploiement-de-lauthentification-forte
  • L’utilisateur est obligé de s’authentifier sur son poste client avec l’authentification. Cela dégrade l’expérience utilisateur lorsque l’on se trouve en entreprise et qu’on ne souhaite donc pas utiliser DirecAccess.

2/ Logon Script

Les lecteurs réseaux sont parfois mappés par un script s'exécutant après l'ouverture de session (logon script). Pour que cette solution soit fonctionnelle, il suffit d'intégrer un test vérifiant que la connectivité DirectAccess est montée et de boucler dessus tant que ce n'est pas le cas. Cela peut être fait en validant l'accès à une ressource d'entreprise comme un partage ou l'url du serveur NLS de DirectAccess. Cependant cette solution présente l'inconvénient de devoir parfois laisser un script tourner continuellement.

3/ Management servers

L’une des autres possibilités est d’ajouter les serveurs de fichiers utilisés par ces lecteurs réseaux dans la liste des serveurs de management. Ainsi, l’accès à ceux-ci se fait via le tunnel infrastructure qui ne nécessite pas d’authentification forte et qui est monté dès le démarrage de l’ordinateur avant l’ouverture de session (si une connexion à internet est disponible). Cependant, cette méthode est contraire à la volonté de sécuriser les accès aux ressources d’entreprise avec de l’authentification forte. En effet, si l’utilisateur ouvre une session, il pourra accéder aux serveurs de fichiers sans authentification forte et par rebond à d’autres serveurs. Cette solution affaiblit donc la sécurité de l’infrastructure.

Si toutefois vous souhaitez implémenter cette solution, il suffit de lancer la console de gestion DirectAccess et de se rendre dans la configuration du serveur ou du cluster via le menu éponyme. Ensuite, il faut cliquer sur le bouton “Edit” de l’étape 3 de l’assistant de configuration.

Management 1
Dans l’onglet “Management”, il faut indiquer les noms DNS des serveurs de fichiers (les IP ne peuvent être indiquées que si vos serveurs communiquent en IPv6). Vous pouvez ensuite cliquer sur le bouton “Finish”.

Management 2

N’oubliez pas de mettre à jour les stratégies de groupe en cliquant sur le bandeau qui apparait en bas de la console de gestion DirectAccess. Enfin, il faut récupérer cette nouvelle version des GPOs DirectAccess sur vos postes clients (via la commande “gpupdate” par exemple).

4/ Déclenchement de la connectivité DirectAccess après le logon

Le démarrage d'un des services requis pour la connectivité DirectAccess après l'ouverture de session permet de corriger le phénomène. Le service IP Helper (iphlpsvc) permettant notamment de générer les interfaces de transitions IPv4/IPv6 est l'un deux. En effet, aucun tunnel dédié à DirectAccess n'existera tant que ce service n'est pas démarré. Ainsi, le client ne tentera pas de monter les lecteurs réseaux. Néanmoins, via cette méthode, le tunnel infrastructure n'existe pas non plus tant que l'utilisateur n'est pas connecté. Ainsi, un utilisateur qui se connecte pour la première fois sur un ordinateur ne pourra le faire via DirectAccess. Aussi, les patchs ne pourront être récupérés et les stratégies de groupes ne seront pas mises à jour tant qu'un utilisateur n'a pas ouvert de session. Si toutefois vous souhaitez réaliser cette manipulation, il suffit de créer une stratégie de groupe avec les paramètres ci-dessous.

Dans “Computer Configuration / Preferences / Services”, il faut changer le mode de démarrage du service IP Helper afin qu'il démarre manuellement.

Service 1

Dans “Configuration / Preferences / Scheduled Tasks”, il faut créer une tâche planifiée lancée par le compte “SYSTEM”.

GPO 1

On définit l'exécution de celle-ci à l'ouverture de session.

GPO 2

Enfin, on indique qu'il faut lancer le service IP Helper via la commande “net start”.

GPO 3

Aussi, il est nécessaire de gérer le cas d'un utilisateur qui ferme sa session afin de ne pas rencontrer le problème lors de la prochaine ouverture de session. Pour cela, il faut créer une seconde tâche se déclenchant à la fermeture de session.

Celle-ci est quasiment identique en dehors de la commande exécutée (“net stop”) et du déclencheur. Ce dernier est paramétré pour détecter l'événement 4647 du journal d'événements Sécurité. Celui-ci correspond à une demande de fermeture de session par l'utilisateur.

GPO 6

GPO 5

Enfin, cet évènement n'est pas généré par défaut. Pour l'obtenir, il faut activer l'audit sur la catégorie “Logoff”. Cette opération s'effectue par stratégie de groupe dans “Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies”.

GPO 7