Overview (Active Directory Lightweight Directory Services)
Microsoft has changed the name of Active Directory Application Mode (ADAM) to Active Directory Lightweight Directory Services (AD LDS). You might still find references in documentation to ADAM.
One instance of AD LDS can have multiple application partitions, each of which can be mapped to a Content Platform Engine realm. Therefore one instance of AD LDS can be mapped to multiple Content Platform Engine realms.
For each realm, you must create an application server authentication provider and a DirectoryConfigurationADAM object, to establish a one-to-one relationship between Realm object and authentication provider, and also a one-to-one relationship between Realm object and DirectoryConfigurationADAM object. The initial set of these objects is created during Content Platform Engine configuration.
For each DirectoryConfiguration object, FileNet® P8 extracts the realm name from the specified UserBaseDN property value by comparing it with each application partition. For example, if the UserBaseDN for this DirectoryConfiguration object is ou=people, o=isp, and there are two application partitions: o=isp and dc=filenet,dc=com, the realm name for this DirectoryConfiguration object is o=isp.
The following graphic shows Content Platform Engine authenticating with AD LDS:
The next graphic shows the optional configuration of Content Platform Engine authenticating with AD LDS configured for proxy login and search to Active Directory. When a user logs in using an ID found in a the AD LDS object, AD LDS redirects authentication to Active Directory.
You can optionally use the Synchronizer tool, a built-in feature of AD LDS, to pull user account information from Active Directory. In this scenario, AD LDS user accounts are proxy users. FileNet P8 provides support for native and proxy users in AD LDS as follows:
- If a user class is based on userProxyFull, which stores the user ID in AD LDS while the account password remains in Active Directory, AD LDS will re-direct bind requests to Active Directory.
- If a class lists msds-BindProxy as its auxiliary class, then it is a proxy user, and AD LDS will re-direct bind requests to Active Directory.
- If a class such as organizationalPerson lists msds-bindableObject as its auxiliary class, then AD LDS processes the bind request directly as a native AD LDS user.
- FileNet P8 does not support users based on userProxy, which does not contain the required e-mail address attribute.
When properly configured this provides one-way data flow from Active Directory to AD LDS. You could continue to provision AD LDS-only accounts in AD LDS, and both types of accounts could authenticate to a FileNet P8 application, following normal configuration of Content Platform Engine classes' Default Instance Security tabs in Administration Console for Content Platform Engine. The application does not need to be aware of this Active Directory interaction.
Consult your AD LDS documentation for how to use the userProxyFull object and the msds-bindableObject auxiliary class.