PI Services

Le blog des collaborateurs de PI Services

Activer l’Authentification Multi Facteur (MFA) dans Office 365

Introduction

Cette fonctionnalité disponible aussi dans Azure appelé authentification forte ou double authentification permet de renforcer la sécurité d’accès aux ressources web.

L’activation est accessible par le centre d’administration office sur l’onglet utilisateurs actifs, le lien « gérer l’authentification multi-facteur » se trouve en bas de page après sélection de l’utilisateur.

administ

Mise en place

Dans la liste des utilisateurs sélectionner un ou plusieurs utilisateurs et cliquer sur le bouton activer.

De la même façon sélectionner désactiver pour un utilisateur ayant déjà la fonctionnalité activée.

Le lien “gérer les paramètres” concerne la gestion au niveau de la méthode de contact, des mots de passe d’application ou pour réinitialiser la MFA sur les mobiles reliés.

image

Une fois activé, lors de la première connexion au portail Office l’utilisateur entre son identifiant et mot de passe habituel (1ère authentification). Un message avertit de la mise en place d’une procédure supplémentaire de sécurité.

image

La configuration commence et il faut choisir entre 3 méthodes de contact. Nous allons les tester les 3 et garder notre préférée. 

Méthode de contact 1 : L’appel.

L’appel téléphonique (Microsoft US) vers un mobile ou bureau: un message audio vous demande d’utiliser la touche # pour confirmer la demande d’accès.

imageimageimage

image

La configuration est terminée (étape 3). Vous recevez un code précieux valable sur vos applications client lourd comme Outlook MailOs Skype etc. à utiliser en lieu et place du mot de passe habituel.

Je vais donc l’utiliser pour configurer Outlook. Et pour Skype, il suffit de se déconnecter et se reconnecter avec le nouveau mot de passe de 16 caractères.

imageimage

Vous pouvez changer d’avis et vouloir utiliser la méthode par SMS ou application mobile !

Il faudra passer par une réinitialisation de la méthode de contact ou ponctuellement utiliser le lien autre option de contact.

Méthode de contact 2 : Validation par SMS

Tout ce passe à l’étape 1.

image image

Un code numérique à 6 caractères vous parvient et doit-être reporté dans le champs de vérification pour validation.

Notez aussi la possibilité d’espacer la 2ème vérification tous les 30 jours.

Méthode de contact 3: Validation par application mobile.

A l’étape 1, vous choisissez application mobile puis cliquez sur le bouton configurer.

image

Vous aurez besoin de l’application Azure Authenticator et de l’application Barcode Scanner pour lire le QR Code.

Soit vous ajouter manuellement un compte dans l’application mobile Authenticator en saisissant le code de 9 caractères puis l’URL complet, ou en sélectionnant analyser le QR Code.

L’application mobile génère un code numérique à 6 caractères qui doit-être reporté dans le champs de vérification avant la fin du temps imparti pour valider l’accès.

L’application mobile peut aussi générer un message pop-up “Approuver” ou “Refuser”.

C’est la méthode que je préfère, pas de code à reporter juste un clic sur Approuver !

image image image

Attention !

Le signalement provoque l’inaccessibilité au compte dans l’immédiat et peut-être le “bannissement” du mobile utilisé (à confirmer).

Car pour le moment impossible de configurer à nouveau la MFA sur le mobile pour cet utilisateur. Même après une réinitialisation des paramètres ou la désactivation-réactivation de la fonctionnalité, cet utilisateur devra se passer de MFA pour de nouveau avoir accès au ressources! Ou changer de mobile?! ou de numéro de téléphone.

Gestion de licence Office 365 en PowerShell

 

Bonjour, nous allons voir les bases pour gérer ses licences O365 en powerShell

Connexion au tenant O365

 

Nous allons enregistrer les informations de connexion

$cred = Get-Credential

Puis nous allons nous connecter au tenant lié au informations de connexion enregistré précédemment.

Connect-MsolService -Credential $cred

 

Récupération des offres

Si vous n’avez pas d’erreur vous êtes connecté a votre tenant.

Nous allons récupérer les infos sur nos offres

Get-MsolAccountSku | Format-Table AccountSkuId

 

Nous allons ensuite listé les produits disponible dans l’offre que nous allons assigner.

$ServicePlans = Get-MsolAccountSku | Where {$_.SkuPartNumber -eq “ENTERPRISEPREMIUM_NOPSTNCONF”}
$ServicePlans.ServiceStatus

 

Voici les correspondances produits des valeurs de servicePlan pour un abonnement E5.

image

Création d’une offre personnalisée

En nous basant sur les valeurs servicesPlan, nous allons créer notre option de licence.

$MyO365Sku = New-MsolLicenseOptions -AccountSkuId piservices:ENTERPRISEPREMIUM_NOPSTNCONF -DisabledPlans LOCKBOX_ENTERPRISE,EXCHANGE_ANALYTICS,ATP_ENTERPRISE,MCOEV,INTUNE_O365,MCOSTANDARD,EXCHANGE_S_ENTERPRISE

Le paramètre –DisabledPlans permet des choisir les éléments que l’on souhaite désactiver dans l’offre.

 

Attribution de la licence

Pour des raison légal il faut spécifier le pays où a licence sera utilisé.

Set-MsolUser -UserPrincipalName adrien.gougeon@piservices.fr -UsageLocation FR

Enfin nous n’avons plus qu’a associer notre licence avec nos options.
Set-MsolUserLicense -UserPrincipalName adrien.gougeon@piservices.fr -AddLicenses piservices:ENTERPRISEPREMIUM_NOPSTNCONF -LicenseOptions $MyO365Sku

 

version script

Voici en bonus les commandes dans un script simple et fonctionnel.

$cred = Get-Credential
Connect-MsolService -Credential $cred

$MyO365Sku = New-MsolLicenseOptions -AccountSkuId piservices:ENTERPRISEPREMIUM_NOPSTNCONF -DisabledPlans LOCKBOX_ENTERPRISE,EXCHANGE_ANALYTICS,ATP_ENTERPRISE,MCOEV,INTUNE_O365,MCOSTANDARD,EXCHANGE_S_ENTERPRISE

$users=Get-MsolUser -Synchronized -UnlicensedUsersOnly | where {$_.UserPrincipalName -notlike 'adm_*' -and $_.UserPrincipalName -like '*@piservices.fr'} | select -Property UserPrincipalName

Foreach ($user in $users) {

    Set-MsolUser -UserPrincipalName $user.UserPrincipalName -UsageLocation FR

    Set-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -AddLicenses piservices:ENTERPRISEPREMIUM_NOPSTNCONF -LicenseOptions $MyO365Sku


}

Nous avons la commande :

Get-MsolUser -Synchronized -UnlicensedUsersOnly | where {$_.UserPrincipalName -notlike 'adm_*' -and $_.UserPrincipalName -like '*@piservices.fr'} | select -Property UserPrincipalName

Cette commande permet d’obtenir les utilisateurs qui sont synchronisés et sans licence. le résultat est ensuite filtré pour enlever les comptes admins et cibler le domaine que nous voulons manipuler et enfin nous ne prenons que le champ UserPrincipalName car c’est le seul qui nous sert pour le script.

Bonus

Voici en bonus des commandes utiles pour améliorer vos scripts.

Pour sélectionner toutes les entrée d’une OU sans les sous-OU et mettre une valeur dans extensionAttribute15.

Get-ADUser -Filter * -SearchBase "VOTRE OU" -SearchScope 1 -Properties extensionAttribute15 | Set-ADUser –Add @{extensionAttribute15="AzureAdSync"}

Cette commande peut vous être utile si vous faites de la synchro d’AD on-premise avec azure AD connect

Azure AD Connect : Retour d'expérience

Introduction

Azure AD Connect est devenu, depuis quelques mois, le nouvel outil de synchronisation d'identité entre une infrastrcture Active Directory On-Premise et Azure Active Directory. Ce dernier doit remplacé les outils existants (Dirsync et Azure AD Sync) en consolidant les fonctionnalités de chacun de ceux-ci. Aussi, il apporte de nombreuses fonctionnalités comme la synchronisation des attributs étendus, la synchronisation Azure AD vers Active Directory On premise des groupes ou encore une interface de monitoring Azure AD Connect Health. Malheureusement, toutes ces nouvelles fonctionnalités nécessitent de souscrire à la version basic voir premium d’Azure Active Directory.

Du point de vue de l'installation, Microsoft à simplifié les choses pour les personnes disposant déjà d'un des outils précédemment cités. Le but de cet article est de partager un retour d'expérience sur la mise à jour de Dirsync vers Azure AD Connect au travers d'un guide pas à pas puis de détailler les changements entre les deux outils.

Azure AD Connect peut être téléchargé via le lien suivant :

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Mise à jour

Lors du lancement du programme d'installation, il est d'abord demandé d'accepter la licence utilisateur.

Install 02

Il s'en suit une analyse du serveur existant afin de valider que la configuration Dirsync est compatible avec le processus de migration Azure AD Connect. Si celle-ci n'est pas compatible, il faudra alors réaliser une installation complète du produit. Cela implique de reconfigurer intégralement l'outil (comptes, base de données, règles de filtrage, ….). Plusieurs causes peuvent être responsables de la non prise en charge de la migration :

  • Un trop grand nombre d'objets à synchroniser (+ de 50000)

  • L'utilisation d'une DLL d'extension personnalisée. Ces dernières permettent d'étendre les fonctionnalités de synchronisation en réalisant du filtrage plus poussé ou une transformation sur certains attributs. Il s'agit d'un concept hérité de Forefront Identity Manager (FIM). En effet Azure AD Connect, comme ses prédécesseurs est toujours basé sur cet outil.

  • La suppression d'attributs dans les règles de synchronisation.

Install 03

Lorsque l'analyse est terminée, il faut indiquer le chemin d'installation ainsi que les informations d'accès à la base de données et éventuellement un compte de service. Comme pour Dirsync, ce dernier doit posséder les droits "Replicate Directory Changes" au niveau du domaine.

Install 04

Le programme installe ensuite les prérequis.

Install 05

Les informations (login/mot de passe) du compte utilisé par Dirsync pour accéder à Azure Active Directory doivent être renseignées.

Install 06

Puis, il est nécessaire d'indiquer un compte Active Directory ayant les droits administrateur de l'entreprise.

Install 07

La dernière étape consiste à choisir si l'on a activé le mode hybride et s'il faut démarrer la synchronisation dès la fin de l'installation. Ne pas cocher la case permet néanmoins de valider que la configuration a été correctement reportée depuis Dirsync.

Install 08

Enfin, l'installation s'exécute (une dizaine de minutes).

Install 10

Revue post installation

Une fois l'installation terminée, DirSync est désinstallé et est remplacé par Azure AD Connect. De nouvelles icônes apparaissent :

  • Azure AD Connect : Permet de voir et configurer les paramètres principaux de l'outil

  • Synchronization Rules Editor : Cet utilitaire sert à la configuration des règles de filtrages et de transferts d'attributs et ne se trouvent plus dans la console de gestion de FIM.

  • Synchronization Service : Cet icône mène à la console de FIM contenant les connecteurs de gestion des identités qui a été renommé pour l'occasion. Comme pour Dirsync, il y a deux connecteurs :

    • Active Directory on premise / Azure AD Connect : import uniquement (sauf en cas d'utilisation du writeback avec Azure AD Premium)

    • Azure AD Connect / Azure Active Directory

  • Synchronisation Service Key Management Utility : Utilitaire de gestion de la clé encryptant les données dans Azure AD Connect

NB : Elles sont identiques à celles présentes dans Azure Active Directory Sync.

Menu 01

De plus, comme pour Dirsync, une tâche planifiée nommée Azure AD Sync Scheduler est créée. Elle s'exécute toutes les trois heures (mais il est bien sûr possible de changer ce comportement).

Task 01

Revue de la configuration

Azure AD Connect :

L'utilitaire Azure AD Connect permet plusieurs options :

  • Revue de la configuration actuel

  • Configuration des options de synchronisation

  • Mise à jour du connecteur

  • Gestion du mode staging

Configure 01

La première option permet simplement une revue de la synchronisation mise en place avec une visualisation des annuaires synchronisés et des options activées (synchronisation du mot de passe, des attributs étendues, mapping de l'attribut servant d'UPN dans Office 365). En effet depuis Windows Azure Active Directory Sync, il est possible d'implémenter une synchronisation multi-forêt. Aussi, une synchronisation vers des annuaires différents d'Active Directory est prévue par Microsoft mais cette fonctionnalité n'est pas encore implémentée.

NB : L'option de filtrage par groupe n'est disponible que pour une nouvelle installation et n'est conseillé par Microsoft que dans le cadre d'un déploiement progressif.

Configure 02

Les trois autres options nécessitent d'indiquer un compte administrateur Azure Active Directory  afin de modifier certaines options de configuration.

Configure 03

Le second onglet offre la possibilité d'ajouter d'autres annuaires Active Directory pour la synchronisation.

Configure 04

Il permet aussi d'activer ou désactiver certaines options comme la gestion du mode hybride d'Exchange ou l'écriture inversée (Azure AD vers Active Directory On premise).

Configure 05

L'actualisation du connecteur peut être utilisée après une mise à jour de votre schéma Active Directory. Ainsi, Azure AD Connect pourra mettre à jour ses connecteurs en cas de changement.

Enfin, la dernière option concerne l'activation du mode staging. Lorsqu'il est activé, aucun changement n'est synchronisé/exporté vers Active Directory (si le Writeback est activé) ou vers Office 365. Cela permet de valider sa configuration avant d'appliquer un changement.

Configure 06

Synchronization Service :

Il s'agit de la console Synchronisation Service de Forefront Identity Management. Cependant pour chaque connecteur (appelé Management Agent), les options de configuration sont bien plus légères que dans Dirsync. Il n'est possible de configurer que les paramètres de connexion à l'annuaire, les attributs accessibles et le filtrage par unité d'organisation (via le bouton Container de l'onglet Configure Directory Partitions). En effet, la configuration des filtres par attribut et des règles de jointure d'attribut s'effectue via l'outil présenté dans le chapitre suivant. Cette nouveauté était apparue avec Azure Active Directory Sync.

Post Install 01

Synchronization Rules Editor :

Cet outil  change la manière dont sont gérées les règles de synchronisation. Cette gestion ne s'effectue plus au sein de la console de synchronisation héritée de Forefront Identity Manager. Néanmoins, cette nouveauté permet d'utiliser la syntaxe déclarative de FIM qui n'était utilisable qu'au travers de FIM portal (et qui nécessite des CAL pour chaque utilisateur géré par ce système). Ce langage donne la possibilité d'effectuer des opérations simples sans passer par du développement en C# ou VB.Net. Les deux liens ci-dessous expliquent la syntaxe et la détaille :

L'utilitaire offre une vision globale des règles entrantes (import depuis Active Directory On premise ou Azure AD) et sortantes (export vers Active Directory On premise ou Azure AD). Toutes ces règles ont une priorité (la plus faible étant prioritaire sur les autres). Si ces dernières ont un poids supérieur à 100 alors elles correspondent aux règles par défaut de l’outil.

Configure 07

Nous remarquons sur l'image précédente qu'il y a une règle avec une priorité de 99. Il s'agit d'une règle personnalisée reprise lors de la migration de Dirsync. Celle-ci filtre les utilisateurs via un attribut Active Directory. On peut définir le type d'objet source (ici l'annuaire Active Directory On premise) et le type d'objet dans la Metaverse, c’est-à-dire dans la base de données d'Azure AD Connect. Enfin, on peut redéfinir la priorité de la règle. 

Configure 08

L'onglet suivant permet de définir le ou les attributs utilisé(s) pour filtrer les objets (ici des utilisateurs mais cela peut aussi s'appliquer à des groupes par exemple). La définition du filtrage se fait de la même façon que sur Dirsync (les objets satisfaisants la règle étant exclus de la synchronisation).

Configure 09

Ensuite, il est possible de définir une règle de jointure entre un objet provenant de la source (annuaire Active Directory ou Azure Active Directory) et la metaverse. Cette jointure s'effectue sur un attribut. Dans le cas de notre règle de filtrage, il n'existe pas de règle de jointure. Cependant il n'est pas nécessaire d'en ajouter.

Configure 10

En effet, si l'on ouvre la règle avec la priorité 100 (In From AD - User Join), on remarque qu'une règle de jointure existe déjà pour les objets de types utilisateurs.

Configure 12

Enfin, on définit les valeurs transmises depuis la source vers la metaverse. Elles peuvent être de trois types :

  • une valeur constante

  • un attribut source

  • un attribut source transformé via la syntaxe déclarative

Dans le cadre d'un filtrage par attribut pour la synchronisation, les objets non synchronisés doivent posséder l'attribut cloudFiltered avec la valeur True dans la metaverse.

Configure 11

Conclusion

L'installation est donc très similaire à celle de Dirsync et demande les mêmes informations (compte administrateur de l'entreprise, serveur SQL, ...). De plus, le processus de mise à jour est simplifiée au maximum. Néanmoins, pour les personnes n'ayant pas utilisées Azure Active Directory Sync, l'administration et notamment la configuration les règles de synchronisation est différente.

Powershell & Office 365 : Provisionning de licences

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)

Get-MsolAccountSku

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

ServiceStatus

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 :

EXCHANGE_S_STANDARD Exchange Online (Plan 2)
MCOSTANDARD Lync Online (Plan 2)
SHAREPOINTENTERPRISE SharePoint Online (Plan 2)
SHAREPOINTWAC Office Online
OFFICESUBSCRIPTION Office ProPlus
RMS_S_ENTERPRISE Azure Active Directory Rights Management
INTUNE_O365 Intune
YAMMER_ENTERPRISE Yammer
 

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

Office 365 – Résoudre l’erreur de migration “Cannot find a recipient that has mailbox GUID”

Contexte

Dans un environnement Exchange 2013 en mode hybride, vous obtenez l’erreur suivante lors de la migration d’une boite aux lettres Exchange Online vers Exchange OnPremise :

Error: MigrationPermanentException: Cannot find a recipient that as mailbox GUID <GUID>.

2015-09-08_181420

Cette erreur est due à l’absence du GUID sur la RemoteMailbox de l’utilisateur côté Exchange OnPremise.

Si vous lancez la commande suivante sur l’Exchange Management Shell, vous obtiendrez un GUID nul :

Get-RemoteMailbox <SamAccountName> | fl *ExchangeGUID*

2015-09-08_181240

Résolution

Afin de résoudre l’erreur et pouvoir procéder à la migration de la boite, vous devez modifier le GUID de la RemoteMailbox pour le faire correspondre à celui de la boite côté Exchange Online.

Vous pouvez récupérer le GUID de la boite depuis le message d’erreur ou depuis une console PowerShell connectée à ExchangeOnline avec la commande

Get-Mailbox <SamAccountName> | fl *ExchangeGUID*

2015-09-08_181501

Ensuite depuis l’Exchange Management Shell, lancez la commande suivante :

Set-Mailbox <SamAccountName> –ExchangeGUID <GUID>

2015-09-08_181532

Relancez votre migration.

2015-09-09_100059

ADFS / Yammer : Renouvellement des certificats

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

 

03

 

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.

 

02

 

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 :

 

01

 

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.

Retour d'expérience : Migration de tenant Office 365 Partie 2

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

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

image

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

image

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.

image

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.

image 

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

image

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

image 

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

Yammer Domain

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.

Yammer

On peut ensuite confirmer l'activation du service.

Yammer Enable Yammer Enable 2

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

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.

Office 365 – Retour d’expérience d’une migration IMAP

Introduction

L'offre Office 365 inclut un outil de migration. Cet outil permet la migration des boites mails depuis Exchange (2003 / 2007 / 2010 /2013) vers Office 365 ou depuis un autre serveur de messagerie utilisant l'IMAP vers Office 365.
Ce billet portera sur mon retour d'expérience d'une migration IMAP vers Office 365.

Retour d'expérience

Les prérequis


1) Chaque compte migré doit avoir un utilisateur unique associé avec une licence active. Le compte peut être uniquement dans le cloud ou synchronisé avec Active Directory (via DirSync par exemple).
Dans le cadre d'une architecture hybride (c'était le cas dans ce projet), d'autres prérequis utilisateurs sont nécessaires. L'utilisateur doit être "connu" par les serveurs Exchange OnPremise. Pour cela la commande PowerShell suivante est à passer sur les serveurs Exchange OnPremise :

Enable-RemoteMailbox –Identity Utilisateur –RemoteRoutingAddress utilisateur@tenant.mail.onmicosoft.com –PrimarySMTPAddress utilisateur@domaine.fr
Remarque : Attention, si l'utilisateur possède d'autres adresses SMTP que la principale il est nécessaire de les indiquer dans la commande à l'aide du paramètre EmailAddresses
Remarque 2 : Il est également recommandé d'avoir l'UPN (UserPrincipalName) de l'utilisateur qui soit égal à l'adresse email afin de faciliter la connexion aux services Office 365.

2) Un Migration Endpoint avec les éléments suivants :

  • L'URL du serveur IMAP
  • Le type d'authentification (Basic ou NTLM)
  • Le chiffrement (Aucun, SSL, TLS)
  • Le port utilisé pour se connecter en IMAP au serveur
  • Le nombre maximum de migrations simultanées
  • Le nombre maximum de synchronisation incrémentales simultanées

image
3) Un fichier CSV contenant l'adresse email cible, le nom d'utilisateur et le mot de passe du compte IMAP (ou d'un compte administrateur). Le fichier CSV sera construit ainsi :

Les éléments migrés


La migration IMAP n'inclut que la partie mail. En effet les éléments de type contacts, calendrier, tâches… ne sont pas pris en compte.
La migration IMAP prend en compte les mails qui se trouvent dans les différents dossiers (et sous dossiers) personnels ainsi que les dossiers de base (Boite de réception, éléments envoyés, éléments supprimés…).

La migration


La migration se déroule par lot. Chaque lot peut comporter jusqu'à 5000 utilisateurs.
Pour une meilleure gestion des erreurs et de la volumétrie, des lots de 1200 utilisateurs environ ont été fait.
A titre d'exemple, le temps de migration pour un lot de 1200 utilisateurs ayant une volumétrie d'environ 30 Go au total (soit une moyenne de 25Mo/BAL) a mis un peu plus de deux heures.
Cette estimation est bien évidement propre à l'architecture et peut être différente en fonction de la bande passante et des performances du serveur source.

La gestion des erreurs


Il est courant qu'un lot de migration comporte des erreurs. Pour les identifier il est possible d'utiliser la commande PowerShell suivante sur le tenant Office 365 :
Get-MigrationUser -ResultSize Unlimited | ?{$_.Status -ne "Synced"}

image

Les utilisateurs en échec peuvent être sorti du lot de migration et relancés dans un lot séparé.
Remarque : Un utilisateur ne peut pas être inclus dans un nouveau lot s'il appartient déjà à un lot. Microsoft met également à disposition des rapports (au format CSV) sur la plateforme d'administration d'Office 365 – Exchange.

Conclusion

Dans le cadre de cette migration, le pourcentage d'erreur a été de 0.2% (moins d'une vingtaine de boites en erreur sur plus de 6000 boites migrées).
Le seul point négatif est la limite des éléments migrés. Les calendriers, carnets d'adresses… ne sont pas pris en compte et doivent être fait manuellement par l'utilisateur ou via un autre outil de migration.


Pour conclure l'outil de migration fonctionne parfaitement. Même s'il possède peu de fonctionnalités contrairement à d'autres outils de migration (Refresh IT, Quest…) il permet une migration simple à un moindre coût.

DirSync – Changement de l’adresse e-mail recevant les alertes

Contexte

Lors de la mise en place de DirSync dans une architecture, ce dernier envoie automatiquement des mails lors des problèmes de synchronisation.

Problème

L’adresse e-mail utilisée par DirSync n’est plus consultée et nous ne recevons plus d’alertes.

Solution

DirSync utilise l’adresse e-mail principale du tenant Office 365 (l’adresse enregistrée à la création du tenant). Il faut donc modifier cette adresse pour recevoir les alertes DirSync.

Une fois connecté au portail d’administration d’Office 365, il faut cliquer sur le nom de la société en haut à droite de la page. Puis il est possible de modifier les informations du compte principal, notamment l’adresse e-mail.

image

image

Powershell : Connexion à Exchange Online

Introduction

Powershell est intégré dans tous les nouveaux produits et services de Microsoft. Grâce à ce langage de scripting il est tout naturellement possible d'administrer Exchange Online via le Remote Powershell. Au delà d'offrir des possibilités d'automatisation, certaines opérations ne sont réalisables que par ce biais.

La gestion d'Exchange Online se décompose en 2 parties :
L'installation d'un module Powershell pour la gestion des utilisateurs dans l'Active Directory Azure
La connexion à Exchange Online pour l'administration des paramètres de la messagerie et des boîtes aux lettres.

Cet article s'adresse donc aux personnes souhaitant administrer Exchange Online mais aussi à ceux qui utilisent Active Directory dans le cloud Azure.

Nous allons voir comment accéder à la gestion des utilisateurs sur Office 365, à leurs boîte email Exchange Online. Je montrerai aussi quelques erreurs courantes (problème d'installation et connexion derrière un proxy) que l'on peut rencontrer lors d'une interaction avec Office 365 ainsi que leurs résolutions.

A noter que, comme les sessions distantes Powershell sont apparues avec la version 2, il est nécessaire de posséder à minima cette version pour exécuter les opérations que nous allons voir.

Gestion des utilisateurs Microsoft Online (Azure Active Directory)

Installation :

L'administration des utilisateurs ne peut se faire que via l'installation d'un module Powershell. Ce dernier nécessite un prérequis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez les liens de téléchargement de ce dernier :

Microsoft Online Services Sign-In Assistant– 32 bit version
http://go.microsoft.com/fwlink/?linkid=236299
Microsoft Online Services Sign-In Assistant – 64 bit version
http://go.microsoft.com/fwlink/?linkid=236300

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

Microsoft Online Services Module for Windows PowerShell (32-bit version)
http://go.microsoft.com/fwlink/?linkid=236298
Microsoft Online Services Module for Windows PowerShell (64-bit version)
http://go.microsoft.com/fwlink/?linkid=236297

Vérification de l'installation :

Pour vérifier que le module est opérationnel, il suffit de l'importer et de se connecter aux services MSOnline (en s'authentifiant lorsque c'est demandé) :
On peut ensuite utiliser les commandes comme :

Erreurs rencontrées :

1/ Lors de l'installation de Microsoft Online Services Sign-In Assistant, j'ai rencontré l'erreur suivante :

In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer.

Pour résoudre ce problème, il m'a fallu installer la beta de ce prérequis disponible dans le lien ci-dessous :
http://www.microsoft.com/en-us/download/details.aspx?id=39267

2/ Si un proxy est utilisé lors de la connexion au cloud de Microsoft, alors on obtient l'erreur suivante :

Erreur Proxy

Pour résoudre ce problème, il faut configurer le proxy ainsi que les paramètres d'authentification à utiliser :

Par défaut Powershell utilise le proxy d'Internet Explorer ; on peut reconfigurer le paramétrage du proxy avec la commande « netsh ».

On spécifie une URL de proxy (première ligne) ou on indique que l'on souhaite utiliser les paramètres présents dans Internet Explorer (seconde ligne) :
Aussi, on peut aussi supprimer toute configuration du proxy via la commande suivante :
Pour que Powershell puisse s'authentifier, il faut indiquer un couple login / mot de passe. En général, on utilisera ceux de la session actuellement ouverte. Pour effectuer cette opération, il suffit d'exécuter la commande suivante :

Connexion à Exchange Online

Implémentation :

Le but de l'opération est d’importer toutes les commandes que l’on connait sous Exchange comme « Get-Mailbox » qui existent aussi sous Exchange Online.
Voici les quelques lignes Powershell permettant d'ouvrir une PSSession vers Exchange Online en spécifiant un compte utilisateur pour s'authentifier puis d'importer les cmdlets Exchange. A noter que la liste des commandes disponibles variera en fonction des droits du compte utilisé (grâce à RBAC).

Erreur rencontrée :

Comme pour la gestion des utilisateurs Active Directory dans le cloud, une configuration particulière est attendue lorsque l'on essaie de se connecter en passant par un proxy. L'erreur générique suivante apparaît :

Erreur Proxy Exchange

Pour résoudre ce problème, il est possible d'utiliser la même méthode que précédemment. Cependant, on peut aussi définir les paramètres des sessions Powershell distantes et ainsi configurer un proxy. Dans l'exemple ci-dessous nous utiliserons le proxy défini dans Internet Explorer :

La variable $Credential contient les paramètres d’authentification.