FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Office 365 : activer le MFA avec PowerShell

24 janvier 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à activer ou désactiver le MFA (authentification multifacteur) sur les comptes utilisateurs Office 365 avec PowerShell.

Il s'agit du troisième article au sujet du MFA avec Office 365 puisque j'ai déjà publié les deux tutoriels suivants :

Cette fois-ci encore, nous allons utiliser le module MSOnline. Je vous rappelle que même si ce module est plutôt en fin de vie, et qu'il serait mieux d'utiliser le module Microsoft Graph, je n'ai pas trouvé de commandes permettant de gérer le MFA via ce module. Lorsque ce sera pris en charge par Microsoft Graph, cet article sera actualisé.

II. Activer le MFA avec PowerShell

Ouvrez une console Windows PowerShell afin d'exécuter la commande ci-dessous pour établir une connexion à Office 365. Le prérequis c'est bien sûr de disposer du module MSOnline.

Connect-MsolService

Une fenêtre va s'ouvrir, authentifiez-vous. Ensuite, il ne reste plus qu'à s'amuser avec PowerShell pour gérer le MFA sur les comptes utilisateurs.

Il est nécessaire de créer un objet de type "Microsoft.Online.Administration.StrongAuthenticationRequirement" avec plusieurs propriétés pour activer le MFA au sein d'un compte utilisateur. Cela nous donne les lignes suivantes :

$Mfa = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$Mfa.RelyingParty = "*"
$Mfa.State = "Enabled"
$MfaStatus = @($Mfa)

La variable $MfaStatus contient notre objet et ses propriétés. Cette variable va être utilisée au sein de la commande Set-MsolUser pour activer (ou désactiver) le MFA sur un utilisateur.

Voici un exemple :

Set-MsolUser -UserPrincipalName [email protected] -StrongAuthenticationRequirements $MfaStatus

Voilà, le MFA est désormais activé pour cet utilisateur et il n'aura plus qu'à configurer un second facteur d'authentification.

Office 365 - Activer MFA avec PowerShell

Prenons un autre exemple : on souhaite activer le MFA sur tous les membres d'un groupe de sécurité Active Directory. Pour cela, il faut que l'on commence à récupérer les membres de notre groupe "O365-Licence-E3" dans l'AD :

$Users = Get-ADGroupMember -Identity "O365-Licence-E3" | Foreach{ Get-ADUser -Identity $_.SamAccountName } | Select-Object UserPrincipalName

La commande ci-dessus récupère l'attribut UserPrincipalName car il s'agit de comptes synchronisés via Azure AD Connect donc il s'agit de l'attribut de référence pour l'identifiant du compte Office 365. Vous pouvez sélectionner un autre attribut, comme le champ "mail" par exemple.

Ensuite, il suffit de traiter chaque compte afin d'activer le MFA (en réutilisant l'objet déclaré précédemment) :

$Users | Set-MsolUser -StrongAuthenticationRequirements $MfaStatus

En résumé, voici les différentes lignes de commande PowerShell :

Connect-MsolService

$Mfa = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$Mfa.RelyingParty = "*"
$Mfa.State = "Enabled"
$MfaStatus = @($Mfa)

$Users = Get-ADGroupMember -Identity "O365-Licence-E3" | Foreach{ Get-ADUser -Identity $_.SamAccountName } | Select-Object UserPrincipalName
$USers | Set-MsolUser -StrongAuthenticationRequirements $MfaStatus

Nous pourrions imaginer le même type d'exemple avec un fichier CSV en entrée.

III. Désactiver le MFA avec PowerShell

Pour désactiver le MFA, il ne faut pas reprendre le bout de code précédent et remplacer "Enabled" par "Disabled" car cela ne fonctionnera pas. Par contre, si l'on initialise notre variable $MfaStatus sans lui attribuer la moindre propriété, cela va supprimer la configuration MFA sur l'utilisateur et donc désactiver le MFA.

Il suffira de faire :

$MfaStatus = @()

Puis, de mettre à jour le compte :

Set-MsolUser -UserPrincipalName [email protected] -StrongAuthenticationRequirements $MfaStatus

Si vous avez besoin de désactiver le MFA sur tous les comptes utilisateurs de votre tenant (ou de l'activer sur tous les comptes), je vous invite à utiliser le script fourni par Microsoft et disponible sur cette page (testé et approuvé !) :

The post Office 365 : activer le MFA avec PowerShell first appeared on IT-Connect.

Office 365 : obtenir le statut du MFA avec PowerShell

21 janvier 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à obtenir le statut du MFA (authentification forte) sur les comptes utilisateurs Office 365 avec PowerShell.

Précédemment, nous avons vu comment mettre en place le MFA sur Office 365 et comment l'activer sur les utilisateurs à partir de l'interface graphique.

Pour obtenir le statut du MFA sur les utilisateurs, c'est-à-dire pour savoir s'il est actif ou non et visualiser le second facteur actif, nous allons utiliser le module MSOnline. Même si ce module est plutôt en fin de vie, il reste d'actualité pour manipuler le MFA dans le sens où le module Microsoft Graph ne permet pas, à ce jour, de gérer le MFA. Enfin, en tout cas je n'ai pas trouvé la solution de mon côté...

II. Obtenir le statut du MFA avec PowerShell

Ouvrez une console Windows PowerShell et exécutez la commande ci-dessous pour établir une connexion à Office 365 (le module MSOnline doit être présent sur votre machine).

Connect-MsolService

Une fenêtre va s'ouvrir, authentifiez-vous. Pour obtenir le statut du MFA pour un utilisateur, il faut regarder la propriété "StrongAuthenticationMethods" de son compte via la commande Get-MsolUser.

On va commencer par stocker les informations dans une variable, en spécifiant l'identifiant de l'utilisateur :

$User = Get-MSolUser -UserPrincipalName [email protected]

Puis, nous allons pouvoir afficher l'état du MFA sur ce compte :

$User.StrongAuthenticationMethods

Si la commande ci-dessus ne retourne aucun résultat, c'est que le MFA est désactivé sur cet utilisateur ou qu'il est activé mais pas encore configuré (aucun second facteur actif).

Dans le cas où le MFA est actif et configuré, la liste des méthodes disponibles pour le second facteur s'affiche. La méthode par défaut est visible via la propriété "IsDefault" qui prend la valeur "True".

Exemple - Office 365 : StrongAuthenticationMethods
Exemple - Office 365 : StrongAuthenticationMethods

Sur l'image ci-dessus, on peut voir que le MFA est actif et configuré pour cet utilisateur et que le second facteur par défaut est "OneWaySMS", c'est-à-dire un code unique envoyé par SMS.

Pour éviter de le faire en deux temps, on peut sélectionner le nom d'affichage de l'utilisateur, son identifiant et créer une propriété calculée avec PowerShell, nommée MFAStatus, pour afficher directement le second facteur par défaut. Dans le cas où le MFA est désactivé sur l'utilisateur, on précisera "Disabled". Voici la commande complète :

Get-MsolUser -UserPrincipalName [email protected] | Select DisplayName,UserPrincipalName,@{N="MFAStatus"; E={ if( $_.StrongAuthenticationMethods.IsDefault -eq $true) {($_.StrongAuthenticationMethods | Where IsDefault -eq $True).MethodType} else { "Disabled"}}}

Dans le même esprit, on peut obtenir le statut du MFA pour tous les utilisateurs du tenant. Pour cela, il suffit de retirer le paramètre "-UserPrincipalName" de la commande Get-MsolUser et de préciser "-All" à la place.

Ce qui donne :

Get-MsolUser -All | Select DisplayName,UserPrincipalName,@{N="MFAStatus"; E={ if( $_.StrongAuthenticationMethods.IsDefault -eq $true) {($_.StrongAuthenticationMethods | Where IsDefault -eq $True).MethodType} else { "Disabled"}}}

Voici le résultat obtenu :

La méthode "PhoneAppNotification" visible sur l'image ci-dessus correspond à l'utilisation d'une application comme Microsoft Authenticator.

Si l'on souhaite obtenir le statut du MFA uniquement sur les comptes qui ont le rôle "Administrateur général", c'est possible aussi. Il faut commencer par récupérer la liste de ces comptes (en prenant uniquement ceux sous licence) :

$AdminUsers = Get-MsolRoleMember -RoleObjectId $(Get-MsolRole -RoleName "Company Administrator").ObjectId | Where-Object {$_.isLicensed -eq $true}

Il ne reste plus qu'à appliquer une boucle Foreach et réutiliser la commande étudiée précédemment pour obtenir le statut du MFA sur les comptes admins :

$AdminUsers | Foreach{ Get-MsolUser -UserPrincipalName $_.EmailAddress | select DisplayName,UserPrincipalName,@{N="MFA Status"; E={ if( $_.StrongAuthenticationMethods.IsDefault -eq $true) {($_.StrongAuthenticationMethods | Where IsDefault -eq $True).MethodType} else { "Disabled"}}}}

Avec ces quelques commandes PowerShell, vous êtes en mesure de vérifier le statut du MFA sur vos comptes Office 365 !

The post Office 365 : obtenir le statut du MFA avec PowerShell first appeared on IT-Connect.

PowerShell : comment se connecter à Microsoft Graph API ?

20 janvier 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment utiliser le module Microsoft Graph PowerShell pour s'authentifier sur son environnement Azure AD, Microsoft 365 ou Office 365.

À partir du 30 juin 2022, Microsoft ne supportera plus l'Active Directory Authentication Library (ADAL) et l'Azure Active Directory Graph API, deux composants utilisés pour s'authentifier sur Azure Active Directory. Autrement dit, ils permettent de s'authentifier sur Azure AD et Office 365 afin de réaliser toutes les opérations d'administration une fois la connexion établie, comme la création, la suppression et la modification de comptes sur Office 365. Les applications qui s'appuient sur ADAL ne pourront plus s'authentifier du tout, tandis que de façon générale il n'y aura plus de support et donc plus de mises à jour de sécurité.

Microsoft souhaite que les entreprises s'appuient sur le SDK Microsoft Graph qui permet de s'authentifier sur les services Cloud et les tenants Office 365 via Microsoft Graph API. Cette API est développée par Microsoft depuis plusieurs années et elle permet l'administration de l'ensemble des services Cloud, de façon un peu plus moderne.

Afin de préparer l'avenir, dans ce premier article je vais vous expliquer comment établir une connexion à Azure AD ou Office 365 via le module Microsoft Graph. Nous verrons les deux méthodes de connexion, ainsi que quelques astuces pour bien débuter avec ce module que moi-même je continue de découvrir.

II. PowerShell : l'avenir des modules AzureAD et MSOnline

Allons droit au but : si vous utilisez des scripts PowerShell qui s'appuient sur les modules AzureAD pour l'Azure Active Directory et MSOnline pour la partie Office 365, il va falloir mettre à jour ces scripts pour basculer sur Microsoft Graph. C'est indispensable, si vous ne souhaitez pas que vos scripts arrêtent de fonctionner à partir du 30 juin 2022.

À terme, ces deux modules vont être remplacés par Microsoft Graph, et le nom du module c'est "Microsoft.Graph" pour être précis. Puisque ce nouveau module est déjà disponible, cela vous permet de commencer ce travail de mise à jour de vos scripts et outils.

Toutes les commandes PowerShell vont évoluer puisque ce module contient son propre jeu de commandes. Par exemple, la commande New-MsolUser qui permet de créer un nouvel utilisateur Office 365 va être remplacée la commande New-MgUser.

Avant même de parler des commandes pour interagir avec les objets (utilisateurs, groupes, etc...) de votre tenant, il faut savoir que la connexion aux services va évoluer aussi. Oubliez les deux commandes Connect-AzureAD et Connect-MsolService disponible via les deux modules AzureAD et MSOnline. La connexion à votre environnement avec le module Microsoft Graph s'appuie sur Connect-MgGraph. D'ailleurs, cette nouvelle commande fonctionne différemment, comme nous allons voir dans la suite de ce tutoriel.

Pour le moment, nous avons encore plusieurs mois devant nous pour mettre à jour nos scripts PowerShell, donc il n'est pas nécessaire de paniquer. De mon côté, je vais travailler sur l'actualisation de mes articles PowerShell qui parlent Office 365 et Azure pour vous aider également.

II. Microsoft Graph : les deux modes de connexion

Lors de l'utilisation du module Microsoft Graph et du cmdlet Connect-MgGraph pour établir une connexion à votre tenant, vous avez le choix entre deux modes de connexion :

  • Une connexion avec un accès délégué

Avec le mode "accès délégué", il faut préciser les permissions dont vous avez besoin au moment de la connexion au tenant, et c'est en se connectant avec un compte qui a les droits que vous allez pouvoir créer cette délégation et permettre l'accès aux ressources.

  • Une connexion avec un accès application

Avec le mode "accès application", il est nécessaire d'inscrire une nouvelle application dans Azure Active Directory afin de créer un point de connexion. Ensuite, il faudra accorder des autorisations à cette application pour que les scripts qui l'utilisent soient en mesure d'effectuer les actions déclarées dans votre code PowerShell. Pour se connecter via cette méthode, il faudra spécifier plusieurs informations : ID du tenant, ID de l'application et un nom de certificat ou une empreinte de certificat (qu'il faudra générer en amont).

Il faut savoir qu'au-delà du mode de connexion, il y a deux points de terminaison disponibles côté Microsoft : Microsoft Graph v1.0 et Microsoft Graph Beta. Sans surprise, le point de terminaison permet de bénéficier des dernières fonctionnalités en avant-première.

Avant d'établir la connexion à Microsoft Graph, vous pouvez choisir le point de terminaison que vous souhaitez utiliser. Par défaut, Microsoft Graph v1.0 est utilisé.

Pour basculer sur le profil bêta, il faudra exécuter cette commande :

Select-MgProfile -Name "beta"

À l'inverse, pour sélectionner de nouveau la V1.0, il faudra exécuter :

Select-MgProfile -Name "v1.0"

Pour ce tutoriel, je vais utiliser Microsoft Graph v1.0 comme point de terminaison.

Il est temps de passer à la pratique, en commençant par l'installation du module.

III. Installer le module PowerShell Microsoft Graph

Le module Microsoft Graph est disponible sur la PowerShell Gallery (voir ici) et il s'installe avec la commande "Install-Module" comme les autres modules.

Si vous souhaitez l'installer uniquement pour l'utilisateur en cours, utilisez le scope "CurrentUser" et pour l'installer au niveau de la machine précisez "AllUsers" (droits administrateur requis).

Ce qui donne :

Install-Module Microsoft.Graph -Scope CurrentUser
Install-Module Microsoft.Graph -Scope AllUsers
Install-Module Microsoft.Graph
Install-Module Microsoft.Graph

L'installation de ce module global prend généralement plusieurs minutes car il installe tous les sous-modules. Une fois que c'est fait, vous pouvez vérifier avec cette commande que le module est installé :

Get-InstalledModule Microsoft.Graph
Get-InstalledModule Microsoft.Graph
Get-InstalledModule Microsoft.Graph

Pour ma part et à titre indicatif, c'est la version 1.9.1 qui est installée (dernière en date).

IV. PowerShell : Microsoft Graph via l'accès délégué

Commençons par étudier le principe de connexion via l'accès délégué, à partir de la commande Connect-MgGraph. Je vous rappelle que cette commande sert à établir une connexion à Microsoft Graph via PowerShell.

Lors de la connexion à Microsoft Graph, il faut spécifier un ou plusieurs scopes (étendues) en fonction de ce que vous cherchez à effectuer. Afin de pouvoir utiliser les étendues sélectionnées, une délégation d'accès sera créée au moment de la connexion.

Par exemple, si l'on souhaite récupérer la liste des utilisateurs de notre tenant, on a besoin d'un accès en lecture aux utilisateurs. Cela se traduit par le nom d'étendue suivant :

User.Read.All

Dans le cas où l'on aurait besoin de créer un nouvel utilisateur, l'étendue serait différente puisqu'il faudrait des droits d'écriture. L'étendue à utiliser serait :

User.ReadWrite.All

Je vais vous donner quelques astuces par la suite pour identifier les étendues. Il faut savoir que l'on peut sélectionner plusieurs étendues, et que ce n'est pas anormal d'en sélectionner entre 5 et 10.

Continuons sur l'idée suivante : récupérer la liste des utilisateurs, à partir de l'étendue "User.Read.All". La commande Connect-MgGraph à exécuter sera :

Connect-MgGraph -Scopes "User.Read.All"

Cette commande va ouvrir un navigateur sur votre machine afin d'effectuer la connexion et d'accorder l'accès à l'application "Microsoft Graph PowerShell". Cela nécessite un accès avec des droits administrateur. Il faudra accepter la requête, comme sur l'exemple ci-dessous.

Connexion à Microsoft Graph via PowerShell
Connexion à Microsoft Graph via PowerShell

Ensuite, un message s'affiche pour indiquer que la fenêtre peut être fermée : Authentication complete. You can return to the application. Feel free to close this browser tab.

Retour dans la console PowerShell. Un message "Welcome To Microsoft Graph!" doit être visible !

Pour lister les utilisateurs, on va tout simplement utiliser cette commande :

Get-MgUser

Comme le montre l'image ci-dessous, la liste des utilisateurs est retournée. Parfait !

Get-MgUser
Exemple - Get-MgUser

Si l'on essaie de lister les groupes, on peut voir que l'on obtient un message d'erreur : Insufficient privileges to complete the operation. En bref, nous n'avons pas les droits, ce qui est normal puisque l'on a pas précisé l'étendue qui permet de lire les groupes au moment de la connexion !

Get-MgGroup
Microsoft Graph - PowerShell : exemple de privilèges insuffisants
Microsoft Graph - PowerShell : exemple de privilèges insuffisants

Dans la console PowerShell en cours, on peut exécuter une seconde fois Connect-MgGraph pour ajouter l'étendue "Group.Read.All" qui permettra de lire les informations des groupes.

Connect-MgGraph -Scopes "Group.Read.All"

Cela va venir s'ajouter à la session déjà ouverte et donc conserver l'étendue "User.Read.All". Suite à l'exécution de cette commande, il faut de nouveau approuver la connexion via le navigateur. Désormais, on peut récupérer la liste des groupes.

La prochaine fois, vous pouvez appeler directement les deux étendues :

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All"

Du fait que cette méthode nécessite une interaction et une validation via le navigateur, elle n'est pas faite pour être utilisée dans des scripts. La seconde méthode que nous allons voir dès maintenant sera plus adaptée.

Juste avant cela, on va se déconnecter proprement de Microsoft Graph :

Disconnect-MgGraph

V. PowerShell : Microsoft Graph via l'accès application

Nous devons inscrire une nouvelle application au sein d'Azure Active Directory, puis ensuite lui accorder des autorisations. Cette application sera notre point d'entrée avec PowerShell.

À partir du portail Azure, dans Azure Active Directory, cliquez sur "Inscriptions d'applications" à gauche puis sur le bouton "Nouvelle inscription".

Azure AD : inscription d'une nouvelle application
Azure AD : inscription d'une nouvelle application

Donnez un nom à cette application, par exemple "Script-PowerShell-Graph". Conserver l'option "Comptes dans cet annuaire d'organisation uniquement" pour l'option "Types de comptes pris en charge" et pour l'URI de redirection, laissez vide.

Cliquez sur le bouton "S'inscrire".

L'application est inscrite. Il y a deux informations qu'il faudra récupérer par la suite, car nous en aurons besoin lors de la connexion avec PowerShell : ID d'applications (client) et ID de l'annuaire (locataire).

Désormais, nous devons accorder des autorisations à notre application.

B. Attribuer des autorisations Microsoft Graph à l'application

Toujours sur le portail Azure, au sein de notre application, cliquez sur "API autorisées" à gauche puis au centre sur "Ajouter une autorisation".

Ajouter des autorisations Microsoft Graph API à l'application
Ajouter des autorisations Microsoft Graph API à l'application

Nous souhaitons ajouter une autorisation "Microsoft Graph" et cela tombe bien c'est proposé directement.

Cliquez sur "Autorisations de l'application".

Ensuite, il faut rechercher les autorisations. Cela fonctionne sur le même principe que les étendues de la première méthode de connexion étudiée. Pour trouver l'autorisation qui permet de consulter la liste des groupes, il suffit de rechercher "group" et de cocher l'option "Group.Read.All". Pour les utilisateurs, suivez le même principe.

Cliquez sur "Ajouter des autorisations" pour ajouter toutes les autorisations sélectionnées.

Il faut que l'on accorde un consentement administration au niveau de l'organisation pour pouvoir bénéficier de ces droits dans notre application, à savoir notre script PowerShell. Cliquez sur le bouton "Accorder un consentement d'administrateur pour IT-Connect" et validez.

Tous les feux sont au vert :

Passons à la troisième étape : la gestion du certificat.

C. Générer un certificat auto-signé avec PowerShell

Nous allons créer un certificat auto-signé puis l'exporter au format CER puis PFX.

Le format PFX est intéressant pour transférer le certificat et sa clé privée sur un autre serveur : une étape indispensable si vous souhaitez vous authentifier auprès de votre application depuis plusieurs serveurs différents. Le certificat (et sa clé privée) devra être déployé sur chaque machine devant se connecter à l'application.

Grâce à la commande ci-dessous, nous allons créer un certificat auto-signé et le stocker dans le magasin de certificat personnel local. Remplacez seulement "IT-Connect" par le nom de votre organisation.

$cert = New-SelfSignedCertificate -Subject "CN=IT-Connect" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256

Ensuite, il faut exporter ce certificat sur notre machine, car il va falloir le charger sur Azure AD. En PowerShell toujours, c'est faisable avec la commande "Export-Certificate". Pour ma part, je l'exporte dans "C:\TEMP" mais adaptez le chemin dans la commande ci-dessous.

Export-Certificate -Cert $cert -FilePath "C:\TEMP\IT-Connect.cer"
Exporter un certificat avec PowerShell
Exporter un certificat avec PowerShell

Si vous avez besoin d'utiliser ce certificat sur d'autres serveurs (ce qui sera le cas si un autre serveur doit s'authentifier sur Microsoft Graph via PowerShell), vous devez l'exporter au format PFX. Si vous n'avez pas ce besoin, vous pouvez ignorer les deux commandes qui suivent.

Commençons par créer un mot de passe pour la clé privée associée à notre certificat :

$mdp = ConvertTo-SecureString -String "MotDePasse" -Force -AsPlainText

Ensuite, on exporte au format PFX avec Export-PfxCertificate en précisant le certificat via $cert, le mot de passe via $mdp et le chemin vers le fichier de sortie au format PFX.

Export-PfxCertificate -Cert $cert -FilePath "C:\temp\IT-Connect.pfx" -Password $mdp

Une fois que c'est fait, il suffira de copier le PFX sur les autres serveurs et de l'importer. Pensez à stocker le mot de passe de la clé privée dans votre gestionnaire de mots de passe préféré...

Retournez sur l'interface Azure AD, toujours dans notre application, et cliquez sur "Certificats & secrets" sur la gauche. Ensuite, cliquez sur "Télécharger le certificat" et chargez le fichier CER. Validez et il va apparaître dans la liste des certificats comme ceci :

Copiez la valeur "Empreinte numérique" (Thumbprint), car nous allons en avoir besoin pour la suite.

D. Connexion à Microsoft Graph avec le certificat

Voilà, la configuration est prête : nous allons pouvoir nous connecter à Microsoft Graph via PowerShell. Pour cela, il nous faut trois informations :

  • L'ID d'applications (client) pour le paramètre -ClientID
  • L'ID de l'annuaire (locataire) pour le paramètre -TenantId
  • L'empreinte numérique du certificat pour le paramètre -CertificateThumbprint

Ce qui donne la commande Connect-MgGraph suivante :

Connect-MgGraph -ClientID a8615473-xxxx-yyyy-zzzz-123456789123 -TenantId 806d3d28-aaaa-bbbb-cccc-123456789123 -CertificateThumbprint A3FA9DEE117D49EC8F2A1CFF4567FABC3

Exécutez cette commande, et là, c'est magique on est directement authentifié ! Aucune action n’est nécessaire, c'est la combinaison de ces trois valeurs (et la présence du certificat sur la machine) qui permet de s'authentifier sur Microsoft Graph.

En termes de droits, on est limité à ce qui est déterminé au niveau des autorisations de l'application. Si l'on ajoute des droits à notre application via le portail Azure, il faudra se déconnecter et se reconnecter pour que ce soit pris en compte.

Disconnect-MgGraph
Connect-MgGraph -ClientID a8615473-xxxx-yyyy-zzzz-123456789123 -TenantId 806d3d28-aaaa-bbbb-cccc-123456789123 -CertificateThumbprint A3FA9DEE117D49EC8F2A1CFF4567FABC3

Il ne reste plus qu'à interagir avec notre environnement Microsoft ! Cette méthode d'authentification est idéale pour vos scripts PowerShell.

VI. Microsoft Graph : comment identifier les permissions ?

Sur le principe, Microsoft Graph est prometteur notamment sur la gestion très fine des permissions, mais cela peut rapidement devenir un casse-tête pour trouver les bonnes permissions. Je crois que chez Microsoft ils en ont conscience, car il y a un cmdlet qui permet de rechercher plus facilement des permissions : Find-MgGraphPermission.

Si l'on souhaite obtenir toutes les permissions Microsoft Graph relatives à Microsoft Teams, on pourra exécuter la requête suivante (cela ne nécessite pas d'être authentifié auprès de Microsoft Graph).

Find-MgGraphPermission teams

Vous allez voir que cette commande retourne deux sections : Delegated pour l'accès délégué et Application pour l'accès application. En fonction de ce que vous recherchez, précisez le type de permissions, car le nom peut varier :

Find-MgGraphPermission teams -PermissionType Delegated

ou

Find-MgGraphPermission teams -PermissionType Application

Grâce à la sortie de cette commande et le filtre, on peut trouver plus facilement le nom des permissions. Pour les groupes, les utilisateurs, etc... On peut rechercher.

Find-MgGraphPermission groups
Find-MgGraphPermission user

En complément, vous pouvez retrouver des informations sur cette page qui référence l'ensemble des permissions (un CTRL+F sera inévitable pour rechercher dans la page) :

Les permissions c'est une chose, mais ensuite il faut trouver la bonne commande, ou en tout cas la commande de remplacement vis-à-vis de ce que l'on connait avec les modules MSOnline et AzureAD. Pour cela, on peut s'aider de Get-Command avec un filtre sur un mot clé. Par exemple :

Get-Command -Module Microsoft.Graph* *team*

À vous de jouer ! Pour ma part, cet article d'introduction me servira de point de départ pour les prochains d'articles qui parleront de cas particuliers : création d'utilisateurs, manipulation d'équipes Teams, de boites aux lettres, etc... N'hésitez pas à partager votre retour d'expérience avec Microsoft Graph en postant un commentaire.

The post PowerShell : comment se connecter à Microsoft Graph API ? first appeared on IT-Connect.

Sauvegarde Office 365 avec un NAS Synology

18 janvier 2022 à 16:00

I. Présentation

Si vous avez un NAS Synology, de l'espace disque inutilisé, et un tenant Office 365 / Microsoft 365, alors ce tutoriel devrait vous intéresser. En effet, nous allons voir comment utiliser un NAS Synology pour sauvegarder les données Office 365 à l'aide du paquet gratuit Active Backup for Microsoft 365.

Lorsque l'on utilise Office 365 pour son entreprise ou son établissement scolaire, c'est un peu risqué de compter uniquement sur Microsoft pour la sauvegarde des données. Vous allez me dire, pourquoi ? Et bien, Microsoft sauvegarde bien vos données (et le stockage est redondé), ce n'est pas le problème, mais la période de conservation par défaut est de seulement 30 jours. Par exemple, lorsqu'un fichier est supprimé de OneDrive, il est récupérable pendant 30 jours suite à sa suppression.

Pour mettre en place une véritable politique de sauvegardes de ses données stockées dans le Cloud Microsoft, soit vers un autre Cloud ou vers son infrastructure on-premise, on peut s'appuyer sur différents outils disponibles sur le marché.

Pour en citer quelques-uns : Veeam Backup for Microsoft 365, AvePoint Microsoft 365 Backup, ou encore Acronis Cyber Backup. Ce qui peut différencier ces solutions, c'est leur capacité à sauvegarder les différents éléments, notamment au sein des équipes Teams qui contiennent énormément d'informations.

Aujourd'hui, je vais vous parler d'Active Backup for Microsoft 365, disponible gratuitement sur les NAS Synology et qui va permettre de sauvegarder un bon nombre d'éléments. En effet, vous pouvez sauvegarder les boîtes aux lettres, les contacts, les calendriers, ainsi que les espaces de stockage OneDrive et SharePoint. Puisque Teams stockent ses fichiers dans des sites SharePoint, ces données peuvent être sauvegardées avec cet outil.

Note : la solution proposée par Synology prend en charge les différents plans de licences, aussi bien Business, Enterprise que Education.

La présentation étant faite, nous allons pouvoir passer à la partie pratique. Je pars du principe que vous disposez déjà d'un tenant Office 365 et que votre NAS Synology est déjà en place avec un partage (qui sera utilisé pour stocker les sauvegardes). Mon NAS Synology tourne sous DSM 7 (mais ce paquet existe sur les versions précédentes).

Si vous avez besoin d'aide pour créer votre tenant Office 365, vous pouvez suivre ce tutoriel :

II. Installation d'Active Backup for Microsoft 365

La première étape consiste à installer le paquet "Active Backup for Microsoft 365" à partir du Centre de paquets de DSM. Il suffit de rechercher le paquet et de cliquer sur le bouton "Installer".

Installation du paquet Active Backup for Microsoft 365
Installation du paquet Active Backup for Microsoft 365

Un assistant va s'exécuter. Il est nécessaire d'activer le paquet à l'aide d'un compte Synology (gratuit) alors cliquez sur le bouton "Activer".

Acceptez la "Déclaration de confidentialité" et connectez-vous avec votre compte Synology, ou créez un compte le cas échéant. Lors de la création du compte, un code de sécurité est envoyé sur l'adresse e-mail renseignée.

Après s'être connecté avec un compte Synology, le paquet est activé. C'est tout bon.

Passons à la seconde étape, qui est de loin la plus technique : l'inscription de l'application Azure pour Active Backup.

III. Inscrire l'application Azure pour Synology

L'inscription d'une nouvelle application au sein d'Azure peut être effectuée à partir du portail d'administration d'Azure, à coup de clics. Pour simplifier l'inscription de l'application conformément aux prérequis de Synology, notamment pour attribuer les bonnes autorisations, le fabricant fournit un script PowerShell nommé "AppGenerator.ps1".

Commencez par télécharger le script via ce lien officiel : AppGenerator.ps1

Ce script est clean et il va réaliser différentes actions, notamment l'inscription d'une application, l'ajout des autorisations et la génération d'un certificat pour l'authentification.

Note : si le module AzureAD n'est pas présent sur votre machine, le script va l'installer.

Ouvrez une console Windows PowerShell en tant qu'administrateur. Commencez par définir la politique d'exécution PowerShell sur "RemoteSigned" uniquement pour le processus en cours (cette console). Ce script est signé par Synology.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

Ensuite, déplacez-vous dans le dossier où se situe le script AppGenerator.ps1 que vous venez de télécharger. Pour ma part, c'est dans le dossier "C:\TEMP".

cd C:\TEMP\

Enfin, il ne reste plus qu'à exécuter le script :

.\AppGenerator.ps1

Confirmez que vous souhaitez exécuter le script signé par Synology Inc en précisant "O" puis Entrée.

Exécution du script AppGenerator.ps1 de Synology
Exécution du script AppGenerator.ps1 de Synology

Au début de l'exécution du script, le message "Before generating your Azure AD application, please enter a password you wish to use to protect the certificate" s'affiche. Vous devez préciser un mot de passe qui va servir à protéger le certificat (pour la clé privée).

Ensuite, il faut s'authentifier auprès de votre environnement Office 365 avec un compte administrateur afin que le script puisse inscrire l'application.

À la fin, le message "Congratulations! Your Azure application has been successfully generated" s'affiche : tout s'est bien passé. Il faut noter les valeurs de "Tenant ID" et "Application ID" car nous en aurons besoin dans un second temps. Le certificat au format PFX est disponible dans le répertoire courant du script.

Remarque : ces valeurs sont récupérables à tout moment à partir du portail Azure.

Script AppGenerator de Synology pour la sauvegarde Office 365
Script AppGenerator de Synology pour la sauvegarde Office 365

Au sein du portail Azure AD, si vous allez dans "Azure Active Directory" puis "Inscriptions d'applications", vous pouvez retrouver l'application "Microsoft 365 Backup" correspondante à Active Backup. Pour gagner du temps, vous pouvez cliquer sur le lien qui s'affiche en jaune dans la console PowerShell (voir ci-dessus).

Dans la section "API autorisés", cliquez sur le bouton "Accorder un consentement d'administrateur pour IT-Connect" et validez pour approuver les autorisations.

Application "Microsoft 365 Backup" générée par Synology
Application "Microsoft 365 Backup" générée par Synology

Suite à cette action, tous les voyants passent au vert au niveau de la colonne "Statut", comme ceci :

L'application est prête ! Nous allons pouvoir sauvegarder les données de notre tenant Office 365 !

IV. Sauvegarder les données Office 365 sur le NAS Synology

La suite du tutoriel va se dérouler via DSM et l'application Active Backup for Microsoft 365. Démarrez l'assistant de création de tâche s'il ne se lance pas tout seul... Et sélectionnez "Créer une nouvelle tâche de sauvegarde".

Active Backup for Microsoft 365 - Créer une nouvelle tâche de sauvegarde
Active Backup for Microsoft 365 - Créer une nouvelle tâche de sauvegarde

La première étape consiste à indiquer les informations liées à l'application inscrite dans Azure AD afin d'établir la communication avec votre tenant. Voici comment remplir les champs :

  • Point de terminaison Microsoft 365 : choisissez "Microsoft 365"
  • Adresse e-mail de l'admin du domaine : indiquez l'adresse e-mail du compte administrateur
  • ID du locataire : l'ID de votre tenant, correspondant à la valeur "Tenant ID" récupérée à la fin du script
  • ID de l'application : l'ID de votre application, correspondant à la valeur "Application ID" récupérée à la fin du script
  • Fichier du certificat : cliquez sur "Charger" afin de sélectionner le certificat au format PFX généré par le script
  • Mot de passe du certificat : précisez le mot de passe de la clé privée du certificat, c'est-à-dire le mot de passe spécifié précédemment lors de l'exécution du script

Cliquez sur "Suivant".

Ensuite, d'autres champs sont à renseigner :

  • Nom de la tâche : nommez cette tâche, tout simplement, pour ma part ce sera "Tenant-IT-Connect.tech"
  • Destination de la sauvegarde : vous devez sélectionner le partage dans lequel seront stockées les sauvegardes Office 365
  • Liste des sauvegardes : en cliquant sur le bouton "Modifier", vous pouvez choisir les éléments à sauvegarder pour chaque compte Office 365

Enfin, l'option "Activer Active Backup for Microsoft 365 Portal" permet d'ouvrir le portail de restauration des données à vos utilisateurs. Les droits d'accès à ce portail sont à gérer dans un second temps. Pour ma part, je n'active pas ce portail.

Note : à partir du "Panneau de configuration" puis "Privilèges d'application", vous pouvez attribuer des droits au portail Active Backup à tout moment.

En cliquant sur le bouton "Modifier", vous pouvez sélectionner ce que vous souhaitez sauvegarder ou non. Sur l'image ci-dessous, la colonne "Disque" correspond à l'espace OneDrive de l'utilisateur. Pour le reste, c'est explicite.

Vous pouvez naviguer entre les utilisateurs, les groupes et les sites (SharePoint et donc aussi les équipes Teams) en cliquant sur les trois liens en haut à gauche. Lorsque la sélection est effectuée, cliquez sur "OK".

Active Backup for Microsoft 365 : choix des éléments à sauvegarder
Active Backup for Microsoft 365 : choix des éléments à sauvegarder

Poursuivez... voici l'étape "Activer les services de découverte automatique". En fait, cela permet de choisir ce qu'il faudra sauvegarder pour tous les nouveaux utilisateurs, groupes et sites créés par la suite. De cette façon, les nouveaux objets seront ajoutés à la tâche de sauvegarde automatiquement selon cette configuration.

Désormais, il faut planifier la sauvegarde. Lorsque l'option "Sauvegarde continue" est choisie, l'application "surveille" continuellement l'activité de vos utilisateurs afin de sauvegarder les nouveaux fichiers ou les fichiers modifiés. L'option "Sauvegarde manuelle" nécessite que la sauvegarde soit déclenchée manuellement à partir de l'interface DSM, tandis que l'option "Sauvegarde programmée" permet de planifier la sauvegarde : une seule fois, tous les week-ends, un jour sur deux, tous les lundis, tous les jours, etc... En fonction de ce que vous souhaitez, à une heure spécifique.

Active Backup for Microsoft 365 : planifier la sauvegarde
Active Backup for Microsoft 365 : planifier la sauvegarde

Quant à la conversation des versions de fichiers, soit vous pouvez conserver toutes les versions (attention à l'espace disque...), soit vous pouvez déterminer le nombre de jours pendant laquelle une version précédente est conservée. Je vous invite à lire l'explication ci-dessous pour bien comprendre ce principe qui s'applique sur chaque fichier.

Cliquez sur "Suivant" lorsque vous avez fait votre choix. Le récapitulatif s'affiche, cliquez sur "Effectué". L'application vous demande si vous souhaitez exécuter la sauvegarde dès maintenant, ou attendre la prochaine planification.

Je tiens à préciser que vous pouvez revenir sur votre configuration à tout moment pour apporter des modifications à la tâche. Il suffit de sélectionner la tâche puis de cliquer sur "Modifier".

Lorsque la tâche est en cours, vous pouvez suivre la progression depuis l'interface Active Backup for Microsoft 365.

La vue d'ensemble fait office de tableau de bord et elle ne devrait pas dépayser les personnes habituées à utiliser les applications de la suite Active Backup. Vous pouvez visualiser le nombre de comptes protégés par service (Disque, Courrier, etc.), ainsi que l'espace disque utilisé par service et par utilisateur.

Tableau de bord Active Backup for Microsoft 365
Tableau de bord Active Backup for Microsoft 365

Maintenant, si l'on bascule sur l'explorateur de fichiers de DSM, c'est-à-dire "File Station", on peut regarder à quoi ressemblent les données sauvegardées.

Les données sauvegardées sont stockées à la racine du partage dans un dossier nommé "ActiveBackupForMicrosoft365" avec un sous-dossier par tâche. Certains éléments ne sont pas visibles directement, notamment les e-mails, par contre les fichiers sont consultables en parcourant l'arborescence de la sauvegarde.

Voici un exemple des données sauvegardées à partir de l'onglet "Fichiers" du canal "Général" de l'équipe Teams "Redacteurs" de mon tenant.

Aperçu des données sauvegardées avec Active Backup for Microsoft 365
Aperçu des données sauvegardées avec Active Backup for Microsoft 365

À partir de l'application "Active Backup for Microsoft 365" vous pouvez créer d'autres tâches de sauvegarde, mais aussi accéder au "Journal" afin de garder un oeil sur les actions réalisées (tâche créée, sauvegarde effectuée, données restaurées, etc.), sous la forme d'un log.

V. Restaurer les données avec Active Backup for Microsoft 365

Pour finir ce tutoriel, je vais vous parler de la restauration des données à partir d'Active Backup for Microsoft 365. Pour cela, il faut utiliser l'icône nommée "Active Backup for Microsoft 365 Portal" : un nouvel onglet va s'ouvrir.

En tant qu'administrateur du NAS, on peut accéder à toutes les données sauvegardées. Pour naviguer entre les comptes utilisateurs, les tâches (si vous en avez plusieurs) et les types de contenu, il faut utiliser les boutons en haut à droite. Par exemple, en cliquant sur "Rôle de l'affichage", vous allez pouvoir choisir le compte afin de voir les données sauvegardées pour ce compte.

Si l'on prend l'exemple d'un fichier que l'on souhaite restaurer, il suffit de le sélectionner et de cliquer sur "Restaurer".

Restauration d'un fichier OneDrive avec Active Backup for Microsoft 365
Restauration d'un fichier OneDrive avec Active Backup for Microsoft 365

Le fichier sera restauré au sein du OneDrive de l'utilisateur dans un dossier nommé "Restore_<date>_<heure>" (ou à l'emplacement d'origine selon le choix effectué au moment de restaurer).

Maintenant, si l'on souhaite restaurer un autre élément, par exemple un e-mail, il faut changer de type de contenu, car par défaut, ce sont les fichiers qui sont sélectionnés. Il faut cliquer sur le bouton avec 4 carrés en haut à droite, puis choisir "Courrier".

Ensuite, l'e-mail à restaurer doit être sélectionné et la restauration pourra être lancée, sur le même principe que pour un fichier. Pour l'e-mail, vous pouvez décider d'effectuer la restauration dans le dossier d'origine, en écrasant l'e-mail s'il existe ou en ignorant en cas de conflit, sinon il est possible de restaurer dans un dossier spécifique à la restauration. Ce dossier sera créé automatiquement et visible par l'utilisateur via Outlook ou tout autre client de messagerie. Il portera le nom "Restore_Inbox_<date>_<heure>". Cette option est pratique si vous avez besoin de restaurer de nombreux e-mails, cela permettra à l'utilisateur de récupérer ce dont il a besoin à partir des éléments restaurés.

Restauration d'un e-mail avec Active Backup for Microsoft 365
Restauration d'un e-mail avec Active Backup for Microsoft 365

Voilà, vous savez désormais installer et configurer Active Backup for Microsoft 365 sur votre NAS Synology pour protéger les données de votre tenant Office 365 !

The post Sauvegarde Office 365 avec un NAS Synology first appeared on IT-Connect.

Comment mettre en place le MFA sur Office 365 ?

17 janvier 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place l'authentification multifacteur (MFA) au sein d'Office 365. Les informations de cet article pourront vous aider également si vous utilisez Azure AD sans Office 365.

Je vais commencer par quelques rappels sur l'authentification multifacteur et les licences nécessaires (ou non), avant de parler de la mise en œuvre technique du MFA avec Office 365.

II. Rappel sur l'authentification multifacteur

Lorsqu'un utilisateur se connecte à un compte, que ce soit sur Office 365 ou un autre site, et bien il doit saisir son mot de passe personnel afin de s'authentifier. Grâce à l'authentification multifacteur, l'utilisateur devra définir une seconde méthode d'authentification afin de se connecter à son compte : le mot de passe seul ne suffira plus. Par exemple, l'utilisateur devra saisir son mot de passe puis un code reçu par SMS (en guise de second facteur d'authentification).

Même si l'on parle d'un avenir sans mot de passe, il est fortement recommandé de mettre en place l'authentification multifacteur afin de renforcer la sécurité des accès.

Pour utiliser l'authentification multifacteur, il faut :

  • Un élément que vous connaissez : votre mot de passe
  • Un élément unique que vous possédez : votre numéro de téléphone portable pour recevoir un code par SMS, une application d'authentification, une clé de sécurité (celles de chez Yubico sont assez populaires !) ou un jeton matériel
  • Un élément biométrique que vous possédez : l'empreinte digitale ou la reconnaissance faciale

Vous l'aurez compris, il faudra utiliser la combinaison de votre mot de passe et de l'un des facteurs évoqués ci-dessus. Parmi les méthodes d'authentification disponibles chez Microsoft, vous avez plusieurs choix possibles :

  • L'application d'authentification Microsoft Authenticator (ou équivalent) pour générer des codes à usage unique
  • Le numéro de téléphone afin de recevoir un code à usage unique par SMS
  • Le numéro de téléphone afin de recevoir un appel téléphonique automatique pour confirmer l'authentification via l'appui sur une touche spécifique
  • La clé de sécurité (ou le jeton matériel) qui doit être connecté sur votre poste afin de valider l'authentification

III. Office 365 : faut-il une licence pour le MFA ?

Sur le Cloud Microsoft, de nombreuses fonctionnalités sont soumises à l'utilisation d'une licence spécifique. Dans certains cas, les licences additionnelles permettent de débloquer des options supplémentaires. En fait, c'est le cas du MFA puisque c'est une fonctionnalité gratuite, mais avec des options limitées.

Pour bénéficier de fonctionnalités ou de plus de méthodes d'authentification, il faut recourir à des licences spécifiques. Avec Office 365, on est plutôt bien servi, ce qui n'est pas forcément le cas pour une utilisation d'Azure AD sans Office 365.

Sur son site, Microsoft propose un tableau de synthèse qui permet d'y voir plus clair à ce sujet, voici le lien : Microsoft Docs - Licensing MFA

Office 365 : licensing MFA
Office 365 : licensing MFA

Sur un tenant Office 365, l'utilisation d'une licence Azure AD Premium P1 ou P2 permettra d'accéder à des fonctionnalités supplémentaires, comme les rapports d'utilisation du MFA. Cette licence doit être attribuée aux utilisateurs en plus de leur licence Office 365, ce qui va forcément ajouter des coûts supplémentaires. En fait, tout dépend des fonctionnalités dont vous avez besoin. Malgré tout, je tiens à (re)préciser que le MFA en lui-même est inclus de base avec les licences Office 365.

Note : la licence Azure AD Premium P1 intègre d'autres fonctionnalités intéressantes comme le portail de réinitialisation du mot de passe en libre-service.

Au sein d'Office 365, l'authentification multifacteur s'applique à toutes les applications Office 365. Par exemple, cela s'applique au portail Office 365, à la connexion via le client OneDrive ou encore au sein d'Outlook. Par contre, l'authentification sur un poste Windows avec un compte Office 365 ne sera pas protégée par le MFA.

Passons maintenant à la mise en œuvre du MFA.

IV. MFA et les options de sécurité par défaut

Dans la documentation de Microsoft, on peut lire : "Si votre locataire (tenant) a été créé le 22 octobre 2019 ou à une date ultérieure, il est possible que les paramètres de sécurité par défaut soient activés dans votre locataire.". Avec les paramètres de sécurité par défaut, le MFA est automatiquement activé sur l'ensemble des utilisateurs. Lors de la mise en route d'un tenant Office 365, il est courant de désactiver cette option... Je vous invite à vérifier l'état de cette option via le portail Microsoft Azure.

Sur ce portail, accédez à Azure Active Directory et cliquez sur "Propriétés" dans le menu à gauche.

Ensuite, descendez dans la page, tout en bas, afin de trouver le lien "Gérer les paramètres de sécurité par défaut". Cliquez sur le lien, un panneau latéral va s'ouvrir et vous allez voir l'état de l'option "Activer les paramètres de sécurité par défaut". Afin de réaliser un déploiement progressif du MFA auprès de vos utilisateurs, cette option doit être désactivée sinon vous n'avez pas le contrôle.

Paramètres de sécurité par défaut : MFA
Paramètres de sécurité par défaut : MFA

Par exemple, lorsque cette option est activée, un message s'affiche à la connexion "Microsoft a activé les paramètres de sécurité par défaut pour garantir la sécurité de votre compte.".

Nous allons voir comment gérer le MFA au niveau des utilisateurs Office 365.

V. Configurer le MFA sur Office 365

Cette fois-ci, rendez-vous sur le portail Office 365 (ou voir ci-dessous la seconde copie d'écran). Sous le menu "Utilisateurs", cliquez sur "Utilisateurs actifs" et une fois que la page est chargée, cliquez sur le bouton "Authentification multifacteur". Un nouvel onglet dédié au MFA va s'ouvrir.

Accès à la configuration du MFA via Office 365
Accès à la configuration du MFA via Office 365

Ce menu est également accessible à partir du portail Azure. Pour cela, au sein d'Azure Active Directory, cliquez sur "Utilisateurs" puis "Tous les utilisateurs". Sur la droite, un bouton "MFA par utilisateur" sera proposé dans le même esprit que sur l'interface Office 365.

Accès à la configuration du MFA via Azure AD
Accès à la configuration du MFA via Azure AD

Avant d'activer le MFA sur un ou plusieurs utilisateurs, nous allons regarder les paramètres. Pour cela, cliquez sur l'onglet "Paramètres du service". J'attire votre attention sur plusieurs paramètres :

  • Mots de passe application : je vous recommande de désactiver cette option afin d'empêcher la génération de mots de passe d'application, car cela permet de contourner le MFA. Attention tout de même, si vous avez besoin de vous authentifier sur des appareils spécifiques ou des applications qui ne prennent pas en charge le MFA, vous êtes contraint de laisser l'option activée.
  • Mémoriser multi-factor authentication sur un appareil approuvé : dans un monde idéal, il faudrait que l'utilisateur se réauthentifie avec son mot de passe et son second facteur à chaque fois. À l'usage, c'est différent et cela risque d'être contraignant pour les utilisateurs surtout s'il s'agit du poste qu'un utilisateur utilise tous les jours... En activant cette option, vous pouvez autoriser l'ajout du poste dans la liste de confiance de l'utilisateur pour une durée spécifique (modifiable et par défaut de 90 jours). Ainsi, il pourra se connecter uniquement avec son mot de passe pendant X jours sur ce poste.

Configuration de l'authentification multifacteurs dans Office 365
Configuration de l'authentification multifacteur dans Office 365

Ces paramètres sont modifiables ultérieurement. Une fois votre choix effectué, cliquez sur "Enregistrer".

Basculez sur l'onglet "Utilisateurs", car c'est à cet endroit que vous allez pouvoir activer ou désactiver le MFA sur un ou plusieurs utilisateurs.

Plusieurs options sont possibles pour gérer le MFA :

En sélectionnant les utilisateurs dans la liste et en cliquant sur "Activer" à droite, comme sur l'exemple ci-dessous avec un seul compte.

Activer le MFA sur un utilisateur dans Office 365
Activer le MFA sur un utilisateur dans Office 365

Une fenêtre de confirmation va apparaître où il sera nécessaire de cliquer sur "Activer multi-factor authentication". Le lien "https://aka.ms/MFASetup" permet aux utilisateurs d'enregistrer leurs facteurs additionnels, mais de toute façon ce sera proposé à la prochaine connexion Web.

Le MFA va être activé uniquement sur l'utilisateur que j'ai sélectionné, en complément de ceux où le MFA est potentiellement déjà actif. Pour avoir ce contrôle par utilisateur, je vous rappelle qu'il faut désactiver les options de sécurité par défaut.

Pour éviter de le faire en mode graphique avec des cases à cocher, vous pouvez utiliser le mode "Bulk" qui s'appuie sur un CSV. Pour cela, il faut cliquer sur le bouton "Mettre à jour en bloc" et télécharger un modèle de CSV qu'il faudra ensuite charger. Ce fichier est assez simple, il suffit d'indiquer deux champs : le nom d'utilisateur et le statut souhaité pour le MFA. Voici l'exemple officiel :

Username, MFA Status
[email protected], Enabled
[email protected], Disabled
[email protected], Disabled
[email protected], Enabled
[email protected], Enabled

Une autre alternative consiste à utiliser PowerShell, mais j'aborderais ce point au sein d'un article dédié. 🙂

Lorsque l'utilisateur se connectera la prochaine fois, il devra définir un second facteur d'authentification, par exemple un numéro de téléphone afin de recevoir un SMS. Si vous avez activé l'option qui permet d'approuver les appareils, une option supplémentaire sera proposée au moment de s'authentifier :

Office 365 - Connexion MFA avec approbation d'un appareil
Office 365 - Connexion MFA avec approbation d'un appareil

VI. Conclusion

Suite à la lecture de ce tutoriel, vous êtes en mesure de mettre en place l'authentification multifacteur sur votre tenant Office 365. Même s'il est possible d'aller plus loin, en activant certaines fonctionnalités ou en s'appuyant sur PowerShell, cela vous permettra d'activer le MFA auprès d'un ou plusieurs utilisateurs.

Finalement, le plus compliqué ce n'est pas la partie technique, mais plutôt la gestion du changement auprès des utilisateurs. Pensez à bien communiquer auprès de vos utilisateurs avant l'activation, car ils auront besoin d'un minimum d'encouragement et d'accompagnement pour appréhender cette nouvelle sécurité.

Pour vous roder, vous pouvez activer le MFA sur les comptes avec des privilèges élevés dans un premier temps. Ensuite, sur un groupe pilote de quelques utilisateurs afin d'y aller progressivement. Rassurez-vous, tout va bien se passer ! 🙂

D'autres articles seront publiés au sujet du MFA sur Office 365 : restez connectés !

The post Comment mettre en place le MFA sur Office 365 ? first appeared on IT-Connect.

Office 365 : synchroniser l’option « L’utilisateur devra changer le mot de passe »

8 décembre 2021 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment permettre le changement de mot de passe depuis Office 365 pour les utilisateurs Azure AD synchronisés depuis l'Active Directory, en activant la synchronisation de l'attribut "L'utilisateur devra changer le mot de passe".

Les infrastructures hybrides, avec d'un côté l'Active Directory local et de l'autre Office 365 avec l'Azure AD sont courantes. La synchronisation des objets, notamment les utilisateurs, est effectuée au travers d'Azure AD Connect. De nombreux attributs sont synchronisés de l'Active Directory local vers Azure AD (Office 365) : le nom, le prénom, l'adresse e-mail, la fonction, le numéro de téléphone, etc....

Active Directory - Option "L'utilisateur devra changer le mot de passe"
Active Directory - Option "L'utilisateur devra changer le mot de passe"

Si vous cochez l'option "L'utilisateur devra changer le mot de passe" sur un compte de l'Active Directory, cela signifie qu'à la prochaine ouverture de session, l'utilisateur devra définir un nouveau mot de passe. Le problème, c'est que s'il ouvre sa session sur Office 365, il obtiendra un message d'erreur lui indiquant que le mot de passe est incorrect (même si le mot de passe est correct). En fait, c'est à cause de l'option "L'utilisateur devra changer le mot de passe", car l'utilisateur doit changer son mot de passe, mais Office 365 n'en est pas capable.

Concrètement, vous obtenez le message d'erreur : "Votre compte ou mot de passe est incorrect. Si vous avez oublié votre mot de passe, réinitialisez-le maintenant."

Dans ce cas, l'utilisateur doit ouvrir une session sur un poste Windows membre du domaine Active Directory afin de pouvoir définir son nouveau mot de passe. Comment faire si l'on veut que l'utilisateur puisse définir son nouveau mot de passe depuis Office 365 ? C'est ce que nous allons voir dans ce tutoriel.

II. Prérequis

Pour que cela fonctionne, vous devez respecter plusieurs prérequis :

  • Activer la synchronisation de l'attribut "pwdLastSet" correspondant à l'option "L'utilisateur devra changer le mot de passe" dans Azure AD Connect
  • Activer la réécriture du mot de passe dans Azure AD Connect
  • Activer la réinitialisation du mot de passe en libre-service sur les utilisateurs (ce qui nécessite une licence avec cette fonction, comme l'Azure AD Premium P1)

Avertissement : à mon sens, la mise en place de cette fonctionnalité implique que le mot de passe temporaire définit à l'utilisateur, en attendant qu'il le change, soit suffisamment complexe ! Si vous mettez "Password" par défaut en attendant que l'utilisateur le modifie, c'est un gros risque, car quelqu'un pourrait facilement le deviner et se connecter au compte de l'utilisateur depuis l'extérieur via Office 365.

Maintenant, nous allons voir dans la pratique comment mettre en place ces prérequis.

III. Synchroniser "L'utilisateur devra changer le mot de passe"

Afin qu'Azure AD Connect synchronise l'option "L'utilisateur devra changer le mot de passe", nous devons activer un paramètre supplémentaire au sein de l'outil de synchronisation.

Cette modification s'effectue sur le serveur Azure AD Connect à partir d'une console PowerShell. Commencez par exécuter la commande suivante (elle récupère seulement l'état actuel de votre configuration) :

Get-ADSyncAADCompanyFeature

L'option "ForcePasswordChangeOnLogOn" sera certainement définie sur "False", car c'est la configuration par défaut. Nous devons la basculer sur "True" pour activer la synchronisation de l'attribut. Pour cela, exécutez la commande PowerShell suivante :

Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true

Voici ce que ça donne sur mon infra de test :

IV. Activer la réécriture du mot de passe dans Azure AD Connect

Sur votre serveur Azure AD Connect, ouvrez l'exécutable du même nom, puis cliquez sur le bouton "Configurer". Ensuite, dans la liste choisissez "Personnalisation des options de synchronisation" et vous devrez alors vous authentifier.

Au sein des fonctionnalités facultatives, cochez l'option "Réécriture du mot de passe" si ce n'est pas déjà coché.

Cliquez sur "Suivant" et validez cette nouvelle configuration.

V. Réinitialisation du mot de passe en libre-service

Vous devez activer la fonction de réinitialisation du mot de passe en libre-service (SSPR), car c'est un prérequis côté Microsoft. Pour cela, je vous invite à consulter mon tutoriel à ce sujet, cela m'évitera de me répéter inutilement.

VI. Tester

Maintenant que nous respectons tous les prérequis, nous allons pouvoir tester. Ce qui nécessite de cocher l'option "L'utilisateur devra changer le mot de passe" sur un compte de l'Active Directory synchronisé sur Office 365. Ensuite, sur le serveur Azure AD Connect, on va forcer une synchronisation :

Start-ADSyncSyncCycle -PolicyType Delta

Ensuite, il faut ouvrir une page de connexion à Office 365 (portal.office.com), renseigner l'adresse e-mail, puis le mot de passe et cliquer sur "Se connecter".

À la place du message d'erreur que l'on avait toute à l'heure, désormais l'étape "Mettre à jour votre mot de passe" s'affiche. Il ne reste plus qu'à ressaisir le mot de passe actuel, puis le nouveau par deux fois afin de le changer !

Cliquez sur "Se connecter" lorsque c'est fait. Si c'est la première connexion de l'utilisateur, il devra définir son numéro de téléphone ou e-mail de secours pour la réinitialisation du mot de passe en libre-service. Pendant ce temps, son nouveau mot de passe sera réécrit dans l'Active Directory local afin qu'il puisse l'utiliser également pour se connecter sur un poste membre du domaine Active Directory.

The post Office 365 : synchroniser l’option « L’utilisateur devra changer le mot de passe » first appeared on IT-Connect.

Office 365 et ADDS : activer la réinitialisation du mot de passe en libre-service

18 novembre 2021 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment activer la réinitialisation du mot de passe en libre-service pour vos utilisateurs Active Directory synchronisés sur Office 365, via Azure AD Connect. Ce tutoriel va permettre de configurer la fonctionnalité Self-Service Password Reset (SSPR) d'Azure AD.

En mettant en place Azure AD Connect comme nous l'avions vu dans un précédent tutoriel, vous pouvez synchroniser les utilisateurs de votre annuaire local vers Office 365, et donc par extension sur Azure AD.

Si la synchronisation du hachage des mots de passe est activée, lorsqu'un utilisateur change son mot de passe depuis son PC, ce mot de passe est synchronisé sur Office 365 et cela devient son mot de passe Cloud également. Par contre, si l'utilisateur oublie son mot de passe, c'est un peu plus compliqué... Il doit passer par le service informatique pour le réinitialiser, car il n'a plus accès à sa session et il n'a pas possibilité de le réinitialiser via Office 365 / Microsoft 365.

Grâce à la configuration de la fonctionnalité "Self-Service Password Reset" (SSPR), on va pouvoir changer la donne puisque l'utilisateur pourra réinitialiser son mot de passe en totale autonomie, via Office 365. Plus largement, l'utilisateur pourra changer son mot de passe via le portail libre-service, même s'il ne l'a pas perdu.

Note : dans cet article, je vous présente la fonction SSPR dans le cadre d'un scénario hybride, mais cette fonction est disponible également pour un tenant avec uniquement des utilisateurs Cloud.

II. Ce dont vous avez besoin

Pour suivre ce tutoriel, vous avez besoin d'un tenant Office 365 / Microsoft 365, avec au minimum un utilisateur couvert par une licence prenant en charge cette fonctionnalité (voir ci-dessous).

Au niveau de l'infrastructure, il suffira d'avoir un domaine Active Directory et l'outil Azure AD Connect en place. Je vais revenir sur la synchronisation de cet outil dans la suite de ce tutoriel.

La fonctionnalité "Self-Service Password Reset" nécessite d'avoir une licence compatible, c'est-à-dire qui intègre la fonction "Changement ou réinitialisation de mot de passe utilisateur hybride avec réécriture locale"C'est le cas des licences suivantes (qui intègrent aussi d'autres fonctionnalités) :

  • Azure AD Premium P1
  • Azure AD Premium P2
  • Microsoft 365 Business Premium
  • Microsoft 365 E3

Chaque utilisateur qui doit pouvoir utiliser la fonction de réinitialisation du mot de passe en libre-service doit être couvert par une licence. Si l'on se réfère aux bonnes pratiques de Microsoft, cette fonction doit être activée sur tous les utilisateurs. À titre indicatif, la licence Azure AD Premium P1 est facturée 5,10 € HT par utilisateur et par mois.

Vous pouvez demander des licences d'essais via l'interface d'administration Office 365 (Facturation > Acheter des services).

III. Azure AD : configurer la réinitialisation libre-service

Avant d'adapter la configuration d'Azure AD Connect, nous devons configurer la fonctionnalité sur le portail Microsoft Azure. Accédez au portail Azure et connectez-vous avec un compte Administrateur général : portal.azure.com

Une fois sur la page d'accueil, cliquez sur "Azure Active Directory" et une fois sur la vue d'ensemble d'Azure Active Directory, cliquez sur "Réinitialisation du mot de passe" dans le menu de gauche.

Sous "Gérer", cliquez sur "Propriétés" afin de pouvoir activer la fonctionnalité "Réinitialisation du mot de passe en libre-service activée". Vous avez deux choix :

  • Sélectionné : vous activez la fonctionnalité pour tous les utilisateurs membres d'un groupe spécifique
  • Tout : vous avez la fonctionnalité pour tous vos utilisateurs (attention aux licences)

Pour ma part, j'utilise une licence d'essai alors je vais prendre "Sélectionné" et sélectionner un groupe : O365-SelftServicePasswordReset.

Réinitialisation du mot de passe en libre-service
Réinitialisation du mot de passe en libre-service

Il s'agit d'un groupe de sécurité présent dans mon annuaire Active Directory et synchronisé au travers d'Azure AD Connect. Ce groupe contient un membre : "Guy Mauve", ce sera mon cobaye pour tester la fonctionnalité. Ce compte dispose d'une licence Azure AD Premium P1.

En cliquant sur la section "Méthodes d'authentification", vous pouvez choisir les méthodes disponibles pour les utilisateurs afin de permettre la réinitialisation du mot de passe.

Grâce à l'option "Téléphone mobile", l'utilisateur recevra un code sur son téléphone et il devra le saisir à l'écran afin de pouvoir réinitialiser son mot de passe.

L'option "Nombre de méthodes à réinitialiser" signifie que l'utilisateur doit configurer au moins l'une des méthodes, puisque c'est positionné sur "1". Dans cet exemple, il doit définir au moins un e-mail ou un numéro de téléphone mobile comme méthode de secours pour recevoir le code.

Passons à la partie Azure AD Connect.

IV. Configurer Azure AD Connect pour la réinitialisation libre-service

Nous devons adapter, ou tout du moins vérifier la configuration d'Azure AD Connect, afin de s'assurer qu'elle permet d'utiliser la réinitialisation libre-service des mots de passe. En fait, lorsqu'un utilisateur va modifier son mot de passe via le portail libre-service, il faut que ce mot de passe soit réécrit dans l'Active Directory local. De cette façon, il pourra utiliser ce nouveau mot de passe pour se connecter sur son PC, en plus d'Office 365.

Connectez-vous sur le serveur où Azure AD Connect est installé et ouvrez la console du même nom. Cliquez sur le bouton "Configurer". Pendant ce temps, la synchronisation est suspendue.

À l'étape suivante, cliquez sur "Personnalisation des options de synchronisation" dans la liste d'éléments. Connectez-vous avec votre compte Administrateur général lorsque l'étape "Connexion à Azure AD" apparaît.

Avancez jusqu'à l'étape "Fonctionnalités facultatives". Ici, vous devez vous assurer que l'option "Réécriture du mot de passe" est cochée. En anglais, cette option se nomme "Password writeback".

Ensuite, il ne vous reste plus qu'à continuer jusqu'à la fin et c'est tout bon.

V. Azure AD : intégration on-premise du portail libre-service

Nous devons retourner sur le portail Azure, toujours au même endroit que toute à l'heure : Azure Active Directory > Réinitialisation du mot de passe.

Dans le menu de gauche, cliquez sur "Intégration locale". Le message "Votre client de réécriture local est opérationnel". Vérifiez que l'option "Réécrire des mots de passe dans votre répertoire local" est sur "Oui" afin que le mot de passe soit réécrit dans l'Active Directory.

Note : la seconde option positionnée sur "Non" permet de dire qu'un déverrouillage de compte doit toujours impliquer le changement du mot de passe.

Intégration on-premise du portail de réinitialisation libre-service
Intégration on-premise du portail de réinitialisation libre-service

La configuration est terminée, nous allons pouvoir tester.

VI. Office 365 : tester la fonction Self-Service Password Reset

Maintenant, je suis dans la peau de l'utilisateur "Guy Mauve" et j'ai oublié mon mot de passe. Je me retrouve face à la page de connexion d'Office 365 : que faire ? Est-ce que j'appelle le service informatique ? Non, car ils m'ont dit que je pouvais me débrouiller comme un grand... Je vais essayer pour voir.

Je commence par cliquer sur le lien "J'ai oublié mon mot de passe".

Ensuite, il faut saisir son adresse e-mail et remplir le captcha avant de pouvoir poursuivre.

L'option "Envoyer un SMS à mon téléphone mobile" s'affiche. Il faut saisir son numéro de téléphone et cliquez sur "Envoyer un SMS". Alors bien sûr, il ne faut pas saisir n'importe quel numéro de téléphone, mais celui associé à votre compte.

Dans l'exemple de "Guy Mauve" c'est le numéro de téléphone renseigné dans le compte Active Directory qui est remonté sur Office 365 et automatiquement utilisé par Microsoft. Si ce n'est pas fait, la réinitialisation ne fonctionnera pas puisqu'il n'y a aucune méthode de récupération utilisable (voir la suite de l'article pour plus d'explications).

Revenons à notre assistant... J'ai bien reçu un code par SMS, je le saisis et je clique sur "Suivant".

Désormais, il faut saisir un nouveau mot de passe par deux fois.

Voilà, le tour est joué ! Je viens de réinitialiser mon mot de passe moi-même, sans solliciter le service informatique ! C'est désormais mon nouveau mot de passe pour me connecter à Office 365 et à ma session Windows.

Vous vous demandez surement ce qu'il se passe suite à l'activation de la fonctionnalité SSPR auprès de vos utilisateurs ?

Sachez qu'à la prochaine connexion sur leur compte Office 365, un écran "Plus d'informations requises" s'affichera. Cela est nécessaire puisque pour utiliser la réinitialisation du mot de passe en libre-service, il faut que Microsoft ait connaissance soit d'un numéro de téléphone, soit d'un e-mail de secours (souvenez-vous de la configuration sur Azure). Si Microsoft n'a ni l'un ni l'autre, il vous le fera savoir de cette façon et l'utilisateur devra suivre les étapes afin de pouvoir utiliser cette nouvelle fonctionnalité.

En cliquant sur "Suivant", l'assistant "Protéger votre compte" s'affiche. Vous devez indiquer un numéro de téléphone sur lequel recevoir le code en cas de besoin. Si l'utilisateur préfère l'e-mail de secours, il doit cliquer sur "Je veux configurer une autre méthode" et choisir l'e-mail (la liste dépend des méthodes sélectionnées dans la configuration Azure).

Voilà, il ne vous reste plus qu'à communiquer auprès de vos utilisateurs ! Pour vous aider, Microsoft met à disposition sur son site des templates. Ils sont en anglais, mais vous pouvez les adapter. Voir cette page : SSPR Materials

Exemple - Template d'e-mail proposé par Microsoft

Bonus : sachez qu'un utilisateur peut réinitialiser son mot de passe à tout moment en utilisant cette adresse fournie par Microsoft : https://aka.ms/sspr

The post Office 365 et ADDS : activer la réinitialisation du mot de passe en libre-service first appeared on IT-Connect.

Office 365 Mail Tip: How To Quickly Empty Any Folder in Outlook

27 juillet 2021 à 02:32
Par : Kent Chen

One of the users’ mailboxes got out of space the other day. After doing a bit of digging, here is what I found.

And that’s right. One of the tasks with too many attachments kept failing to sync back to the server and it quickly ate all the space left under his account.

If you have used Outlook before, you know how painful it is to clean up 49GB of data out of any folder. And here is a quick tip for those who just want a quick way to clean up space so they can be back to work right away.

Unfortunately, Outlook is not up for the task. We will be using Outlook web instead.

Log into Outlook online, click the Gear icon and choose View all Outlook settings.

In the General, tab, click the Storage tab. You will see the list of folders on the right that have the most data in there. Click the Empty button next to the folder you want to clean up and pick the option of All, 3 months, 6 months, or 12 months or older.

One-click. That’s all they need and Outlook online will take care of the rest.

The post Office 365 Mail Tip: How To Quickly Empty Any Folder in Outlook appeared first on Next of Windows.

❌