BYOD : Le “Workplace Join” de Windows Server 2012 R2
Comme annoncé dans le 1er billet d’inauguration, l’objectif de ce blog était d’aborder le sujet du BYOD sur un aspect vision et approche mais également selon un angle plus technique permettant de mettre en œuvre des solutions techniques découlant de ces principes. Concernant l’approche technique, nous avons orienté notre travail sur la réalisation de guides étapes par étapes : la série de 5 guides « Bring Your Own Device (BYOD) Test Lab Guides - Series v1.2 » estdisponible en téléchargement depuis le Microsoft Download Center à l’URL https://www.microsoft.com/en-us/download/details.aspx?id=38778.
Dans ce billet technique, nous allons nous intéresser à la fonctionnalité nommée « Workplace Join » (que l’on pourrait traduire par « jonction au lieu de travail ») qui apparaît avec la version Windows Server 2012 R2. Cette nouvelle possibilité conçue pour prendre en compte les scénarios BYOD, permet d’enregistrer un périphérique Windows ou non-Windows dans l’annuaire Active Directory de l’entreprise. Par exemple, il est désormais possible de référencer un périphérique tournant sous iOS (iPad ou iPhone) dans Active Directory. Concernant les OS Windows, la possibilité d’enregistrement est actuellement disponible sur le poste client Windows 8.1 (en version Preview au moment de l’écriture de ce billet) et devrait être rapidement reportée sur Windows 7; les mobiles tournant sous Android sont également en prévision.
Plusieurs questions viennent immédiatement à l’esprit :
- Quelle différence par rapport à la jonction au domaine qui existe depuis que les OS serveurs Microsoft existent ?
- Quel intérêt pour un PC/tablet Windows par rapport à une jonction au domaine ?
- Quel est l’intérêt de référencer les appareils personnels dans Active Directory, pour quels avantages ?
Nous allons tenter de répondre à ces questions en détaillant, dans un premier temps, le principe du Workplace Join et, ensuite, en expliquant quelles informations supplémentaires seront disponibles et comment les utiliser.
Jonction au domaine
Le fait d’intégrer un poste dans un domaine Active Directory non seulement le référence mais le poste va se voir attribuer également un compte de machine avec identifiant de sécurité, un mot de passe etc. ; il va pouvoir s’authentifier en tant que machine sur le domaine (en Kerberos) et recevoir des configurations contrôlées de manière centrale par AD à travers le mécanisme de GPO ; en résumé le poste est connu de l’entreprise, authentifié, et peut être contrôlé de manière centrale y compris au niveau de la configuration des paramètres de sécurité. De plus, d’un point de vue de l’utilisateur c’est le fait de disposer du SSO qui est le plus notable : depuis un poste dans le domaine, tout utilisateur déclaré lui aussi dans le domaine, ou un domaine visible à travers une relation d’approbation, pourra accéder aux ressources sans aucune réauthentification grâce au mécanisme Windows Integrated Authentication (WIA) qui permet de basculer automatiquement entre les protocoles Kerberos et NTLM. Pour rappel, l’accès authentifié à des applications en http/https s’appuyant sur WIA bénéficie également du SSO.
De même, certaines fonctionnalités ne sont disponibles que pour les postes appartenant à un domaine : par exemple DirectAccess, l’établissement de connexions protégées par IPsec, la possibilité d’avoir des revendications machine (claims) dans Active Directory, etc.
Poste Windows hors-domaine
Pour les postes hors-domaine, les choses se compliquent au niveau du SSO ; par défaut lors d’une tentative de connexion à une ressource, l’authentification s’appuiera sur des comptes utilisateurs locaux du client et du serveur ; le compte utilisateur devra être déclaré dans chaque base locale et avec un mot de passe synchronisé si on veut que l’authentification se fasse de manière transparente. Ce mode Workgroup est difficilement concevable dans un scénario d’entreprise où le nombre de postes et de serveurs peut se compter en dizaines de milliers. D’un point de vue sécurité, le poste hors-domaine n’est pas forcément le bienvenu car il n’est ni connu ni contrôlé par l’IT et peut être considéré comme poste pirate.
Un exemple typique et récent est illustré par la tablette Windows RT qui, bien que tournant sous un OS Windows (sur un processeur ARM) ne peut être joint à un domaine Active Directory. Dans un contexte d’entreprise, il sera difficile d’éviter les demandes de réauthentification de l’utilisateur avec son compte de domaine lorsqu’il devra accéder aux différentes ressources.
Périphérique non-Windows
Inutile d’espérer mieux pour les OS non-Windows qui n’implémentent pas cette notion de jonction à un domaine AD ni non plus le protocole Kerberos. Chaque connexion nécessitera d’entrer un couple identifiant-mot de passe sauf à autoriser la mise en cache de ces informations, ce qui n’est pas forcément une bonne pratique de sécurité.
Etape 1 : Jonction au Workplace
Comment se matérialise le Workplace Join du côté du poste client ? En prenant le cas d’un poste Windows 8.1 (hors-domaine), on dispose dans Change PC Settings\Networks de l’option permettant de rejoindre le WorkPlace. Il suffit alors de spécifier l’identité qui sera associée à ce périphérique puis d’entrer dans l’écran suivant les informations d’authentification de l’utilisateur sur le domaine. (Cliquez sur l’image pour agrandir).
Une fois cette étape franchie avec succès, votre périphérique est enregistré dans Active Directory et associé à l’identité. Pour le confirmer, vous verrez affiché au-dessus du bouton Leave, le message “’This device has joined your workplace network”.
Etape 2 : Vérification côté client
Le moyen le plus simple pour vérifier que le périphérique a été correctement enregistré est d’aller explorer le magasin des certificats de l’utilisateur local. On y trouve un certificat avec un nom pas très user-friendly (ici CN=9a358823-…) émis par une autorité de certificat au nom plus évocateur de MS-Organisation-Access.
C’est ce certificat −avec sa clé privée associée− qui va permettre de reconnaitre, d’identifier et d’authentifier ce périphérique. Ces informations pourront être ensuite fournies aux applications sous la forme de revendications présentées dans un jeton SAML à travers le service de jetons ADFS.
Il est intéressant de remarquer qu’il n’est pas nécessaire d’installer une quelconque infrastructure à clé publique et que c’est le service d’enregistrement hébergé sur le serveur ADFS qui a émis ce certificat. Au-delà du CN (MS-Organisation-Access), le nom complet de l’émetteur du certificat montre bien qu’il appartient au domaine contoso.com, qui correspond au domaine créé pour notre maquette (DC=contoso, DC=com).
Etape 3 : Vérification par accès à une application de test
Une application de test basique est disponible dans le SDK Windows Identity Foundation SDK 3.5, qui permet d’afficher les revendications qui lui sont fournies à travers le jeton SAML après que l’utilisateur s’est authentifié auprès du serveur ADFS. Le serveur ADFS a été configuré pour retransmettre à l’application l’ensemble des revendications disponibles.
Sur la page de l’application on doit noter les éléments suivants :
- L’identité de l’utilisateur authentifié : il s’agit de ahaddock appartenant au domaine Contoso
- Un ensemble de revendications liées au périphérique (devicecontext) parmi lesquelles
- Devicecontext/claims/isregistereduser= true qui signifie que l’utilisateur a bien enregistré ce périphérique
- Devicecontext/claims/identifier avec la valeur 9a358823-… qui correspond au CN du certificat de ce périphérique !
Dans un scénario BYOD, cela permet tout simplement de disposer d’informations sur le périphérique à partir duquel l’utilisateur accède à l’application (ou au service) pour prendre des décisions d’accès. On peut, par exemple, imposer que le périphérique soit enregistré (isregistereduser=true) et donc associé à l’identité, et qu’il soit en plus managé (ismanaged=true).
Si vous vous rappelez le billet « BYOD : Ce qui change dans la classification des équipements » dans lequel on parle de classification des terminaux, il devient possible, à travers les informations portées par les revendications de type « device », de distinguer leur catégorie d’appartenance.
Ces informations transportées dans le jeton SAML pourront être utilisées par le nouveau service de passerelle de Windows Server 2012 R2, Web Application Proxy (WAP) qui, s’appuyant sur un serveur de jetons ADFS pour l’authentification, sera capable d’autoriser ou non l’accès à des applications qu’il publie en fonction de ces revendications. Nous aborderons WAP dans un billet à venir.
Ce qu’il faut retenir :
Windows Server 2012 R2 introduit la notion de Workplace Join qui permet d’enregistrer des périphériques mobiles dans l’annuaire Active Directory tout en les associant à une identité. Les informations sur le périphérique peuvent être véhiculées à travers le jeton SAML qui sera proposé à l’application ou services Web par le serveur de jetons ADFS qui aura pris en charge l’authentification.
Dans le prochain billet, nous continuerons à investiguer le sujet du Workplace join mais du côté Active Directory.