AD LDS proxy objects are used in special cases where an application can perform a simple LDAP bind to AD LDS but the application still needs to associate the AD LDS user with a security principal (user account) in Active Directory. A process through which AD LDS can accept a bind request from an application and redirect this bind request to Active Directory, based on the contents of a proxy object, is referred to as bind redirection.
Bind redirection occurs when a bind to AD LDS is attempted using a proxy object (user proxy) - an object in AD LDS that represents a user account in Active Directory. Each proxy object in AD LDS contains the security identifier (SID) of a user in Active Directory. When an application attempts to bind to a proxy object, AD LDS takes the SID that is stored in the proxy object, together with the password that is supplied at bind time, and presents the SID and the password to Active Directory for authentication.
A proxy object in AD LDS represents an Active Directory user account, and it can be augmented to store additional data related to that user account that is specific to the application. Through bind redirection, applications can take advantage of the identity store of Active Directory, while retaining the flexibility of using AD LDS as an application data store.
To add a proxy object to AD LDS
You can examine an existing proxy object by using the Properties command on that object. The Properties dialog box allows you to view the user account that is represented by the proxy object. However, due to a limitation of AD LDS, this setting cannot be changed on an existing proxy object. You can select an Active Directory domain user account only at the time that the proxy object is created. After a proxy object is created, this setting cannot be modified.
When creating a proxy object, you can select a user account from any domain that is registered with Active Roles, provided that the domain is trusted by the computer on which the AD LDS instance is running.
A proxy object for a domain user cannot be created in an AD LDS directory partition that already contains a foreign principal object (FPO) or a proxy object for that same domain user.
For a given user account in Active Directory, you can view a list of proxy objects that represent the user account in AD LDS: In the Properties dialog box for the user account, go to the Object tab and click AD LDS Proxy Objects.
This section elaborates on each of these tasks.
By using the Active Roles console, you can configure Managed Units in Active Roles to represent virtual collections of directory objects, from AD LDS, Active Directory or both, for the distribution of administrative responsibilities and enforcement of business rules. By enabling Managed Units to include directory objects from any location, be it AD LDS or Active Directory, Active Roles provides the ability to implement role-based delegation and policy based administrative control of directory data where appropriate, without regard to directory boundaries.
You can use the following instructions to configure an existing Managed Unit so that it holds AD LDS objects such as AD LDS users, groups, or organizational units. For detailed instructions on how to create and administer Managed Units, see the Rule-based Administrative Views section earlier in this document.
To configure an existing Managed Unit to include AD LDS objects returned from a query
You can also configure membership rules of categories other than “Include by Query” in order to include or exclude AD LDS objects from a Managed Unit. To do so, select the appropriate category in the Membership Rule Type dialog box. Further steps for configuring a membership rule are all about using either the Create Membership Rule dialog box to set up a certain query or the Select Objects dialog box to locate and select a certain object.
By using the Active Roles console, you can apply Active Roles Access Templates to delegate control of AD LDS data the same way as you do for the directory data held in Active Directory domains. By applying Access Templates to users or groups (Trustees) on AD LDS objects and containers, you can give the Trustees the appropriate level of access to directory data held in AD LDS, thus authorizing them to perform a precisely defined set of activities related to AD LDS data management.
Active Roles provides a rich suite of pre-configured Access Templates to facilitate delegation of AD LDS data management tasks. For a list of the AD LDS-specific Access Templates, refer to the Access Templates Available out of the Box document, which is part of the Active Roles documentation set. You can find those Access Templates in the Configuration/Access Templates/AD LDS (ADAM) container, in the Active Roles console.
You can use the following instructions to examine which Access Templates are applied to a given AD LDS object, such as an AD LDS user, group, organizational unit, container, or entire directory partition, and to add or remove Access Templates in order to change the level of access the Trustees have to that object.
For detailed instructions on how to create, configure and apply Access Templates, see the Role-based Administration section earlier in this document.
In the Delegation of Control Wizard, you can select the users or groups (Trustees) to give permissions to, and select one or more Access Templates from the Access Templates/AD LDS (ADAM) container to define the permissions. As a result, the Trustees you select have the permissions that are defined by those Access Templates on the AD LDS object. The Trustees can exercise the permissions only within Active Roles as Active Roles does not stamp permission settings in AD LDS.
In the Active Roles Security dialog box, an Access Template can only be removed if it is applied to the object you have selected (rather than to a container that holds the object). To view the Access Templates that can be removed on the current selection, clear the Show inherited check box.
Instead of removing an Access Template in the Active Roles Security dialog box, you can select the Access Template and then click Disable in order to revoke the permissions on the object that are defined by the Access Template. In this way, you can block the effect of an Access Template regardless of whether the Access Template is applied to the object itself or to a container that holds the object. You can undo this action by selecting the Access Template and then clicking Enable.