ADsOpenObject and IADsOpenDSObject::OpenDSObject

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 implicitly use the caller'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 specifying 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.

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 not do so. Instead, don't specify any credentials and implicitly use the credentials of the caller's security context. To bind to a directory object using the caller's credentials with ADsOpenObject or IADsOpenDSObject::OpenDSObject, specify NULL for both username and password.

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.