Microsoft Entra ID

Objectif : lire un tenant Microsoft Entra ID (API Microsoft Graph, lecture seule) pour en tirer les appareils, les comptes privilégiés et les chemins d'administration du cloud.

Le connecteur se règle sur Connecteurs → Microsoft Entra ID :

• identité du tenant ;
• application enregistrée ;
• secret client ou certificat ;
• périmètre des appareils ;
• balayage des comptes et groupes.

Le résultat se consulte sur la page Entra ID du menu Sécurité (/entra/).

Méthode d'authentification : on en choisit une seule. Avec « Secret client », seul le champ Secret client est à remplir ; avec « Certificat », ce sont Certificat (PEM public) et Clé privée (PEM). La page n'affiche que les champs de la méthode choisie ; ceux de l'autre méthode peuvent rester vides.

Ce qu'Entra alimente dans InfraRiver

Où	Quoi
Inventaire des serveurs	Les appareils Entra du périmètre choisi (serveurs seulement par défaut), rapprochés des serveurs déjà connus
Inventaire des comptes (/vue-accounts/)	Les utilisateurs (type « cloud ») et les service principals (type « service »), source « Microsoft Entra ID »
Chemins d'administration	Rôles annuaire, permissions Graph dangereuses, propriétaires, pivot Active Directory → Entra, administrateurs locaux d'appareils, exécution via Intune
Fiche d'un serveur	Un encart « Intune » (conformité, chiffrement, dernière synchronisation) quand le serveur est aussi un appareil Intune
Page Entra ID	Tout ce qui précède, plus les groupes et les constats (MFA, invités)

Quels appareils deviennent des serveurs

Le réglage Périmètre des devices de la page du connecteur décide quels appareils Entra entrent dans l'inventaire :

Périmètre	Appareils retenus
servers_only (par défaut)	Les Linux serveur (Ubuntu, Debian, Red Hat, Rocky, SUSE…) et les Windows Server reconnus par leur numéro de build
managed	Tout appareil joint à l'annuaire (AzureAd ou ServerAd), quel que soit son système
all	Tous les appareils, postes personnels compris

Graph indique seulement « Windows » pour un Windows Server comme pour un poste : InfraRiver lit donc la version du système (par exemple 10.0.20348.2655) et la compare à la table des builds. Les builds 14393, 17763 et 20348 sont les Windows Server 2016, 2019 et 2022 ; les builds 19041 à 19045, 22000, 22621 et 22631 sont des postes Windows 10 ou 11. La build 26100 est à la fois Windows Server 2025 et Windows 11 24H2 : elle est retenue comme Windows Server 2025 seulement si Intune (famille d'édition « Server ») ou l'ordinateur Active Directory de même identifiant le confirme. Sans confirmation, l'appareil reste hors de l'inventaire, avec la raison indiquée.

Le système et sa version sont enregistrés sur la fiche du serveur et alimentent la fin de support (EOLRIVER).

Rien n'est exclu sans trace. Chaque synchronisation écrit dans le journal : appareils lus · retenus · exclus comme postes · sans OS reconnu. Les mêmes chiffres s'affichent sous le réglage du périmètre, avec le lien voir les appareils exclus : nom, système lu dans Graph, version et raison (« poste de travail », « build 26100 ambiguë »…). « Sans OS reconnu » regroupe les appareils dont le système ne permet pas de dire s'ils sont des serveurs (aucun système renseigné, build Windows inconnue, distribution Linux inconnue).

Complément Intune. Quand le profil Intune est accordé, InfraRiver lit aussi la version du système, l'édition, le modèle, le constructeur, le numéro de série, la mémoire et le disque de l'appareil. Pour un serveur venu d'Entra, ces valeurs complètent la fiche : version du système si Graph ne la donne pas, mémoire vive si elle est vide, le reste (modèle, constructeur, numéro de série) étant conservé avec la source « Microsoft Entra ID ». Si Graph refuse l'un de ces champs, InfraRiver relit la liste de base et Intune reste utilisable. Si Graph refuse cette lecture étendue, InfraRiver retombe sur la liste de base et l'indique : un avertissement s'affiche sur la page du connecteur et dans les angles morts de la page Entra ID (« Intune enrichi à moitié »). L'édition de Windows (skuFamily) n'existe que dans l'API bêta de Graph : elle est lue à part, et son absence ne laisse que le numéro de build pour distinguer un Windows Server 2025 d'un poste.

Groupes et appartenances

Les groupes ne figurent pas dans l'inventaire des comptes : ils se consultent sur l'onglet « Identités » de la page Entra ID.

Le connecteur lit les appartenances directes aux groupes et la dernière connexion de chaque utilisateur. La lecture des appartenances demande un appel par groupe : sur un tenant de plusieurs milliers de groupes, la synchronisation est plus longue.

Les groupes imbriqués (un groupe qui en contient un autre) sont suivis niveau par niveau :

• la fiche d'un groupe donne ses membres directs et le total en suivant les groupes imbriqués, avec le chemin (« via … ») ;
• la fiche d'un utilisateur donne tous les groupes dont il fait partie, directement ou non ;
• un groupe de plus de 5 000 membres est conservé tronqué.

Rapprochement avec Active Directory, Keycloak et Zabbix

Un compte synchronisé depuis Active Directory est relié à son compte AD par le SID on-premises : sur la fiche de l'un, l'autre apparaît en « identité confirmée (SID) ».

Un compte cloud seul n'a pas de SID. Il est relié à un compte AD par un UPN identique (badge « même UPN »), à défaut seulement « par nom ».

Un compte Entra est aussi retrouvé dans Keycloak et Zabbix quand l'adresse e-mail (ou le nom de connexion) est identique à son UPN ou à son adresse principale — jamais sur une ressemblance. La fiche d'un utilisateur Entra montre ces correspondances.

Pour permettre ce rapprochement, Keycloak conserve maintenant l'adresse e-mail de ses utilisateurs, et Zabbix celle de leur premier moyen d'envoi e-mail actif (si le compte d'API peut le lire).

Objets supprimés ou disparus

Un objet supprimé du tenant disparaît de ces listes à la synchronisation suivante.

Un chemin d'administration ou un constat de compte (MFA, invité) que le connecteur ne revoit plus depuis plus de deux intervalles de synchronisation est retiré lui aussi : rôle retiré, permission révoquée, application supprimée. Les cartes et le bandeau de synchronisation comptent donc les mêmes chemins.

Décocher le balayage des utilisateurs, des groupes ou des service principals retire de même ce type d'objets.

Ce que le connecteur ouvre : Entra ID et Microsoft 365

Le connecteur Entra ID porte toute la partie Microsoft d'InfraRiver, avec la même application enregistrée, la même synchronisation et le même journal :

Page	Question à laquelle elle répond	Droit
Entra ID (/entra/)	Qui peut administrer quoi, et quels comptes, groupes, appareils ou applications sont à risque ?	Connecteurs — lecture ; accepter un risque : Connecteurs — gestion
Microsoft 365 (/m365/)	Le tenant est-il configuré selon un référentiel (Secure Score, EIDSCA, SCuBA) ? Voir le guide.	Microsoft 365 — voir la conformité (administrateur, auditeur) ; accepter un risque : administrateur

Il faut que le connecteur soit activé pour voir ces pages : désactivé (Administration → Connecteurs), elles se ferment (erreur 404) et leurs liens disparaissent du menu et de la recherche ; les données déjà collectées restent en base et reviennent à la réactivation.

La page de configuration du connecteur reprend ce récapitulatif en bas de page :

• pages disponibles et droits ;
• différence entre Entra ID et Microsoft 365 ;
• permissions Graph à accorder par profil du script (securite, intune, m365) et effet de leur absence ;
• licences qui changent ce qui est lisible ;
• ce que le connecteur ne fait pas.

Créer l'application et accorder les permissions

La page de configuration propose la carte Créer l'application et accorder les permissions (Azure Cloud Shell). Elle évite de sélectionner les permissions Graph une par une dans le portail : le script crée l'App Registration (ou complète l'existante), déclare toutes les permissions en lecture seule des profils cochés et accorde le consentement administrateur.

1. Cochez les profils : Sécurité (obligatoire), Intune, Microsoft 365 / Secure Score (cochés par défaut) et Licences (facultatif). Oublier Intune laisse vides les onglets Intune.
2. Dans le portail Azure, ouvrez Cloud Shell, choisissez Bash, avec un compte Global Administrator ou Privileged Role Administrator.
3. Cliquez Copier la commande et collez-la dans Cloud Shell (elle contient le script en entier), ou Télécharger le script puis lancez bash new-infrariver-entra-app.sh --profiles securite,intune,m365.
4. Reportez le tenant_id et le client_id affichés en fin de script dans les paramètres de connexion, puis ajoutez un secret ou un certificat à l'application dans le portail.

Le script se relance sans risque : s'il a été lancé sans Intune, relancez-le avec Intune pour compléter les permissions. --dry-run affiche la liste sans rien modifier, et le script refuse toute permission qui ne serait pas en lecture seule.

La page Entra ID

En tête : l'état du connecteur, la dernière synchronisation et dix cartes. Les cartes cliquables ouvrent le tableau déjà filtré.

Carte	Ce qu'elle compte
Identités du tenant	Utilisateurs, groupes et service principals lus (ouvre l'onglet « Identités »)
Constats à traiter	Constats de l'onglet Analyses non acceptés (seuil de dormance de 90 jours)
Appareils Intune	Appareils enrôlés dans Intune (ouvre l'onglet « Appareils Intune »)
Appareils Entra	Appareils rapprochés dans l'inventaire des serveurs (ouvre l'inventaire filtré sur la source Entra)
Comptes privilégiés (ouvre les identités privilégiées)	Comptes, groupes ou applications porteurs d'un rôle annuaire sensible, d'une permission applicative dangereuse ou propriétaires d'un objet privilégié
Chemins d'administration	Lignes « qui peut faire quoi sur quoi » déduites de ces droits
Global Administrators	Comptes ayant le rôle Global Administrator
Permissions Graph dangereuses	Permissions applicatives de lecture-écriture sensibles accordées à une application
Sans MFA enregistré	Comptes sans aucune méthode d'authentification multifacteur
Politiques d'accès conditionnel	Politiques lues dans le tenant

La page compte six onglets, au format des autres inventaires (filtre par colonne, tri, pagination). Un clic sur un onglet ne change que le tableau : la page garde sa position, et l'adresse (?view=…) peut être partagée ou rechargée. Le nombre affiché sur l'onglet est celui des lignes qu'il contient :

• Chemins d'administration ;
• Identités ;
• Analyses ;
• Appareils Intune ;
• Déploiements Intune (déploiements et politiques) ;
• Comptes et signaux.

Onglet Chemins d'administration

Chaque ligne donne : qui, cible, capacité, type, mécanisme, confiance, signaux (par exemple secret récent) et date de dernière observation.

Les types possibles :

• rôle annuaire ;
• permission Graph ;
• propriétaire d'objet ;
• pivot Active Directory → Entra ;
• domaine fédéré ;
• administrateur local d'appareil ;
• exécution via Intune.

Note

Toutes les lignes sont « déclarées » : le connecteur lit des droits, il n'observe pas leur usage.

Onglet Identités

Tous les objets lus, avec filtres par colonne. Colonnes :

• nom ;
• type (utilisateur, invité, groupe, service principal) ;
• actif ou non ;
• détail (groupe de sécurité, attribuable à un rôle, synchronisé depuis l'AD, nombre de membres) ;
• date de création ;
• dernier changement de mot de passe ;
• dernière connexion ;
• privilège et sa raison.

Un clic sur le nom ouvre la fiche de l'identité : ses informations, ses groupes, les groupes dont il est propriétaire, ses chemins d'administration et ses constats. Pour un groupe, la fiche ajoute ses propriétaires, sa règle d'appartenance s'il est dynamique et ses membres.

Onglet Analyses

Les constats de sécurité calculés sur le tenant, avec filtres par gravité, catégorie, constat et compte. Ils sont recalculés à chaque synchronisation : un constat disparaît quand la situation est corrigée.

Le seuil « Dormant après N jours » se règle dans l'en-tête de la colonne Détail (90 par défaut).

Accepter un risque. Le bouton Accepter le risque (droit de gérer les connecteurs) ouvre un formulaire qui demande :

• une justification (5 caractères au moins) ;
• une durée : 30 jours, 90 jours par défaut, 6 mois ou 1 an — une date de fin est obligatoire ;
• un motif : « Risque accepté » ou « Objet de test ».

L'acceptation est inscrite au journal d'audit. Le constat quitte la liste « À traiter » et se retrouve sous « Acceptés » avec qui l'a accepté, quand, jusqu'à quand et pourquoi. À l'échéance il revient dans « À traiter » ; on peut aussi le rouvrir à tout moment.

Constats calculés :

Catégorie	Constat	Gravité
Authentification	Compte privilégié sans MFA enregistré	Critique pour Global Administrator, Privileged Role Administrator ou Privileged Authentication Administrator, élevée sinon
Authentification	Compte privilégié exclu d'une politique qui impose le MFA	Élevée
Authentification	Compte privilégié avec MFA faible seulement (SMS, appel vocal)	Moyenne
Privilèges	Peut devenir Global Administrator sans l'être : Privileged Role Administrator, Privileged Authentication Administrator, ou une application avec RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All ou Application.ReadWrite.All	Critique ou élevée selon le cas
Privilèges	Invité porteur d'un rôle privilégié	Élevée
Privilèges	Compte désactivé mais toujours privilégié	Moyenne
Comptes dormants	Compte privilégié dormant	Élevée
Comptes dormants	Invité dormant	Moyenne
Comptes dormants	Compte actif dormant	Faible
Applications	Service principal privilégié avec un secret expiré	Moyenne
Applications	Service principal privilégié avec un secret de très longue durée	Faible
Groupes	Groupes imbriqués en boucle	Moyenne
Groupes	Groupe privilégié sans aucun membre (attribution sans effet)	Faible
Groupes	Groupe privilégié à plus de trois niveaux d'imbrication	Faible
Accès conditionnel	Aucune politique d'accès conditionnel	Élevée
Accès conditionnel	Aucune politique appliquée n'impose le MFA à tous les utilisateurs	Élevée
Accès conditionnel	Aucune politique appliquée ne bloque l'authentification héritée	Moyenne
Accès conditionnel	Des politiques existent mais aucune n'est appliquée (désactivées ou en simple rapport)	Moyenne
Intune	Script, remédiation ou application poussé à tout le parc (élevée pour un script qui s'exécute en SYSTEM, moyenne sinon)	Élevée ou moyenne
Intune	Appareil d'un administrateur non conforme, non chiffré, débridé ou sans synchronisation récente	Élevée
Intune	Aucune politique d'approbation multi-administrateur (élevée si des déploiements ou des droits d'exécution Intune existent)	Moyenne ou élevée
Intune	Aucune politique de conformité	Élevée
Intune	Plateforme (Windows, iOS, macOS, Android) dont des appareils sont enrôlés mais sans politique de conformité ayant un destinataire	Élevée
Intune	Politique de conformité sans destinataire	Moyenne
Intune	Réglage « marquer non conformes les appareils sans politique » désactivé (un poste sans politique passe pour sain)	Moyenne
Intune	Délai de non-connexion à 0 jour (un appareil qui ne se connecte plus reste conforme)	Faible
Intune	Appareils débridés	Élevée
Intune	Appareils non conformes (élevée à partir de 20 % du parc)	Moyenne ou élevée
Intune	Appareils non chiffrés	Moyenne
Intune	Appareils dont l'utilisateur principal a été supprimé ou désactivé	Moyenne
Intune	Appareils sans synchronisation depuis 30 jours	Faible
Groupes	Groupe sensible (privilégié, attribuable à un rôle ou cible d'un déploiement Intune) sans propriétaire	Moyenne
Groupes	Groupe sensible dont un propriétaire est invité, désactivé ou inconnu	Moyenne
Groupes	Groupe sensible à appartenance dynamique (quiconque peut modifier les attributs visés par la règle y entre)	Moyenne
Autres sources	Compte désactivé dans Entra mais toujours actif dans Keycloak (élevée si privilégié) ou présent dans Zabbix	Moyenne ou élevée
Autres sources	Compte Keycloak ou Zabbix actif, avec une adresse du domaine de l'entreprise, sans compte Entra	Moyenne
Synchronisation AD	Compte privilégié synchronisé depuis l'AD (qui contrôle le compte dans l'AD contrôle le rôle dans le cloud)	Moyenne
Synchronisation AD	Compte désactivé dans l'AD mais actif dans Entra (privilégié : élevée)	Moyenne
Synchronisation AD	Compte synchronisé dont le SID est introuvable dans l'AD collecté	Faible

Conditions d'évaluation

• Les constats Intune regroupent les appareils par constat (« 12 appareils sur 340 », avec un lien vers la liste filtrée) ; seuls les appareils d'administrateurs et les déploiements sont listés un par un.
• Les constats Intune ne sont évalués que si Intune a pu être lu (permissions DeviceManagement*.Read.All).
• Les constats d'accès conditionnel ne sont évalués que si la lecture des politiques a réussi (permission Policy.Read.All) : une liste vide n'est un constat que si elle a bien été lue.
• Les croisements avec l'AD n'existent que si le connecteur Active Directory a collecté des comptes.

Onglet Appareils Intune

Les appareils enrôlés. Le nom est un lien vers la fiche du serveur quand l'appareil est aussi un serveur de l'inventaire : même appareil Entra, sinon même nom unique.

Colonnes :

• nom ;
• système ;
• propriété (entreprise / personnel) ;
• utilisateur principal, avec la mention « privilégié » quand c'est un administrateur ;
• conformité ;
• chiffrement ;
• dernière synchronisation.

Le filtre « À risque » isole les appareils :

• non conformes ;
• non chiffrés ;
• débridés (jailbreak / root) ;
• sans synchronisation depuis 30 jours ;
• dont l'utilisateur principal a été supprimé ou désactivé.

Onglet Déploiements Intune

Les scripts PowerShell, scripts shell macOS, remédiations proactives et applications poussés par Intune. Pour chacun : type, compte d'exécution (SYSTEM ou utilisateur) et destinataires (tout le parc, des groupes, aucune affectation). Jamais le contenu d'un script.

Le filtre « Tout le parc » montre ce qui touche toutes les machines.

La liste contient aussi les politiques de conformité (plateforme, destinataires) et les politiques d'approbation multi-administrateur (plateforme ou type, groupes d'approbateurs).

Onglet Comptes et signaux

Un constat par ligne :

• rôle annuaire actif ou éligible ;
• permission applicative ;
• propriétaire d'objet ;
• aucune méthode MFA enregistrée ;
• MFA faible ;
• exclusion des politiques MFA.

Angles morts affichés

Quand la licence du tenant ne permet pas de tout lire, un bandeau le dit au lieu de laisser croire que tout est couvert :

• PIM (Entra ID P2 ou Governance) : sans lui, un administrateur seulement éligible n'apparaît pas.
• Dernières connexions (Entra ID P1 ou P2 et permission AuditLog.Read.All) : sans elles, les règles de comptes dormants ne sont pas évaluées.
• Politiques d'accès conditionnel (permission Policy.Read.All) : sans elle, les constats d'accès conditionnel ne sont pas évalués.
• Méthodes d'authentification (Entra ID P1 ou P2) : sans elles, « Sans MFA enregistré » et « MFA faible » ne sont pas calculables.

Droits

La page est visible avec le droit de lecture sur les connecteurs ; le bouton « Configuration du connecteur » demande le droit de les gérer.