PI Services

Le blog des collaborateurs de PI Services

DirectAccess : Conseils et Astuces

Introduction

Même si l'implémentation de DirectAccess s'est fortement simplifiée depuis Windows 2012 R2, il est possible de rencontrer de nombreuses difficultés lorsque le déploiement se fait en entreprise et non dans un lab. En effet, les postes clients, les équipements réseaux et bien d'autres facteurs peuvent influer sur le bon fonctionnement de cette technologie. Cet article à pour but de regrouper des conseils et des astuces pour réussir son déploiement de DirectAccess plus rapidement et est basé sur un retour d'expérience. Ainsi, j'évoquerai notamment les configurations non supportées, les outils pour dépanner un déploiement et quelques conseils lors de l’implémentation de son infrastructure DirectAccess.

NB : Cet article se base sur la version intégrée à Windows 2012 R2 de DirectAccess.

Configurations non supportées

Généralités :

Vous trouverez ci-dessous 2 liens vous indiquant les configurations non supportées et les types de déploiement possibles :

Manage Out et ISATAP :

Le Manage Out est la fonctionnalité permettant de gérer un client DirectAccess à distance. Cela peut offrir la possibilité à SCCM d'interagir avec l’ordinateur distant ou encore de se connecter à distance en remote desktop. Cependant, cela nécessite d'être en IPv6 natif. En effet, selon technet, bien que l'ISATAP soit fonctionnel, son utilisation n'est pas supportée. De plus, son déploiement n'est pas possible dans un environnement multisite ou avec du load balancing.

Modification des stratégies de groupes :

La modification des stratégies de groupes créés par DirectAccess n'est pas supportée.

Certificats à courbes elliptiques :

Les algorithmes de la suite B (dont font partie les algorithmes à courbes elliptiques) sont supportés depuis DirectAccess sous Windows 2008 R2 (https://technet.microsoft.com/en-us/library/ee382307(v=ws.10).aspx) et doivent pouvoir être utilisés pour les certificats ordinateurs . Cependant, il n'existe aucune documentation permettant de les utiliser avec DirectAccess. Aussi, le choix des algorithmes utilisés se fait au niveau des règles de connexion qui sont paramétrées par les stratégies de groupes DirectAccess. Par défaut, la règle de connexion utilise l'algorithme RSA. Pour le changer il faut se rendre dans les stratégies de groupe puis modifier les règles suivantes :

  • GPO DirectAccess Client Settings : DirectAccess Policy-ClientToCorp

  • GPO DirectAccess Client Settings : DirectAccess Policy-ClientToInfra

  • GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToCorp

  • GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToInfra

Les règles s'éditent dans “Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security”. Dans l'onglet “Authentication”, il faut cliquer sur le bouton “Customize” puis éditer la méthode d'authentification utilisant des certificats ordinateurs en la sélectionnant et en cliquant sur “Edit”.

01

02

Enfin, le champ “Signing Algorithm” peut être changé avec le bon algorithme.

03

Cependant, nous avons vu précédemment que la modification de stratégies de groupe DirectAccess n'est pas supportée. De plus, la customisation proposée sera écrasée à chaque modification de la configuration DirectAccess. L'une des solutions pourrait être de créer une stratégie de groupes avec des règles de connexion identiques mais incluant les algorithmes à courbes elliptiques. Cependant, il n'y a aucune certitude que cette règle sera traitée avant l'original car il n'y a pas de priorité sur celles-ci. Il existe donc un flou autour du déploiement de certificats signés par un algorithme à courbes elliptiques.

Contraintes système d'exploitation clients

Windows 8 et supérieur

Les versions Windows 8 clients et supérieures supportent toutes les fonctionnalités de DirectAccess ainsi que tous les types de déploiements. De plus DirectAccess sur Windows 8 ne nécessite pas d'avoir une infrastructure PKI (hormis dans le cas d'une authentification forte, y compris OTP) et fonctionne alors avec des certificats auto signés. Cependant vous pouvez rencontrez quelques contraintes lors de l'activation de l'authentification forte (http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx).

Windows 7

Le déploiement de DirectAccess sur des clients Windows 7 nécessite obligatoirement d'avoir une infrastructure PKI (certificat ordinateur en auto enrollment). De plus, si vous souhaitez une infrastrcture en haute disponibilité, sachez que vous ne pourrez opter que pour le load balancing. La fonctionnalité multisite permettant de posséder plusieurs serveurs DirectAccess en standalone tout en laissant le choix au client sur lequel il souhaite se connecter n'est pas disponible pour cette version de Windows. Aussi, si sur Windows 8, la méthode de transition IPv6 / IPv4 recommandée est l'IPHTTPS (notamment par sa simplicité de mise en oeuvre), ce n'est pas le choix le plus évident sous Windows 7. En effet, l'IPHTTPS réalise une double encryption des flux DirectAccess, ce qui peut causer des problèmes de performances. Pour rappel, depuis Windows 8, le tunnel IPSec étant s��curisé, la communication IPHTTPS ne réalise plus d'encryption évitant ainsi de réaliser deux fois cette opération (IPHTTPS et tunnel IPSec).

Troubleshooting

Netsh

L’outil en ligne de commande Netsh est sans doute l’un des outils les plus utiles pour effectuer un premier debug. Pour chaque interface liée à une technologie de transition IPv6/IPv4, nous pouvons obtenir un statut de connexion :

  • 6To4 : netsh interface 6to4 show state
  • Teredo : netsh interface teredo show state
  • IPHTTPS : netsh interface httpstunnel show interfaces

Par exemple, lorsqu’il y a un problème avec la vérification de la CRL sur l’interface IPHTTPS, nous obtenons le code d’erreur 0x80092013 (pour l’attribut “Last Error Code”). Une recherche sur votre code d’erreur vous permettra d’identifier rapidement la cause d’une mauvaise connexion.

D’autre part Netsh peut vous aider à configurer vos interface réseaux. Il est d’ailleurs recommandé de désactiver les interfaces non utilisées. Par exemple, 6To4 qui n’est que très rarement utilisé peut être désactivé via la commande suivante :

Journaux d’événements

Vous pouvez retrouver des informations utiles dans l’observateur d’évènements pour dépanner votre connexion DirectAccess, Le journal “Operational” présent dans “Applications and services Logs > Microsoft > Windows > CAPI2” vous donnera des informations liés à vos certificats (erreur sur la vérification de la CRL, certificat expiré,…). Il convient de l’activer avant de pouvoir l’utiliser. en cliquant sur “Enable Log” via un clic droit sur le journal.

Aussi, le journal de sécurité peut vous renseigner sur les connexions IPSec qui ont réussies ou échouées. Pour se faire, il faut activer l’audit via la commande suivante :

En cas d’erreur, les id des évènements importants à retrouver sont les suivants : 4653, 4654, 4984.

Enfin, en cas de déploiement d’une infrastructure avec authentification forte via OTP, le journal “OTPCredentialProvider” présent dans “Applications and services Logs”, vous renseignera sur les évènements liés à cette méthode d’authentification.

Directaccess Connectivity Assistant

Le Directaccess connectivity assistant (DCA) est un assistant de connexion pour DirectAccess. Ce dernier est nativement disponible sur Windows 8 et supérieur mais nécessite d'être déployé sur Windows 7 (http://www.microsoft.com/en-us/download/details.aspx?id=29039). Il est d'ailleurs obligatoire dans le cadre de l'activation de l'authentification forte (via OTP ou carte à puce).

En marge du déploiement du client, il faut intégré le fichier ADMX dans le magasin central Active Directory afin de pouvoir le configurer par stratégie de groupe sur tous les postes utilisateurs concernés. Il convient donc de créer une stratégie de groupe possédant à minima les paramètres suivants (présent dans “Computer Configuration > Policies > Administratives Templates” ) :

  • Corporate resources

  • DTEs

Le paramètre “Corporate resources”, correspond à des ressources dont l'accès est testé pour valider que la connexion DirectAccess est opérationnelle. Attention : ces tests sont différents du serveur NLS (Network Location Server) qui permet à Windows de savoir s'il doit tenter de se connecter au réseau d'entreprise via DirectAccess. Ici, il s'agit simplement de tests réalisés par le DCA. La connexion DirectAccess peut être opérationnelle alors que l'une des ressources n'est pas disponible (et la connexion sera alors indiquée comme non fonctionnelle). Il est donc conseillé de fournir des ressources redondées. De plus, pour que DCA fonctionne de façon optimale, il est nécessaire d'indiquer une ressource de type PING et une autre de type HTTP (pointant sur un site web de votre infrastructure qui n’est pas le serveur NLS).

06

Le paramètre DTEs indique les points de terminaisons de la connexion DirectAccess sur le serveur. Ces derniers peuvent être obtenus de plusieurs manières. Chacune des règles  “DirectAccess Policy-ClientToCorp” et “DirectAccess Policy-ClientToInfra” de la GPO cliente (“GPO DirectAccess Client Settings”) possède l'une des valeurs à renseigner. Pour l'obtenir, rendez-vous dans l'onglet “Advanced” puis cliquez sur le bouton “Customize” de la section “IPsec tunneling”. Le champ “IPv6” de la section “Remote tunnel endpoint” contient la valeur recherchée.

05

Celles-ci sont à indiquer au format “PING:IP_Récupérée” dans la stratégie de groupe de configuration du client DCA.

07

Ces valeurs peuvent aussi être récupérées dans le registre via la commande Powershell suivante :

Cet outil permet de générer des logs exploitables par un administrateur pour débugguer des problèmes de connexions (vérification des certificats, test des connexions teredo, 6TO4 et iphttps, configuration firewall, ...). Pour se faire, l'utilisateur qui rencontre une erreur devra effectuer un clic droit sur le client (dans la barre des tâches) et cliquer sur “Advances Diagnostics”. Cela aura pour effet de générer une page html contenant les résultats dans le répertoire “C:\Users\NOM_USER\AppData\Local\Microsoft\DCA”.

image

DirectAccess Client Troubleshooting Tool

Cet outil permet de débugguer une connexion DirectAccess en la vérifiant point par point (Test certificats, firewall, ...). Ce dernier est disponible à partir de Windows (http://www.microsoft.com/en-us/download/details.aspx?id=41938), cependant, veillez à l'installer sur un système d'exploitation avec langue US sinon vous rencontrerez une erreur pendant l'exécution des tests.

04

Astuces

Mise à jour du système d'exploitation

Cela peut paraître normal mais il est impératif de mettre à jour continuellement vos serveurs DirectAccess et surtout avant l'implémentation de cette fonctionnalité. En effet, un très grand nombre de correctifs concernant DirectAccess ont été mis à disposition depuis la sortie de Windows 2012 R2.

Configuration IP et changement

Il s'agit plus d'un conseil que d'une astuce mais je vous recommande fortement de ne jamais changer la configuration IP d'un serveur sur lequel DirectAccess est configuré. En effet, cela peut avoir des effets de bord sur le serveur lui-même en dehors de la fonctionnalité DirectAccess qui peut ne plus être configurable. Vous pouvez vous retrouver confronter à devoir remettre l'ordinateur dans le domaine ou réinstaller la machine elle-même.

Configuration IP et load balancing

Si vous envisager un déploiement avec du load balancing, l’IP de la VIP (HLB ou NLB) sera l'IP original de votre serveur DirectAccess lorsque vous configurerez la haute disponibilité. Il faut donc tenir compte de cet aspect lorsque l'on fixe l'IP de son premier serveur DirectAccess lors de ce type de déploiement.

Teredo, 6To4, IPHTTPS et NAT

Dans le cas où l'infrastructure DirectAccess est derrière du NAT, il n'est possible d'utiliser que l'IPHTTPS (quelque soit le mode de déploiement : load banlancing, standalone).

OTP et Carte à puces

Je vous invite à consulter le lien suivant concernant le déploiement de l'authentification forte pour DirectAccess : http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx. Ce dernier explique le fonctionnement mais aussi les éventuelles erreurs que vous pouvez rencontrer et comment les corriger.

DirectAccess : Déploiement de l'authentification forte

Introduction

DirectAccess a grandement évolué depuis sa première version sous Windows 2008 R2. Microsoft a simplifié le déploiement ce rôle tout en ajoutant des fonctionnalités supplémentaires. Ainsi, depuis Windows Server 2012, DirectAccess supporte l'authentification forte via une SmartCard ou un OTP (One Time Password). C'est le sujet de cet article où nous allons aborder plusieurs aspects de cette fonctionnalité. Tout d'abord, nous verrons le fonctionnement et les contraintes imposées sur ce type de déploiement, avant d’en réaliser un déploiement. L'usage de la Smartcard et de l'OTP sera détaillé.

La plateforme utilisée sera Windows 2012 R2. La partie OTP est composé d'un serveur multiOTP et d'un serveur radius Tekradius qui sont tous les deux gratuits et permettent de réaliser un environnement de test simplement. Nous partirons du principe que DirectAccess est déjà déployé et fonctionnel. Seuls le déploiement du service OTP et l'ajout du support de l'authentification forte dans l'infrastructure DirectAccess seront détaillés. Enfin, une infrastructure de PKI est nécessaire pour réaliser ce type de déploiement. Dans cet article, cette dernière est implémentée sur Windows 2012 R2.

Fonctionnement

Généralités

Lorsque l'utilisateur se connecte sur son ordinateur, DirectAccess tente de savoir s'il est sur le réseau interne comme dans un fonctionnement classique. Lorsque le tunnel infrastructure est monté, l'utilisateur est invité à entrer des informations d'authentification supplémentaires. Cela peut être une smartcard ou un code à usage unique (OTP). Si la fonctionnalité OTP est activée, cela active aussi obligatoirement l'authentification par smartcard (l'inverse n'étant pas réciproque). Il existe ensuite deux possibilités. S'il s'agit d'une authentification par carte à puce alors l'authentification est réalisé directement avec le certificat utilisateur.

Dans le cadre d'une authentification par OTP, les paramètres d'authentification entrés sont transmis en SSL au serveur DirectAccess avec une demande de certificat par carte à puce. En effet, cette fonctionnalité se base sur une authentification par certificat de type carte à puce (même avec un OTP). Le certificat généré possède une durée de vie très courte. Comme dans une demande de certificat par carte à puce classique, celle-ci sera signée par une entité possédant un certificat d'enrollment, c’est-à-dire donnant la possibilité de signer des demandes de certificats de carte à puce au nom d'un autre utilisateur. Dans le cadre de DirectAccess, ce seront les serveurs DirectAccess qui posséderont ces certificats d'enrollment et pourront dont signer les demandes de certificats des clients DirectAccess. Le serveur DirectAccess vérifie le code à usage unique auprès du serveur OTP. Ce dernier doit fonctionné avec un serveur radius. Le serveur DirectAccess s'adresse au serveur radius pour effectuer la vérification de l'authentification. Si le code à usage unique est correct, il signe la demande de certificat et la transmet au client DirectAccess. Le client transmet cette demande signée à l'autorité de certification et stocke le certificat associé. Le client se comporte désormais comme un client authentifié via carte à puce.

Voici un schéma récapitulatif de la cinématique de connexion pour l’OTP :

image

1 et 2/ Connexion à l’annuaire Active Directory via le tunnel infrastructure.

3/ Des paramètres d’authentification supplémentaires sont demandés pour monter le tunnel utilisateur

4/ Envoie du code à usage unique récupéré sur un périphérique (smartphone par exemple) et d’une demande de certificat de logon OTP via une connexion SSL avec le serveur DirectAccess.

5 et 6/ Communication du serveur DirectAccess avec le serveur Radius

7/ Le serveur radius contacte le serveur OTP pour vérifier le code à usage unique.

8 et 9/ Le serveur radius remonte le succès ou l’échec de l’authentification auprès du serveur DirectAccess

10/ Si l’authentification a réussi, le serveur DirectAccess signe la demande de certificat de logon OTP avec son certificat d’enrollment et l’envoie au client DirectAccess.

11 et 12/ Le client DirectAccess envoie la demande de certificat signée à l’autorité de certification au travers du serveur DirectAccess. L’autorité de certification renvoie le certificat de logon OTP associé.

13/ Le client DirectAccess récupère le certificat, le stocke et réalise une authentification Kerberos (non représentée ici) via carte à puce pour monter le tunnel utilisateur.

Si l’authentification par carte à puce est réalisée alors le schéma s’arrête à l’étape 4 et cette dernière se déroule au travers du tunnel infrastructure.

Contraintes

Comme vu dans son fonctionnement, ce type de déploiement nécessite forcément une infrastructure de PKI. L'option force tunneling (non activée par défaut) ne peut pas être activée dans un déploiement avec l'OTP car ce type d'authentification nécessite une connexion SSL en dehors du tunnel IPSec pour que le client puisse transmettre ces paramètres d'authentification supplémentaires. De plus, lors d'un déploiement utilisant IPHTTPS avec des équipements réseaux se trouvant entre le client et le(s) serveur(s) DirectAccess (comme un load balancer), ceux-ci ne doivent pas décrypter le flux SSL (fonctionnement en mode path through).

Client Windows 8

Pour les clients utilisant cette version de Windows, l'activation de l'authentification OTP ne permet plus d'utiliser le “null encryption” sur les connexions IPHTTPS. Pour rappel, cela permet d'éviter une double encryption (IPSec et flux IPHTTPS). Cela peut donc affecter les performances des connexions utilisateurs.

Clients Windows 7

Les clients Windows 7 doivent obligatoirement posséder le DirectAccess Connectivity Assistant v2.0 (http://www.microsoft.com/en-us/download/details.aspx?id=29039). Un popup permettant d'insérer des paramètres d'authentification supplémentaires apparait lorsque cela est nécessaire. Sa configuration est détaillé dans l’article suivant : http://blog.piservices.fr/post/DirectAccess-Conseils-et-Astuces.aspx.

Déploiement

Généralités

Si vous ne souhaitez configurer que l'authentification par Smartcard alors vous pouvez vous rendre directement sur le chapitre nommé “Configuration de DirectAccess”. Les autres chapitres sont dédiés au déploiement de l'authentification par OTP.

Installation et configuration de multiOTP

Tout d'abord, il faut commencer par récupérer les binaires de multiOTP sur le site suivant : http://www.multiotp.net/. Une fois l'archive extraite, la configuration peut être réalisée via une invite de commande. Celle-ci va nous permettre de réaliser une synchronisation des comptes utilisateurs Active Directory afin qu'ils soient présent dans multiOTP. Ci-dessous, vous trouverez les commandes à exécuter commentées :

Nous pouvons ensuite lancer une synchronisation via la commande suivante :

 

Cette dernière affichera les utilisateurs créés ainsi que les éventuelles erreurs de synchronisation. Cette commande est à insérer dans une tâche planifiée pour exécuter une synchronisation à intervalle régulier. Pour chaque utilisateur, un fichier est créé dans le sous dossiers “Users” de multiOTP.

Dans ce déploiement les utilisateurs récupère le code à usage unique via Google Authenticator (qui peut s'installer sur tous les téléphones mobiles android, windows phone et iOS). Pour configurer le client Google Authenticator, il est nécessaire de générer un QR Code pour chaque utilisateur que ce dernier scannera avec son téléphone. Pour se faire, il faut exécuter la commande ci-dessous :

 

NB : Pensez à remplacer NOM_USER par le nom de l'utilisateur pour lequel vous générer le QR Code et NOM_FICHIER par le nom du fichier image. Le fichier peut être envoyé à l'utilisateur afin qu'il puisse ajouter son compte dans Google Authenticator. L'OTP est normalement opérationnelle. Vous pouvez effectuer des tests de connexion avec la commande suivante :

 

NB : Pensez à remplacer NOM_USER par le nom de l'utilisateur et CODE par le le code à usage unique fourni par Google Authenticator.

Si l'opération réussi, vous obtenez un résultat similaire à l'image ci-dessous :

02

Astuce : Si vous vous trompez souvent de code (6 échecs) alors votre compte peut être bloqué ou votre authentification retardée de 300 secondes (3 échecs). Pour débloquer un compte il faut lancer la commande suivante :

 

Vous pouvez modifier le comportement de multiOTP (nombre de fois avant que le compte ne soit bloqué ou que l'authentification soit retardée ainsi que le délai avant la prochaine tentative de connexion) via les commandes ci-dessous :

Installation et configuration de TekRadius

Cette étape consiste à configurer un serveur radius avec lequel DirectAcces va communiquer. Ce dernier doit pouvoir s'intégrer avec multiOTP et est donc installé sur le même serveur que celui-ci. Pour rappel, c'est par lui que transite la vérification du code à usage unique. Les deux serveurs recommandés avec multiOTP sont FreeRadius et TekRadius LT. J'ai choisi le second qui est supporté nativement sur Windows (FreeRadius est un portage linux) et qui bénéficie d'une interface graphique permettant de la configurer simplement. Les binaires peuvent être récupérés sur http://www.kaplansoft.com/download.html.

Il faut ensuite exécuter le fichier setupe.exe afin d'installer l'outil.

01

La configuration principale se fait dans l'onglet “user” de l'interface qui s’ouvre en cliquant sur “TekRadius LT Manager”. Il faut créer un utilisateur par défaut (que l'on doit nommé “default”) puis ajouter le lancement d'un programme externe lorsqu'une requête sera effectuée par le serveur DirectAccess. Le programme lancé sera multiOTP. Dans la section “Attribute”, il faut sélectionner l'option “Check”, puis définir l'action effectuée à “External-Executable” et enfin insérez la commande exécutée par TekRadius comme suit : C:\multiotp\multiotp.exe %ietf|1% %ietf|2% (il est supposé ici que multiOTP est déployé dans “C:\multiOTP\”).

02

Dans l'onglet client, il faut ajouter notre server DirectAcces afin que ce dernier soit autorisé à communiquer avec TekRadius. Il faut insérer l'IP du serveur DirectAccess puis le secret (code utilisé pour communiquer) et enfin cliquez sur le bouton “Add/Update”.

03

Enfin dans la section “Service Parameters” de l'onglet “Settings” , on peut changer le port utilisé par TekRadius (par défaut 1812 UDP&TCP) ainsi que le niveau de trace généré par l'outil (je vous conseille de le définir à Debug dans un premier temps afin de valider la configuration, cela permet d'identifier clairement les éventuelles erreurs de configuration). On termine la configuration en cliquant sur le bouton “Save Settings” et en lançant le service via le bouton à gauche de ce dernier.

04

Le serveur TekRadius est à présent opérationnel.

Configuration des modèles de certificats

Certificat d'enrollment (signature des demandes de certificat OTP) :

Lancer la console de gestion des modèles de certificat. Choisir le modèle “Computer” puis dupliquer le (clic droit “Duplicate template”).

01

Dans l'onglet “Compatibility”, définissez à Windows 2012 R2 la valeur du champ “Certification Authority” et à Windows 8.1 / Windows Server 2012 R2 celle du champ “Certificat Recipient”. Cette valeur est à adapter selon le système d'exploitation utilisé sur votre autorité de certification et vos serveurs DirectAccess.

02

Dans l'onglet “General”, définissez un nom ainsi que la durée de vie du certificat et la période avant son expiration durant laquelle le serveur DirectAccess pour renouveler son certificat.

03

Dans l'onglet “Security”, ajouter vos serveurs DirectAccess (via le bouton “Add”) et donner leurs les permissions de lecteur (“Read”), d'enrollement (“Enroll”) et d'autoenrollement (“Autoenroll”).

04

Pour les utilisateurs authentifiés (“Authenticated Users”), laissez uniquement la permission de lecture.05

 

Supprimez la permission d'enrollement (“Enroll”) sur le groupe des ordinateurs du domaine (“Domain computers”).

06

Enfin, pour les groupes administrateurs du domaine (“Domain Admins”) et administrateur de l'entreprise, définissez la permission à contrôle total (“Full Control”).

0807

Dans l'onglet “Subject Name”, sélectionner l'option “DNS name” dans la liste déroulante “Subject Name format” et cocher la case “DNS name” sous “Include this information in alternate subject name” afin d'ajouter le nom DNS de l'ordinateur trouvé dans l'annuaire Active Directory en tant que sujet du certificat mais aussi comme SAN (subject alternative name).

09

Enfin, dans “Extensions”, il faut sélectionner le champ “Application Policies” et supprimer toutes les entrées existantes. Il est ensuite nécessaire de cliquer sur “Add” puis “New” et d'ajouter un nom ainsi que la valeur “1.3.6.1.4.1.311.81.1.1” dans le champ “Object Identifier”. La création de ce modèle est terminée.

101112

Certificat OTP :

Dans la console de gestion des modèles de certificat. Choisir le modèle “Smartcard Logon” puis dupliquer le (clic droit “Duplicate template”).

Dans l'onglet “Compatibility”, définissez à Windows 2012 R2 la valeur du champ “Certification Authority” et à Windows 7 / Windows Server 2008 R2 celle du champ “Certificat Recipient”. Cela correspond à la version du système d'exploitation minimale pour nos clients DirectAccess. Si vous n'utiliser pas de client sous Windows 7, vous pouvez changer cette valeur à Windows 8 ou Windows 8.1 en fonction de vos besoins.

13

Dans l'onglet “General”, définissez un nom ainsi que la durée de vie du certificat. La période de renouvellement doit être nulle.

14

Dans l'onglet “Security”, il faut définir les permissions du groupe des utilisateurs authentifiés (“Authenticated Users”) à “Read” et “Enroll”.

15

Il est aussi nécessaire de donner les permissions de contrôle total (“Full Control”) aux groupes administrateurs du domaine et administrateurs de l'entreprise.

1617

Dans l'onglet “Subject Name”, sélectionnez l'option “Full Distinguished Name” dans la liste déroulante “Subject Name format” et cocher la case “User principal name (UPN)” sous “Include this information in alternate subject name”.

18

Dans l'onglet “Server”, cocher la case “Do not store certificates and requests in the CA database” afin de ne pas polluer la base de donnée de l'infrastructure PKI lors des connexions des clients DirectAccess.

19

Dans l'onglet “Issuance Requirements”, vérifier que la case “This number of authorized signatures" est cochée et insérez la valeur 1. Vérifiez que le champ “Policy type required in signature” possède la valeur “Application Policy” et choisissez le modèle créé précédemment (DirectAccess OTP RA) pour le champ “Application Policy”. Cela permet de définir le certificat ayant le droit de signer des requêtes de certificat.

20

Enfin, dans “Extensions”, il faut sélectionner le champ “Application Policies” et supprimer toutes les entrées existantes sauf “Smart Card Logon”. La création de ce second modèle est terminée.

20post

Ajout des modèles à l'infrastructure PKI :

Dans la console de gestion de l'autorité de certification (“Certificate Authority”), il est nécessaire de publier les modèles qui viennent d'être créé. Cette opération se réalise dans l'onglet “Certificate Templates”. Il suffit de faire un clic droit et de choisir l'option “Certificate Template to Issue”. Il faut sélectionner les deux modèles créés précédemment et valider avec le bouton “OK”.

21

Enfin, afin d'autoriser la PKI à ne pas stocker certaines demandes de certificat ou certains certificat, il faut exécuter la commande ci-dessous :

Il vous sera ensuite demandé de redémarrer le service Active Directory Certificate Services pour que le changement soit pris en compte.

22

Configuration de DirectAccess

Nous pouvons maintenant configurer DirectAccess afin qu'elle fonctionne avec l'authentification forte (Smartcard ou OTP).

Pour réaliser cette étape, il faut se rendre dans la console “Remote Access Management” permettant de configurer son infrastructure DirectAccess. Dans la section “Configuration”, il faut éditer l'étape 2 nommée “Remote Access Server” (Bouton “Edit”).

01

Lorsque l'assistant s'ouvre, il faut ajouter des paramètres sur l'onglet nommé “Authentication”. Par défaut, la case “Active Directory Credential” est sélectionnée dans “User Authentication”. Pour activer uniquement l'authentification par carte à puce, il suffit de sélectionner la case “Two-factor authentication” et la configuration est terminée. Si vous souhaitez également activer l'authentification par OTP, il faut cocher la case “Use OTP”. Cela activera des onglets de configuration supplémentaires.

02

Dans la section “OTP Radius Server”, il faut indiquer le nom DNS ou l'IP du serveur TekRadius que nous avons installé précédemment ainsi que le secret (via le bouton “Change”) que nous avons défini dans la section client de l'outil et enfin le port s'il ne s'agit pas de celui par défaut (1812).

03

04

Dans l'onglet “OTP CA Servers”, il convient de renseigner l'autorité de certification délivrant les certificats dont nous avons créé les modèles (l'ajout se fait via le bouton “Add”).

05

NB : Vous pouvez rencontrez une erreur indiquant qu’aucune autorité de certification n’a pu être détectée. Il s’agit d’un bug de l’assistant graphique corrigé par un hotfix disponible en suivant ce lien : https://support.microsoft.com/fr-fr/kb/3047733 (Toutefois, il reste possible de réaliser la configuration via Powershell sans le hotfix).

image

Dans l'onglet “OTP Certificate Templates”, il faut indiquer le modèle utilisé pour l'authentification par OTP puis le modèle permettant de signer les requêtes de certificat OTP.

06

Par défaut, tous les utilisateurs doivent s'authentifier via carte à puce ou OTP. Cependant, vous pouvez spécifier un groupe d'utilisateurs pouvant s'authentifier uniquement grâce à l'authentification intégré dans la section “OTP Exemptions”. Vous pouvez ensuite valider cet assistant.

07

Dans l'étape 3 de la configuration de DirectAccess, il est nécessaire d'effectuer une modification lorsque l'on configure l'OTP. Il faut autoriser les clients DirectAccess à contacter l'autorité de certification délivrant les certificats pour l'authentification par OTP avant qu'il n'est accès aux ressources internes de l'entreprise. Cela leur permet d'obtenir le certificat pour monter le tunnel utilisateur. Dans la section “Management” de l'assistant, il convient d'indiquer le nom DNS de l'autorité de certification sur laquelle nous avons ajouté les modèles précédemment créés.

08pre

Il est ensuite nécessaire d'appliquer le changement de configuration (ce bouton apparait en dessous de la vue globale de configuration de DirectAccess).

08

Pour vérifier que le service est fonctionnel, nous pouvons nous rendre dans l'onglet “Operations Status” de la console de gestion d'accès à distance.

09

Il est aussi possible de vérifier qu'un site IIS a été créé sur le serveur. Ce dernier est nommé “DAOtpSite”.

10

Enfin, en ouvrant un navigateur sur le serveur, on peut vérifier que ce site est fonctionnel via l'url : https://localhost/DAOtpauth.dll

11

Vous pouvez maintenant mettre à jour les stratégies de groupes de vos postes clients (gpupdate /force) et tester l'authentification en vous connectant à distance.

test win 7

Si vous rencontrez des erreurs sur l'OTP, n'hésitez pas à regarder le journal d'évènements “OTPCredentialProvider” (dans “Applications and Services Logs”) de votre poste client ainsi que les traces générés par TekRadius sur le serveur radius (présent dans le répertoire Logs du dossier d'installation de TekRadius). Nous pouvons d'ailleurs remarqué qu'un utilisateur nommé DAProbeUser tente de s'authentifier à intervalle régulier. Comme ce dernier n'existe pas dans multiOTP, une erreur est remontée. Ce comportement est tout à fait normal. Il s'agit simplement du sonde DirectAccess permettant de tester la disponibilité de l'OTP.

01

NB : Vous pouvez rencontrez l'erreur 0x80040001 sur votre client lorsque vous tentez de vous authentifier via OTP. Il s'agit d'un bug qui se corrige en installant la KB suivante :

  • Windows 8 : https://support.microsoft.com/en-us/kb/2973071

  • Windows 7 : https://support.microsoft.com/en-us/kb/2939489

    event viewer win 7

Nested Hyper-V sous NanoServer Technical Preview 4

 

La Technical Preview 4 de Windows Server 2016 est désormais disponible. https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

 

De nouveaux Packages Nano sont désormais disponible.

Vous pouvez construire vos VM nanos avec l’outil NanoServerBuild_x64.

 

Disponible ici : https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&authkey=%21ANkLug_PPC-kh-8

 

Présentation ici :  http://blog.piservices.fr/post/Provisionner-des-VHDs-et-VM-Nano-Server.aspx

 

 

Exemple de nouveaux Packages disponible sous TP4

 

clip_image001

 

 

Un package SCVMM même :D

 

clip_image002

 

 

Cocher la case New-VM.

 

Pour activer le Nested sur le/les VMs créées, cocher la case Nested.

Celle-ci autorisera la virtualisation imbriquée.

 

Attention : Pour que le Nested soit fonctionnel, vous devez être sous une build de l’OS Hyperviseur root supportant la fonctionnalité Nested (Exemple : Windows 10 Build 10586)

 

clip_image003

 

 

Cliquer sur Let’s Go pour démarrer les opérations.

(Des fichiers logs sont générés là ou vos VHDs sont créés).

 

clip_image004

 

 

image

 

 

Une fois les opérations finies, votre / vos VM(s) sont créées.

 

 

Démarrer votre VM

clip_image006

 

 

Authentifier vous

clip_image008

 

 

Nous sommes bien en TP4.

clip_image010

 

 

Création d’un VM imbriquée

 

Nous allons maintenant essayer de créer une VM dans notre Nano Server lui-même virtualisé.

 

Enter-PSSession -VMName NanoTP4 -Credential administrator

New-VHD -Path c:\Base.vhdx -SizeBytes 1GB

New-VM -Name "new 3" -MemoryStartupBytes 32MB -VHDPath c:\Base.vhdx

Get-vm | Start-VM

 

On remarque que la VM démarre correctement. Cela signifie que le Nested est fonctionnel.

 

clip_image012

 

En TP3, le démarrage de la VM ne fonctionnait pas.

image

 

 

Vous pouvez désormais créés des labos avec SCVMM en prime avec tout un tas de clusters :) (y)

 

Have Fun !

SCOM - Moniteur de performance multi-instances

Lors de la création d’un moniteur de performance, il peut arriver qu’il soit nécessaire de superviser plusieurs instances du compteur et d’alerter lorsque n’importe laquelle de ces instances dépasse le seuil paramétré.

La solution qui vient alors immédiatement à l’esprit est alors d’utiliser les wildcard (jokers) dans le nom de l’instance :

clip_image002

Malheureusement, voici ce qui se produit dans ce cas :

clip_image004

clip_image006

Le moniteur détecte bien que l’instance w3wp dépasse le seuil paramétré et passe donc en Critical, mais instantanément après le moniteur détecte que l’instance w3wp#10 est elle toujours sous le seuil et il repasse donc en Healthy : la vérification se fait pour chaque instance du compteur l’une après l’autre, et si un seul d’entre eux n’est pas en critical, le moniteur repasse en vert immédiatement.

Et ce manège recommence à chaque exécution du moniteur…

Une première bonne solution consiste alors à utiliser une variable à la place d’un wildcard en tant qu’Instance.

Prenons l’exemple d’un moniteur de performance qui serait ciblé sur la classe Logical Disk.

Cette classe dispose de propriétés, dont plusieurs correspondent au nom des instances de compteurs :

clip_image007

On peut alors réutiliser une de ces variable dans le champ Instance de l’assistant de création du moniteur, à l’aide de la petite flèche située à sa droite :

clip_image008

On aura donc un moniteur pour chaque instance SCOM de la classe logical disk, ciblé uniquement sur l’instance du compteur de performance qui lui correspond.

Il arrive cependant qu’aucune classe SCOM ne dispose de propriétés utilisables en tant que variable,  typiquement en reprenant le premier exemple du process w3wp.exe.

Dans ce cas, une autre solution existe : le module de détection de condition (condition detection module) System.LogicalSet.ExpressionFilter introduit dans SCOM 2007 R2 permet de déterminer quand arrêter le traitement des données provenant d’une datasource lorsque celle-ci renvoie plusieurs résultats (ce qui est le cas quand un System.Performance.DataProvider est ciblé sur plusieurs instances d’un compteur perfmon).

Autrement dit, en utilisant ce module, les valeurs de chaque instance du compteur sont analysées l’une après l’autre. Dès qu’une de ces instances dépasse le seuil défini, le moniteur passe en Critical et s’arrête sans analyser les instances suivantes, empêchant donc le moniteur de repasser en Healthy.

L’utilisation de ce module n’est toutefois pas possible directement depuis la console SCOM et nécessite de créer son propre MonitorType :

<TypeDefinitions>

<MonitorTypes>

<UnitMonitorType ID="MultipleInstance.Perf.MonitorType" Accessibility="Public">

<MonitorTypeStates>

<MonitorTypeState ID="AboveThreshold" NoDetection="false" />

<MonitorTypeState ID="BelowThreshold" NoDetection="false" />

</MonitorTypeStates>

<Configuration>

<xsd:element name="ComputerName" type="xsd:string" />

<xsd:element name="CounterName" type="xsd:string" />

<xsd:element name="ObjectName" type="xsd:string" />

<xsd:element name="InstanceName" type="xsd:string" />

<xsd:element name="AllInstances" type="xsd:boolean" />

<xsd:element name="Frequency" type="xsd:unsignedInt" />

<xsd:element name="Threshold" type="xsd:double" />

</Configuration>

<OverrideableParameters>

<OverrideableParameter ID="Frequency" Selector="$Config/Frequency$" ParameterType="int" />

<OverrideableParameter ID="Threshold" Selector="$Config/Threshold$" ParameterType="double" />

</OverrideableParameters>

<MonitorImplementation>

<MemberModules>

<DataSource ID="DS_PerfData" TypeID="Performance!System.Performance.DataProvider">

<ComputerName>$Config/ComputerName$</ComputerName>

<CounterName>$Config/CounterName$</CounterName>

<ObjectName>$Config/ObjectName$</ObjectName>

<InstanceName>$Config/InstanceName$</InstanceName>

<AllInstances>$Config/AllInstances$</AllInstances>

<Frequency>$Config/Frequency$</Frequency>

</DataSource>

<ConditionDetection ID="BelowThresholdDetection" TypeID="SystemLibrary7585010!System.LogicalSet.ExpressionFilter">

<Expression>

<SimpleExpression>

<ValueExpression>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>LessEqual</Operator>

<ValueExpression>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Passthrough</EmptySet>

<SetEvaluation>All</SetEvaluation>

</ConditionDetection>

<ConditionDetection ID="AboveThresholdDetection" TypeID="SystemLibrary7585010!System.LogicalSet.ExpressionFilter">

<Expression>

<SimpleExpression>

<ValueExpression>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>Greater</Operator>

<ValueExpression>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Block</EmptySet>

<SetEvaluation>Any</SetEvaluation>

</ConditionDetection>

</MemberModules>

<RegularDetections>

<RegularDetection MonitorTypeStateID="BelowThreshold">

<Node ID="BelowThresholdDetection">

<Node ID="DS_PerfData" />

</Node>

</RegularDetection>

<RegularDetection MonitorTypeStateID="AboveThreshold">

<Node ID="AboveThresholdDetection">

<Node ID="DS_PerfData" />

</Node>

</RegularDetection>

</RegularDetections>

</MonitorImplementation>

</UnitMonitorType>

</MonitorTypes>

</TypeDefinitions>

On constate que ce module se configure très simplement à l’aide de deux balises xml : EmptySet et SetEvaluation.

EmptySet indique le traitement à appliquer : Passthrough (on continue le traitement des données vers les modules suivants dans le workflow, c’est le mode par défaut) ou Block (qui arrête le traitement du wokflow).

SetEvaluation indique si les données de chaque instance doivent correspondre (All), ou si une seule suffit (Any).

Dans l’exemple ci-dessus, on demande donc d’arrêter le traitement (Block) dès que n’importe quelle instance du compteur (Any) passe au dessus du seuil défini.

Ne reste alors plus qu’à implémenter le Moniteur à proprement parler :

<UnitMonitor ID="w3wp.process.privatebytes.monitor" Accessibility="Public" Enabled="false" Target="SharePoint2!Microsoft.SharePoint.2013.SPServiceInstance.Excel" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="MultipleInstance.Perf.MonitorType" ConfirmDelivery="true">

<Category>PerformanceHealth</Category>

<AlertSettings AlertMessage="w3wp.process.privatebytes.monitor_AlertMessageResourceID">

<AlertOnState>Error</AlertOnState>

<AutoResolve>true</AutoResolve>

<AlertPriority>Normal</AlertPriority>

<AlertSeverity>Error</AlertSeverity>

</AlertSettings>

<OperationalStates>

<OperationalState ID="AboveThreshold" MonitorTypeStateID="AboveThreshold" HealthState="Error" />

<OperationalState ID="BelowThreshold" MonitorTypeStateID="BelowThreshold" HealthState="Success" />

</OperationalStates>

<Configuration>

<ComputerName>$Target/Host/Property[Type="MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>

<CounterName>Private Bytes</CounterName>

<ObjectName>Process</ObjectName>

<InstanceName>w3wp*</InstanceName>

<AllInstances>false</AllInstances>

<Frequency>300</Frequency>

<Threshold>2000000000</Threshold>

</Configuration>

</UnitMonitor>

Et cette fois-ci le moniteur ne bagotte plus, tant que n’importe laquelle des instances du compteur sera au dessus du seuil, le moniteur restera en Critical :

clip_image009

Pour aller plus loin : https://msdn.microsoft.com/en-us/library/hh442318.aspx?f=255&MSPPError=-2147217396

SCCM 2012 – Un déploiement s’exécute en boucle / L’agent se réinstalle toutes les 5h

 

Après le déploiement d’une tâche de reboot via SCCM (un simple de shutdown /r à intervalle planifiée sur une collection de serveurs), je me suis rendu compte que quelques serveurs rebootaient en boucle toutes les 5h.

Après mal de questionnement et d’analyse de log, je me suis aperçu que l’agent SCCM se réinstallait à la même fréquence, ce qui expliquait la répétition de la tâche de reboot étant donné son paramétrage assez « souple » (pas de maintenance window…).

Restait à identifier la raison de cette réinstallation… Ni les logs, ni la console SCCM ne contenaient d’information utile.

Pire, même en désactivant le service de l’agent (bloquant ainsi toute communication avec le serveur), il continuait à se réinstaller (et donc à se réactiver) !

La solution est finalement venue comme souvent d’une recherche sur internet, après avoir trouvé les bons mots-clés… Et le coupable s’avère être une tâche planifiée créée par CCMSETUP lors du premier déploiement de l’agent SCCM, dans le dossier Microsoft/Configuration Manager/Microsoft/Configuration Manager (oui, deux fois !) :

clip_image001

Cette dernière est paramétrée pour se relancer toutes les 5h et sert normalement lorsque CCMSETUP n’arrive pas à contacter le serveur SCCM, afin de reprendre le déploiement de l’agent ultérieurement.

Sauf que pour une raison quelconque (la répétition de l’arborescence Microsoft/Configuration Manager) peut faire penser à un bug qui créerait la tâche au mauvais endroit), il arrive que cette tâche planifiée ne soit jamais supprimée, et l’agent se réinstalle donc en boucle indéfiniment…

La solution est alors toute trouvée : il suffit de supprimer (ou au minimum de désactiver) cette tâche planifiée et tout rentre dans l’ordre!

Nagios XI – Exemple d’Auto-Discovery

 

La fonction de découverte de Nagios XI permet de scanner un réseau pour détecter les devices/hosts disponibles, de détecter leur OS et d’appliquer a l’issu, un template de supervision correspondant issu des plugins disponibles.

 

clip_image002

clip_image004

A partir de la page principale (Home Dashboard), sélectionner Run Auto- Discovery.

clip_image002[4]

Sélectionner New Auto-Discovery job

clip_image004[4]

Renseigner le champ Scan Target avec le réseau a scanner

Cliquer sur Show Advanced Options pour afficher les options ci-dessous

clip_image006

L’option OS Detection activée (On), permet une découverte du système d’exploitation

Cliquer Submit pour exécuter le job de découverte.

clip_image008

Laisser le job s’exécuter …

clip_image010

Dans l’exemple ci-dessus, 17 hosts ou devices ont été trouvés

clip_image012

Le champ Default Service permet d’appliquer à l’issu de l’assistant de découverte, des services à superviser. (None : Aucun service ; Common : des services standards ; All : Tout les services disponible)

Cliquer Next

clip_image013

Les hôtes découverts sont affichés.

Leur nom d’hôtes peut être spécifié dans le champ Host Name.

Les services à superviser à l’issu de l’assistant de découverte peuvent être activés/désactivés à ce niveau.

clip_image015

Par défaut les hôtes et leur services seront supervisés toutes les 5 minutes

En cas de problème détécté, le retry de ces vérifications sera effectué chaque minutes, 5 fois avant génération d’une alerte.

clip_image017

Dans l’exemple ci-dessus Aucune notification n’est envoyée.

clip_image019

Cette étape permet de préciser a quels groupes d’hotes et groupes de services appartiennent les nouveaux hôtes et services, et de quel hôte parent ils dépendent éventuellement. Cette configuration est a effectuer plutôt a posteriori de la découverte.

clip_image021

Cliquer Apply pour appliquer la configuration

clip_image023

La configuration est appliquée

clip_image024

image

Les vues d’hôtes et de services affiche a présent les hôtes et services appliqués.

Script – Deploiement Config Agent NSCP (Nagios)

 

Le script ci-dessous propose d’automatiser le déploiement du fichier de config de l’agent nscp (nsclient.ini) et de fichier de scripts/commandes associés.

Lien du script plus bas.

### SCRIPT DE DEPLOIEMENT DES SCRIPTS/ FICHIERS NSC VERS AGENT NSCP # Chemin du fichier du/des scripts a uploader vers le répertoire scripts de l'agent nsclient $SourceScript="D:\TEMP\SCRIPTS_TO_SEND\MyScript.ps1" # Chemin du fichier NSC Mis a jour, a transferer $SourceInifile="D:\TEMP\CONFIG_TO_SEND\nsclient.ini" #Chemin du repertoire et du sous repertoire Scripts de l'agent Nsclient $NSCProgPath="c$\Program Files\NSClient++" $NSCScriptsPath="c$\Program Files\NSClient++\Scripts" #Chemin du log $logdate=get-date -Format ddMMyyyy--HHmm $log="D:\TEMP\log_$logdate.txt" #Fonction de backup du fichier nsclient.ini Function backup-nscfile ($computer) { Try { copy-item "\\$computer\$NSCProgPath\nsclient.ini" -Destination "\\$computer\$NSCProgPath\nsclient.ini.bak" -ErrorAction Continue } Catch { write-host -BackgroundColor White -ForegroundColor red "Erreur lors de la sauvegarde du fichier nsclient.ini sur $computer" "Erreur lors de la sauvegarde du fichier nsclient.ini sur $computer" | Out-File $log -Append } } #Fonction de copie du nouveau fichier nsclient Function copy-nscfile ($computer) { Try { copy-item $SourceInifile -Destination "\\$computer\$NSCProgPath\" -Force -ErrorAction Continue } Catch { write-host -BackgroundColor White -ForegroundColor red "Erreur lors de la copie du nouveau fichier nsclient.ini sur $computer" "Erreur lors de la copie du nouveau fichier nsclient.ini sur $computer" | Out-File $log -Append } } #Fonction de copie du/des scripts Function copy-script ($computer) { Try { copy-item $SourceScript -Destination "\\$computer\$NSCScriptsPath\" -Force -ErrorAction Continue } Catch { write-host -BackgroundColor White -ForegroundColor red "Erreur lors de la copie du script sur $computer" "Erreur lors de la copie du script sur $computer" | Out-File $log -Append } } #Liste de machines cibles $computers=@("SERVER1";"SERVER2";"SERVER3";"SERVER4";"SERVER5") # Affichage du fichier nsc foreach ($computer in $computers) { #Horodatage $datetime=get-date "$datetime - $computer :" | Out-File $log -Append write-host -BackgroundColor White -ForegroundColor Blue "$computer :" ; if (!(Get-ChildItem -Path "\\$computer\$NSCProgPath\" -ErrorAction SilentlyContinue | Where-Object {$_.Name -eq "nsclient.ini"})) { Write-Host -BackgroundColor White -ForegroundColor Red "Le chemin vers le fichier de config nsclient.ini n'a pas été trouvé sur $computer" "Le chemin vers le fichier de config nsclient.ini n'a pas été trouvé sur $computer" | Out-File $log -Append } Else { write-host -BackgroundColor White -ForegroundColor Blue "copie du fichier de script ..." copy-script -computer $computer write-host -BackgroundColor White -ForegroundColor Blue "backup et remplacement du fichier nsclient.ini..." backup-nscfile -computer $computer copy-nscfile -computer $computer write-host -BackgroundColor White -ForegroundColor Blue "Redemarrage du service nscp..." Get-Service -Name nscp -ComputerName $computer | Restart-Service } }