Recipe 4.4 Using a Fast or Concurrent Bind

4.4.1 Problem

You want to perform an LDAP bind using a concurrent bind, also known as a fast bind. Concurrent binds are typically used in situations where you need to authenticate a lot of users, but those users do not need to directly access the directory or the directory access is done with another account.

4.4.2 Solution

This works only on a Windows Server 2003 domain controller. Using a graphical user interface
  1. Open LDP.

  2. From the menu, select Connection Connect.

  3. For Server, enter the name of a DC.

  4. For Port, enter 389.

  5. Click OK.

  6. From the menu, select Options Connection Options.

  7. Under Option Name: select LDAP_OPT_FAST_CONCURRENT_BIND

  8. Click the Set button

  9. From the menu, select Connection Bind.

  10. Enter credentials of a user.

  11. Click OK.

4.4.3 Discussion

Concurrent binding, unlike simple binding, does not generate a security token or determine a user's group memberships during the authentication process. It only determines if the authenticating user has a valid enabled account and password, which makes it much faster than a typical bind. Concurrent binding is implemented as a session option that is set after you establish a connection to a domain controller, but before any bind attempts are made. After the option has been set, any bind attempt made with the connection will be a concurrent bind.

There are a couple of caveats when using concurrent binds. First, you cannot enable signing or encryption, which means that all data for concurrent binds will be unencrypted over the network. Secondly, because the user's security token is not generated, access to the directory is done anonymously and access restrictions are based on the ANONYMOUS LOGON principal.

It is worth mentioning that there is another type of bind that is also known as a "fast bind," which has been available since Windows 2000, but it is completely different from the procedure I just described. This fast bind is implemented within ADSI, and simply means that when you fast bind to an object, the objectClass attribute for the object is not retrieved; therefore, the object-specific IADs class interfaces are not available. For example, if you bound to a user object using an ADSI fast bind, then only the basic IADs interfaces would be available, not the IADsUser interfaces. This is the complete list of interfaces that are available for objects retrieved with fast binds: IADs, IADsContainer, IDirectoryObject, IDirectorySearch, IADsPropertyList, IADsObjectOptions, ISupportErrorInfo, and IADsDeleteOps.

You must use IADsOpenDSObject::OpenDSObject interface to enable fast binds. If you call IADsContainer::GetObject on a child object of a parent you used a fast bind with, the same fast bind behavior applies. Unlike concurrent binds, ADSI fast binds do not impose any restrictions on the authenticating user. It means that the object-specific IADs interfaces will not be available. Also, no check is done to verify the object exists when you call OpenDSObject.

ADSI fast binds are useful when you need to make a lot of updates to objects you know exist (perhaps from an ADO query that returned a list of DNs) and you do not need any IADs-specific interfaces. Instead of two trips over the network per object binding, there would only be one. Here is example code that shows how to do an ADSI fast bind:

const ADS_FAST_BIND = 32
set objLDAP = GetObject("LDAP:")
set objUser = objLDAP.OpenDSObject("LDAP://<ObjectDN>", _
                                     "<UserUPN>", _
                                     "<UserPassword>", _ 

4.4.4 See Also

MSDN: Using Concurrent Binding and MSDN: ADS_AUTHENTICATION_ENUM

    Chapter 3. Domain Controllers, Global Catalogs, and FSMOs
    Chapter 6. Users
    Appendix A. Tool List