quote:

---

ADsOpenObject and IADsOpenDSObject::OpenDSObject
[This is preliminary documentation and subject to change.]

The major advantages of using ADsOpenObject and IADsOpenDSObject::OpenDSObject are the following:

The ability to specify an alternate user name and password to authenticate to the directory.
The ability to use encryption to protect the data exchange over the network between your application and the directory server.
It is recommended that you use the logged on user's credentials whenever possible. However, if you need to supply alternate credentials, you can use these Open methods. If you choose to bind using alternate credentials, do not cache the password. You can use the same alternate credentials in multiple bind operations by specifying the user name and password for the first bind operation and then specify only the user name to make subsequent binds. The system sets up a session on the first call and uses the same session on subsequent bind calls as long as the following conditions are met:

You specify the same user name in each bind operation.
You use serverless binding or bind to the same server in each bind operation.
You keep the session open by holding on to an object reference from one of the bind operations. The session is closed when the last object reference is released.
ADsOpenObject and IADsOpenDSObject::OpenDSObject take advantage of the Windows NT Security Support Provider Interfaces (SSPI) to allow flexibility in authentication options. The major advantage of using these interfaces is to provide different types of authentication to Active Directory clients and to encrypt the session. Currently, ADSI does not allow certificates to be passed in. Therefore, you can use SSL for encryption and then Kerberos, NTLM, or simple authentication, depending on how the flags are set on the dwReserved parameter. Note that you cannot ask for a specific SSPI provider in ADSI, although you will always get the highest preference protocol. In the case of a Windows 2000 client binding to a Windows 2000 server, the protocol is Kerberos. For a Windows NT 4.0 client binding to a Windows 2000 server, the protocol is NTLM. Not allowing a certificate for authentication is fine in the case of a Web page, because authentication occurs prior to running the Web page.

Although Open operations allow you to specify a user and password, you should use the current logged on user context to bind and leverage that user context to control access to the directory. If you use ADsOpenObject or IADsOpenDSObject::OpenDSObject to bind to an object, specify NULL for both username and password to use the current logged-on user's credentials. When an application binds using a user's credentials, that application can access only the objects and object properties to which that particular user has access. If the user does not have read access to an object, the application never sees the object when accessing the object in that user's context.

Finally, if you want to bind with no authentication, you can use the ADS_NO_AUTHENTICATION flag. No authentication means that ADSI attempts to bind as an anonymous user to the target object and performs no authentication. This is equivalent to requesting anonymous binding in LDAP and means "Everyone" is the security context.

---