Security Contexts and Active Directory

When your application binds to Active Directory, it does so in the security context of a security principal, which can be a human user or an entity such as a computer or a Win32 service. The security context is the user account information that the system uses to enforce security when a thread tries to access a securable object. This information includes such things as the user's security identifier (SID), group memberships, and privileges.

A user establishes a security context by presenting credentials for authentication. If the credentials are authenticated, the system produces an access token that identifies the group memberships and privileges associated with the user's account. The system checks your access token whenever you try to access a directory object. It compares the information in your access token to the accounts and groups allowed or denied access by the object's security descriptor.

You can use the following methods to control the security context with which you bind to Active Directory.

• Bind using the ADS_SECURE_AUTHENTICATION option with the ADsOpenObject function or IADsOpenDSObject::OpenDSObject method and explicitly specify a username and password. The system authenticates these credentials and generates an access token that it uses for access checks for the duration of that binding. For more information, see Authentication.
• Bind using the ADS_SECURE_AUTHENTICATION option but without specifying credentials. If you are not impersonating a user, the system uses the primary security context of your application, that is, the security context of the user who started your application. In the case of a Win32-based service, this is the security context of the service account or the LocalSystem account.
• Impersonate a user and then bind with ADS_SECURE_AUTHENTICATION but without specifying credentials. In this case, the system uses the security context of the client being impersonated. For more information, see Client Impersonation.
• Bind using ADsOpenObject or IADsOpenDSObject::OpenDSObject with the ADS_NO_AUTHENTICATION option. This method binds without authentication and results in "Everyone" as the security context. Only the LDAP provider supports this option.

If possible, you should bind without specifying credentials. In other words, use the security context of the logged-on user or the impersonated client. This enables you to avoid caching credentials. If you must use alternate user credentials, prompt for the credentials, bind with them, but do not cache them. To use the same security context in multiple bind operations, you can specify the user name and password for the first bind operation and then specify only the user name to make subsequent binds. For details on using this technique, see Authentication.

Some security contexts are more powerful than others. For example, the LocalSystem account on a domain controller has complete access to Active Directory, whereas a typical user has only limited access to a some of the objects in the directory. In general, your application should not run in a powerful security context, such as LocalSystem, when a less powerful security context is sufficient to perform the operations you need to perform. This means that you may want to divide your application into separate components, each of which runs in a security context appropriate to the Active Directory operations you need to perform. For example, your application's setup could be broken up as follows:

• Perform schema changes and extensions in the context of a user who is a member of the Schema Admins group.
• Perform configuration container changes in the context of a user who is a member of the Enterprise Admins group.
• Perform domain container changes in the context of a user who is a member of the Domain Admins group.