Understanding ADAM bind redirection
Updated: August 22, 2005
Applies To: Windows Server 2003 R2
ADAM bind redirection
Active Directory Application Mode (ADAM) bind redirection is designed for use primarily with legacy applications that are unable to authenticate directly against Active Directory but still need to use ADAM as the application data store. Through bind redirection, ADAM can accept a bind request from an application and redirect this bind request to Active Directory, based on the contents of a proxy object. A proxy object in ADAM represents an Active Directory security principal, and it can be augmented to store additional data related to that security principal that is specific to the application. Through bind redirection, applications can take advantage of the identity store of Active Directory without any additional overhead. For example, if an administrator disables an account in Active Directory, that account can no longer be used to bind to ADAM. In addition, applications retain the flexibility of using ADAM as an application data store.
Proxy objects for bind redirection
Bind redirection relies on the existence of stub, or proxy, objects in ADAM, each of which represents an Active Directory security principal. To implement bind redirection, you first create a proxy object schema definition to store data that is specific to your application. In this definition, you include the msDS-bindProxy auxiliary class. The msds-BindProxy class possesses a single "must contain" attribute, ObjectSid, which holds the security ID (SID) of the associated Active Directory security principal. You can initially populate ADAM with proxy objects representing Active Directory users through a synchronization mechanism, such as Microsoft Identity Integration Server 2003, or through the construction and importation of .ldf files into ADAM.
Processing bind requests
When a user sends a bind request to ADAM, ADAM does the following based on the type of request:
For simple bind requests:
If the object class to which the user requests a bind possesses msDS-bindableObject as a static auxiliary class, ADAM processes the bind request directly, generating a security context that is based on the ADAM user's SID.
If, instead, the object class to which the user requests a bind possesses the msDS-bindProxy as an auxiliary class, ADAM redirects the bind request to Active Directory. ADAM then generates a security context that includes the token that is returned by Active Directory in response to the redirection, along with the ADAM groups in which the principal is a member.
For simple authentication and security layer (SASL) bind requests:
The bind request goes directly to the AcceptSecurityContext application programming interface (API) call. ADAM generates a security context that is based on the token that is returned from AcceptSecurityContext.
Designing applications for bind redirection
Although bind redirection is intended for preexisting, legacy applications, it can also be used with new applications. However, for new and modifiable applications, it is recommended that you write the application to use Windows security principals, rather than proxy objects, for authentication. With this type of design, you can maintain a single sign on (SSO) solution and prevent the duplication of accounts.
New and modifiable applications
For applications that are currently in development, and for applications that can be updated, it is recommended that you write your applications to authenticate directly against Active Directory, using Windows security principals. This type of design provides the highest degree of security, because passwords flow directly from the client to Active Directory, rather than through ADAM. ADAM can then be used simply as an application-specific data store. Proxy objects in ADAM can hold application data that is specific to each Windows security principal, and an attribute on the ADAM proxy object can be used to uniquely link each proxy object to a particular Windows security principal. A unique identifier on a Windows security principal, such as a security ID (SID) or a globally unique identifier (GUID), can be used for this linking. If your application is unable to authenticate against Active Directory, and you need to synchronize directory contents between ADAM and Active Directory, you can use a synchronization service, such as Microsoft Identity Integration Server (MIIS). However, this option introduces a delay between the originating update and the synchronization of the update.
In some cases, you may be running already deployed, directory-enabled applications that cannot be modified. In these cases, your application may send a flat string to the directory, expecting the return of a distinguished name string with which to bind. For this scenario, the ADAM proxy object can support a unique distinguished name, and it can also contain a flag indicating that the object represents a security principal in Active Directory. Based on the presence of the flag, when a user attempts to bind to the proxy object, ADAM redirects the bind request to Active Directory, rather than processing the request locally.
Because bind redirection can only be used in conjunction with simple bind requests, any password that is sent to ADAM as part of a bind redirection is sent in a plaintext, unencrypted format. Therefore, it is strongly recommended that you implement bind redirection only when using an encrypted connection, for example, Secure Sockets Layer (SSL), which is the default setting in ADAM.
ADAM should be used to store data that is specific to a particular application, while Active Directory should be used to hold more widely used data.
Only simple bind requests can be redirected.
You cannot modify the password of an Active Directory security principal through a bind redirection.
Bind direction only supports security principals from the forest to which the computer is joined or to a trusted domain or forest.
If both msDS-bindProxy and msDS-bindableObject are specified as auxiliary classes on a single object, msDS-bindableObject takes precedence.