TLDR

En récap :

• si accès à un portail admin -> demande MFA (obligatoire à compter d’octobre 2025)
• si accès à la page de gestion des moyens MFA -> demande MFA
• si MFA est “enforced” pour l’utilisateur -> demande MFA quelle que soit le portail (mais bypass possible en fonction de l’IP)
• si self-service password reset activé -> MFA obligatoire même pour Office

Software TOTP

Les jetons utilisés par MS Authenticator ne sont pas standards ; ils ne peuvent être utilisés que dans l’applis MS Authenticator (qui doit avoir accès aux notifications push pour fonctionner).
Pour utiliser un TOTP standard, il faut utiliser l’option “Je souhaite utiliser une autre application d’authentification”.

Les 2 méthodes génèrent des QRCode, mais ceux de MS encodent une URL de type “phonefactor://” alors que ceux standard encodent une URL de type “otpauth://” .
Il est pertinent de sauvegarder les QRcode standards, car ils contiennent juste un secret (une graine) qui peut être réutilisée à tout moment.
Ceux de MS permettent une communication limitée dans le temps avec les serveurs de MS, donc ça ne sert à rien de les conserver.

Si on scanne un code “phonefactor://” avec une appli standard, certaines renverront juste une erreur, alors que d’autres (comme Aegis) signifieront explicitement ne pas être compatibles avec la méthode propriétaire de MS.

MS Auth permet l’identification soit par notification push, soit par un code type TOTP.
À noter que le code TOTP généré par MS Auth n’est pas le même qu’avec une appli standard !

Si les 2 méthodes sont activées pour un compte donné, on peut alors utiliser soit le code TOTP, soit le code MS Auth lors de la demande MFA.

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

L’accès conditionnel du MFA nécessite des licences Entra P1/P2.

Si l’organisation n’a pas ces licences, la MFA peut être forcée pour tous les utilisateurs via le mécanisme des “paramètres de sécurité par défaut”. Ceux-ci exigent (entre autres) la MFA pour tous les utilisateurs.
Ils peuvent s’activer et se désactiver dans
Entra admin center -> Entra ID -> Overview -> Properties -> Manage security defaults (tout en bas de la page)

Il est aussi possible de forcer les utilisateurs 1 par 1 via le menu Per-user MFA (voir plus bas).

Paramètrage général

Le menu “Entra ID -> Multifactor authentication” n’est pas toujours disponible ; à voir si cela dépend de la date de création du tenant, ou bien des licences Entra Premium ?
Il semble que ces paramètres sont de toute façon dépréciés par MS, et voués à être remplacés par ce qui suit.

Entra admin center -> Entra ID -> Authentication methods
Contient les paramétrages globaux pour la MFA.

Policies (Stratégies) : permet de choisir quels modes de MFA sont autorisés selon les groupes d’utilisateurs.

• Software OATH token : TOTP standard ; sera proposé sous l’intitulé “MS Authenticator” mais avec l’option “Autre appli”
• MS Authenticator : option “phonefactor://” de MS

Certaines stratégies peuvent être paramétrées en cliquant sur leur nom.

Note sur les codes TOTP (MS Auth / OATH Soft token) :

• si seulement MS Auth activé : absence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Pro ou scolaire”
• si les MS Auth + OATH activés : présence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Pro ou scolaire”
• si seulement OATH activé : présence de l’option “Autre appli” ; choisir MS Auth demande de sélectionner un compte “Autre”

Settings -> “System-preferred multifactor authentication” :
Ceci force les utilisateurs à être, en premier lieu, exposé à la méthode MFA considéré la + sécurisée par MS. Celle-ci peut changer au fil du temps.
Si cette fonctionnalité est désactivée, les utilisteurs peuvent choisir eux-même la méthode proposée en 1er (voir paragraphe sur la gestion par les utilisateurs finaux).
Ceci n’empêche jamais les utilisateurs d’utiliser une autre méthode ; ça définit juste la première méthode proposée. Ils peuvent toujours en choisir une autre (à condition qu’elle soit autorisée par les stratégies) en déclarant la 1e méthode inaccessible.

“Registration campaign” : ne supporte actuellement (septembre 2025) que MS Authenticator

Obligation MFA pour les centres d’admin

https://aka.ms/mfaforazure
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

Activée de force le 30 septembre 2025 au + tard.
Contrairement à ce qui est indiqué sur la doc MS, le centre d’admin M365 (https://admin.microsoft.com) n’est pas encore concerné (même si ça va surement finir par venir).
Mais activée pour le centre d’admin Entra, d’Intune, et le portail Azure, notamment.

Le paramétrage pour désactiver la MFA en provenance de certaines plages d’IP ne s’appliquent pas à l’accès aux centres d’admin ; la MFA sera demandée en tous les cas.

Se gère ici :
https://entra.microsoft.com/#view/Microsoft_Azure_Resources/MfaSettings.ReactView
Besoin d’être avec “accès élevé” pour modifier les paramètres.

(note : la même page est aussi accessible via les portails Intune et Azure ; c’est bien le même paramétrage accessible de 3 endroits différents)

Les options proposées semblent être un sous-ensemble de celles autorisées dans les “Stratégies”. En activant tout, j’ai le choix entre :

• MS Auth
• TOTP
• Hardware token
• SMS
• Appel

Pour pouvoir accéder aux centres d’admin, il faut qu’une des méthodes ci-dessus soit activée dans les Stratégies, et que l’utilisateur s’enregistre via cette méthode.

Paramètres MFA par utilisateur

Peut se gérer dans Entra ID -> Users -> onglet “Per-user MFA”
(le menu Entra admin center -> Entra ID -> Multifactor authentication -> Additional cloud-based multifactor authentication settings envoie dans le même menu)

Lorsqu’on active la MFA pour un utilisateur, son état passe à “enabled”. Cela signifie qu’il sera contraint d’activer la MFA à sa prochaine connexion.
Une fois la MFA enregistrée par l’utilisateur final, son état passe à “enforced”. À partir de là, elle est nécessaire même pour une simple connexion à Office.

Lorsque l’état est “disabled”, la MFA est ignorée pour les connexions simples à Office. Elle reste nécessaire pour les centres d’admin, ou l’accès à la page utilisateur final de gestion de la MFA.

Entra ID -> Users -> choisir user -> Authentication methods
permet de visualiser les modes d’auth disponibles, indisponibles (activées par l’utilisateur, mais désactivées par les stratégies) et par-défaut pour l’utilisateur sélectionné ; permet d’ajouter certains modes (mail, tél) et d’en supprimer d’autres.

On ne peut pas voir ses propres méthodes d’auth via ce menu ; il faut passer par le lien du paragraphe “Utilisateur final”.

Services settings

Dans l’onglet “Per-user MFA”, il y a un onglet “Service settings”.
C’est ici que l’on peut autoriser la mémorisation d’une réponse MFA pendant plusieurs jours.
On peut aussi y désactiver la MFA pour certaines plages d’IP (fonctionne pour les accès standards à Office, mais pas aux centres d’admin ni à la gestion MFA par l’utilisateur final).

Self-service password recovery

Entra -> Entra ID -> Password reset
Les utilisateurs pour lesquels SSPR est activé ont l’obligation d’activer la MFA, avant de pouvoir se connecter via la connexion web (navigateur, connexion Office etc).

La réinitialisation se fait ici :
https://passwordreset.microsoftonline.com

Il faut valider la MFA par une des méthodes enregistrées et on peut reset son propre mot de passe.

Gestion par l’utilisateur final

https://mysignins.microsoft.com/security-info

L’accès à cette page est lui-même soumis à la MFA.
Les stratégies listées ici sont celles pour lesquelles il y’a une donnée enregistrée. Cela ne signifie pas que ce mode d’auth est accepté par Entra. Il peut avoir été désactivé.

À noter que l’utilisateur peut gérer ses moyens de MFA, mais pas les demandes de MFA elles-mêmes, ni les moyens acceptés et ceux refusés.
Ceci est paramétré par MS et/ou les admins.

App password

Il faut que la MFA soit “enforced” pour l’utilisateur qui veut créer un “app password”.
Ensuite, dans la gestion par l’utilisateur final, il devrait être possible de créer un app password.

Conditional Access

Dans les conditions -> Clients apps, “Mobile apps and desktop clients” inclut la jonction d’un appareil à Entra, la connexion à un Compte Pro ou Scolaire, à Office etc.
Ça inclut également Thunderbird via Oauth.

Général

Azure Files est un stockage cloud, accessible via SMB par une machine locale, ou une VM Azure.

Azure Files peut stocker plusieurs types de ressources, comme les conteneurs blob, mais je m’intéresse ici uniquement aux partages de fichiers.

Il y’a également la possibilité de créer des partages NFS, mais je n’aborde pas ce cas ici. Un partage est accessible soit par SMB soit par NFS, mais pas les 2 en même temps.

Guide de planification général Azure Files

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-planning

Quelques considérations

MS conseille de ne pas mélanger les différents types de ressources au sein d’un même compte de stockage (si il contient un partage Azure Files, alors il est déconseillé d’y mettre un stocke blob par exemple).

Dans la mesure du possible, essayer de ne mettre qu’un seul partage par compte de stockage (chaque partage aura son propre compte de stockage).

Compte de stockage

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-account-overview

La gestion se fait sur le portail Azure, section “Comptes de stockage”.
Il faut créer un compte de stockage (qui lui-même doit appartenir à un groupe de ressources).
Les performances du compte de stockage (standard ou premium) est défini définitivement à la création du compte.

Le compte de stockage est protégé par 2 clés, “storage account key”. On peut les voir sur le portail Azure, dans le compte de stockage -> Sécurité + réseau (colonne de gauche) -> Clé d’accès.
Ces clés donnent un accès admin complet à l’ensemble des partages et données du compte de stockage.

Pay-as-you-go ou provisionned

https://learn.microsoft.com/en-us/azure/storage/files/understanding-billing

Calculateur de coûts ici :
https://azure.microsoft.com/en-us/pricing/calculator/

Il y a 2 modèles de facturation pour les partages Azure Files :

• le modèle provisionné v2 (le v1 est uniquement pour les storage premium, en SSD) (on définit d’avance une capacité max de stockage, des IOPS et de la bande passante, et le coût est fixe)
• le modèle à l’usage, où on paye chaque Go de stockage, chaque transaction, et chaque Mo de transfert

Le modèle de facturation est défini au niveau du compte de stockage, et sera visible dans ses propriétés (Kind : StorageV2 pour du PAYG, FileStorage pour du provisionné).
Cependant, pour les modèles provisionnés, le décompte de l’usage des ressources est fait pour chaque partage. C’est lorsqu’on déploie un partage que l’on commence à être facturé.

Pour des volumes de données faibles, le modèle PAYG peut être intéressant, mais il revient vite cher s’il y’a du volume de données (~ 300€/mois pour 2.7 To de données en cool storage dont le seul accès est la sauvegarde quotidienne ; en cool storage, le coût des transactions est vite important ! )

Le modèle provisionné peut vite être + intéressant, mais il a des quantités minimum (32Go, 500IOPS, 60MiB/s) qui induisent des coûts fixes, avec un minimum de ~30€/mois pour chaque partage.
Il est possible d’augmenter les performances du partage à tout moment. Pour ça :
Comptes de stockage -> sélectionner -> File shares -> ... (au bout de la ligne du partage) -> Change size and performance
On peut également diminuer le provisonnemnt, mais seulement 1 fois/24h.

Redondance

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-redundancy

LRS : 3 copies dans le même datacenter
ZRS : 1 copie dans chacun de 3 datacenter différents (dans la même région primaire)
GRS : LRS en zone primaire + LRS en zone secondaire
GZRS : ZRS en zone primaire + LRS en zone secondaire

Le niveau de redondance est défini au niveau du compte de stockage, mais il pourra être changé par la suite. Pour ceci :
Storage accounts -> sélectionner -> Data management -> Redundancy
et choisir la nouvelle redondance.
Attention MS prévient que ça peut mettre plusieurs jours (ou semaines !) pour démarrer.

Zones de disponibilité :
https://learn.microsoft.com/fr-fr/azure/reliability/availability-zones-overview?tabs=azure-cli#azure-regions-with-availability-zones

Partages

Une fois le compte de stockage créé, on peut créer des partages (Portail -> Comptes de stockage -> Partages de fichiers puis + Partage de fichiers). Le nom ne peut pas contenir de majuscule.

Chaque partage a son propre niveau de performance (froid, chaud, optimisé pour les transactions).
Celui-ci peut se changer par la suite si besoin.
MS conseille, s’il y a des gros volumes à transférer, de commencer par le niveau optimisé pour les transactions le temps de la migration, puis de repasser à un autre niveau après.

Chaque partage a ses paramètres de sauvegarde.

Suppression réversible (Soft delete)

Concerne uniquement la suppression d’un partage (et non de fichiers dans ce partage).
Si activé, lorsqu’un partage est supprimé, il reste “dans la corbeille” pendant un temps (configurable).
Activé au niveau du compte de stockage, pour tous les partages lui appartenant.
Article chez MS

Les partages dans l’état soft-delete sont facturés selon le modèle de facturation choisie pour le compte de stockage (ils comptent comme s’ils étaient actifs).

Paramètres SMB

Récap chez Microsoft

L’accès SMBv3 est ok pour Windows 10 et Debian Bullseye. Les paramètres SMB sont identiques pour tous les partages au sein d’un compte de stockage.

Accéder au partage Azure Files

Article chez Microsoft

Obtenir l’UNC

Ça devrait toujours être \\nomducomptedestockage.file.core.windows.net\nom-du-partage .

Pour le vérifier :
Azure Portal -> Comptes de stockage -> Sélectionner le compte de stockage souhaité -> Partage de fichiers (colonne de gauche du panneau central) puis clic sur Connecter
Cela donne un script, dans lequel on trouve l’UNC.
On y voit aussi la clé de sécurité, derrière le /pass=

Connexion via clé

Si on veut établir la connexion manuellement, on peut ajouter les informations de connection dans Panneau de configuration -> Comptes d'utilisateur -> informations de connexion Windows (ou à la volée lors de la connexion) :

• Adresse : nomducomptedestockage.file.core.windows.net
• Utilisateur : nomducomptedestockage (ou localhost\nomducomptedestockage )
• Mot de passe : clé du compte de stockage

Il est bien sûr possible d’automatiser le déploiement de ce partage via GPO (ou Intune).

Depuis Linux

smb://nomducomptedestockage.file.core.windows.net/nom-du-partage
Mêmes utilisateurs et mot de passe. “Domaine” non-pertinent.

Authentification/autorisations

Article chez Microsoft

L’accès au partage se fait :

• soit par la “storage account key” (donne un accès complet admin à tous les partages du compte de stockage)
• soit par un accès basé sur l’identité (IAM)

Si on veut utiliser l’IAM, il est bien de commencer par vérifier que le montage fonctionne en utilisant la storage key, pour s’assurer du bon fonctionnement de la partie réseau sans s’occuper de la partie authentification.

Si on veut utiliser l’IAM, il faut le paramétrer. Un paramétrage sur le compte de stockage lui-même est nécessaire (chaque entité doit avoir les droits d’accès au compte de stockage pour accéder à un partage inclus dedans).

Ce paramétrage se fait sur le portail, dans Compte de stockage -> le choisir -> Access Control (IAM) -> Add -> Add role assignment .
On recherche “SMB”, puis on choisit le rôle “Storage File Data SMB Share Contributor” (pour un contributeur simple, qui peut modifier les fichiers).
On y affecte ensuite l’entité qui doit bénéficier de ce rôle (un groupe, un utilisateur).

Si on souhaite pouvoir modifier les ACL directement sur les dossiers/fichiers, depuis l’explorateur Windows, il faut accorder le rôle “Collaborateur à privilèges élevés de partage SMB des données du fichier de stockage”.

Chaque partage de ce compte héritera de cette IAM. Il est possible de surcharger chacun des partage avec d’autres droits (par exemple refus d’accès ?).

Il y a 3 méthodes d’authentification auprès d’une “source AD”, chacune avec ses spécificités.

Auprès d’un AD local (AD DS)

Il est nécessaire de pouvoir contacter ce DC local lors de l’établissement de la connexion au partage.
Ce DC local peut éventuellement être hébergé dans le cloud, avec accès via un VPN.
Disponible seulement pour les utilisateurs hybrides (synchronisés depuis le DC local vers Entra ID).

Introduction - MS
Activation - MS

Entra Domain Services (Entra DS, anciennement Azure AD DS)

Il s’agit d’un domaine géré (managé) par MS, qui fournit entre autres des fonctionnalités de DC et de GPO.
Il semble plutôt fait pour la gestion centralisée de serveurs virtuels, et il ne peut être contacté que via la connexion à un VPN.
Prend en charge les utilisateurs hybrides ainsi que cloud-only.
Les clients (postes utilisateurs) ne peuvent pas être Entra-joined ou Entra-registered.
les clients doivent être joints au domaine hosté pour que tout soit automatisé.
Il est toutefois possible de monter le partage depuis un poste non-joint à un domaine en fournissant des IDs explicites.

Récap chez Microsoft
Activation

Entra Kerberos

C’est une authentification directement auprès d’Entra, uniquement pour les utilisteurs hybrides (synchronisés depuis un DC local).
L’accès peut se faire sans besoin de connexion au DC (sauf pour régler les droits d’accès, là une connexion au DC sera nécessaire).
Les postes clients doivent être Entra-joined ou Entra-hybrid-joined ; pas ok si joints à Entra DS ou si joints uniquement à un AD local.

Détails sur mon memo

Migration des données

https://learn.microsoft.com/fr-fr/azure/storage/files/storage-files-migration-overview

Plusieurs méthodes possibles ; par exemple :

• simplement avec robocopy d’un lecteur à l’autre
• avec Azure Storage Mover
• avec Azure Files Sync

Azure Files Sync

https://brouillons.raphaelguetta.fr/post/azure-files-sync/

Pour synchroniser un serveur local avec un partage Azure Files Sync
https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-planning

Possible de faire de la synchro simple.
Possible aussi de donner au server local un rôle de cache, les clients s’adressant à lui et lui échangeant avec Azure.

Azure Storage Mover

https://learn.microsoft.com/en-us/azure/storage-mover/service-overview

Capable de gérer des gros volumes de données.
Transfère les metadonnées.

Requiert la création sur Azure d’une ressource Azure Storage Mover
Requiert ensuite la création d’un agent (apparement c’est une VM)

Coût

https://azure.microsoft.com/fr-fr/pricing/details/storage/files/#pricing

Il y’a plusieurs choses distinctes qui sont facturées : stockage utilisé, transactions (lecture/écriture de données), metadonnées, backups, snapshots etc…

Facturation provisionnée (espace pré-payé, qu’il soit utilisé ou non)

Facturation à l’usage pour les modes standard (optimisé pour les transactions, chaud, froid).

Le stockage est de moins en cher quand on descend dans les gammes (optimisé pr transactions -> chaud -> froid)
Les transactions sont de + en + chères quand on descend dans la gamme.

Il est possible de changer le niveau de chacun des partages à tout moment. Ceci entraîne toutefois des transactions donc de la facturation.

Sauvegarde

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview

https://memo.raphaelguetta.fr/post/azure-files-backup

Disques managés

disques virtuels attachables à une VM azure en tant que disque local
https://azure.microsoft.com/fr-fr/pricing/details/managed-disks/
en HDD, 8To = 300€/mois

Montable sur plusieurs serveurs virtuels ?

Généralités

L’authentification via Entra kerberos permet à un poste de s’authentifier sur Azure Files (ou autre application hébergée sur Azure) en ayant uniquement besoin d’être en lien avec internet (nécessité de pouvoir contacter certains noms de domaine publics appartenant à Microsoft).
Cette authentification passe par un ticket Kerberos émis par Azure, qui doit être récupéré par le poste client lors de la connexion utilisateur.

Elle repose sur une architecture hybride (utilisateurs existants sur un AD local qui sont synchronisés sur Entra via Entra Connect Sync).
Les postes utilisés pour accéder aux ressources Azure doivent également être en jonction hybride à Azure (donc joints au domaine local, puis joints à MS Entra). Une jonction simple à Entra, ou une jonction simple au domaine local, ne permettront pas l’authentification auprès des ressources cloud.

Il est nécessaire d’avoir une connectivité au DC local pour définir les autorisations NTFS sur les fichiers/dossiers du partage Azure Files.

Il est également nécessaire d’avoir une connectivité au DC local pour établir la jonction hybride d’un poste.
Il est aussi nécessaire d’avoir une connectivité au domaine local pour paramétrer le poste pour récupérer toutes les informations nécessaires à l’établissement de la connexion au partage réseau Azure Files.
Une fois cette connexion établie, on peut accéder au partage Azure Files sans connectivité au DC (à voir s’il faut renouveler le ticket Kerberos de temps en temps avec un dialogue avec le DC ?)

Présentation générale chez MS

Prérequis

• il faut une synchronisation des utilisateurs locaux vers Entra via Entra Connect Sync (utilisateurs hybrides)
• il faut une jointure hybride des postes à Entra
• le compte de stockage Azure ne doit pas avoir d’autre méthode d’auth déjà activée (la désactiver si c’est le cas)
• les services WinHttpAutoProxySvc et iphlpsvc doivent être en cours d’exécution (sur le poste client je suppose ? Ça devrait être le cas par défaut)
• l’authentification multifacteurs (MFA) doit être désactivée pour l’appli Azure représentant le compte de stockage
• l’OS client doit être Win 10 Pro/Entreprise v2004 ou ultérieure, ou Win Server 2022, complètement à jour (note : pour un serveur qui définit les droits, synchronise vers Entra, mais n’accède pas à des partages Azure, un Server 2016 est OK)

Activation de l’auth

Via le portail Azure

Comptes de stockage -> sélectionner le compte -> Stockage des données -> Partages de fichiers
À côté de “Accès basé sur l’identité”, choisir “Configurer” puis choisir “Microsoft Entra Kerberos”.

J’ai personnellement eu une erreur lors de l’activation en passant par le portail Azure (error : is not available with June21 api version alors je suis passé par Powershell.

Via Powershell

Si besoin :
Install-Module -Name Az.Storage
puis
Connect-AzAccount

Pour activer l’auth :

$rgname = "myressourcegroup"
$saname = "mystorageaccount"
Set-AzStorageAccount -ResourceGroupName $rgname -StorageAccountName $saname -EnableAzureActiveDirectoryKerberosForFile $true 

Si on fait ceci depuis un DC local, on peut extraire le nom de domaine local et le GUID de domaine local avec ces commandes :

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot

et on peut alors ajouter ces arguments à la commande précédente :
-ActiveDirectoryDomainName $domainName -ActiveDirectoryDomainGuid $domainGuid

Autorisation de l’application

Étape indispensable

Aller sur Entra ID -> Identité -> Applications -> Inscription des applications
et choisir Toutes les applications

On doit y retrouver une application nommée “[Storage Account] mystorageaccount.file.core.windows.net”
On la sélectionne, puis on ouvre le menu “API autorisées”, et on y coche “Accorder un consentement d’administrateur pour Ma Super Entreprise”

Note : autorisations par défaut :
Microsoft Graph -> Autorisations déléguées :

• openid
• profile
• User.Read

Configuration des clients

Pour rappel, le client doit être hybrid-joined à Entra après avoir été joint au domaine.

Il faut activer un paramètre autorisant la récupération des tickets Kerberos lors du login.
Ceci peut se faire via GPO, mais uniquement sur Server 2019 et ultérieur, via :
Config Ordi -> Stratégies -> Modèles d'administration -> Système -> Kerberos -> Autoriser la récupération du ticket Kerberos cloud lors de la connexion
Je suppose qu’il est possible d’importer le modèle kerberos.admx mais je ne l’ai pas fait.

Si on n’a pas de Server 2019+ dans le domaine, on peut le faire par une entrée de registre ; manuellement via :
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
ou via une GPO qui ajoute une entrée de registre :
Config ordi -> Préférences -> Paramètres Windows -> Registre -> Nouvel Élément registre :

• Update
• HKLM
• Chemin : SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
• Nom : CloudKerberosTicketRetrievalEnabled
• REG_DWORD
• Valeur : 1

C’est également faisable via intune (voir doc MS).

Il est nécessaire de redémarrer pour appliquer ce paramètre.

une fois ceci fait (et un lecteur connecté ?), on devrait pouvoir voir le ticket Kerberos via la commande klist (à lancer en simple utilisteur et non admin).

Accès à des comptes de stockage Azure via une authentification AD locale

L’activation du paramètre pour Kerberos empêche l’accès par ces postes à un autre compte de stockage Azure, qui serait configuré avec l’authentification via AD locale.
S’il était nécessaire de faire cohabiter les 2, il faudra suivre ces étapes

Jonction avec Entra

Les appareils peuvent être enregistrés (Entra registered), joints (Entra joined) ou en jonction hybride (Entra hybrid-joined).

https://www.it-connect.fr/inscription-machines-entra-id-registered-joined-hybrid-joined/
https://learn.microsoft.com/en-us/entra/identity/devices/faq
https://learn.microsoft.com/en-us/entra/identity/devices/manage-stale-devices

Registered

https://learn.microsoft.com/en-us/entra/identity/devices/concept-device-registration

Si on ajoute un “Compte professionnel ou scolaire”, même sur un appareil perso, alors l’appareil apparaît dans Entra en tant que Registered. Il reste la “propriété” du son propriétaire de base.
Dans Entra ID, on voit la personne qui a ajouté le Compte pro ou scolaire. Si cette personne est supprimée d’Entra ID, le propriétaire sera défini à Aucun.

Si on supprime le “Compte professionnel” des paramètres de Windows, l’appareil disparaît d’Entra.

Lors du 1er lancement d’Office, si on refuse la gestion de l’appareil par la société (“Non, se connecter à cette application uniquement”), l’appareil n’apparait pas dans Entra, et le compte n’est pas référencé dans Accès pro ou scolaire.
Si on accepte la gestion, ça ajoute le compte pro/scolaire et inscrit l’appareil dans Entra.

Entra-joined

https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join

L’appareil appartient à l’organisation, et est joint à Entra ID par un admin de l’organisation.
L’architecture administrative est complètement sur le cloud.
Ce mode permet l’accès aux ressources cloud, ainsi que locales.
Le paramétrage des appareils se fait avec un MDM, comme Intune.
Il faut Win Pro ou + (ou Server 2019+).

Pour joindre l’appareil à Entra, il faut aller dans “Compte professionnel ou scolaire”, puis au lieu de rentrer l’adresse mail, il faut sélectionner la proposition, en bas de la fenêtre (sous “Actions alternatives”), “Joindre cet appareil à Microsoft Entra ID”
(si cette proposition n’apparaît pas, c’est probablement un Windows Famille, ou alors l’ordi est déconnecté d’internet)

Le choix du compte qui établit la jonction définit si le poste est automatiquement inscrit dans Intune, ou non (par le réglage d’inscription d’Intune).

Il est impossible d’avoir un appareil qui soit Entra-joined et joint à un domaine ! L’application d’un mode de connexion empêche l’application du second (on aura un message d’erreur si on essaye). Pour avoir cette configuration, il faut faire une jonction hybride.

Entra hybrid-joined

Ce sont les appareils qui sont joints au domaine local, et également “joints” à Entra ID.
le point de départ est la connexion au domaine local. Puis ce domaine doit être configuré pour permettre une jonction hybride (plusieurs méthodes possibles).
Une fois ceci fait, les postes concernés récupéreront automatiquement la connexion à Entra ID.

https://memo.raphaelguetta.fr/post/entra-hybrid-joined

dsregcmd

La commande dsregcmd permet de diagnostiquer le statut et les problèmes de connexion à Entra ID.

On peut ajouter le flag /debug à chaque paramètre pour avoir plus d’infos.

Le flag /forcerecovery force à se reconnecter.

dsregcmd /status permet de voir le statut de connexion actuel de l’appareil. Un article chez MS donne des informations sur chacun des champs, mais j’en liste ici quelques-uns qui me semblent importants.

Sous"Device State", tout en haut :

• AzureAdJoined permet de dire s’il est joint à Entra (si YES, il sera donc joined ou hybrid-joined)
• EnterpriseJoined correspond à Workplace Joined, je n’explore pas cette possibilité
• DomainJoined correspond à un domaine local (si YES, il sera donc joint uniquement au domaine, ou bien hybrid-joined)

Sous"User State" :

• NgcSet correspond à l’utilisation de Windows Hello
• WorkplaceJoined correspond à la présence d’un Compte Professionnel ou scolaire (et le nombre est en dessous, WorkAccountCount)

Sous “Device Details”, on peut trouver l’ID de l’appareil, que l’on retrouvera dans Entra ID (sous ID de l’appareil, et non ID de l’objet).
“Device Details” n’apparaît que si l’appareil est (hybrid-)joint à Entra.
“DeviceAuthStatus” doit être à SUCCESS, sinon c’est qu’il y a un problème au niveau de son enregistrement sur Entra ID.

Sous “Tenant Details”, on voit les détails du tenant Entra (notamment son ID, que l’on retrouve sur la page d’accueil d’Entra).
On y voit aussi MdmUrl, à voir si c’est utile pour la confguration d’Intune ?

Défaire la jonction

Paramètres -> Comptes -> Accès professionnel ou scolaire -> Connecté par xx@xx -> Déconnecter
Ça exige d’avoir un compte admin local auquel on peut se connecter.

On peut aussi défaire la jonction en invite de commande en admin :
dsregcmd /debug /leave
Attention, il n’y a pas de garde-fou, il faut avoir accès à un compte hors de l’organisation pour ouvrir une session après le redémarrage !
Si il n’y avait pas de compte admin, un identifiant de l’organisation sera proposé au redémarrage, sans possibilité de changer, et le mot de passe ne fonctionnera pas.
En ce cas, on peut essayer de réactiver le compte Administrateur, par exemple avec chntpw.

L’appareil disparaîtra d’Entra et Intune.

Admin locaux des appareils

https://learn.microsoft.com/en-us/entra/identity/devices/assign-local-admin

Selon le paramétrage d’Entra, l’utilisateur effectuant la jonction sera admin local du poste, ou non.
Ceci se paramètre dans
Entra admin center -> Entra ID -> Devices -> Overview -> Manage -> Device settings
et activer “Registering user is added as local administrator on the device during Microsoft Entra join (Preview)”.
À noter que l’utilisateur sera supprimé du groupe Local admins si la jonction à Entra est supprimée.

De plus, les utilisateurs avec les rôles Entra suivants :

• “Global Admin”
• “Entra Joined Device Local Administrator”
  auront également les droits admin lorsqu’ils ouvrent une session sur un poste (quel que soit le poste, on ne peut pas filtrer par ce mécanisme).
  Les modifications sur les membres de ces groupes seront bien effectives, même sur des postes qui ont été joints auparavant. Il est nécessaire que le poste récupère un PRT (Primary Refresh Token) pour que ces manips soient appliquées, ce qui peut prendre jusqu’à 4h.
  Il faut aussi se déco/reco.

Si on révoque le rôle Local Admin d’un utilisateur, celui-ci le conserve tant que sa session reste ouverte. À sa prochaine ouverture de session, il ne les aura plus (si la révocation a été synchro sur les serveurs Entra)

On peut voir ces affectations dans netplwiz.
On voit l’utilisateur qui a fait la jonction directement dans les utilisateurs de l’ordinateur.
Si on va dans
lusrmgr.msc -> Groupes -> Administrateurs
on voit les SID, qui correspondent aux rôles Entra d’admin.

Vérification des SID

https://niklastinner.medium.com/convert-entra-roles-to-sids-132d93ea21fc
https://blog.piservices.fr/post/2023/10/28/azure-ad-convertir-un-guid-azure-ad-en-sid-en-utilisant-powershell

Le SID que l’on voit dans Windows n’est pas visible dans Entra. Si on veut vérifier les SID, il faut récupérer l’id du rôle Entra, puis le convertir en SID via un script que des personnes merveilleuses ont écrit et mis à dispo.

Pour récupérer l’id du rôle, aller sur MS Graph Explorer
Se connecter avec un compte ayant les droits d’accès corrects
Exécuter la requête GET sur https://graph.microsoft.com/v1.0/directoryRoles/
Dans le résultat, chercher (Ctrl-F) le rôle en question (par exemple en cherchant “device”).

Une fois trouvé, on copie l’ID, et on le colle dans le script suivant, dans la variable $objectId
On exécute le script via Powershell, et ça nous donne le SID Windows correspondant.

function Convert-AzureAdObjectIdToSid {
<#
.SYNOPSIS
Convert an Azure AD Object ID to SID
  
.DESCRIPTION
Converts an Azure AD Object ID to a SID.
Author: Oliver Kieselbach (oliverkieselbach.com)
The script is provided "AS IS" with no warranties.
  
.PARAMETER ObjectID
The Object ID to convert
#>
 
    param([String] $ObjectId)
 
    $bytes = [Guid]::Parse($ObjectId).ToByteArray()
    $array = New-Object 'UInt32[]' 4
 
    [Buffer]::BlockCopy($bytes, 0, $array, 0, 16)
    $sid = "S-1-12-1-$array".Replace(' ', '-')
 
    return $sid
}
 
$objectId = "73d664e4-0886-4a73-b745-c694da45ddb4"
$sid = Convert-AzureAdObjectIdToSid -ObjectId $objectId
Write-Output $sid

Entra ID

https://entra.microsoft.com

Azure Active Directory (AAD) s’appelle maintenant “Entra ID”.
C’est une solution de gestion des identités et d’authentification, avec 2FA, SSO etc…

Autre portail accessible, via le portail Azure :
https://aad.portal.azure.com/#dashboard

Cout

https://www.microsoft.com/fr-fr/security/business/microsoft-entra-pricing

Différents niveau de prix.
Niveau basique gratuit.
Niveau P1 (Premium 1) inclus dans Microsoft 365 Business Premium (et non Standard)

Le niveau gratuit semble suffire pour une gestion basique.

Réinitialisation de mot de passe libre-service

Non disponible dans les services gratuit. Nécessite Microsoft Entra ID Premium (P1/P2).

2FA/MFA

https://memo.raphaelguetta.fr/post/entra-mfa

Entra Domain Services

Anciennement Azure Active Directory Domain Services (AADDS).
Entra DS Permet de fournir des fonctionnalités de domaine hébergées sur Azure (sans controleur de domaine).
MS appelle ça un “domaine managé” (ou domaine géré).

Il me semble que c’est dédié à l’administration centralisée de serveurs, mais pas pour les machines utilisateurs (le domaine managé n’est pas accessible sans VPN).

Synchronisation avec un AD local

Identité hybride

Présentation chez MS
Lorsqu’un utilisateur possède une identité commune sur les services clouds et le système sur site (on-premises), MS appelle ça une identité hybride.

Il y’a plusieurs façons d’obtenir des identités hybrides.

Password hash Sync : le hash du mot de passe local est synchronisé vers Entra ID ; permet de se connecter directement auprès des services MS avec le même mot de passe que sur le domaine local

Pass-through authentication : les demandes d’authentification auprès du cloud sont transmises au serveur AD on-premises qui les valide

Federation : si l’authentification n’est pas faite par Entra ID mais par un système externe, qui peut avoir ses propres contraintes.

Gestion des utilisateurs

Désactiver l’expiration du mot de passe

Peut se faire en interface web pour l’ensemble des utilisateurs, mais pour du cas par cas, peut uniquement se faire depuis Powershell.

Appareils

https://memo.raphaelguetta.fr/post/entra-jonction-appareils

Les appareils peuvent être enregistrés (Entra registered), joints (Entra joined) ou en jonction hybride (Entra hybrid-joined).
https://www.it-connect.fr/inscription-machines-entra-id-registered-joined-hybrid-joined/

https://learn.microsoft.com/en-us/entra/identity/devices/faq

https://learn.microsoft.com/en-us/entra/identity/devices/manage-stale-devices

Comportement de Win 11 lors de l’OOBE

Pc Win 11 Pro : s’il est setup en tant que “pour le travail ou l’école” :

• si adresse quelconque, message comme quoi ça n’appartient pas à un compte MS pro ou scolaire
• si adresse hotmail, même message d’erreur
• avec adresse qui appartient bien à un domaine géré chez MS 365, le poste apparaît dans Entra ID en tant que “Microsoft Entra joined”.

Pour pouvoir joindre un domaine, il faut se déconnecter de AzureAD (Entra) dans Paramètres -> Comptes -> Accès Professionnel ou Scolaire ; le poste disparaît alors de la liste dans Entra ID.

Généralités

https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-hybrid-join-windows-current

La jonction hybride ne peut se faire que lorsque le poste est déjà joint à un domaine.

Plusieurs possibilités existent pour établir cette jonction. Celle décrite en méthode principale par MS va concerner l’ensemble des postes de la forêt. Elle se fait via Entra Connect Sync, avec une configuration complémentaire (facultative pour la synchro des users/passwords, mais obligatoire pour la jonction hybride généralisée).

Prérequis

En tous les cas, il faudra :

• une synchro des utilisateurs/passwords via Entra Connect Sync
• les droits Administrateur d’entreprise pour la forêt locale
• l’autorisation des utilisateurs de joindre leur machine à Entra ID (c’est un paramètre sur l’annuaire Entra)
• l’accès à certaines URLs Microsoft (voir les détails chez MS ; en l’absence de proxy/firewall/DPI ça ne devrait pas être un souci)

Le paramétrage de la jonction hybride passe par la création d’un point de connection de service (SCP).

Jonction manuelle et contrôlée

Permet de déployer la jonction hybride sur seulement les OU choisies, à fins de test.

https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-join-manual

https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-join-control

Dans mon cas, j’avais déjà activé le SCP via Entra connect Sync avant de le faire manuellement ; si les étapes suivantes ne suffisent pas, peut-être que d’autres étapes, automatisées par Entra Connect Sync sont nécessaires.

Supprimer le SCP si déjà existant

Il faut s’assurer que le SCP est absent de la configuration du DC local.
Pour ceci, lancer la modification ADSI adsiedit.msc et naviguer dans :

• “Configuration [dcname.domain.com]”
• “CN=Configuration,DC=domain,DC=com”
• “CN=Services”
• “CN=Device Registration Configuration”
• clic-droit sur “CN=62a0ff2e-97b9-4513-943f-0d221bd30080” -> “Propriétés” -> “Éditeur d’attributs”
• trouver, si elles existent, les valeurs azureADId et azureADName
• sur chacune d’elles, si elles existent, Modifier -> Supprimer

Déployer les entrées de registre sur les postes clients

Il est nécessaire de déployer les valeurs “TenantId” et “TenantName” sous la clé “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD” .

Pour ceci, on passe par une GPO :

• Config ordi -> Préférences -> Paramètres Windows -> Registre -> Nouvel élément registre (à faire 2 fois)
• Update
• HKLM
• Chemin d’accès : SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
• Nom de valeur : TenantId et TenantName
• Type : REG_SZ
• Valeur : l’ID du tenant (trouvable sur la page d’accueil d’Entra) et le nom de tenant (type monentreprise.onmicrosoft.com , ou utiliser un domaine personnalisé qui a été validé sur MS)

Finalisation

Il faut ensuite attendre (ou déclencher) la synchro Entra Connect Sync (après avoir déployé les clés de registre sur le client). Il apparaîtra dans Entra en tant que “En attente” (Pending).
On peut alors redémarrer le poste pour finaliser la jonction hybride, ou le faire manuellement en administrateur avec la commande dsregcmd /debug /join.
Le poste sera alors considéré comme “hybrid-joined” dans Entra ID avec une date d’inscription.
Cette entrée devrait remplacer l’entrée précédente de type “registered” si elle était présente. On perd également l’information sur la personne qui a joint son compte MS (on le voyait en registered, on ne le voit plus en hybrid-joined). Je suppose qu’on peut retrouver cette info avec Intune.

Si ce n’était pas le cas :

• vérifier que la synchronisation Entra Connect Sync a bien été effectuée récemment, sans erreur
• attendre suffisamment longtemps pour que l’ensemble serveur/client/Entra soit dans le même état (peut prendre 30 minutes)
• vérifier dans Entra -> Appareils que l’appareil est bien présent ; si son type de jointure est “hybrid-joined”, vérifier que son état “Inscrit” est bien une date, et non “En attente”
• s’il est “En attente”, essayer de redémarrer le client, ou lancer dsregcmd /debug /join
• vérifier avec dsregcmd /status s’il y a d’éventuelles erreurs

Suppression de la jonction

Pour sortir définitivement un poste d’Entra ID, je n’ai pas trouvé d’autre solution que de quitter le domaine puis le joindre à nouveau.

Pour quitter la jonction hybride, il faut entrer dans une invite de commande en administrateur et lancer la commande :
dsregcmd /debug /leave
Cette commande met quelques secondes à aboutir, et l’appareil se retrouve instantanément déconnecté (visible dans le résultat de dsregcmd /status).

Tant que les clés de registre TenantId et TenantName restent présentes, il est toujours possible de re-joindre Entra en entrant dsregcmd /debug /join.
Si on les supprime, la jonction hybride ne fonctionnera plus.

Ceci a également pour effet de supprimer complètement l’appareil de Entra ID. Toutefois, si Entra Connect Sync continue de fonctionner sur le serveur, cet appareil sera re-synchronisé à la prochaine sync en tant que hybrid-join, et en “Pending”. Ça semble être lié à son objectGUID.
Pour qu’il ne soit plus du tout synchronisé, il faut sortir le poste du domaine, puis supprimer le compte Ordinateur sur le DC, puis re-joindre le domaine. La nouvelle entité aura un objectGUID différent, ce qui lui permettra de ne pas être considéré comme hybrid-join lorsqu’il est synchronisé.

Dépannage

https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-hybrid-join-windows-current

Suppression accidentelle du poste dans Entra ID

Si un poste est supprimé dans Entra ID sans défaire la jonction avant, celui-ci se pensera toujours hybrid-joined, mais pas Entra ID.
Il réapparaîtra dans Entra ID au cours de la prochaine synchro, mais restera en l’état “Pending”.
Pour être réellmeent ré-enregistré, il est nécessaire de faire dsregcmd /debug /leave puis dsregcmd /debug /join (qui nécessitera une connectivité au DC).
À voir si ça peut être automatisé via GPO ?

Mise en cohérence des domaines

Dans mon cas, l’AD avait été pis en place il y’a longtemps, le domaine local était du genre domain.oldcompany.com, mais les utilsateurs utilisaient aujourd’hui des adresses mail du genre user@newcompany.fr, et l’abonnement O365 avait pour domaine initial unusedcompany.onmicrosoft.com.

Dans ces conditions, la synchro de l’AD vers Azure donnait des identifiants du type nomprenom@unusedcompany.onmicrosoft.com, ce qui rend tout plus pénible, par exemple la connexion à OWA qui ne marche pas avec d’éventuels alias, mais qu’avec cet identifiant.

Comme le domaine initial ne peut être changé, il faut ajouter et vérifier le domaine newcompany.fr dans la gestion des domaines sur le portail O365, connecté en admin de l’abonnement. Pour le vérifier, il faudra aller mettre une preuve TXT dans la zone DNS.
Il faut ensuite ajouter un nouveau suffixe UPN au domaine (Outils d’administration -> Domaines et approbations Active Directory -> Propriétés -> Suffixes UPN), on ajoutera ici newcompany.fr car c’est l’adresse couramment utilisée par l’entreprise. Il faut ensuite modifier les suffixes UPN des utilisateurs dans les Utilisateurs et Ordinateurs AD, pour les passer de p.nom@domaine.oldcompany.fr à p.nom@newcompany.fr. Il est possible de le faire en PowerSehll, par exemple avec ce script

Ainsi, les utilisateurs auront un seul couple adresse/password pour se connecter à tout (Session sur le domaine, OWA, Portail O365 pour télécharger les logiciels etc).

Préparer l’AD local pour la synchro

Pour synchroniser un Active Directory local avec les services Azure Active Directory, il faut commencer par préparer l’AD local (notamment étendre le schéma AD sur un serveur Windows 2012). Cette page de Microsoft détaille beaucoup plus la précédure.

Il faut récupérer une installation d’Exchange 2013, par exemple sur cette page de chez Microsoft. On la décompresse, on lance cmd puis la commande suivante :
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Une fois que le schéma est préparé, on peut identifier les incohérences dans l’annuaire avant de synchroniser avec O365. Pour ça, on utilise l’outil IdFix (DL). Dans le cas où une offre dediée à O365 a été souscrite, il faut aller dans les paramétres et choisir “Dedicated” au lieu de “Multi-tenants”. On clique sur Query, on le laisse chercher, on vérifie puis acccepte les modifications, on fait Apply et on voit ce que ça donne. Si tout va bien, on peut passer à la synchro avec Azure. Si il y’a des problèmes (par exemple attributs non-existants), revérifier que l’AD a bien été préparé tel qu’indiqué sur le tuto de Microsoft.

Mise en oeuvre Azure AD Connect

Télécharger AAD Connect. La dernière version à prendre en charge Windows Server 2012 R2 est la 1.6.16.

Synchronisation du hachage de mot de passe.
Utilisé l’UPN (userPrincipalName) comme nom d’utilisateur AAD.

Powershell

Pour charger le module :
Import-Module ADSync
ou si ça ne fonctionne pas :
Import-Module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync" -Verbose

Une fois installé et configuré, il est possible de synchroniser manuellement avec la commande PowerShell :
start-adsyncsynccycle -policytype delta

Vérification de la synchro

Les utilsateurs et groupes doivent apparaître dans le centre d’admin Office.
On peut aussi vérifier explicitement ici :
https://admin.microsoft.com/#/dirsyncmanagement