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.
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: