PI Services

Le blog des collaborateurs de PI Services

Office 365 – Les mails automatiques ne sont pas envoyés dans la langue de l’utilisateur

Contexte

Dans Office 365 lorsque vous activez une fonctionnalité qui déclenche un mail automatique (exemple : activation de l’UM, activation du PSTN calling…) le mail est rédigé dans la langue du tenant et non dans celle de l’utilisateur.

2017-10-09_141755

Explications et solution

Par défaut l’ensemble des mails envoyés automatiquement utilise la langue sélectionnée lors de la création du tenant. Donc si votre tenant a été créé en Français l’ensemble des mails sont envoyé en Français.

Pour changer la langue, en anglais par exemple, il faut que l’utilisateur possède l’attribut PreferredLanguage de renseigné sur son compte Active Directory. Pour l’anglais il est possible de mettre “EN-US” ou “EN-GB”.

La liste des code possibles est disponible au lien suivant https://technet.microsoft.com/en-us/library/ee825488.aspx.

2017-10-09_144640

Une fois la valeur modifiée (et après avoir effectué une synchronisation AzureADConnect) le mail envoyé est en anglais !

2017-10-09_141815

Script de modification de l’attribut PreferredLanguage dans l’AD

Si vous souhaitez modifier en masse l'ensemble des utilisateurs vous pouvez utiliser le script PowerShell ci-dessous.

$users = Get-ADUser -Filter * -SearchBase "DC=MONDOMAINE,DC=COM" -SearchScope Subtree
$actual=1
$total = $users.count
foreach($user in $users)
{ 
   $sam = $user.SamAccountName
   Write-Progress -Id 1 -Activity ("Working...Please wait") -PercentComplete ($actual / $total * 100) -Status ("Working on {0} - {1} / {2}" -f $sam, $actual, $total)
   Set-ADUser $sam -add @{PreferredLanguage="EN-GB"}
   $actual++
}

 

 

Office 365 - VIsualiser des rapports avec Power BI

Description

Le pack de contenu Office 365 Adoption dans Power BI permet d’obtenir des informations sur la façon dont votre organisation a adopté les différents services au sein de Office 365 pour communiquer et collaborer. Vous pouvez visualiser et analyser les données d’utilisation Office 365, créer des rapports personnalisés et les partager au sein de votre organisation.

Configuration

Pour profiter de cette nouvelle fonctionnalité il faut utiliser votre compte d’administration Office 365 et se rendre à l’adresse suivante : https://app.powerbi.com

Une fois dessus créer un compte en rentrant votre compte :

clip_image002

Une fois sur votre espace de travail cliquez sur « obtenir des données » depuis le volet de navigation

clip_image003

Cliquez sur « Obtenir » au niveau de la tuile Services

clip_image005

Vous pouvez maintenant choisir et installer l’application dont vous avez besoin. Par exemple vous pouvez installer l’application « Azure Active Directory Activity Logs » qui vas vous permettre d’avoir plusieurs statistiques sur votre infrastructure :

clip_image007

Le prérequis pour cette application est de rentrer le nom de domaine suivi de la procédure dauthentification.

Voici un autre exemple avec l’application « Office 365 Adoption Preview » :

clip_image009

Le prérequis pour cette application est de rentrer le nom de tenant suivi de la procédure dauthentification.

Information

Pour plus d’information concernant la configuration, je vous invite à consulter les liens suivants :

Création d'un site SharePoint online via un template personalisé

1. Se rendre sur l'interface d'administration de SharePoint Online

Sélectionner : Nouveau > Collection de sites privée

2. Renseigner les champs suivants

  1. titre
  2. addresse du site web
  3. la langue
  4. le modèle (choisir personalisé)
  5. le fuseau horaire
  6. l'administrateur du site
  7. le quota

3. Patienter pendant la création du site

4. Application du template de site

Se rendre sur le site qui a été créé et cliquer sur "Galerie solutions" pour charger le template personalisé.

Sélectionner "Télécharger la solution"

Sélectionner le fichier template à injecter puis valider par OK

Activer le module et patienter pendant le chargement du template. 

FIN.

 

 

Changement d'UPN en mode hybride directement dans O365

Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Set-MsolUserPrincipalName -UserPrincipalName first.lastname@contoso.fr -NewUserPrincipalName first.lastname@contoso.onmicrosoft.com

 

Set-MsolUserPrincipalName -UserPrincipalName first.lastname@contoso.onmicrosoft.com -NewUserPrincipalName first.lastname@contoso.com

 

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

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.