Contextes de sécurité et services de domaine Active Directory

  • Article

Lorsqu’une application est liée à un contrôleur de domaine Active Directory , elle le fait dans le contexte de sécurité d’un principal de sécurité, qui peut être un utilisateur ou une entité telle qu’un ordinateur ou un service système. Le contexte de sécurité est le compte d’utilisateur que le système utilise pour appliquer la sécurité lorsqu’un thread tente d’accéder à un objet sécurisable. Ces données incluent l’identificateur de sécurité utilisateur (SID), les appartenances aux groupes et les privilèges.

Un utilisateur établit un contexte de sécurité en présentant des informations d’identification pour l’authentification. Si les informations d’identification sont authentifiées, le système produit un jeton d’accès qui identifie les appartenances au groupe et les privilèges associés au compte d’utilisateur. Le système vérifie votre jeton d’accès lorsque vous tentez d’accéder à un objet d’annuaire. Il compare les données de votre jeton d’accès aux comptes et groupes accordés ou refusés par le descripteur de sécurité d’objet.

Utilisez les méthodes suivantes pour contrôler le contexte de sécurité avec lequel vous liez à un contrôleur de domaine Active Directory :

  • Liez à l’aide de l’option ADS_SECURE_AUTHENTICATION avec la fonction ADsOpenObject ou la méthode IADsOpenDSObject::OpenDSObject et spécifiez explicitement un nom d’utilisateur et un mot de passe. Le système authentifie ces informations d’identification et génère un jeton d’accès qu’il utilise pour la vérification de l’accès pendant la durée de cette liaison. Pour en savoir plus, consultez Authentification.
  • Lier à l’aide de l’option ADS_SECURE_AUTHENTICATION , mais sans spécifier d’informations d’identification. Si vous n’empruntez pas l’identité d’un utilisateur, le système utilise le contexte de sécurité principal de votre application, c’est-à-dire le contexte de sécurité de l’utilisateur qui a démarré votre application. Dans le cas d’un service système, il s’agit du contexte de sécurité du compte de service ou du compte LocalSystem.
  • Empruntez l’identité d’un utilisateur, puis liez-le avec ADS_SECURE_AUTHENTICATION, mais sans spécifier d’informations d’identification. Dans ce cas, le système utilise le contexte de sécurité du client qui est emprunté. Pour plus d’informations, consultez Emprunt d’identité client.
  • Liez à l’aide d’ADsOpenObject ou d’IADsOpenDSObject::OpenDSObject avec l’option ADS_NO_AUTHENTICATION . Cette méthode lie sans authentification et génère « Tout le monde » comme contexte de sécurité. Seul le fournisseur LDAP prend en charge cette option.

Si possible, liez sans spécifier d’informations d’identification. Autrement dit, utilisez le contexte de sécurité de l’utilisateur connecté ou du client emprunté. Cela vous permet d’éviter la mise en cache des informations d’identification. Si vous devez utiliser d’autres informations d’identification d’utilisateur, demandez les informations d’identification, établissez une liaison avec celles-ci, mais ne les mettez pas en cache. Pour utiliser le même contexte de sécurité dans plusieurs opérations de liaison, vous pouvez spécifier le nom d’utilisateur et le mot de passe de la première opération de liaison, puis spécifier uniquement le nom d’utilisateur pour effectuer les liaisons suivantes. Pour plus d’informations sur l’utilisation de cette technique, consultez Authentification.

Certains contextes de sécurité sont plus puissants que d’autres. Par exemple, le compte LocalSystem sur un contrôleur de domaine dispose d’un accès complet à services de domaine Active Directory, tandis qu’un utilisateur classique n’a qu’un accès limité à certains des objets du répertoire. En général, votre application ne doit pas s’exécuter dans un contexte de sécurité puissant, tel que LocalSystem, lorsqu’un contexte de sécurité moins puissant est suffisant pour effectuer les opérations. Cela signifie que vous souhaiterez peut-être diviser votre application en composants distincts, chacun s’exécutant dans un contexte de sécurité approprié aux opérations à effectuer. Par exemple, la configuration de votre application peut être divisée comme suit :

  • Effectuez des modifications de schéma et des extensions dans le contexte d’un utilisateur membre du groupe Administrateurs de schéma.
  • Effectuez des modifications de conteneur de configuration dans le contexte d’un utilisateur membre du groupe Administrateurs d’entreprise.
  • Effectuez des modifications de conteneur de domaine dans le contexte d’un utilisateur membre du groupe Administrateurs de domaine.