Fonctionnement de l’authentification unique auprès de ressources locales sur des appareils joints à Azure AD

Ce n’est probablement pas une surprise qu’un appareil joint à Azure Active Directory (Azure AD) vous offre une expérience d’authentification unique auprès des applications cloud de votre locataire. Si votre environnement dispose d’Active Directory Domain Services en local, vous pouvez étendre l’expérience SSO sur les appareils joints Azure AD à des ressources et applications s’appuyant sur un AD local.

Cet article explique comment cela fonctionne.

Prérequis

  • Un appareil joint à Azure AD.
  • L’authentification unique locale exige une communication à visibilité directe avec vos contrôleurs de domaine AD DS locaux. Si les appareils joints Azure AD ne sont pas connectés au réseau de votre organisation, un réseau privé virtuel ou une autre infrastructure réseau sont requis.
  • Azure AD Connect : Pour synchroniser les attributs utilisateur par défaut, comme le nom de compte SAM, le nom de domaine et l’UPN. pour plus d’informations, consultez l’article Attributs synchronisés par Azure AD Connect.

Fonctionnement

Avec un appareil joint à Azure AD, vos utilisateurs ont déjà une expérience de l’authentification unique après des applications cloud de votre environnement. Si votre environnement comporte un AD Azure et un AD sur site, vous souhaiterez peut-être étendre le champ de votre expérience SSO à vos applications de ligne de métier (LOB) sur site, aux partages de fichiers et aux imprimantes.

Les appareils joints à AD Azure n’ont pas connaissance de votre environnement AD local, car ils n’y sont pas joints. Cependant, vous pouvez fournir à ces appareils des informations supplémentaires sur votre annuaire AD local avec Azure AD Connect.

Si vous avez un environnement hybride, avec à la fois Azure AD et un AD local, il est probable que vous avez déjà déployé Azure AD Connect ou la synchronisation cloud Azure AD Connect pour synchroniser vos informations d’identité locales sur le cloud. Dans le cadre du processus de synchronisation, les informations locales de l’utilisateur et du domaine sont synchronisées sur Azure AD. Quand un utilisateur se connecte à un appareil joint à Azure AD dans un environnement hybride :

  1. Azure AD renvoie les détails du domaine local de l’utilisateur à l’appareil, ainsi que le jeton d’actualisation principal
  2. Le service de l’autorité de sécurité locale (LSA) active l’authentification Kerberoset NTLM sur l’appareil.

Notes

Une configuration supplémentaire est requise lorsque l’authentification par mot de passe pour des appareils joints Azure AD est utilisée.

Pour une authentification sans mot de passe basée sur une clé de sécurité FIDO2 et l’approbation au niveau du cloud hybride Windows Hello Entreprise, consultez Activer la connexion par clé de sécurité sans mot de passe aux ressources locales avec Azure Active Directory.

Pour l’approbation au niveau de la clé hybride Windows Hello Entreprise, consultez Configurer des appareils joints à Azure AD pour l’authentification unique locale avec Windows Hello Entreprise.

Pour l’approbation de certificats hybrides Windows Hello Entreprise, consultez Utilisation de certificats pour l’authentification unique locale AADJ.

Lors d’une tentative d’accès à une ressource demandant Kerberos ou NTLM dans l’environnement local de l’utilisateur, l’appareil :

  1. Envoie les informations du domaine local et les informations d’identification au contrôleur de domaine localisé pour authentifier l’utilisateur.
  2. Reçoit un ticket TGT (Ticket-Granting Ticket) Kerberos ou un jeton NTLM basé sur le protocole pris en charge par la ressource ou l’application locale. Si la tentative d’obtenir le ticket TGT Kerberos ou le jeton NTLM pour le domaine échoue (le délai d’expiration du DCLocator associé peut entraîner un retard), des entrées du gestionnaire d’informations d’identification sont tentées ou l’utilisateur peut recevoir une fenêtre contextuelle d’authentification demandant des informations d’identification pour la ressource cible.

Toutes les applications qui sont configurées pour l’authentification Windows intégrée bénéficient automatiquement de l’authentification unique quand un utilisateur tente d’y accéder.

Ce que vous obtenez

Avec l’authentification unique, sur un appareil joint à Azure AD, vous pouvez :

  • Accéder à un chemin UNC sur un serveur membre d’AD
  • Accéder à un serveur web membre d’AD configuré pour la sécurité intégrée de Windows

Si vous voulez gérer votre annuaire AD local à partir d’un appareil Windows, installez les Outils d’administration de serveur distant.

Vous pouvez utiliser :

  • Le composant logiciel enfichable ADUC (Active Directory Users and Computers) pour administrer tous les objets AD. Cependant, vous devez spécifier manuellement le domaine auquel vous voulez vous connecter.
  • Le composant logiciel enfichable DHCP pour administrer un serveur DHCP joint à AD. Cependant, il peut être nécessaire de spécifier le nom ou l’adresse du serveur DHCP.

Ce que vous devez savoir

  • Il peut être nécessaire d’ajuster votre filtrage par domaine dans Azure AD Connect pour que les données sur les domaines nécessaires soient synchronisées si vous avez plusieurs domaines.
  • Les applications et les ressources qui dépendent de l’authentification de la machine Active Directory ne fonctionnent pas, car les appareils joints à Azure AD n’ont pas d’objet ordinateur dans AD.
  • Vous ne pouvez pas partager des fichiers avec d’autres utilisateurs sur un appareil joint à Azure AD.
  • Les applications qui s’exécutent sur votre appareil joint Azure AD peuvent authentifier les utilisateurs. Ils doivent utiliser l’UPN implicite ou la syntaxe de type NT4 avec le nom complet du domaine comme partie du domaine, par exemple : user@contoso.corp.com ou contoso.corp.com\user.
    • Si les applications utilisent le nom NETBIOS ou le nom hérité comme contoso\user, les erreurs reçues par l’application sont soit l’erreur STATUS_BAD_VALIDATION_CLASS - 0xc00000a7, soit l’erreur Windows ERROR_BAD_VALIDATION_CLASS - 1348 « La classe d’informations de validation demandée était non valide ». Cela se produit même si vous pouvez résoudre le nom de domaine hérité.

Étapes suivantes

Pour plus d’informations, consultez Présentation de la gestion des appareils dans Azure Active Directory.