BYOD : Le “Workplace Join” de Windows Server 2012 R2 : Partie 3 (Enregistrement de l’iPad)

Le mécanisme de jonction au Workplace disponible avec Windows Server 2012 R2 ne s’applique pas uniquement aux périphériques équipés d’un système d’exploitation Windows. Ce billet va décrire l’expérience utilisateur lors du processus d’enregistrement d’un iPad et fournir quelques informations complémentaires sur la mécanique d’enregistrement telle qu’elle est déjà abordée dans les deux billets précédents dont la lecture préalable est recommandée BYOD : Le “Workplace Join” de Windows Server 2012 R2 et BYOD : Le “Workplace Join” de Windows Server 2012 R2 : Partie 2 (Vue du côté Active Directory).

Enregistrement de l’iPad

Pour pouvoir procéder à l’enregistrement de l’iPad, il suffit d’ouvrir le navigateur Safari et d’entrer l’URL https://adf1s.contoso.com/enrollmentserver/otaprofile

La page d’introduction s’affiche indiquant que la jonction au Workplace impliquera l’installation d’un profil.

La page de demande d’authentification AD FS s’affiche dans la foulée : on est invité à entrer l’identité du compte utilisateur Contoso avec lequel le périphérique doit être associé, ainsi que son mot de passe.

Dans le cadre de cette maquette, la jonction au Workplace se fait depuis l’extérieur à travers Web Application Proxy qui joue le rôle de proxy AD FS et permet d’effectuer l’enregistrement en-dehors du réseau interne de l’entreprise. Cette fonction d’enregistrement étant critique, il serait possible de paramétrer une authentification multi-facteur pour exiger, par exemple, que l’utilisateur acquitte un message sur son téléphone portable ou entre un OTP reçu par SMS pour validation.

Une fois l’authentification effectuée – AD FS s’appuie sur Active Directory pour valider les informations d’authentification du compte utilisateur −, l’écran d’invitation de la poursuite du processus d’enrôlement s’affiche. Une case à cocher verte « Verified » indique que le certificat utilisé par le service chargé de l’enregistrement est considéré comme de confiance, et plus précisément que le certificat de l’autorité racine de Contoso ayant délivré de certificat est elle-même considérée comme autorité racine de confiance.

Après appui sur le bouton Install, on reçoit l’avertissement indiquant que l’installation du profil lié à l’enregistrement modifiera les paramètres de l’iPad.

On confirme la poursuite de l’installation en appuyant sur « Install Now » avant d’être invité à entrer le code PIN d’accès de l’iPad.

Le processus d’enregistrement s’exécute et « Profile Installed » s’affiche dans la barre à côté du bouton « Done » indiquant l’achèvement sans erreur de la jonction au Workplace.

Vous venez d’assister à l’enrôlement d’un périphérique non-Microsoft dans l’annuaire Active Directory ( !) en s’appuyant sur la fonction de jonction au Workplace mais à la nuance près que, même si l’iPad va être référencé dans l’annuaire, il ne s’agit pas d’une jonction à un domaine comme pour un poste Windows. Pour vous remémorer la différence entre Workplace Join et Domain Join, référez-vous au billet précédent BYOD : Le “Workplace Join” de Windows Server 2012 R2.

Vérification de l’enregistrement de l’iPad

Pour vérifier simplement au niveau de l’iPad qu’il est correctement enregistré, il suffit d’aller dans Settings\General\Profiles\Workplace Join pour s’assurer que la jonction au Workplace est effective pour le compte utilisateur spécifié (ici ahaddock@contoso.com).

En choisissant More Details, on peut visualiser le certificat avec, comme CN, un identifiant de type GUID (ici faf9d200-…) qui caractérise l’association entre l’utilisateur et sa tablette, ce certificat étant délivré par la PKI MS-Organization-Access intégrée dans le service d’enregistrement DRS.

De la même manière que décrit dans le billet précédent BYOD : Le “Workplace Join” de Windows Server 2012 R2 : Partie 2 (Vue du côté Active Directory), on peut retrouver dans Active Directory la preuve de l’enregistrement du périphérique dans l’OU RegisteredDevices où l’objet de classe Device correspondant au GUID précédent identifie le périphérique à la pomme croquée.

En affichant les attributs, on peut contrôler que l’attribut msDS-DeviceOSType spécifie « iOS ».

 

Accès à l’application de test

L’application de test, qui affiche la liste des revendications qui lui sont présentées en entrée dans le jeton SAML, va permettre de vérifier également que la tablette est bien enregistrée et que les revendications de contexte sur le périphérique sont présentes ; ces informations pourront être ensuite utilisées pour construire des règles de contrôle d’accès.

On peut identifier plusieurs éléments intéressants :

• Tout d’abord la revendication identity/claims/name qui précise l’identité de l’utilisateur accédant à la ressource (contoso\ahaddock) ;
• Ensuite les revendications devicecontext/claims/ostype qui indique qu’il s’agit d’un système d’exploitation iOS et sa version au moment de l’enregistrement devicecontext/claims/osversion ;
• La revendication confirmant que l’utilisateur a été associé à ce périphérique (devicecontext/claims/isregistereduser) ;
• Enfin, des informations telles que la revendication insidecorporatenetwork positionnée à false qui indique que l’accès à l’application a été fait depuis l’extérieur avec un proxy nommé WAP (devicecontext/claims/x-ms-proxy indiquant WAP) et l’adresse IP du périphérique accédant (devicecontext/claims/x-ms-forwarded-client-ip).

Concernant ces dernières informations, elles sont ajoutées en chemin par le composant Web Application Proxy (WAP) qui, en tant qu’intermédiaire, relaie la requête du poste vers l’application.

Désenregistrement de l’iPad du Workplace

La suppression de cette relation utilisateur-périphérique, concrétisée par la jonction au Workplace, peut être réalisée à travers l’interface de l’iPad en naviguant sur Settings\General\Profiles\Workplace Join.

Il suffit d’appuyer sur le bouton Remove…

Et de confirmer la suppression du profil.

Le certificat généré lors de la jonction au Workplace sera supprimé du périphérique, invalidant immédiatement son enregistrement. Les informations de type devicecontext ne seront plus disponibles et toute règle prenant en compte ces revendications pourra contrôler ou refuser l’accès à l’utilisateur ; les règles peuvent être paramétrées au niveau du serveur de jetons AD FS pour autoriser l’émission du jeton, ou intégrées au niveau de l’application elle-même en fonction des valeurs des revendications qui lui sont transmises).

Dans un scénario de perte ou vol, où l’on n’a plus accès au périphérique mobile, l’invalidation de la jonction au Worlpkace peut se faire par le simple geste administratif consistant à supprimer dans Active Directory l’objet Device associé à périphérique dans l’OU RegisteredDevice. La relation n’existant plus entre le périphérique et l’utilisateur, la preuve de possession du certificat sur l’iPad devient caduque.

Ce qu’il faut retenir

La fonction de jonction à un Workplace intégrée dans Windows Server 2012 R2 ne concerne pas uniquement les OS Windows ; la démonstration est faite dans ce billet avec l’enregistrement d’un périphérique mobile non-Windows : l’iPad. L’enregistrement est initié à partir du navigateur et crée un profil sur l’iPad intégrant un certificat délivré par le service d’enregistrement DRS. L’association entre le périphérique et l’utilisateur est également consignée dans Active Directory sous la forme d’un objet de classe Device. Dès lors, les revendications liées au périphérique sont disponibles pour appliquer si besoin des règles de contrôle d’accès : par exemple, on peut autoriser l’accès uniquement à des périphériques enregistrés, à certains types d’OS, ou imposer une authentification multi-facteur, etc. Enfin la jonction au Workplace peut être supprimée soit à partir de l’iPad, soit dévalidée à partir de l’annuaire Active Directory dans un scénario de perte ou de vol.