Introduction

Cette publication décrit les étapes nécessaires pour tester l’authentification unique (également appelée fédération des identités) à l’aide d’informations d’identification d’entreprise dans une forêt d’utilisateurs en environnement de production via l’utilisation d’une organisation fictive, « contoso.com ». Cette publication part de l’hypothèse que le lecteur est déjà un peu familiarisé avec l’authentification unique (fédération des identités) dans Office 365 et qu’il a déjà lu les articles suivants :

1. How single sign-on works (en anglais uniquement)
2. Préparer l’authentification unique
3. Planifier et déployer AD FS 2.0 en vue d’une utilisation avec l’authentification unique
4. Établissement d’une relation d’approbation avec Office 365 Installer et configurer le module Microsoft Online Services pour Windows PowerShell pour l’authentification unique

Deux scénarios principaux sont impliqués dans le pilotage et la mise en place du déploiement de l’authentification unique dans une organisation :

Scénario 1 : l’organisation sait dès le début qu’elle souhaite appliquer l’authentification unique (fédération des identités) dans Office 365. Elle établit donc une relation d’approbation entre son environnement Active Directory (via Active Directory Federation Service 2.0) et Office 365.

• Dans ce scénario, l’organisation est en mesure de tester et de mettre en place le déploiement destiné à ses utilisateurs de l’authentification unique vers les services Office 365, en licenciant simplement les utilisateurs fédérés sur le portail d’administration (une fois qu’ils ont établi la relation d’approbation à l’aide du module Microsoft Online Services pour Windows PowerShell).
• Par ailleurs, l’organisation peut configurer une règle de revendication d’autorisation sur le serveur AD FS 2.0, qui générera uniquement un jeton de sécurité (pour l’utilisateur authentifié) s’il est membre d’un groupe de sécurité local. Les utilisateurs du programme pilote peuvent donc être placés dans ce groupe de sécurité, comme pourront l’être vos autres utilisateurs lorsque vous mettrez en place le déploiement dans l’organisation.

Scénario 2 : l’organisation a décidé initialement de ne pas utiliser l’authentification unique (fédération des identités). À la place, ses utilisateurs ont recours à des ID de cloud Microsoft Online (c’est-à-dire des ID non fédérés) pour se connecter aux services Office 365. Plus tard, l’organisation décide d’utiliser l’authentification unique en convertissant ses utilisateurs existants des ID de cloud Microsoft Online standard en ID fédérés. Comme il s’agit d’un scénario plus complexe en matière de pilotage et de mise en œuvre du déploiement, il est décrit ci-après beaucoup plus en détail.

• REMARQUE : actuellement, il n’est pas possible de procéder au déploiement de l’authentification unique dans votre organisation avec ce scénario dans Office 365, car la conversion d’un domaine standard en domaine fédéré est pour le moment de type tout ou rien (tous les utilisateurs sont automatiquement convertis pour utiliser l’authentification unique à leur prochaine connexion). Un domaine fédéré ne peut contenir que des utilisateurs fédérés/à authentification unique.
• Néanmoins, le pilotage de l’authentification unique avec un ensemble d’utilisateurs de l’environnement de production de votre forêt de production est possible et décrit en détail ci-dessous.

Préparation

Contoso Ltd. est une organisation de la taille d’une entreprise qui compte plus de 2 000 employés dans le monde entier. Elle a déployé Active Directory sur site dans une forêt unique, contoso.com. Contoso est également un client d’Office 365 et possède plus de 2 000 licences de la suite Office 365. Contoso a vérifié la propriété du domaine contoso.com auprès d’Office 365. Elle utilise la synchronisation d’annuaires pour synchroniser sa forêt Active Directory locale contoso.com (utilisateurs, contacts et groupes) avec Office 365. Cette procédure a permis de créer automatiquement des ID Microsoft Online (informations d’identification de cloud) pour chacun des utilisateurs locaux (utilisateurs avec ouverture de session activée) de la forêt contoso.com. Ainsi, tous les employés de Contoso qui utilisent Office 365 possèdent des informations d’identification/un nom d’utilisateur principal (UPN, User Principal Name) de cloud (distincts des informations d’identification fournies par l’entreprise) dans contoso.com. Par ailleurs, contoso.com est le domaine SMTP principal de l’organisation. 

L’organisation Contoso est très heureuse de son passage à Office 365. Néanmoins, elle évalue différents points noirs associés à la gestion des comptes locaux et dans le cloud. Cela a conduit Contoso à effectuer des recherches sur l’authentification unique. À ce titre, elle a décidé que l’investissement à effectuer pour déployer l’authentification unique vaut la peine. Néanmoins, avant d’effectuer cet investissement, les administrateurs informatiques de Contoso souhaitent d’abord tester l’authentification unique auprès de véritables utilisateurs de l’environnement de production ainsi que différents scénarios d’authentification fédérée avant de la déployer au reste de leur société.

Hypothèses

Contoso Publishing (ou votre organisation) :

1. Possède déjà un environnement AD local.
2. Dispose déjà d’une forêt unique, qui contient les comptes d’utilisateurs.
3. A déjà une synchronisation d’annuaires en cours d’exécution dans sa forêt.
4. A déjà des utilisateurs qui se connectent à Office 365 à l’aide des ID de cloud Microsoft Online, qui sont dans le domaine de la forêt (comme contoso.com). Ce sont des comptes non fédérés, qui sont donc authentifiés par le système d’identité d’Office 365.
5. A déjà des utilisateurs qui possèdent une adresse SMTP principale sous contoso.com. (Remarque : ce n’est pas obligatoire.)
6. N’a pas encore configuré l’authentification unique.

Étapes du test

1. Déployez AD FS 2.0 (conformément aux instructions de l’article Planifier et déployer AD FS 2.0 en vue d’une utilisation avec l’authentification unique) dans l’environnement de production de Contoso.
2. Achetez un nouveau domaine auprès d’un bureau d’enregistrement de domaines. Ce domaine doit être distinct de votre domaine de production (en d’autres termes, il ne peut pas s’agir d’un sous-domaine d’un domaine de production existant). Par exemple ici, nous partons de l’hypothèse de l’achat de fabrikam.com et de son utilisation dans l’exemple à partir de maintenant.
3. Fédérez le domaine fabrikam.com avec Office 365 en suivant les instructions de l’article Installer et configurer le module Microsoft Online Services pour Windows PowerShell pour l’authentification unique, sur la procédure à suivre pour ajouter un domaine fédéré.
4. Ajoutez fabrikam.com en tant que suffixe de domaine UPN dans votre forêt Active Directory (reportez-vous aux instructions de l’article http://technet.microsoft.com/fr-fr/library/cc756944(WS.10).aspx [en anglais seulement]).
5. Sélectionnez les utilisateurs de ce programme pilote et informez-les (à l’avance via des messages électroniques) qu’ils font partie de ce programme pilote d’authentification unique et des modifications de connexion auxquelles ils doivent s’attendre pendant ce programme pilote. Ce faisant, indiquez-leur également la date prévue pour cette modification. Informez-les qu’une fois la transition effectuée, à chaque fois que le système leur demandera d’entrer un ID, ils devront taper leur nouveau nom UPN (celui qui figure sous le domaine fabrikam.com).
6. Accédez au Centre d’administration Active Directory ou allez dans ADSI (Utilisateurs et ordinateurs Active Directory) et activez les noms UPN des utilisateurs du programme pilote pour qu’ils figurent sous le domaine fabrikam.com.
   1. REMARQUE : si les utilisateurs faisant partie du groupe de test du programme pilote possèdent des cartes à puce, il se peut que cette technique ne soit pas appropriée. En effet, elle implique de modifier le nom UPN de l’utilisateur et rend donc sa carte à puce non valide pendant la durée du programme pilote. Les organisations doivent également vérifier si des applications internes ou l’accès aux ressources utilisent les noms UPN des utilisateurs et s’ils nécessitent une mise à jour.
   2. REMARQUE : cette technique n’a pas d’effet sur l’adresse SIP ni sur les adresses de proxy SMTP des utilisateurs. Il est tout à fait justifié de posséder un nom UPN différent d’une adresse SMTP principale.
   3. Dès que tous les utilisateurs du programme pilote auront procédé à la modification de leur nom UPN, accédez à l’ordinateur qui exécute DirSync et « forcez » une synchronisation (ou attendez simplement pendant 3 heures au plus jusqu’à la prochaine synchronisation) :
      1. Accédez à %program files%\Microsoft Online Directory Sync.
      2. Double-cliquez sur DirSyncConfigShell.psc1 pour ouvrir une session du composant logiciel enfichable DirSync de PowerShell.
      3. Sur la ligne de commande PS, tapez Start-OnlineCoexistenceSync, puis appuyez sur Entrée.
      4. Vérifiez que la mise à jour de DirSync est terminée en vous connectant au portail d’administration O365 et au Panneau de configuration Exchange et en consultant les listes d’utilisateurs à ces deux emplacements. Les modifications des noms UPN des utilisateurs du programme pilote doivent être appliquées dans les deux listes d’utilisateurs.
      5. Les utilisateurs du programme pilote de Contoso doivent tester scrupuleusement les différents scénarios de connexion pour s’assurer que l’authentification unique (et le déploiement d’AD FS 2.0) est correctement configurée et qu’elle est prête à être déployée dans toute l’organisation. Les tests incluent l’accès aux services Office 365 à partir des navigateurs et des applications client enrichies (par exemple Office 2007 ou Office 2010, Lync et Outlook 2007 ou Outlook 2010) dans les environnements suivants :
         1. À partir d’un ordinateur ayant rejoint un domaine.
         2. À partir d’un ordinateur n’ayant pas rejoint de domaine sur le réseau de l’entreprise.
         3. À partir d’un ordinateur itinérant ayant rejoint un domaine hors du réseau de l’entreprise.
         4. À partir d’un ordinateur personnel.
         5. À partir d’une borne Web (navigateur uniquement).
         6. À partir d’un téléphone de type smartphone (par exemple, Exchange Active Sync).

Fédérer le domaine de production contoso.com

Lorsque l’organisation Contoso est satisfaite de la configuration de l’authentification unique et convaincue qu’elle fonctionne correctement d’après les tests du programme pilote exposés plus haut, elle est prête à la déployer vers ses utilisateurs existants, dans l’environnement de production. Cela implique 2 étapes principales :

1. Retour des utilisateurs du programme pilote dans le domaine standard de production (contoso.com) et suppression du domaine fédéré de test (fabrikam.com). Cette suppression signifie que le déploiement d’AD FS 2.0 peut désormais être utilisé pour fédérer votre domaine de production (contoso.com).
2. Fédération du domaine contoso.com en convertissant ce domaine standard en domaine fédéré.
3. Informez les utilisateurs du programme pilote qu’ils vont revenir au domaine de production standard et que leur expérience de l’authentification unique va s’arrêter temporairement. Indiquez-leur que leur nom UPN va réutiliser le domaine de production (contoso.com) et qu’ils recevront un nouveau mot de passe temporaire pour accéder à Office 365 (c.-à-d. qu’ils referont ce qu’ils faisaient avant le lancement du programme pilote). Vous devez également les informer que dans le cadre de cette transition, ils risquent de connaître une brève période de temps mort.
4. Rebasculez le domaine du nom UPN des utilisateurs du programme pilote de fabrikam.com vers contoso.com.
5. Attendez que l’utilitaire DirSync synchronise les modifications ou forcez une synchronisation à l’aide des instructions données précédemment.

Retour des utilisateurs du programme pilote dans le domaine de production (contoso.com)

• REMARQUE : DirSync affiche une erreur en raison d’un code défectueux. Le déplacement de cette façon d’un domaine fédéré vers un domaine standard sera pris en charge dans le futur, une fois ce défaut corrigé.

1. Redéplacer l’utilisateur vers un domaine standard (non fédéré) du cloud requiert l’utilisation du module Microsoft Online Services pour Windows PowerShell. Il s’agit du module qui contient les cmdlets de l’outil de fédération. Déplacez chaque utilisateur du programme pilote dans le domaine contoso.com en utilisant la cmdlet Set-MsolUserPrincipalName. Exemple :

• set-msoluserprincipalname –UserPrincipalName john@fabrikam.com

-newUserPrincipalName john@contoso.com

1. Lorsque les noms UPN des utilisateurs du programme pilote mis à jour sont visibles sur le portail d’administration, réinitialisez tous les mots de passe de cloud de ces utilisateurs (sur le portail d’administration) et distribuez les mots de passe temporaires aux utilisateurs du programme pilote.

• Les utilisateurs du programme pilote seront contraints de modifier leur mot de passe lors de leur première connexion et après qu’ils auront été redéplacés vers le domaine contoso.com[1].

Fédération du domaine de production (contoso.com)

1. Sur l’ordinateur exécutant AD FS, ouvrez le module Microsoft Online Services pour Windows PowerShell (pour plus d’informations, reportez-vous à l’article Installer et configurer le module Microsoft Online Services pour Windows PowerShell pour l’authentification unique). Cette fois, après vous être connecté au service et à AD FS, supprimez le domaine de test fédéré, fabrikam.com, à l’aide de la cmdlet Remove-MSOLFederatedDomain.
2. Informez tous les utilisateurs de l’environnement de production possédant des licences/comptes Office 365 dans contoso.com que l’authentification unique va être activée pour leurs comptes de connexion Office 365 et indiquez-leur la date prévue pour cette activation. Expliquez à tous les utilisateurs finaux les modifications qui interviendront dans leur mode de connexion une fois que le domaine contoso.com sera fédéré.
3. Fédérez ensuite le domaine contoso.com à l’aide de la cmdlet Convert-MSOLDomainToFederated. 
   1. REMARQUE : l’exécution de cette procédure de conversion peut prendre jusqu’à 24 heures. Microsoft recommande de l’effectuer lors d’un week-end.
   2. REMARQUE : cette procédure de conversion convertit toutes les informations d’identification de cloud des utilisateurs de contoso.com en informations d’identification fédérées, ce qui leur permet d’utiliser les informations d’identification fournies par leur entreprise pour se connecter aux services Office 365. Actuellement, la mise en place de cette procédure de conversion n’est pas possible avec Office 365.