Binding With Encryption

Sensitive data exchanged over a network should be encrypted. To allow this, ADSI supports two types of encryption, Kerberos and Secure Sockets Layer (SSL). Both types of encryption require the use of ADsOpenObject or IADsOpenDSObject::OpenDSObject for binding.

GetObject and ADsGetObject cannot be used for binding in this case because these functions cause the LDAP requests used by ADSI and the data returned from the directory server to transmit across the network as plaintext. For debugging purposes, it is helpful to turn encryption off so the Network Monitor can be used to view the LDAP requests and data between the client and the directory server.

Kerberos-based Encryption

To use Kerberos-based encryption, specify the ADS_USE_SEALING flag when calling ADsOpenObject or IADsOpenDSObject::OpenDSObject. The ADS_USE_SEALING flag can also be used to verify data integrity, that is, to ensure the data received is the same as the data sent. If the ADS_USE_SEALING flag is specified, the ADS_USE_SIGNING flag is automatically specified as well. Both flags require Kerberos authentication, which works only under the following conditions:

• The client computer must be running on Windows 2000, Windows Server 2003, Windows 9x, or Windows NT 4.0 with the directory service client installed.
• The client computer must be a member of a Windows 2000 mixed mode or native mode domain.
• The client computer must be logged on to the Windows 2000 domain, or to a domain trusted by a Windows 2000 domain.
• ADsOpenObject or IADsOpenDSObject::OpenDSObject must be called with null credentials; that is, alternate credentials cannot be specified.

SSL-based Encryption

To use SSL-based encryption, specify the ADS_USE_SSL flag when calling ADsOpenObject or IADsOpenDSObject::OpenDSObject. If only the ADS_USE_SSL flag is specified, ADSI opens SSL port 636 and then performs a simple bind over that SSL channel. If both the ADS_SECURE_AUTHENTICATION and ADS_USE_SSL flags are specified, the binding behavior depends on the client that the call is made from. Prior to Windows Server 2003, ADSI first opens an SSL channel and performs a simple bind using the specified user name and password or the current user context if both user name and password are null. On Windows Server 2003, ADSI performs a secure authentication rather than a simple bind.

To use SSL-based encryption while communicating with Active Directory, Active Directory must have enabled Public Key Infrastructure (PKI). PKI can be enabled by setting up an enterprise certificate authority on one of the servers in Active Directory, including one of the Active Directory servers itself. Setting up an enterprise certificate authority causes an Active Directory server to get a server certificate that can then be used to do SSL-based encryption.