Set up federated repositories

1. Configure the LDAP directory

2. Log on to the Dmgr console...
   http://dmgr_host:9060/ibm/console

   ...with admin credentials specified during installation of WAS.

   ...and go to...

   Security | Global Security | Available realm definitions | Federated Repositories | Configure

3. If installing Connections Content Manager, set the realm name to defaultWIMFileBasedRealm.

4. Click...
   Add Base entry to Realm | Repository reference page | Add Repository | New page

5. Type a repository identifier, such as mycoRepository into the Repository identifier field.

6. Specify the LDAP directory that we are using in the Directory type field.

   Supported directories include

   Directory type	LDAP directory supported by IBM Connections
   IBM Tivoli Directory Server	IBM Tivoli Directory Server 6.1, 6.2, 6.3
   Lotus Domino	Lotus Domino 8.0 or later, 8.5 or later
   Novell Directory Services	eDirectory 8.8
   Sun Java System Directory Server	Sun Java System Directory Server 7
   Windows Active Directory	Microsoft Active Directory 2008
   Microsoft Active Directory Application Mode	Referred to as Active Directory Lightweight Directory Services (AD LDS) in Windows Server 2008.

7. Set the host name or IP address of the primary LDAP directory server in the Primary host name field.

8. If the directory does not allow LDAP attributes to be searched anonymously, provide values for the Bind distinguished name and Bind password fields.

   For example, the Domino LDAP directory does not allow anonymous access, so if we are using a Domino directory, specify the user name and password with administrative level access in these fields.

9. Specify the login attribute or attributes to use for authentication in the Login properties field.

   Separate multiple attributes with a semicolon. For example:

   uid;mail

   With Active Directoy we can use an email address as the login, specify mail as the value for this property.

   If we use the samAccountName attribute as the login, specify uid as the value for this property.

10. Click Apply and then click Save.

11. On the Repository reference page, the following fields represent the LDAP attribute type and value pairs for the base element in the realm and the LDAP repository. (The type and value pair are separated by an equal sign (=), for example: o=example. These can be the same value when a single LDAP repository is configured for the realm or can be different in a multiple LDAP repository configuration.)

    Distinguished name of a base entry that uniquely identifies this set of entries in the realm

    Identifies entries in the realm. For example, on a Domino LDAP server: cn=john doe, o=example.

    Distinguished name of a base entry in this repository

    Identifies entries in the LDAP directory. For example...

    cn=john doe, o=example

    This value defines the location in the LDAP directory information tree from which the LDAP search begins. The entries beneath it in the tree can also be accessed by the LDAP search. In other words, the search base entry is the top node of a subtree which consists of many possible entries beneath it.

    For example, the search base entry could be...

    o=example

    ...and one of the entries underneath this search base could be...

    cn=john doe, o=example

    For defined flat groups in the Domino directory, enter a blank character in this field.

    For Domino LDAP and want to address the root node of the ldap such as o=company, use root for the Distinguished name of a base entry that uniquely identifies this set of entries in the realm field and leave the Distinguished name of a base entry in this repository field blank.

12. Click Apply and then click Save.

13. Click OK to return the Federated Repositories page.

14. In the Repository Identifier column, click the link for the repository or repositories that you just added.

15. In the Additional Properties area, click the LDAP entity types link.

16. Click the Group entity type and modify the object classes mapping.

    We can also edit the Search bases and Search filters fields, if necessary. Enter LDAP parameters that are suitable for the LDAP directory.

    We can accept the default object classes value for Group. However, if we are using Domino, change the value to dominoGroup.

17. Click Apply and then click Save.

18. Click the PersonAccount entity type and modify the default object classes mapping. We can also edit the Search bases and Search filters fields, if necessary. Enter LDAP parameters that are suitable for the LDAP directory. Click Apply, and then click Save to save this setting.

    For a Domino LDAP, replace the default mapping with dominoPerson and dominoGroup object classes for person account and group entities.

19. In the navigation links at the beginning of the page, click the name of the repository you have just modified to return to the Repository page.

20. If the applications rely on group membership from LDAP, to create a group attribute definition, click...
    Additional Properties | Group attribute definition link | Member attributes link | New

    ...and enter group membership values in the fields...

    • Name of member attribute
    • Object class

    Click Apply and then click Save.

    For IBM Tivoli Directory Server, use either...

    • groupOfNames
    • groupOfUniqueNames

    WAS uses groupOfNames by default. In most cases, delete this default mapping, and create a new mapping for group entities using groupOfUniqueNames.

    For groupOfUniqueNames, for group member attribute use "uniqueMember"

    For groupOfNames, for group member attribute use "member"

    If we changed objectclass for Group to dominoGroup earlier, add dominoGroup to the definition of Member.

    If we do not configure the group membership attribute, the group member attribute is used for searching group membership. To enable searches of nested group membership, configure the group membership attribute.

    For example, for an Activities group membership attribute...

    • Member is used by groupOfNames
    • uniqueMember is used by groupOfUniqueNames

21. To support more than one LDAP directory, repeat steps 6-20 for each additional LDAP directory.

22. For each of the repositories added, run Add Base Entry to Realm

23. Set the new repository as the current repository:
    Security | Global Security | Available realm definitions | Federated Repositories | Set as current | Apply | Save

24. Enable login security on WAS:

    1. Select the Administrative Security and Application Security check boxes.

       For better performance, clear the check box...

       Java 2 security check box

    2. Click Apply and then click Save.

25. Create an administrator for WAS:

    1. Restart the dmgr, log again, and go to...
       Users and Groups | Administrative user roles | Add | Adminstrator

    2. Search for a user.

       Ensure that this user ID does not have spaces in the name.

    3. Select the target user and click the arrow to move the user name to the box...
       Mapped to role

    4. Click OK and then click Save.

    5. Log out of the dmgr.

    6. Restart the dmgr and the nodes.

    7. Log into the dmgr using the new administrator credentials.

26. Set a primary administrative user:

    Security | Global Security | Available realm definitions | Federated Repositories | Configure
    1. Enter the user name that you mapped in the previous step in the Primary administrative user name box.

    2. Click Apply and then click Save.

27. Log out of the dmgr and restart WebSphere Application Server.

28. When WAS is running again, log in to the console using the primary administrative user name and password.

29. We can test the new configuration by adding some LDAP users to the WAS with administrative roles.

30. For SSL for LDAP, add a signer certificate to the trust store:

    1. From the WAS console, select...
       SSL Certificate and key management | Key Stores and certificates | CellDefaultTrustStore | Signer Certificates | Retrieve from port

    2. Type the DNS name of the LDAP directory in the Host field.

    3. Type the secure LDAP port in the Port field (typically 636).

    4. Type an alias name, such as LDAPSSLCertificate, in the Alias field.

    5. Click Apply and then click Save.

31. To enable single sign-on (SSO) for Connections:

    1. From the WAS console, select...
       Security | Global security | Web and SIP security | Single sign-on (SSO)

    2. Select...
       • SSO Domain Name
       • Enabled
       • Interoperability Mode (optional)
       • Web inbound security attribute propagation

    3. Return to the Global security page and click...
       Web and SIP security | General settings | Use available authentication data when an unprotected URI is accessed

    4. Click Apply and then click Save.

32. To verify users in the LDAP directory have been successfully added to the repository:

    1. From the WAS console, select Users and Groups > Manage Users.

    2. In the Search by field, enter a user name that you know to be in the LDAP directory, and click Search.

       If the search succeeds, you have partial verification the repository is configured correctly. However, this check cannot check for the groups that a user belongs to. Check that if you leave the default Search by field of User ID, then specify a known UID within the LDAP in the search input field.

See

• Choose login values
• Specify the global ID attribute for users and groups
• Specify a custom ID attribute for users or groups

Parent topic:
Pre-installation tasks

Related:
Deployment options
Set the SSO domain name
Before installing for migration