Federating two LDAP servers without a common root organization

You can leverage the directory integration features of Virtual Member Manager (VMM) in WebSphere Application Server to map between different organizational hierarchies in LDAP.

Before you begin

Ensure that before you federate multiple LDAP servers (with common root or different root), you check that the RDN prefix for users is the same, for example uid or cn, but not a mix of both.

About this task

The mapping of these disjointed organization structures is specified in the VMM configuration file. To map between different organizational hierarchies in LDAP and WebSphere Commerce database, you must set the mapping in Virtual Member Manager.

Procedure

Before WebSphere Commerce is set up with LDAP, ensure that a new admin user is created under the WebSphere Commerce Seller Organization (o=seller organization,o=root organization) that has the Site Administrator role for the Root Organization (o=root organization). This user is your new Site Administrator, since the site administrator (user -1000) is above the two new base entries that are going to be created. Here is a sample LDAP configuration:


WebSphere Commerce organization DN (Do not change)	Corresponding LDAP1 DN (Shoppers)	Corresponding LDAP2 DN (Administrators)
`o=default organization,o=root organization`	`cn=customers,cn=area1,dc=local`	`n/a`
`o=seller organization,o=root organization`	`n/a`	`ou=people,o=companyname`

Manually run VMM setup (Federated Repository setup) in WebSphere Application Server admin console:
1. Start WebSphere Commerce server1.
2. Open the WebSphere Integrated Solutions Console.
3. Expand Security and click Global Security.
4. In the User account repository section, select Federated repositories from the Available realm definitions drop-down menu. Then, click Set as current > Configure.
5. Click Add Base entry to Realm...
6. Click Add Repository... to add the LDAP 1 (Shopper) repository if it does not exist.
7. Complete the following fields:
  - Repository identifier
  - Directory type
  - Primary host name
  - Bind DN and bind password
  - Login properties: uid or cn, depending on how user DNs are configured on the LDAP server. For instance,uid=xxx,o=root organization or cn=xxx,o=root organization
  For more information, see Configuring LDAP in a federated repository configuration.
8. Click OK. The values that are entered are validated and the default values are populated based on the Directory type.
9. Back on the Add base entry to realm page, select the added repository, for example, ITDS6. Then, complete the two DN fields with the top-level organization for LDAP 1. For instance:
  Distinguished name of the base entry that uniquely identifies this set of entries in the realm: o=default organization,o=root organization
  Distinguished name a base entry in this repository: cn=customers,cn=area1,dc=local
10. Click OK when done.
11. Click Add Repository... to add the LDAP 2 (Admin) repository if it does not exist.
12. Complete the following fields:
  - Repository identifier
  - check
  - Directory type
  - Primary host name
  - Bind DN and bind password
  - Login properties: uid or cn, depending on how user DNs are configured on the LDAP server. For instance, uid=xxx,o=root organization or cn=xxx,o=root organization. This must be the same as LDAP 1.
  - For more information, see Configuring LDAP in a federated repository configuration.
13. Click OK. The values that are entered are validated and the default values are populated based on the Directory type.
14. Back on the Add base entry to realm page, select the added repository, for example, LDAP2. Then, complete the two DN fields with the top-level organization for LDAP 1. For instance:
  Distinguished name of the base entry that uniquely identifies this set of entries in the realm: o=seller organization,o=root organization
  Distinguished name a base entry in this repository: ou=people,o=companyname
15. Click OK when done.
16. Specify the following, and then click OK:
  - Realm name, such as myRealm.
  - Primary administrative user name: any existing user in any of the realm’s repositories that are used to log on to WebSphere Application Server Admin Console and run wsadmin tasks. It is recommended to use a user from the default internal file repository, rather than the LDAP server. As a result, even if the LDAP server is down, the administrator can still log on to the WebSphere Application Server Admin Console and run wsadmin tasks. If the user does not exist in the file repository yet, it is created there now.
  - Select Automatically generated server identity radio button. The server identity is used for internal WebSphere Application Server intra-component communication. By using an automatically generated server identity, an extra password does not have to be stored in WebSphere Application Server and WebSphere Commerce.
  - Click Use built-in repository if the InternalFileRepository is not already part of the realm.
17. Clear the Enable administrative security check box if it is not being used. In most cases application security is not needed either.
18. Save all changes.
For Development Environment, you must also set Security settings in the server configuration:
1. Select the Security is enabled on this server check box
2. Specify the WebSphere Application Server primary administrator's user ID and password
3. Select the Automatically trust server certificate during SSL handshake check box
Enable LDAP in WebSphere Commerce:
- Runtime: Log on to WebSphere Commerce Config Manager and modify authentication setting to use LDAP instead of DB.
- Toolkit: Modify wc-server.xml as follows:
```
<MemberSubSystem
      	AuthenticationMode="LDAP" ProfileDataStorage="LDAP">   
```
Enable global security in WebSphere Commerce:
1. Modify wc-server.xml and specify the attributes in bold:
```
<Security AdminPwd="PoPLBJhv3M2PnNCZavkGgA=="
      AdminUser="uid=primUser,o=defaultWIMFileBasedRealm"
      AuthMode=""
      Realm="" 
      RunAsID=""
      RunAsPwd=""
      enabled="false"
      enabledGlobal="true" 
passwordpolicy="true"/>
```
  Where:
  - AdminUser: the primary WebSphere Application Server admin user previously selected that is able to log on to WebSphere Application Server Admin Console and run wsadmin scripts
  - AdminPwd: the ASCII encrypted string that is generated by using <WC>\bin\wcs_encrypt with the server identity password (merchant key should NOT be specified when you run wcs_encrypt)
  - enabledGlobal: Needed when WebSphere Application Server Admin Security is enabled to be able to do admin tasks with AdminUser
Modify wc-server.xml to specify that Root Organization in the WebSphere Commerce database must not be synchronized with LDAP, since it is above the base entries that are defined in the WebSphere Application Server federated repositories:
1. Find the SyncOrganizationExclusionList element
2. Add any organization DN values that exist in WebSphere Commerce database, but are above the base entries.
For example, Root Organization:
```
<SyncOrganizationExclusionList display="false">
  <Org DN="o=root organization"/>
</SyncOrganizationExclusionList>
```
Modify wc-server.xml to specify the LDAP DNs of the search bases (base entries) to be used during Logon, SSO, and UserRegistrationAdd. These DNs must be under the root organization:
1. Find the MemberSubSystem element.
2. Add the following sub element inside, specifying the base entry LDAP DNs. These DNs must be under the LDAP Root Organization:
```
<SearchBases display="false"> 
  <Org DN="o=default organization,o=root organization>
  <Org DN="o=seller organization,o=root organization"/> 
</SearchBases> 
```
Run UpdateEAR to propagate the wc-server.xml changes to the EAR.
Restart the WebSphere Commerce Server.
Try to login to Organization Administration Console by using the new site administrator that is under Seller Organization. This user must be able to manage all the organizations, including the users that are descendants of the base entry organizations.
Shoppers should be able to register and logon in a B2C store front.
Enable SSL for the LDAP server (needed for Active Directory).

Results

You have now leveraged WebSphere Commerce to access multiple LDAP registries with dissimilar organizations structures.