De plus en plus fréquemment, j’interviens chez des clients qui construisent des solutions d’automatisation via PowerShell ou d’autres langages pour automatiser des tâches d’administration dans les services reposant sur Microsoft Graph incluant Azure Active Directory, Microsoft Endpoint Manager (Intune), Autopilot, Microsoft 365, etc. Je me rends compte que beaucoup ne suivent pas les bonnes pratiques en la matière en créant des comptes utilisateurs parfois exclus des règles d’accès conditionnel pour faire tourner ces tâches planifiées et automatisées.
Il existe pourtant des méthodes très simples, efficaces, et sécurisées pour se connecter au Graph de Microsoft sans pour autant abaisser le niveau de sécurité mis en place. Vous pouvez pour cela utiliser :
- Les Service Principals correspondent à une application Azure AD dont les tokens peuvent être utiliser pour s’authentifier et obtenir l’accès à des ressources Azure spécifiques.
- Les Managed Identities sont dans le principe similaire aux Service Principals à la différence qu’elles sont liées à des ressources Azure. On en retrouve deux formats : les System assigned Managed Identities qui sont liées à une seule ressource Azure (VM, Web App, etc.) et les User assigned Managed Identities qui sont crées de manière autonome puis assignées à plusieurs ressources Azure.
Vous l’aurez compris chacune des solutions couvre un enjeu : Les Managed Identities peuvent être utilisées pour administrer vos ressources Azure alors que les Service Principals peuvent être utilisés pour gérer des services Cloud (Microsoft 365, Intune, etc.)
Dans cet article, j’aborderais la création d’un Service Principal dans le but d’exécuter par exemple des scripts de traitement sur un des services cités plus haut. On retrouve différentes étapes :
- La création d’un certificat autosigné ou issu d’une autorité de certification de l’entreprise (plus sécurisé).
- Création d’une application Azure Active Directory utilisée pour l’authentification
- Associer le certificat
- Associer les droits Microsoft Graph
- Optionnel : Création d’une règle d’accès conditionnel pour sécuriser ces charges de travail. Cette étape peut être optionnelle mais elle permet de s’assurer que l’application ne peut être utilisée pour s’authentifier que depuis certains réseaux.
- Mise en pratique
Création d’un certificat
On retrouve deux options :
- Créer un certificat à partir de l’autorité de certification de l’entreprise en utilisant un modèle disposant des capacités : Client Authentication. Cette méthode est la plus adéquate car elle permet de révoquer le certificat et faire connaître cette révocation via la liste de révocation de certificat (CRL).
- Créer un certificat autosigné.
Je détaillerais simplement la création d’un certificat autosigné mais vous pouvez aisément utiliser votre PKI.
Idéalement, sur la machine qui exécutera les scripts, exécutez les commandes suivantes pour créer un certificat autosigné valable 6 mois :
$pwd = "<Le Mot de passe de la clé privée du certificat>"
$notAfter = (Get-Date).AddMonths(6) # Valide pour 6 mois
$thumb = (New-SelfSignedCertificate -DnsName "<Nom du tenant>.onmicrosoft.com" -CertStoreLocation "cert:\LocalMachine\My" -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter $notAfter).Thumbprint
$pwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText
Export-PfxCertificate -cert "cert:\localmachine\my\$thumb" -FilePath c:\temp\CertAutomatisation.pfx -Password $pwd
Le certificat apparaît dans le store de la machine ainsi qu’à l’emplacement spécifié
L’étape suivante consiste à exporter le certificat sans sa clé privée :
Note : Je ne détaille pas l’intégralité des étapes d’export mais veillez à ne pas cocher l’export de la clé privée et à exporter le certificat au format CER.
Création d’une application Azure Active Directory
Cette étape permet la création d’une application Azure AD qui sera utilisé pour réaliser l’authentification ainsi que la délégation des permissions adéquates.
Il n’existe pas une seule règle quant à la création des applications Azure AD, ceci doit être réfléchi et dépendre de la gouvernance en place. Vous pouvez par exemple :
- Créer des applications Azure AD dédié par équipe avec les droits granulaires nécessaires à l’automatisation des tâches de l’équipe
- Créer des applications Azure AD dédié à certaines tâches / applications avec les droits granulaires nécessaires à l’automatisation des tâches de l’application
Pour ce faire, ouvrez le portail d’administration d’Azure Active Directory et naviguez dans App Registration puis cliquez sur New registration :
Entrez le nom de l’application et sélectionnez Account in this organizational directory only puis choisssez Register.
Associer le certificat
Une fois l’application créée, vous devez associer le certificat qui sera utilisée pour s’authentifier. Pour cela, une fois l’application créée, choisissez Certificates & Secrets.
Choisissez Certificate si vous utilisez un certificat et cliquez sur Upload certificate.
Sélectionnez le certificat précédemment exporté dans l’étape 1 et spécifiez une description puis cliquez sur Add.
Une fois importé, vous retrouvez le certificat dans le portail :
Maintenant que vous avez configuré les capacités qui vous permettront de vous authentifier, vous pouvez passer à l’association des droits Microsoft Graph dont vous aurez besoin.
Associer les droits Microsoft Graph
On retrouve différents types de permissions :
- Delegated correspond à des permissions déléguées à des utilisateurs pouvant se connecter physiquement au service.
- Application correspond aux permissions déléguées pour des applications ou des services comme c’est le cas pour les Service Principals. Ce sont ces permissions qui nous intéressent.
Pour associer les droits, cliquez sur API Permissions.
Commencez par supprimer la permission User.Read Delegated :
Confirmez la suppression.
Cliquez ensuite sur Add a permission :
La page de sélection des APIs vous permet de choisir les services cibles. On retrouve notamment :
- Microsoft Graph qui propose des permissions pour Office 365, Azure AD, Microsoft Endpoint Manager (Intune), Autopilot, OneNote, SharePoint, Planner, Microsoft Information Protection, etc.
- Azure DevOps
- Azure Services Management
- Intune pour des permissions relatives à des intégrations partenaires (Data Warehouse, Stratégie de conformité partenaire, etc.)
- Etc.
Dans la majorité des cas, ce seront les permissions issues de Microsoft Graph qui vous intéresserons.
Comme expliqué précédemment, choisissez ensuite Application permissions :
Une fois sélectionné, vous avez accès à l’ensemble des catégories de permissions disponibles. Choisissez ensuite de manière granulaire toutes les permissions que vous souhaitez mettre à disposition :
Cliquez sur Add permissions.
Une fois ajouté, les permissions apparaissent. Vous devez ensuite donner le consentement pour le tenant en cliquant grant admin consent for <Tenant>
Vous constatez ensuite que les droits ont été consentis :
Création d’une règle d’accès conditionnel pour sécuriser ces charges de travail
Cette étape n’est pas obligatoire mais fortement recommandée puisqu’elle permet de s’assurer que cette application Azure AD et ses permissions associées, ne peut être utilisée que dans certaines conditions (notamment d’être présent sur un réseau spécifique).
Pour ce faire, ouvrez le portail d’administration Azure AD et naviguez dans Azure Active Directory puis Security et Conditional Access. Choisissez Named locations puis cliquez IP ranges location :
Nommez l’emplacement et ajoutez les adresses IP en cliquant sur + puis en spécifiant l’adresse IP ou la plage associée et Add. Enfin, cliquez sur Create.
Dans Policies, cliquez sur New policy et Create new policy.
Nommez la stratégie d’accès conditionnel selon votre convention de nommage puis cliquez sur Users or workload identities. Choisissez Workload identities et :
- Choisissez All owned service principals pour cibler tous ces types de charges de travail. Avant validez les types de charge de travail pour s’assurer de l’impact associée.
- Choisissez select service principals et le service principal associé.
Choisissez ensuite Cloud Apps or actions puis sélectionnez All cloud apps :
Dans Conditions, ouvrez Locations. Cliquez sur Configure : Yes puis Any location dans Include.
Cliquez sur Exclude puis select et choisissez l’emplacement nommé précédemment créé.
Dans Grant, vérifiez que la condition Block Access est sélectionnée :
Cliquez sur On pour activer la stratégie puis Create. Accessoirement, vous pouvez la créer en mode Report-Only pour voir l’impact de la stratégie via l’espace Sign-In logs.
Mise en pratique
Vous pouvez ensuite utiliser le module Microsoft.Graph et les commandes suivantes pour se connecter.
Pour se connecter, on retrouve deux solutions :
- Utiliser le certificat présent dans le store de l’utilisateur
Import-module Microsoft.Graph
Connect-MGGraph -TenantId "<TenantID>" -ClientId "<ClientID de l’application>" -CertificateThumbprint "EMPREINTE/THUMBPRINT du certificat"
- Utiliser le certificat présent physiquement sur le disque
Import-module Microsoft.Graph
# Load from path.
$password= "<Le Mot de passe de la clé privée du certificat>"
$passwordSecure = ConvertTo-SecureString -AsPlainText -Force $password
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<Chemin vers le certificat PFX>\ CertAutomatisation.pfx", $passwordSecure)
Connect-MGGraph -TenantId "<TenantID>" -ClientId "<ClientID de l’application>" -Certificate $cert
Note : L’identifiant cliente de l’application peut se trouver sur la page Overview / Aperçu de l’application que nous avons créé précédemment.
Vous pouvez ensuite lancer une commande permettant de lister les ressources sur lesquelles vous avez les droits.
Bon scripting !
