PI Services

Problème rencontré

Après l'installation d'une autorité de certification d'entreprise, j'ai rencontré une erreur m'empêchant de publier des modèles de certificats dont la version est supérieures à 1. Ce problème fut rencontré sur Windows 2012 R2 mais ne peut être généralisé à toute installation avec ce système d'exploitation. Néanmoins, cet article permet de résoudre cet incident. Voici tout de même le contexte dans lequel s'est produit ce problème. L'autorité de certification était de type Subordinate  Enterprise et avait été installé avec un fichier CAPolicy.inf contenant notamment la ligne "LoadDefaultTemplates=False". Ce dernier évite de publier les modèles par défaut.

Bien qu'il soit possible de créer des nouveaux modèles dans l'annuaire Active Directory, ces derniers n'étaient pas visibles lors de leur publication via la console de gestion d'autorité de certification.

De plus, même les modèles générés par défaut comme “Workstation Authentication” (modèle de version 2) ou encore “OCSP Response Signing” (modèle de version 3) n'apparaissent pas dans la liste des modèles publiables.

Contrairement à un mauvais choix de type d'autorité de certification (standalone au lieu d'enterprise), il reste possible de publier des certificats mais seulement ceux dont le numéro de version est égale à 1.

Solution

Cette erreur est due à un problème de configuration du registre. Pour rappel, les paramètres de configuration de l'autorité de configuration sont stockés dans “HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\NOM_CA” où “NOM_CA” représente le nom de l'autorité de certification.

Pour corriger l'erreur, il faut mettre à jour le registre via la ligne de commande ci-dessous (celle-ci doit être exécutée en mode administrateur) :

Enfin, pour que la modification soit prise en compte, il est nécessaire de redémarrer le service d'autorité de certification. Vous pouvez réaliser cette opération graphiquement ou via les commandes suivantes :

NB : Une KB Microsoft (http://support.microsoft.com/kb/967332) décrit un problème similaire lors de la mise à jour d'une autorité de certification 2003 ou 2008 en édition Standard vers une édition Enterprise de Windows 2008. En effet, seule cette dernière permet d'installer une autorité de certification de type Enterprise. Cependant, cette KB n'existe pas sous Windows 2012 et supérieure. Il n'y a d'ailleurs plus de contrainte sur l'édition du système d'exploitation installée (tous les types d'autorités de certification pouvant être installées sur une édition standard comme datacenter depuis Windows Server 2012). Néanmoins, l'erreur décrite dans cet article peut tout de même être rencontrée.

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 :

• https://technet.microsoft.com/en-us/library/dn464274.aspx

• https://technet.microsoft.com/en-us/library/dn464273.aspx

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

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

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

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.

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

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

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.

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.

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 :

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 :

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.

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

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

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.

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

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.

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.

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

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

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

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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

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.

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

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

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

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.

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

  

Introduction

Active Directory Federation Services (ADFS) permet de transmettre n'importe quel attribut d'un objet Active Directory à un partenaire par le biais d'une fédération. Cela reste facilement paramétrable via l'interface de gestion ADFS Management (ce paramétrage sera d'ailleurs détaillé dans la suite de cet article).

Cependant, il peut arriver que l'on souhaite transformer un attribut Active Directory en réalisant notamment des manipulations de chaines de caractères. Dans cet article nous étudierons le cas de l'attribut ObjectGuid qui est envoyé de manière encodée (en base 64) et dont le but sera de le transmettre sous la forme standard (exemple : {3F2704E0-4289-11D3-9B0C-0305E92C1301}). Il est aussi possible d'imaginer d'autres cas d'usage comme : mettre en majuscule un attribut, tronquer une chaîne de caractère...

Cette opération se réalise en deux étapes :

• Le développement d'une DLL contenant l'opération de transformation de l'attribut.

• Le déploiement de cette DLL sur un environnement ADFS. Cette dernière sera utilisé au travers d'un "custom attribute store" ADFS en conjonction avec une règle personnalisée de transformation de revendications lors de la configuration de la fédération.

Pour réaliser toutes ces manipulations, il est nécessaire d'avoir un environnement ADFS déjà opérationnel ainsi que Visual Studio (en version 2013 ou supérieure).

Les notions de développements abordées pendant cet article sont très accessibles y compris pour quelqu'un ne développant pas. Le langage utilisé est le C#.

En bonus, vous trouverez une petite application console permettant de tester les attributs retournés par vos fédérations.

NB : Cette article a été rédigé à partir d'une infrastructure ADFS 3.0 (Windows 2012 R2) et de Visual Studio 2015. Il est inspiré d'un article de Tino Donderwinkel : ici.

Fonctionnement

Tout d'abord, voici le principe de fonctionnement lorsqu'une nouvelle revendication doit être transmise à une fédération :

• Une règle basée sur le template LDAP récupère l'attribut AD que l'on souhaite transmettre.

• Une règle personnalisée traite la première revendication et la retourne dans une deuxième revendication après qu'elle ait subit sa transformation via une méthode appelée dans un custom attribute store

Le custom attribute store est composé d'une DLL qui contiendra toutes nos méthodes permettant de transformer des revendications. En effet, dans cet article nous modifions une revendication provenant d'un annuaire Active Directory mais celle-ci peut très bien être issue d'un autre référentiel puisque notre custom attribute store traite une revendication et non un attribut LDAP.

Le développement du custom attribute store nécessite d'implémenter des références à une DLL ADFS. Cela passe par l'ajout d'une DLL contenu dans le répertoire d'ADFS. Cette dernière contient 3 méthodes qu'il faut implémenter :

• Initialize : Elle permet de fournir des paramètres de configuration à l'attribute store. Elle ne sera pas utiliser dans notre cas.

• BeginExecuteQuery : Cette méthode contient une reqête sur l'attribute store. Cela sera modélisé par une méthode de transformation de notre attribut.

• EndExecuteQuery : Elle est appelé lorsque la méthode EndExecuteQuery a terminé son exécution. Elle prend en paramètre le résultat retourné par la méthode précédente.

Prérequis

Pour développer un nouvel attribute store, il faut copier la DLL nommée “Microsoft.IdentityServer.ClaimsPolicy.dll” depuis un serveur ADFS sur l'ordinateur où Visual Studio est installé (celle-ci est située dans “C:\Windows\ADFS”).

Développement

Lorsque le prérequis est rempli, nous pouvons lancer Visual Studio est créer un nouveau projet via le bouton “File” puis “New” et enfin “Project”.

Dans la section “template”, on choisit la catégorie Visual C# et le modèle bibliothèque de classes (“Class Library”). La version 4.5 du Framework .Net ainsi qu'un chemin pour stocker les fichiers doivent être définies.

Le fichier qui nous intéresse le plus et le fichier “Class1.cs” qu'il est possible de renommer via un clic droit puis “Rename” en oubliant pas de valider la popup suivante permettant de modifier toutes les références à ce fichier dans notre projet.

Nous devons ensuite ajouter des références à notre projet. Pour rappel, ces dernières vont nous permettre de communiquer avec l'infrastructure ADFS en joignant entre autre la DLL précédemment copiée (“Microsoft.IdentityServer.ClaimsPolicy.dll”).

Cette première dépendance s'ajoute en effectuant un clic droit sur le champ “References” dans le menu de droite (Solution Explorer) puis en cliquant sur “Add Reference”.

Il faut choisir l'onglet “Browse” et enfin se rendre à l'emplacement de la DLL et la sélectionner

La seconde dépendance s'ajoute de la même manière Il s'agit de “System.IdentityModel”. Il est seulement nécessaire de se rendre dans le menu “Assemblies” au lieu de “Browse”.

Enfin, on ajoute les lignes de codes ci-dessous dans le fichier de classe.

Cela permet d'indiquer les références utilisées dans la classe.

Une fois les références ajoutées, il faut implémenter les méthodes explicitées dans le paragraphe précédent. Pour se faire, on doit ajouter ce qu'on appelle une interface à notre classe. Cela nous donnera accès aux méthodes permettant d'interagir avec ADFS. Notre classe représente l'attribute store que l'on souhaite créé.

Pour ajouter l'interface, il suffit d'ajouter “ : IAttributeStore” après “public class CustomStringAttributeStore”. Un avertissement est levé car Visual Studio ne trouve pas le code permettant de dire que notre classe est un attribute store (il cherche les 3 méthodes évoquées précédemment). Pour corriger cela, il suffit de faire un clic droit sur “IattributeStore” puis de cliquer sur “Implement Interface”. Le code de base pour les 3 méthodes est automatiquement généré.

Ci-dessous, vous trouverez le code pour chacune d'entre elles.

Initialize :

BeginExecuteQuery :

Il s'agit de la méthode où se déroule toute la logique de transformation. La section la plus importante est contenue à l'intérieure de la structure logique Switch. En fonction de la requête demandée, une transformation sera appliquée. Dans notre exemple, je n'ai qu'un seul cas possible, mais on peut améliorer cet attribute store afin qu'il contienne toutes les règles de transformations dont nous avons besoin.

NB : Une méthode Base64ToGuid est appelée dans le case Base64ToGuid. Cette méthode permet de convertir en chaîne lisible, le Guid d'un objet AD qui est normalement encodé en base 64.

EndExecuteQuery :

Le lien suivant mène vers le code complet de la classe : ici

Il suffit ensuite de générer la DLL en passant par le menu “Build” puis en cliquant sur “Build Solution”. La DLL est générée dans le sous répertoire “bin\Debug” du projet défini lors de la création. Par défaut il s'agit du chemin “C:\Users\nom_d'utilisateur\Documents\Visual Studio 2015\Projects”.

Déploiement

Une fois la DLL copiée, il faut la copier sur tous les serveurs ADFS dans le répertoire “C:\Windows\ADFS” (Attention : La DLL ne doit pas être déployée sur les serveurs Web Application Proxy). On peut ensuite passer à la configuration qui se fait via la console ADFS Management.

Configuration du Custom Attribute Store

Dans la section "Trust Relationship", effectuer un clic droit sur “AttributeStore” et cliquer sur “Add Custom Attribute Store”.

Une popup s'ouvre. Il faut renseigner le champ “Custom attribute store class name”. Ce champ doit être rempli avec attention et nécessite une syntaxe particulière :

Namespace.Classe,Nom_du_fichier_dll

Namespace : il s'agit du nom indiquer à côté de ce mot clé dans notre fichier de classe (Ici : CustomStringTransformAttributeStore).

Classe : Le nom de la classe (Ici : StringTransform)

Nom_du_fichier_dll : le nom de la DLL sans son extension (ici : CustomStringTransformAttributeStore)

Lorsque la configuration est validée, un évènement 251 apparait dans le journal Admin d'ADFS (dans la catégorie Applications and Services de l'observateur d'évènements). Lorsqu'il y a une erreur de configuration, un évènement avec l'ID 159 est présent.

Configuration de la fédération de test

Nous allons maintenant créer une fédération de test. Celle-ci ne doit pas forcément pointer vers un service réel. L'outil fourni dans le chapitre suivant permettra de générer des tokens. Dans la section Trust Relationship, il faut se rendre dans la section “Relying Party Trusts” puis choisir l'option “Add Relying Party Trust”.

Cliquez sur le bouton “Start” après l'ouverture de l'assistant. Choisir l'option “Enter data about the relying party manually”.

Insérez un nom pour la fédération puis cliquez sur “Next”.

Cliquez sur “Next” sur les onglets suivants jusqu'à “Configure Identifiers”. Entrez une url dans le champ “Relying party trust identifier” puis cliquez sur “Add”. Cette url n'a pas besoin de répondre.

Il faut ensuite cliquez sur suivant jusqu'à la fin de l'assistant en laissant cocher la case “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes”. Cela nous permettra d'ajouter nos règles sur les revendications dès la création de la fédération (sinon, il vous faudra faire un clic droit sur la fédération et choisir “Edit Claim Rules”).

Dans l'assistant d'édition des règles de revendications, nous allons ajouter deux règles dans l'onglet “Issuance Transform Rules”. Pour se faire cliquez sur “Add Rule”.

Dans l'assistant, nous ajoutons une première règle qui va récupérer un attribut LDAP. On sélectionne donc le modèle “Send LDAP Attributes as Claims”.

On peut ensuite définir un nom puis choisir “Active Directory” en tant qu'attribute store. Enfin, on entre l'attribut LDAP qui nous intéresse pour la colonne “LDAP Attribute” (il peut être inséré à la main s'il n'est pas présent dans la liste comme c'est le cas pour “objectGUID”) puis on choisit une valeur pour “Outgoing Claim Type” (ici, j'ai choisi “Common Name”).

On ajoute ensuite une seconde règle qui va utiliser notre custom attribute store. Cette fois-ci le template à utiliser est “Send Claims Using a Custom Rule”. On défini ensuite un nom et on peut insérer le code suivant dans le champs “Custom Rule”.

Cette règle récupère la revendication “CommonName” que nous avons défini précédemment en tant que revendication de sortie de notre annuaire Active Directory et la transmet à notre custom attribute store (elle est retournée en tant que revendication de type “nameidentifier” en lui appliquant la méthode Base64ToGuid qui correspond au cas que l'on a défini dans notre classe “Transform.cs”. Il est bien entendu possible de changer les revendications, la requête ou le nom du custom attribute store en fonction de vos valeurs.

Test

Afin de tester vos fédérations, je met un outil console à disposition que j'ai développé et que vous pouvez récupérer via le lien suivant : ici. Il sera utile pour valider le bon fonctionnement de notre custom attribute store mais il vous permettra aussi de voir les revendications envoyées à vos partenaires pour n'importe laquelle de vos fédérations. En plus de ce dernier vous devez avoir dans le magasin racine de confiance, le certificat permettant de signé les tokens d'authentification (Token-Signing). Dans un déploiement par défaut, il est auto-signé.

L'outil est composé d'un .exe et d'un fichier .config. Ce dernier doit être rempli. Les paramètres à changer sont :

• relyingPartyId : il s'agit de l'url d'accès à la fédération (le champ "identifier") : https://adfstest.myenterprise.com/adfs/services/trust.

• adfsEndpoint : il s'agit du point d'accès pour effectuer l'authentification (exemple : https://fs.myenterprise.com/adfs/services/trust/13/windowsmixed). Le programme se base sur l'authentification windows. L'url “/trust/13/windowsmixed” doit être active sur l'infrastructure ADFS. Pour se faire, il faut se rendre dans la catégorie “Endpoints” de la console de gestion ADFS, puis effectuer un clic droit et choisir “Enable” sur cette url.

• certSubject : La valeur doit être celle du champ objet du certificat de type Token-Signing. Exemple : CN = ADFS Signing - fs.myenterprise.com.

Une fois l'outil paramétré, il suffit de le lancer l'exécutable. Ce dernier affiche toutes les revendications par un couple "Nom de la revendication : valeur". Voici un exemple de résultat obtenu :

On remarque qu'on obtient bien les deux revendications représentant le GUID, l'une le représentant sous forme d'une chaîne de caractère et l'autre encodé en base 64 (la revendication originale). Notre custom attribute store est donc bien opérationnel.

Si l'on souhaite ajouter de nouvelles transformations de revendications, il suffit maintenant d'ajouter des cas supplémentaires dans la classe et de la redéployer.

Introduction

Dans Office 365, il existe plusieurs méthodes pour ajouter des licences à un utilisateur :

• Via l'interface d'administration manuellement sur chaque utilisateur.
• Via l'interface d'administration manuellement sur plusieurs utilisateurs.
• Avec les cmdlets Powershell Office 365.

Dans cet article, nous allons nous intéresser à l'ajout/suppression de licences via Powershell. Le but est d'automatiser cette opération. On peut facilement imaginer des scénarios conjoints avec Dirsync. Ce dernier provisionne un compte, puis, une tâche ajoute automatiquement les licences nécessaires à l'utilisateur.

D'autre part, il est possible d'ajouter pour chaque utilisateur :

• Une licence complète incluant tout les services de l'abonnement souscrit.
• Certains services d'une licence afin de limiter les accès aux utilisateurs (par exemple : ne donner qu'une licence Exchange sans donner les accès à la suite Office).

Nous nous attarderons sur ces différentes possibilités dans l'un des paragraphes suivants.

Nous ferons un rappel sur les prérequis nécessaires à l'utilisation des cmdlets Powershell avant d'appréhender leur attribution. Nous verrons enfin un script permettant d'automatiser le processus d'ajout/suppression de services via l'utilisation des groupes de sécurité Office 365.

Pré requis

L'administration des utilisateurs Office 365 via Powershell a besoin de l'installation d'un module spécifique. Ce dernier nécessite un prérequis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez le lien de téléchargement de ce dernier :

http://www.microsoft.com/en-us/download/details.aspx?id=41950

Voici maintenant les liens pour récupérer le module Powershell :

http://go.microsoft.com/fwlink/p/?linkid=236298

A titre informatif, la version 32 bits de ces composants n'est plus pris en charge et ne sera plus mis à jour par Microsoft.

Connexion à Office 365 et permission

Pour se connecter à Office 365, il est nécessaire d'exécuter la commande suivante :

Les informations d'authentification fourni doivent correspondre à un utilisateur possédant à minima le rôle de gestion des utilisateurs. Cette attribution permettra d'affecter les licences.

Licences et abonnements

Tout d'abord, nous allons commencer par récupérer les différents abonnements disponibles sur un tenant Office 365. Il s'agit de la commande :

Le résultat obtenu permet aussi de voir les licences disponibles (ActiveUnits) et utilisées. (ConsumedUnits)

Pour chacun des abonnements, il est possible d'accéder aux services disponibles. Exemple avec le premier abonnement de la liste :

Chaque service Office 365 possède donc un identifiant qui est utilise lors de l'affectation de licences à certains utilisateurs. Les services étant différents d'un plan à un autre, voici un tableau récapitulant les identifiants et les services auxquels ils donnent accès pour un abonnement de type E3 :

Pour les autres abonnements, les services ont des noms identiques ou similaires (exemple : SHAREPOINT_S_DEVELOPER au lieu de SHAREPOINTENTERPRISE pour un abonnement développeur).

NB : J'ai noté deux spécificités sur certains services. Premièrement, la licence Office Online doit être attribué conjointement à une licence Sharepoint (on peut facilement s'en rendre compte via le portail d'administration Office 365). Enfin, les licences Yammer n'ont pas besoin d'être attribués. Cela est sans doute dû au fait que l'intégration du service dans l'offre Office 365 n'est pas terminée. Il se peut aussi que cela soit pensé pour simplifier le système. Néanmoins, il apparaît que le nombre d'utilisateurs peut dépasser le nombre de licences sans avoir de réduction de services (Il faut donc faire un suivi régulier du nombre de licences afin d'être en règle).

Gestion des licences utilisateurs

Attribution d'une licence complète

L'attribution d'une licence utilisateur se fait via la commande Powershell "Set-MSOLUserLicence". Il est possible d'utiliser cette commande pour un ou plusieurs utilisateurs. Le paramètre AddLicenses permet d'ajouter une licence correspondant à un plan Office 365.

Exemple d'attribution d'une licence :

NB : Il est nécessaire de fournir l'attribut AccountSkuId de l'objet obtenu avec la commande Get-MsolAccountSku.

NB2 : Si vous attribuez des licences à plusieurs utilisateurs et que le nombre restants est insuffisant, alors la cmdlet affectera quand même des licences jusqu'à épuisement de celles-ci.

Attention, avant d'attribuer une licence, il est nécessaire d'ajouter une localisation à l'utilisateur. Cette opération est automatisable avec la commande suviante :

La location est à remplacer par la valeur voulue (ici : FR).

Attribution d'une licence partielle

Pour l'instant nous avons vu, l'attribution d'une licence donnant accès à tous les services offert par l'abonnement Office 365. Dans certains cas, il peut être voulu de n'autoriser un utilisateur qu'à un certain nombre de services. Pour se faire, il faut créer un objet du type MsolLicenceOption. Celui-ci est une licence à laquelle on a désactivé certains services.

Exemple :

Cette cmdlet crée une licence avec un pack de service désactivant Azure Right Management Services et Lync Online.

La commande crée les options de licencing à partir d'un abonnement (AccountSkuId) et une liste de services sous forme de tableau. Les noms des services à fournir sont ceux définis dans le tableau du paragraphe "Licences et abonnements". On peut ensuite attribuer ces options de licencing via la même commande que précédemment mais en changeant de paramètre :

Script

Présentation

Le but du script ci-dessous est d'effectuer un provisioning automatique des licences Office 365 pour les utilisateurs synchronisés avec Dirsync. Celui-ci est basé sur l'utilisation des groupes de sécurité Office 365 (ce dernier peut être synchronisé via Dirsync). Chaque groupe correspond à l'attribution d'un ou plusieurs accès à des services Office 365.Ce script peut aussi bien gérer l'ajout que la suppression d'accès. Afin de ne pas perturber les accès déjà affectés à un utilisateur sont réattribués (tant qu'ils ne sont pas concerné par le script). Afin de mieux comprendre le comportement du script, voici un scénario d'exemple :

• USER1 appartient au groupe GRP-SharepointOnline
• GRP-SharepointOnline attribue les accès SHAREPOINTENTERPRISE et SHAREPOINTWAC
• USER1 possède déjà un accès à Lync (via MCOSTANDARD)
• Le script s'exécute et donne les accès à SHAREPOINT Online et Office Online à USER1
• USER1 conserve également son accès à Lync Online.

Pour obtenir ce résultat, l'algorithme recalcule les accès de chaque utilisateur. Cette opération est réalisé en récupérant l'attribut DisabledServices de la licence utilisateur (avec Get-MsolUserLicense).

Il permet aussi de ne pas gérer certains services. Cela peut être notamment utile pour Yammer dont l'attribution de licence n'est pas à administrer.

Celui-ci a été utilisé au travers d'un runbook dans System Center Orchestrator mais il peut aussi être utilisé dans une tâche planifié. Il est possible d'imaginer des variantes de ce script. Par exemple, les licences à attribuer pourraient être stockée dans un attribut du groupe. On peut aussi supprimer l'exigence d'être un utilisateur synchronisé par Dirsync (dans ce cas le groupe devra être alimenté via la console Office 365 et non dans Active Directory).

Script

Introduction

Le répertoire SYSVOL est répliqué entre tous les contrôleurs d'un domaine Active Directory. Celui-ci peut être répliqué par FRS (File Replication Service) ou DFS-R (Distributed File System Replication). FRS devient petit à petit obsolète et il convient de migrer vers DFS-R dès que tous les contrôleurs de domaine (DC) utilisent Windows 2008 ou supérieur. Il existe d'ailleurs une procédure fortement documenté par Microsoft pour effectuer cette bascule (https://technet.microsoft.com/en-us/library/dd640019(v=WS.10).aspx). En effet, DFS-R est beaucoup plus robuste et performant.

Cependant, celui-ci peut aussi rencontré des problèmes et la réplication peut se retrouver en erreur avec certains contrôleur de domaine. Lorsque cet incident survient, les stratégies de groupes (GPO) ou les scripts d'ouverture de session (ou de démarrage d'ordinateur) ne sont plus forcément en accord avec la dernière version mise en place. Pire, une stratégie de groupe récemment créée peut ne pas exister sur un contrôleur de domaine. On rencontre alors des erreurs d'application des GPOs sur des postes clients, serveurs ou utilisateurs. Pour pallier à ce problème, il existe une procédure permettant de resynchroniser la totalité (restaurer) du répertoire SYSVOL depuis un contrôleur de domaine valide.

Nous allons voir comment repérer les contrôleur de domaine dont la réplication DFS-R du SYSVOL est en erreur, puis nous aborderons le sujet de la restauration non autoritaire (principe expliqué ci-dessous) du répertoire SYSVOL.

Diagnostic

Pour repérer si un contrôleur de domaine ne réplique plus correctement le répertoire SYSVOL, il existe une multitude de méthodes. Tout d'abord, il suffit de comparer le contenu des dossiers SYSVOL de plusieurs contrôleurs de domaine. Si l'un d'entre eux est vide ou qu'il n'y a pas les mêmes objets alors il y a des problèmes de réplication DFS-R du répertoire SYSVOL.

Il existe aussi des techniques plus fiables. Tout d'abord, dans une invite de commande depuis un contrôleur de domaine, on peut exécuter le script ci-dessous :

Ce dernier affiche un statut de la réplication DFS-R pour chaque contrôleur de domaine. Le chiffre affiché pour chaque DC nous donne l'information. Lorsqu'il y a une erreur celui-ci possède la valeur 5 (une réplication sans erreur équivaut à un statut 4). Aussi, il peut arriver que la valeur soit “No instance avalaible”. Cette information indique qu'il n'y a donc pas de réplication du SYSVOL.

On peut confirmer une erreur de réplication DFS-R (ou même une absence de réplication du SYSVOL) via la recherche d'événements spécifiques dans l'observateur d'événements. Ceux-ci sont situés dans le journal “DFS Replication” et non dans les journaux Active Directory. Il faut rechercher les événements avec les IDs suivants :

• 2012

• 2013

• 4012

Event 2012

L'événement 2012 nous informe d'une erreur de réplication DFS lors d'un arrêt non prévu du serveur (coupure de courant). Si cet événement n'est pas accompagné d'un événement avec l'ID 2013 alors la réplication a repris son cours normal et ne nécessite pas d'action (vous devriez néanmoins obtenir un statut 4 avec la commande précédente pour confirmer cela).

Event 2013

Cet événement indique que la réplication n'a pas repris et qu'il convient de le faire manuellement via la commande suivante :

NB : Pensez à remplacer GUID_VOLUME par le votre. Pour cela, il suffit de copier coller la commande indiqué dans l'événement pour relancer la réplication du répertoire SYSVOL. Cependant, si celle-ci n'a pas été relancé depuis longtemps alors elle ne redémarre pas et on obtient l'événement 4012.

Pour information, les management packs SCOM AD ou DFS ne remontent pas ce type d'erreur.

Event 4012

En effet, lorsqu'une réplication DFS-R a été stoppé pendant plus de 60 jours (valeur par défaut du paramètre MaxOfflineTimeInDays) alors il est nécessaire de lancer une synchronisation complète du dossier répliqué. L'événement donne une procédure qui peut s'appliquer dans le cas où il s'agit d'une réplication DFS-R créé par un administrateur. Néanmoins celle-ci n'est pas applicable dans le cas du répertoire SYSVOL car nous n'avons tout simplement pas accès à cette réplication via la console DFS Management. Il faut alors réaliser une restauration du répertoire SYSVOL.

Procédure de restauration

Cette procédure n'est pas compliquée mais nécessite de la rigueur afin de rétablir la réplication Active Directory du répertoire SYSVOL. Toutefois, celle-ci ne s'applique que lorsque le nombre de contrôleurs de domaine en erreur est faible et que l'on est sûr que celui-ci répliquera le répertoire SYSVOL depuis un contrôleur de domaine sain. Par exemple, cela peut être le cas dans une topologie en étoile lorsque un ou plusieurs contrôleurs de domaine présent sur des sites distants ne répliquent plus le répertoire SYSVOL.

Dans le cas où l'on souhaiterait restaurer le dossier SYSVOL depuis un contrôleur de domaine précis et restaurer tous les autres DC alors il convient de réaliser une restauration autoritaire du SYSVOL (la restauration est forcé depuis un contrôleur de domaine précis et la réplication DFS-R est coupé temporairement sur les autres DC).

Lors de l'exécution du processus ci-dessous, on ne choisit pas un contrôleur de domaine comme source de la restauration, cette dernière est donc dite non autoritaire. Il n'existe pas véritablement de règle pour savoir s'il faut préférer une restauration autoritaire ou non. Cela dépendra donc des cas (pourcentage de DC en erreur, topologie Active Directory complexe). Microsoft recommande toutefois de réaliser une restauration autoritaire dès qu'il y a plus d'un DC qui rencontre ce type de problème (dans des gros environnements cela peut vite devenir compliqué à mettre en œuvre et une restauration non autoritaire peut rester une solution viable).

Pour réaliser une restauration non autoritaire, il faut lancer ADSIEdit avec un compte administrateur du domaine.

Il faut ensuite effectuer un clic droit sur ADSI Edit puis choisir l'option “Connect To”.

Dans les paramètres de connexion il faut choisir de se connecter au contexte d'attribution de noms par defaut (Default Naming Context) et valider.

Enfin, il faut naviguer jusqu'à l'objet du contrôleur de domaine posant problème (Exemple de chemin : CN=DC01,OU=Domain Controllers,DC=myenterprise,DC=com) puis se rendre dans le conteneur “DFSR-LocalSettings” puis “Domain System Volume”.

Sur ce dernier, il faut effectuer un clic droit puis choisir “Properties”. Il faut ensuite trouver l'attribut “msDFSR-Enabled” et passer la valeur à “False” (cette dernière doit être à “True” par défaut). Cela permet de rendre le contrôleur de domaine non authoritaire pour la réplication.

Par la suite, on force une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Sur le DC en erreur, on exécute la commande ci-dessous qui aura pour effet de désactiver la réplication du répertoire SYSVOL :

Un événement avec l'ID 4114 doit être présent dans le journal “DFS Replication” de l'observateur d'événement du contrôleur de domaine en erreur dont voici le contenu :

Nous pouvons maintenant réinitialiser la réplication du répertoire SYSVOL. Dans ADSI Edit, il faut éditer de nouveau l'objet “Domain System Volume” du contrôleur de domaine en erreur et remettre la valeur de l'attribut “msDFSR-Enabled” à “True”.

Il suffit ensuite de forcer une réplication Active Directory depuis un DC sain via l'outil en ligne de commande repadmin :

Puis, on lance une réplication initiale du répertoire SYSVOL depuis le DC sur lequel on effecture une restauration via la commande :

Un premier événement de type avertissement doit être visible dans le journal “DFS Replication”. Celui-ci possède l'ID 4614. Il indique que la réplication Active Directory s'est lancée.

Lorsque la réplication est terminée, un second événement avec l'ID 4604 indique la bonne exécution de celle-ci.

Enfin, on peut vérifier le statut de la réplication du répertoire SYSVOL du contrôleur de domaine via la commande suivante :

NB : Pensez à changer NOM_DC par le nom du contrôleur de domaine à tester.

Introduction

Les Exchanges Web Services (EWS) sont très pratiques pour manipuler le contenu d'une boite aux lettres. Ceux-ci ont été créés pour s'intégrer dans des applications en C# mais peuvent aussi être utilisés dans un script Powershell. Grâce aux EWS, nous pouvons manipuler des dossiers, des messages, le calendrier. Il est possible de réaliser des opérations de créations (comme l'envoi d'un email), suppressions et modifications. Cependant, nous verrons qu'il est nécessaire d'avoir des droits sur la boite aux lettres d'un utilisateur ou d'utiliser un mécanisme d'impersonation pour réaliser ces opérations.

Contexte

Cet article est basé sur un retour d'expérience d'utilisation des EWS dans un environnement Exchange 2010 SP3. Le système de réservation de ressources d'une entreprise (salle, équipements) devait migrer vers Exchange. Un mécanisme de reprise de l'existant a dû être mis en place pour créer les réservations dans les calendriers des ressources et des personnes réservant la ressource.

EWS

Afin d'utiliser les Exchange Web Services dans un script Powershell, il faut installer le package permettant d'interagir avec ceux-ci.

Ce dernier est actuellement en version 2.2 et peuvent s'interfacer avec toutes les versions d'Exchange de 2007 SP1 à la dernière en date : 2013 SP1 (Les cumulatives updates n'ont pas d'importance).

Il est disponible en suivant le lien ci-dessous :

http://www.microsoft.com/en-us/download/details.aspx?id=42951

Impersonation

Les Exchange Web Services utilisent l'autodiscover pour communiquer avec une boite aux lettres spécifique.

Exemple de connexion aux EWS :

Cependant, dès que j'effectuerai une opération sur la boite aux lettres, il me faudra des droits sur cette boite aux lettres comme le contrôle total. Dans le cas contraire, j'obtiendrai des erreurs.

Donner des droits sur un grand nombre de boites aux lettres n'est pas recommandable car cela complexifie l'administration. il existe donc une seconde option permettant de se faire passer pour le compte utilisateur de la boite aux lettres. Il s'agit de l'impersonation. C’est un rôle à attribuer à un compte de service (via le mécanisme RBAC). Cette solution offre plusieurs avantages :

• Simplicité d'administration : on peut rapidement ajouter ou supprimer les droits d'impersonation à un compte.
• Contrôle des comptes visés : le scope des utilisateurs pouvant être "remplacer" par un compte de service peut facilement être modifié sans devoir changer les propriétés de chaque boite aux lettres.
• Décoreller des délégations : le processus d'impersonation n'apparait pas dans les délégations et il est ainsi plus simple de faire la différence entre les deux mécanismes et les différentes autorisations.

Implémentation RBAC

Le rôle permettant l'impersonation est nommé ApplicationImpersonation. Pour l'implémenter, nous allons d'abord créer un scope, c’est-à-dire définir les utilisateurs sur lesquels le compte de service pourra faire de l'impersonation.

Dans l'exemple ci-dessous, nous créons un scope contenant toutes les boites aux lettres utilisateurs :

Puis, nous ajoutons le rôle ApplicationImpersonation à l'utilisateur souhaité en spécifiant le scope créé précédemment.

NB : Pensez à changer la valeur MYUSER par le nom d'utilisateur de du compte réalisant de l'impersonation.

Script

Ci-dessous vous trouverez différentes fonctions Powershell commentées permettant la création d’une réunion avec la possibilité de réserver une salle mais aussi la validation que ces réunions ont bien été créées. Ces fonctions gèrent l’impersonation tant que le compte avec lequel la connexion aux EWS possède ce droit sur les boites aux lettres visées.

Fonction de création de réunions :

Fonction de validation de la réunion dans le calendrier utilisateur :

Cette fonction valide qu’une réunion possédant les bonnes ressources ainsi que les bonnes dates de début et de fin existe dans le calendrier de l’utilisateur.

Elle permet aussi de vérifier qu’il n’y a pas eu de création de doublons dans le calendrier (utile si un script de création de réunion à été exécuté plusieurs fois).

Fonction de validation de la réunion dans le calendrier de la boîte aux lettres de ressources :

Cette fonction cherche une réservation de la ressource en validant les dates et heures ainsi que le nom de la personne ayant créé cet objet. Cette vérifications s‘effectue sur le calendrier de la boite aux lettres de ressource. Le statut de la réservation est aussi vérifié (valeur attendue : Accept) afin d’être certain que la ressource n’ait pas été réservée pas une autre personne.

Tips

La création de nombreuses réservations peut engendrer un grand nombre d'envoi d'email aux utilisateurs ayant réservés ces ressources. En effet, ils vont recevoir des réponses des ressources (acquittement ou refus de la demande) si le système de réservation automatique a été activé (Resource booking attendant). Une solution de contournement peut être mise en place pendant la phase de migration. Elle consiste à limiter le nombre de destinataires à 0 lors de l'envoi d'un mail par la boite aux lettres de ressources.

Pour réaliser cette opération, il suffit de lancer une invite de commande Powershell Exchange (EMS) et d'exécuter la commande suivante :

Ou bien, si l'on souhaite changer la valeur sur toutes les boites aux lettres de salles en une seule commande (on peut remplacer RoomMailbox par EquipmentMailbox pour les boites aux lettres d'équipements).

NB : Pensez à remplacer IDENTIFIANT_BAL par l'identifiant de la boite aux lettres de ressources (Alias par exemple).

Introduction

Exchange bénéficie d'un grand nombre de cmdlet Powershell très abouties et permettant de configurer et d'administrer l'intégralité d'une infrastructure de messagerie. Aussi, celles-ci sont très utiles dans le cas de scripts de provisionning. J'ai rencontré une erreur lorsque je cherchais à créer et à configurer un grand nombre de boites aux lettres de ressources.

Contexte

L'environnement dans lequel j'ai découvert ce problème est une forêt mono domaine Active Directory avec une infrastructure Exchange 2010 SP3 dans laquelle il y avait plusieurs contrôleurs de domaine dans le même site Active Directory que la totalité des serveurs de messagerie.

Plus globalement, cette erreur pourra être rencontrée dès qu'un serveur Exchange pourra être amené à interroger plus d'un contrôleur de domaine.

Erreur rencontrée

Dans un script de provisionning de boîtes aux lettres, on cherche à les créer mais aussi à les configurer. Si l'on souhaite configurer une boite aux lettres tout de suite après sa création alors on obtient une erreur similaire à celle ci-dessous (“ObjectNotFoundException”) :

Cela peut se retrouver en exécutant l'exemple suivant :

Une ou plusieurs opérations de modification (de type Set-…) vont échouer avec le message d'erreur cité précédemment.

Explication

Suite à cette erreur, il est logique de penser que cela est dû à l'interrogation de différents contrôleurs de domaine qui n'ont pas encore répliqué entre eux (Une réplication intra site peut prendre quelques secondes).

Aussi, on peut se dire qu'il suffit alors de spécifier le paramètre DomainController pour corriger le problème en l'indiquant sur toutes les commandes et en définissant un contrôleur de domaine unique qui traitera toutes les opérations.

Cependant, cela ne corrigera pas le problème. Microsoft en donne l'explication dans les fiches Technet des cmdlets :http://technet.microsoft.com/en-us/library/dd335046.aspx.

Le paramètre DomainController ne concerne que le contrôleur de domaine qui va écrire les modifications dans Active Directory. Cependant, un autre contrôleur de domaine  peut être utilisé pour lire l'objet avant d'écrire les changements sur celui spécifié en paramètre.

Aussi, pour une cmdlet de type Get-… (lecture), le paramètre DomainController sera bien le contrôleur de domaine sur lequel l'objet sera lu (cela sera utile pour mettre en place l'une des solutions proposées).

Solution

Pour résoudre ce problème,  il faut donc attendre que la réplication ait eu lieu sur la totalité des contrôleurs de domaine du site Active Directory de l'infrastructure Exchange. Pour cela, nous avons trois solutions.

Solution 1 :

Il est possible de séparer la création des boîtes aux lettres et leurs configurations. Cette solution oblige donc a réaliser le provisioning en plusieurs phases.

Solution 2 :

On peut définir un délai entre l'opération de la cmdlet de création et la cmdlet de configuration via un Start-Sleep par exemple. Cependant, cette solution ne garantit pas que les opérations vont toutes se dérouler correctement. Il faudra sans doute que le délai soit important pour que le provisioning ait un taux de réussite élevé et donc augmenter considérablement le temps d'exécution du script.

Solution 3 :

La dernière solution est une combinaison des deux précédentes puisqu'elle permet de n'avoir qu'une seule phase de provisioning tout en ayant un temps d'exécution relativement rapide.

Cette solution consiste à implémenter une boucle de test de l'opération à réaliser sur le même contrôleur de domaine via la cmdlet de lecture (Get-…).

Exemple :

Il est possible d'ajouter une courte pause entre chaque test afin de ne pas surcharger le processus sans pour autant trop pénaliser le temps d'exécution du script. Le paramètre ErrorAction permet d'alléger l'affichage car on connait déjà l'erreur que l'on va rencontrer.

Il ne vous reste plus qu'à choisir la solution que vous préférez.

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

• Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

• Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

• Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

Sur les serveurs ADFS :

On récupère, le certificat en utilisant la commande suivante :

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

• Renouvellement manuel

• Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

• CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

• CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

• CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

• CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

• CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

Introduction

Cet article divisé en deux parties est un retour d'expérience sur une migration entre tenant Office 365. Il ne traitera pas de tous les services disponibles sur Office 365 mais seulement de ceux rencontrés lors de la migration (voir Contexte). La première partie traitait de la migration des licences, du SSO (ADFS) et de Dirsync (http://blog.piservices.fr/post/Retour-dexperience-Migration-de28099un-tenant-Office-365-Partie-1.aspx). Cette seconde partie sera consacré aux autres services d'Office 365 (Yammer, Exchange Online, Sharepoint Online).

Contexte

Pour rappel, la société possédait deux tenant et souhaitait migrer les services de l'un des deux (nommé ici myenterprise1) vers le second (nommé ici myenterprise2). Pour chaque service, un listing des étapes à réaliser sera détaillé.

Exchange Online

Il n'existe pas de réel procédure pour la migration de boîtes aux lettres entre tenant. Le processus ci-dessous est manuel. Globalement, il consiste à exporter les boîtes aux lettres au format PST, à migrer le domaine SMTP puis à recréer les boîtes aux lettres sur le nouveau tenant. Cette procédure est entièrement manuelle. Voici un listing chronologique des étapes à appliquer :

• Configuration du domaine SMTP sur le nouveau tenant (myenterprise2). Il ne faut bien évidemment pas faire la vérification mais simplement créé les enregistrements et valider qu'ils sont bien visibles avant de passer à l'étape suivante. Cela permet de réduire la coupure de service à quelques minutes. Si les enregistrements DNS ne sont pas créés en amont, le service peut être coupé le temps de la création de ceux-ci et de la propagation dans les DNS (cela peut durer 24H).
• Création des utilisateurs sur le nouveau tenant (positionnement d'un suffixe UPN en *.onmicrosoft.com). Cela permet de gagner encore un peu de temps sur la coupure de service.
• Sauvegarde des boîtes aux lettres sur l'ancien tenant (myenterprise1) au format PST (via Outlook par exemple).
• Changement de domaine des utilisateurs sur l'ancien tenant (myenterprise1). Il suffit de définir leurs suffixes UPN sur le domaine *.onmicrosoft.com afin qu'il n'interfère pas avec la migration du domaine SMTP.
• Suppression du domaine SMTP de l'ancien tenant (myenterprise1) Office 365.
• Vérification du domaine sur le nouveau tenant et attribution de l'intention de domaine de type Exchange Online.
• Changement du domaine d'appartenance des utilisateurs sur le nouveau tenant (mise en place du nouveau domaine SMTP).
• Activation des boîtes aux lettres pour les utilisateurs sur le nouveau tenant (myenterprise2).
• Import du PST d'export réalisé précédemment pour chaque boîte aux lettres sur le nouveau tenant (myenterprise2).
• Reconfigurer les clients Outlook. Il est nécessaire de supprimer le profil et de le recréer pour que la boîtes aux lettres soit accessible.

Toutes les étapes de changements d'UPN sont automatisables via Powershell avec la commande Set-MsolUserPrincipalName (voir script de la section Modification des utilisateurs de la partie 1).

Cette procédure est donc valable pour un faible nombre de boîtes aux lettres. Si le volume de boîte aux lettres est trop important, il reste deux solutions possibles mais plus lourdes et/ou plus onéreuses :

• Migrer vers une infrastructure On Premise Exchange (scénario prévu par Microsoft) puis rebasculer sur le nouveau tenant Exchange Online.
• Utiliser des outils de migrations payants.

Sharepoint Online

Comme pour d’autres services Office 365, la migration d’un site Sharepoint Online est manuelle. La migration se déroule en cinq étapes :

1. Récupération du contenu
2. Génération d’un modèle
3. Import du modèle
4. Intégration du contenu
5. Paramétrage du nouveau site : il s’agit de reconfigurer les paramètres comme les autorisations utilisateurs.

Nous allons nous intéresser à la migration du contenu, à la génération du modèle de site et à l’import de ce dernier.

Migration du contenu

Afin de migrer le contenu d’un site Sharepoint Online, il faut utiliser OneDrive. Il est nécessaire de se connecter au site web à migrer est de copier tout le contenu du site. Néanmoins si votre site possède moins de 50Mo de contenu, il suffira de l’inclure dans le modèle. En effet, ce dernier peut inclure du contenu si celui-ci ne dépasse pas cette limite de taille.

NB : Il existe aussi des outils de migrations payant.

Génération du modèle de site

La génération du modèle de site se fait via la console d’administration du site (Paramètre du site).

Dans la section Action du site, il faut choisir “Enregistrer le site en tant que modèle”.

Un assistant vous proposera ensuite de donner un nom au modèle et éventuellement d’inclure le contenu du site (cette opération n’est fonctionnelle que si votre contenu pèse moins de 50Mo).

Vous pourrez ensuite accéder à la galerie des solutions et télécharger le modèle au format .wsp.

NB : L’option “Enregistrer le site en tant que modèle” n’est parfois pas disponible. Pour l’activer, il faut utiliser Sharepoint Designer 2013. Il est nécessaire d’ouvrir le site depuis ce logiciel en spécifiant son url et de choisir “Options de site” dans le ruban.

Enfin, il faut changer la valeur du paramètre “SaveSiteAsTemplateEnabled” à “True” et appliquer le changement. Ainsi, l’option d’enregistrement du site en tant que modèle sera disponible dans les paramètres du site Sharepoint.

Import du modèle de site

Pour importer un modèle de site, il suffit de créer un nouveau site en spécifiant un modèle personnalisé (le modèle devra être fourni ultérieurement).

Enfin, il faut ouvrir le nouveau site web et choisir “Galerie Solution” dans lors du choix du modèle. Ce lien vous mènera à une fenêtre permettant de charger le fichier .wsp précédemment créé via le bouton “Télécharger la solution”.

Yammer

Yammer étant un service encore peut intégré avec Office 365, il est plus facile à migrer entre deux tenants. Tout d'abord, il est nécessaire de supprimer le domaine qui correspond au nom du réseau Yammer sur l'ancien tenant(myenterprise1). Il s'agit ensuite de l'ajouter sur le nouveau tenant (myenterprise2).

Si le domaine n'est pas fédéré, il faut que ce dernier soit défini comme domaine par défaut de Yammer. Dans le cas contraire, une erreur est remontée au moment de l'activation du service Yammer. Pour réaliser cette opération, il suffit de se rendre dans le listing des domaines, de sélectionner le bon domaine est de cliquer sur l'option “Définir par défaut”.

Nous pouvons ensuite activer Yammer sur le nouveau tenant (myenterprise2). Dans le panneau d'administration d'Office 365, il faut cliquer sur “Tableau de bord” puis choisir “Service Inclus”. Un nouveau panel apparaît sur la droite permettant d'activer Yammer.

On peut ensuite confirmer l'activation du service.

Le réseau Yammer est rattaché au nouveau tenant dès que le service est activé. Il existe deux types d'administrateurs sur Yammer :

• des administrateurs déclarés directement dans Yammer
• des administrateurs héritant de ces droits car ils possèdent le rôle administrateur général du tenant

Les premiers ne subissent aucune perte de droits pendant la migration. Cependant pour la seconde catégorie, il est nécessaire que les utilisateurs aient un compte avec le rôle administrateur général sur le nouveau tenant sinon ils perdront les droits d'administration de Yammer en plus des droits d'administration du tenant (on peut aussi les déclarés directement dans Yammer si on ne souhaitent plus qu'ils soient administrateurs du tenant).

Concernant Yammer Dirsync, comme ce dernier n'interagit pas avec Office 365 (il s'agit d'un second produit de synchronisation différent d'Office 365 Dirsync), il n'y a aucune manipulation à réaliser. Il en est de même pour la configuration du SSO via ADFS.

OneDrive

Concernant OneDrive, il faut, pour chaque utilisateur :

• Arrêter la synchronisation du dossier
• Désactiver l'utilisateur sur l'ancien tenant (myenterprise1)
• Créer son compte sur le nouveau tenant (provisionning manuel ou via Dirsync)
• Synchroniser le nouveau dossier personnel dans lequel on copiera le contenu qui aura été conservé en local sur la machine.
  

Il existe des outils payant si vous souhaitez automatiser le transfert des données entre les deux tenants. Néanmoins, il restera à reconfigurer le client OneDrive.

Conclusion

Contrairement à la migration du SSO et de la synchronisation Dirsync qui est plus structurée (bien qu'il n'existe pas non plus de procédure officielle), la migration de services Office 365 entre tenant est actuellement totalement manuelle et relève plus d'astuces que de réels procédures.