Voici le quatrième article de la série dédiée à la suite EMS (Enterprise Mobility + Security). Au cours des articles précédents, nous avons abordé la mise en place d’un abonnement d’évaluation, la mise en place de l’outil AZURE AD Connect et l’expérience utilisateur apportée par les différents scénarios AZURE AD Connect (Simple Sign on vs Single Sign On avec ADFS).
Nous allons à présent nous intéresser à l’expérience utilisateur en SSO avec Azure AD Join, et voir de quelle façon il sera possible d’obtenir une expérience SSO très intéressante dans un contexte d’entreprise, c’est-à-dire sur un parc de machines jointes à un domaine Active Directory. Nous parlerons également les avantages apportés par Azure AD Join en termes de sécurité.
L’article précédent a détaillé l’expérience utilisateur en SSO avec ADFS. Ce scénario apporte une expérience utilisateur riche des lors que les accès se font depuis l’Intranet. En revanche, les accès effectués depuis l’extérieur de l’entreprise sont très logiquement soumis à une demande d’authentification par formulaire. AZURE AD Join va permettre de délivrer aux utilisateurs une expérience SSO exempte de demande d’authentification, et ce quel que soit l’emplacement utilisé.
Il y a trois méthodes permettant de configurer Windows 10 en vue d’une utilisation professionnelle :
- Jonction à un domaine Active Directory
- Jonction à un domaine Azure AD
- Rattachement d’un compte utilisateur professionnel
Dans tous les cas, cela permet de fournir à l’ordinateur et à ses utilisateurs une identité Azure AD qu’il sera possible de revendiquer auprès des fournisseurs d’applications SaaS. Une fois obtenues, ces identités permettront aux utilisateurs d’accéder en SSO et sans demande d’authentification supplémentaire aux applications SaaS, seule l’authentification de l’ouverture de session étant nécessaire.
Nous nous intéresserons à la seconde méthode, jonction à un domaine Azure AD, mais dans un contexte d’entreprise ou les ordinateurs sont joints à un domaine Active Directory. Notre premier objectif sera d’enregistrer les ordinateurs Windows 10 en tant que périphériques (Devices) auprès de notre instance Azure AD, et ce sans avoir recours à une démarche quelconque des utilisateurs. A l’issue de cette première étape, les ordinateurs seront donc joints à 2 domaines : l’annuaire Active Directory et l’annuaire Azure AD.
L’environnement que nous avons implémenté lors des articles précédents est constitué d’un domaine Active Directory, d’un serveur ADFS et de la plateforme Azure AD Connect. Nous allons utiliser ces composants pour enregistrer automatiquement les ordinateurs du domaine auprès de notre instance Azure AD.
Création d’un point de connexion dans la forêt Active Directory.
En premier lieu, nous devons créer un objet « Service Connection Point » (SCP) dans notre forêt Active Directory. Ce SCP sera utilisé par les ordinateurs du domaine pour localiser l’instance Azure AD associée à la forêt Active Directory. L’objet SCP se trouve dans la partition de configuration de la forêt et porte le nom 62a0ff2e-97b9-4513-943f-0d221bd30080.
Pour créer cet objet, on peut passer par du PowerShell sur le serveur Azure AD Connect (l’installation de Azure AD Connect ajoute le module ADSyncPrep.PSM1 nécessaire à l’opération), mais il faudra préalablement installer sur ce même serveur le module PowerShell « Active Directory ».
Le script à lancer est le suivant (source : https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup )
Le rôle de cet objet est de fournir les informations de l’instance Azure AD aux ordinateurs devant y être joints : Nom de l’instance et Guid.
On pourra vérifier ces informations avec le code PowerShell suivant :
[code language=”PowerShell”]
Clear-Host
$DomainDN = Get-ADDomain | Select-Object -ExpandProperty DistinguishedName
Write-host "Querying SCP Object LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,$DomainDN"
$scp = New-Object System.DirectoryServices.DirectoryEntry
$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,$DomainDN"
$scp.Keywords
[/code]
Ce script nous indique les 2 « Keywords » permettant de localiser notre instance Azure AD : AzureADName et AzureADId
Configuration de la plateforme Azure AD Connect
La configuration de la plateforme Azure AD Connect diffère selon que le domaine est fédéré (SSO avec ADFS) ou géré (Simple Sign On avec synchronisation des hash de mots de passe). Ces modes de fonctionnement ont été décrits sur un précédent article.
On peut obtenir cette information avec la commandelette Get-MSOLDomain :
Dans le cas d’un domaine géré, il suffit de s’assurer que Azure AD Connect synchronise bien les unités organisationnelles détenant les comptes d’ordinateurs devant être joints à Azure AD. L’assistant de configuration de Azure AD Connect nous permet de le vérifier :
Il faudra également activer la fonctionnalité « Device WriteBack », de sorte que les ordinateurs en questions soient enregistrés dans le domaine Active Directory en tant que « Registered Device »
Une fois ce paramétrage en place, les ordinateurs seront inscrits automatiquement dans Azure AD sitôt que Azure AD Connect aura effectué ses tâches de synchronisation. On verra alors apparaitre les objets de type msDS-Device dans le conteneur « RegisteredDevices » du domaine Active Directory grâce à la fonctionnalité « Device Writeback »:
Dans le cas d’un domaine fédéré, il n’est pas nécessaire que Azure AD Connect synchronise les unités organisationnelles des comptes d’ordinateurs, l’enregistrement passera par la plateforme ADFS. Pour cela, il faudra avoir configuré Azure AD Connect en mode fédéré comme décrit sur ce précédent article, et en conservant l’option « Device Writeback » permettant aux « Devices » d’être enregistrés dans l’annuaire Active Directory.
Le processus d’enregistrement des ordinateurs du mode fédéré est plus compliqué que celui du mode géré car il nécessite des règles ADFS permettant cet enregistrement. Ce paramétrage est pris en charge par Azure AD Connect lors de la configuration de l’instance Azure AD en mode fédéré, il n’y a donc (en principe) pas lieu de s’en préoccuper. Le processus d’enregistrement est décrit en détail sur cet article du blog de Jairo CADENA.
L’expérience utilisateur Azure AD Join
Une fois les « Devices » enregistrés dans Azure AD, les utilisateurs bénéficieront d’une expérience SSO améliorée, dans le sens ou le SSO sera effectif sur l’Intranet ainsi qu’à l’extérieur de l’entreprise. L’utilisateur obtiendra à l’ouverture de session un Jeton d’authentification de type « Primary Refresh Token » (PRT) lui permettant d’accéder aux applications accessibles via Azure AD. Ce PRT est utilisé par les applications utilisant ADAL, comme Office 2016, ou les navigateurs IE11 et Edge. Ceci ouvre la voie à un large panel d’applications puisque, comme nous le verrons sur un prochain article, la plateforme Azure AD est à ce jour exploitable par environ 2800 applications SaaS , et il sera possible d’utiliser Azure AD comme méthode d’authentification sur des applications internes publiées par le composant « Azure Application Proxy », intégré à la suite Enterprise Mobility + Security.
Dans le cas du portail Office 365 par exemple, l’accès sur la page https://portal.office.com donne directement accès aux applications accessible, sans avoir à se réauthentifier. Même chose pour le client Outlook 2016, basé sur ADAL, et permettant d’accéder à sa Mailbox Office 365 sans authentification supplémentaire via le PRT.
La valeur ajoutée de Azure AD Join vis à vis de la sécurité.
La fonctionnalité Azure AD Join apporte un intérêt évident en ce qui concerne le confort d’utilisation (amélioration de l’expérience SSO en situation de nomadisme), mais elle permet également d’introduire des règles de sécurité amenées par Azure AD Premium, un des composants de Enterprise Mobility + Security.
Azure AD Premium permet en effet d’ajouter un mécanisme de contrôles d’accès aux applications permettant de n’autoriser les accès qu’à partir de périphériques gérés (enregistrés dans Azure AD)
Le contrôle d’accès conditionnel d’Azure AD Premium nous permettra différentes combinaisons de sécurité parmi lesquelles :
- L’appartenance à un groupe.
- L’emplacement de l’utilisateur (déclencher une authentification forte ou bloquer le compte selon la provenance de la demande)
- Le type de périphérique utilisé (autoriser les accès depuis IOS, Android, Windows Mobile, ou Windows)
- La jonction Azure AD (n’autoriser les accès que depuis les périphériques enregistrés dans Azure AD)
Selon les conditions dans lesquelles la demande sera faite, il sera possible d’appliquer différents niveaux de contrôles :
- Authentification Multi facteur (fonctionnalité également présente dans Azure AD Premium)
- Blocage
Azure AD Join dans les coulisses
Le fonctionnement SSO apporté par Azure AD Join nécessite quelques explications :
L’obtention du PRT se fait lors de l’ouverture de session ou du déverrouillage de celle-ci lorsque l’utilisateur est connecté au réseau d’entreprise. Ce PRT , l’équivalent d’un ticket TGT dans le monde Kerberos, va permettre à l’utilisateur d’obtenir des « Access Token » valides pour des applications qui lui sont autorisées (par exemple Office 365). Sans ce fameux PRT : pas de SSO. Une fois émis, le PRT à une durée de validité pouvant aller jusqu’à 90 jours, ramenée à 14 jours s’il n’est pas utilisé. Source : https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes :
Le PRT a en effet une durée de validité « glissante » : il est émis pour une durée initiale de14 jours pouvant être renouvelée régulièrement (de 14 jours également) sans que ce cumul dépasse les 90 jours par rapport à la date d’émission initiale. Il expire dans tous les cas au-delà de 14 jours de non utilisation.
Lorsqu’il est expiré, le PRT ne permet plus d’accéder aux applications en SSO, il faut alors en obtenir un nouveau et ceci ne peut être fait que par un contact avec un contrôleur de domaine (passage par l’Intranet ou VPN). Ce point devrait faire l’objet d’améliorations dans la future build de Windows 10 car en l’état, l’utilisation du SSO nécessite un contact avec un contrôleur de domaine au moins tous les 14 jours. Sans PRT valide, plus de SSO transparent lorsque l’on se trouve en dehors de l’Intranet : l’utilisateur devra s’authentifier par les méthodes classiques (Authentification par formulaire Web).
Lors de l’enregistrement des ordinateurs, des objets de type « Device » sont créé sur l’instance Azure AD. Le module PowerShell Azure AD nous permet de les identifier :
Ces mêmes objets doivent être présents sur le domaine Active Directory grâce à la fonctionnalité « Device Writeback »
Et enfin, l’utilitaire DSRegCmd.EXE lancé sur un ordinateur joint à Azure AD permet d’obtenir le statut de l’ordinateur. Il permet en particulier d’obtenir des informations relatives à :
- L’état de jonction à un domaine Active Directory
- L’état de jonction à un domaine AZURE AD
- Le statut de l’utilisateur (dispose ou non d’un PRT)
Voila pour aujourd’hui, nous avons fait un tour rapide de la fonctionnalité Azure AD Join, qui va nous ouvrir la voie vers d’autres fonctionnalités de la suite Enterprise Mobility + Security. Pour le prochain article, nous aborderons les fonctionnalité des éditions Azure AD Premium de la suite Enterprise Mobility + Security.