Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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

par Cyril Azoulay | 11 Nov 2016 | Uncategorized

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 :

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)

par Florian Alikoff | 7 Oct 2016 | FIM

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 :

Partie 1 : Introduction, licensing, concepts
Partie 2 : Installation de FIM Synchronisation Service
Partie 3 : Configuration des Managements Agents AD et SQL
Partie 4 : Configuration du Management Agent AD / Profil d’exécution
Partie 5 : Administration de FIM / Gestion de la metaverse
Partie 6 : Création d’une règle d’extension (transformation d’attributs)
Partie 7 : Création d’une règle d’extension de la metaverse (provisioning)

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.

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.

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.

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.

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 :

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

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

Object Deletion rule
Conntor Filter rule
Join Rule
Projection rule
Import Attribute Flow rule

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

Provisioning rule
Deprovisioning Rule
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

par Florian Alikoff | 5 Oct 2016 | DirectAccess, Windows Server 2012 R2

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.

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”.

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.

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

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

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

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.

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”.