Partager via


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

Lorsqu’une application est liée à un contrôleur de domaine Active Directory (DC), 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 les 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 effectuez une liaison à un contrôleur de domaine Active Directory :

  • Liez à l’aide de l’option ADS_SECURE_AUTHENTICATION avec la fonction ADsOpenObject ou IADsOpenDSObject ::OpenDSObject méthode 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 plus d’informations, consultez d’authentification .
  • Liez à 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 emprunt d’identité. Pour plus d’informations, consultez l’emprunt d’identité client.
  • Liez à l’aide ADsOpenObject ou IADsOpenDSObject ::OpenDSObject avec l’option ADS_NO_AUTHENTICATION. Cette méthode se 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 d’identité. Cela vous permet d’éviter la mise en cache des informations d’identification. Si vous devez utiliser d’autres informations d’identification utilisateur, invitez les informations d’identification, liez-les, 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 des liaisons ultérieures. Pour plus d’informations sur l’utilisation de cette technique, consultez d’authentification.

Certains contextes de sécurité sont plus puissants que d’autres. Par exemple, le compte LocalSystem sur un contrôleur de domaine a un accès complet aux services de domaine Active Directory, tandis qu’un utilisateur classique n’a qu’un accès limité à certains objets dans l’annuaire. 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émas.
  • 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.