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.
|
|
4.4.2.1 Using a graphical user interface
Open LDP. From the menu, select
Connection Connect. For Server, enter the name of a DC. For Port, enter 389. Click OK. From the menu, select Options Connection Options. Under Option Name: select LDAP_OPT_FAST_CONCURRENT_BIND Click the Set button From the menu, select Connection Bind. Enter credentials of a user. 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>", _
ADS_FAST_BIND)
4.4.4 See Also
MSDN: Using Concurrent Binding and MSDN:
ADS_AUTHENTICATION_ENUM
|