Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Comment fonctionne le SSO avec les périphériques Windows 10

Posted by Teruin laurent sur octobre 23, 2017


Bonjour vous trouverez ci-joint une traduction d’un article de Jairo Cadena très intéressant précisant les mécanismes d’authentification Azure AD

Article original : https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/comment-page-1/#comment-1307

Thanks Jairo !

Le SSO sous Windows 10 fonctionne pour les types d’applications suivantes :

  • Les applications connectées à Azure AD, dont Office 365, les applications SaaS, les applications publiées via le proxy d’applications AD Azure et les applications personnalisées LOB intégrées à Azure AD.
  • Les Applications et services d’authentification intégrés Windows.
  • ADFS lors de l’utilisation d’ADFS dans Windows Server 2016.

Le jeton de rafraîchissement primaire (PRT)

Le SSO s’appuie sur des jetons spéciaux obtenus pour chacun des types d’applications ci-dessus. Ceux-ci sont à leur tour utilisés pour obtenir des jetons d’accès à des applications spécifiques. Dans le cas de l’authentification traditionnelle Windows Integrated utilisant Kerberos, ce jeton est un TGT Kerberos (ticket-granting ticket). Pour les applications ADFS d’azure, nous appelons cela un jeton de rafraîchissement primaire (PRT). Il s’agit d’un Web Token JSON contenant des revendications concernant à la fois l’utilisateur et le périphérique.

Le PRT est initialement obtenu lors de la connexion Windows (identification/déverrouillage de l’utilisateur) de la même manière que le TGT Kerberos. Ceci est vrai pour les appareils joints à Azure AD joints et les appareils reliés à un domaine. Dans les appareils personnels enregistrés auprès d’Azure AD, le PRT est initialement obtenu sur Add Work ou School Account (dans un appareil personnel, le compte pour déverrouiller l’appareil n’est pas le compte de travail mais un compte grand public, par exemple hotmail. com, live. com, outlook. com, etc.)

Le PRT est nécessaire pour le SSO. Sans cela, l’utilisateur sera invité à fournir des informations d’identification lors de l’accès aux applications à chaque fois. Veuillez également noter que le PRT contient des informations sur l’appareil. Cela signifie que si vous avez une politique d’accès conditionnel basée sur un périphérique défini sur une application, sans le PRT, l’accès sera refusé.

Validité du PRT

Le PRT a une validité de 90 jours avec une fenêtre coulissante de 14 jours. Si le PRT est constamment utilisé pour obtenir des jetons d’accès aux applications, il sera valide pendant toute la durée de 90 jours. Après 90 jours, il expire et un nouveau PRT doit être obtenu. Si le PRT n’a pas été utilisé dans un délai de 14 jours, le PRT expire et un nouveau PRT doit être obtenu. Les conditions qui imposent l’expiration du PRT en dehors de ces conditions incluent des événements tels que le changement/réinitialisation du mot de passe de l’utilisateur.

Pour les appareils raccordés au domaine et Azure AD, le renouvellement du PRT est tenté toutes les 4 heures. Cela signifie que le premier sign-in/unlock, 4 heures après l’obtention de l’outillage, on tente d’obtenir un nouveau PRT

Maintenant, il y a un cas spécifique pour les périphériques liés au domaine. La tentative d’obtenir un nouveau PRT n’a lieu que si le périphérique a une connexion vers un DC (pour une connexion réseau complète Kerberos qui déclenche également la connexion AD Azure). C’est un comportement que nous voulons changer et espérons faire pour la prochaine mise à jour de Windows. Ce changement impliquera que même si l’utilisateur quitte le réseau d’entreprise, le PRT pourra se mettre à jour. L’implication de ce comportement aujourd’hui, est qu’un périphérique connecté à un domaine doit entrer dans le réseau d’entreprise (physiquement ou via VPN) au moins une fois tous les 14 jours.

 

Domaine joints/Azure AD dispositifs joints et SSO

L’étape par étape suivante montre comment le PRT est obtenu et comment il est utilisé pour le SSO.


 

(1) L’utilisateur entre ses informations d’identification dans l’interface utilisateur Windows Logon

Dans l’interface utilisateur Windows Logon, l’utilisateur saisit des informations d’identification pour se connecter/débloquer le périphérique. Les informations de connexions sont obtenues par un fournisseur d’identification. Si vous utilisez un nom d’utilisateur et un mot de passe, le fournisseur d’identification pour le nom d’utilisateur et le mot de passe est utilisé, si vous utilisez Windows Hello for Business (PIN ou bio-gesture), le fournisseur d’identification pour la reconnaissance du NIP, des empreintes digitales ou des visages est utilisé.


(2) Les identifiants sont transmis au plug-in Cloud AP Azure AD pour authentification

Le Credential Provider obtient les informations d’identification de WinLogon qui appellera l’API LsaLogonUser () avec les informations d’identification de l’utilisateur. Les informations d’identification sont transmises à un nouveau composant de Windows 10 appelé Cloud Authentication Provider (Cloud AP). Il s’agit d’un composant à base de plug-in fonctionnant dans le processus LSASS (Local Security Authority Subsystem) avec un plug-in étant le plug-in Azure AD Cloud AP plug-in. Pour plus de simplicité dans le diagramme, ces deux éléments sont représentés sous la forme d’une boîte Cloud AP.

Le plug-in va authentifier l’utilisateur via AD et ADFS (si Windows Server 2016) pour obtenir le PRT. Le plug-in connaîtra le tenant Azure AD et la présence de l’ADFS par les informations mises en cache lors de l’enregistrement de l’appareil.Lorsque les informations du jeton d’identification sont obtenues et mises en cache juste avant l’enregistrement (l’explication s’applique aux dispositifs joints de domaine enregistrés avec Azure AD et Azure AD joints dispositifs).

 

(3) Authentification de l’utilisateur et du dispositif pour obtenir PRT d’Azure AD (et AD FS si fédéré et version de Windows Server 2016)

En fonction des informations d’identification utilisées, le plug-in obtiendra le PRT par des appels distincts vers Azure AD et ADFS.

  • PRT basé sur nom d’utilisateur et mot de passe
    • Pour obtenir le PRT AD Azure en utilisant un nom d’utilisateur et un mot de passe, le plug-in enverra les informations d’identification directement à Azure AD (dans une configuration non fédérée) ou à ADFS (si fédéré). Dans le cas fédéré, le plug-in enverra les informations d’identification au point d’extrémité suivant de WS-trust dans ADFS pour obtenir un jeton SAML qui sera ensuite envoyé à Azure AD.
    • Azure AD authentifiera l’utilisateur avec les informations d’identification obtenues (non fédérées) ou en vérifiant le jeton SAML obtenu auprès d’AD FS (fédéré). Après l’authentification, Azure AD construira un PRT avec les déclarations de l’utilisateur et du périphérique et le retournera à Windows.
  • PRT basé dans le système d’exploitation Windows Hello for Business Identification
    • Pour obtenir l’outil Azure AD PRT en utilisant l’identifiant Windows Hello for Business, le plug-in enverra un message à Azure AD auquel il répondra par un nonce. Le plug-in répondra avec le nonce signé avec la clé d’identification Windows Hello for Business.
    • Azure AD authentifiera l’utilisateur en vérifiant la signature basée sur la clé publique qu’il a enregistrée lors de l’approvisionnement d’accréditation comme expliqué dans le post Azure AD et Microsoft Passport for Work in Windows 10 (veuillez noter que Windows Hello for Business est le nouveau nom de Microsoft Passport for Work).
      LE PRT contiendra des informations sur l’utilisateur et l’appareil, mais une différence avec le PRT obtenu en utilisant le nom d’utilisateur et le mot de passe, est que celui-ci contiendra une demande d’authentification forte.
    • Indépendamment de la façon dont le PRT a été obtenu, une clé de session est incluse dans la réponse qui est cryptée vers le Kstk (une des clés fournies lors de l’enregistrement du périphérique comme expliqué à l’étape 4 de la post AD Join d’azure: que se passe-t-il en coulisse?).
    • La clé de session est décryptée par le plug-in et importée dans la TPM à l’aide du Kstk. Lors de la ré-authentification, le PRT est envoyé à Azure AD de façon signée en utilisant une version dérivée de la clé de session précédemment importée et stockée dans la TPM qu’Azure AD peut vérifier. De cette façon, nous lions le PRT au dispositif physique, ce qui réduit le risque de vol du PRT.

(4) Cache du PRT pour le Web Account Manager afin d’y accéder lors de l’authentification de l’application

Une fois que le PRT est obtenu, il est mis en cache dans l’autorité locale de sécurité (LSA). Il est accessible par le Gestionnaire de comptes Web, qui est également un composant à base de plug-in qui fournit une API pour les applications permettant d’obtenir des jetons à partir d’un fournisseur d’identité donné (IdP). Il peut accéder au PRT par l’intermédiaire du Cloud AP (qui a accès au PRT) qui vérifie un identificateur d’application particulier pour le Gestionnaire de comptes Web. Il existe un plug-in pour le Gestionnaire de comptes Web qui implémente la logique pour obtenir des jetons à partir d’Azure AD et AD FS (si AD FS dans Windows Server 2016).

Vous pouvez voir si un PRT a été obtenu après l’identification/déblocage en vérifiant l’édition de la commande suivante.

dsregcmd.exe /status

 

Dans la section « Etat utilisateur », vérifiez la valeur d’AzureAdPrt qui doit être OUI.


Une valeur de NO indique qu’aucun PRT n’a été obtenu. L’utilisateur n’aura pas de SSO et ne pourra pas accéder aux applications de service qui sont protégées par une politique d’accès conditionnel basée sur les périphériques.

 

(5.6 et 7) Demande d’accès aux demandes d’application token à Web Account Manager pour un service d’application donné

Lorsqu’une application client se connecte à une application de service qui s’appuie sur Azure AD pour l’authentification (par exemple l’application Outlook se connectant à Office 365 Exchange Online), l’application demandera un jeton au Gestionnaire de comptes Web à l’aide de son API.

Le Gestionnaire de comptes Web appelle le plug-in Azure AD qui, à son tour, utilise le PRT pour obtenir un jeton d’accès pour l’application de service en question (5).

Il y a deux interfaces en particulier qui sont importantes à noter.

Celui qui permet à une application d’obtenir un jeton silencieusement, qui utilisera le PRT dans le but d’obtenir un jeton d’accès (silencieusement) s’il le peut. Si ce n’est pas possible, il renverra un code à l’application appelante lui indiquant qu’une interaction avec l’interface utilisateur est requise. Une fois que l’application appelante reçoit ce code, elle pourra appeler une API distincte qui affichera un contrôle Web pour permettre à l’utilisateur d’interagir.

Après avoir retourné le jeton d’accès à l’application (6), l’application cliente utilisera le jeton d’accès pour accéder à l’application de service (7).

Navigateur SSO

Lorsque l’utilisateur accède à une application de service via Microsoft Edge ou Internet Explorer, l’application redirige le navigateur vers l’URL d’authentification Azure AD.

À ce stade, la demande est interceptée via URLMON et le PRT est inclus dans la demande. Une fois les authentifications réussies, Azure AD renvoie un cookie qui contiendra des informations SSO pour les demandes futures. Veuillez noter que la prise en charge de Google Chrome est disponible depuis la mise à jour Creators de Windows 10 (version 1703) via l’extension Google Chrome des comptes Windows 10.

Publicités

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :