BYOD : Le “Workplace Join” de Windows Server 2012 R2 : Partie 2 (Vue du côté Active Directory)

Dans le précédent billet BYOD : Le “Workplace Join” de Windows Server 2012 R2, nous nous sommes intéressés à la description fonctionnelle de la jonction à un Workplace, à la matérialisation de cette jonction par un certificat sur le périphérique client et aux informations sur ce périphérique qui devenaient disponibles sous forme de revendications.

Dans ce nouveau billet, nous allons détailler la cinématique de fonctionnement de la jonction au Workplace avant d’aller regarder en détail dans Active Directory comment est représentée l’association entre le périphérique enregistré et le compte AD de l’utilisateur.

Cinématique de jonction au Workplace

La jonction au Workplace met en relation plusieurs acteurs :

• L’utilisateur qui, depuis le périphérique, déclenche la demande de jonction au Workplace,
• le serveur AD FS qui va prendre en compte l’authentification de l’utilisateur en s’appuyant sur Active Directory,
• le service d’enregistrement DRS (Device Registration Service) qui implémente la fonction d’enregistrement du périphérique,
• et enfin, l’annuaire Active Directory qui va stocker l’information concernant la relation entre l’utilisateur et le périphérique

Si l’on s’intéresse maintenant à la cinématique du processus d’enregistrement :

• L’étape 1 est déclenchée suite à l’action de l’utilisateur pour joindre son périphérique au Workplace ; l’utilisateur est invité à s’authentifier avec son compte utilisateur dans Active Directory. Cette authentification est effectuée par le service AD FS et l’accès authentifié au service DRS à travers le protocole OAuth2 maintenant disponible avec la nouvelle version AD FS de Windows Server 2012 R2.
• En étape 2, le service DRS va procéder à l’enregistrement du périphérique pour ce compte utilisateur en scellant cette association dans Active Directory durant l’étape 3 : un objet de type Device va être créé dans le domaine d’appartenance de l’utilisateur permettant de référencer ce périphérique et de lui associer le compte de l’utilisateur. C’est cette association que représente le petit nuage vert en bas à droite du schéma.
• En étape 4, sur demande du client, un certificat est émis par le service DRS lui-même et retransmis au périphérique qui va le stocker dans le magasin de certificats de l’utilisateur local.

On peut faire deux remarques :

1. Il n’est nul besoin de déployer une infrastructure de PKI ou de s’appuyer sur une infrastructure PKI existante, le service DRS intégrant lui-même sa propre autorité de certification.
2. La jonction au Workplace étant une fonction critique, il est possible d’imposer une authentification multi-facteur ; par exemple, si l’on s’appuie sur la solution Windows Azure Active Authentication (anciennement PhoneFactor), l’utilisateur devra entrer son identifiant et mot de passe puis recevra un appel sur son téléphone portable qu’il devra valider (d’autres modes de vérification sont également disponibles). Cette double vérification permet de s’assurer qu’en cas de vol des credentials de l’utilisateur, la personne malintentionnée ne pourrait pas enregistrer un autre périphérique de manière frauduleuse pour obtenir des accès encore plus privilégiés (sauf à voler également le téléphone et obtenir le code PIN).

Quel intérêt d’enregistrer un périphérique ?

L’association utilisateur-périphérique décrite dans AD va pouvoir ensuite être utilisée comme critère d’évaluation par AD FS pour fournir un second facteur d’authentification transparent : l’utilisateur ne sera autorisé à accéder à une ressource que si le périphérique depuis lequel il effectue l’accès est enregistré et lui est associé. De plus, on dispose d’informations supplémentaires sur le périphérique qui peuvent être prises en compte pour les décisions d’accès à des ressources. Enfin, AD FS génère pour les périphériques enregistrés, un cookie persistant qui permet à l’utilisateur de profiter d’un SSO au-delà de la fermeture de session.

Représentation de la relation périphérique-utilisateur dans Active Directory

Maintenant intéressons-nous à la manière dont est représentée cette association dans Active Directory. Le plus simple est d’utiliser la MMC « Active Directory Users and Computers » et de sélectionner la vue avancée (View\Advanced Features) pour découvrir une nouvelle OU RegisteredDevices. On trouve dans cette OU une liste d’objets de type msDS-Device avec des noms qui ressemblent fortement au format des identifiants utilisés pour les certificats émis pour les périphériques !

Si l’on regarde l’identifiant surligné en bleu (9a358823-0293-4f57-a3bf-a3a44a642e3f), on peut remarquer qu’il correspond au petit nom du certificat qui a été émis pour le périphérique que l’on a enregistré dans le billet précédent (voir ci-dessous).

Allons maintenant regarder de plus près les attributs de cet objet (Properties, onglet Attributes Editor).

Un des attributs les plus intéressants est msDS-RegisteredOwner qui contient l’identifiant de sécurité (SID) du compte utilisateur AD ayant procédé à l’enregistrement. On dispose maintenant dans l’annuaire de la correspondance entre le périphérique et l’utilisateur. La boucle est bouclée : dès lors que l’utilisateur s’est authentifié sur le service AD FS, que le périphérique est capable de présenter le certificat et de prouver qu’il possède la clé privée associée, le service AD FS est en mesure de vérifier que

• Le périphérique est enregistré dans l’annuaire AD
• Le périphérique est associé à l’utilisateur authentifié

Le service AD FS sera donc capable d’accéder aux informations sur le périphérique depuis lequel l’utilisateur accède pour les prendre en compte dans ses propres règles d’autorisation et pour les introduire dans les jetons qu’il émet pour les applications qui lui ont délégué leur authentification (en vocabulaire AD FS, ses Relying Parties).

Ce qu’il faut retenir

La fonction de jonction au Workplace s’appuie sur un service d’enregistrement DRS (Device Registration Service) hébergé par le serveur AD FS. C’est ce service DRS qui génère le certificat installé sur le poste client qui sert de preuve d’enregistrement ; il crée également dans Active Directory un objet scellant la relation entre le périphérique et l’identité de l’utilisateur. Cette jonction au Workplace permet d’obtenir des informations sur le périphérique pouvant être pris comme critères de décision additionnels pour les politiques d’accès à des ressources.

Dans un prochain billet, nous introduirons Web Application Proxy (WAP) dans le paysage de l’authentification et de la protection des applications pour les scénarios BYOD.

Comments

• Anonymous
  January 28, 2015
  Le précédent billet BYOD : Le “Workplace Join” de Windows Server 2012 R2 :