Set up implicit repository linking for the two repositories. Implicit linking is a technique in which linked profile items share a unique property in both repositories, and linking is performed dynamically through code. In early versions of the ATG Personalization module, implicit linking was the recommended technique for splitting profile data among repositories of different types; in ATG 6 and later, this technique was superseded by the composite repository configuration described in Setting Up a Composite Profile Repository. Using implicit linking is still required, however, if you want to set up an LDAP-based user directory, and information about it is included in this manual for that purpose.

Follow the directions in Linking SQL and LDAP Repositories. In particular, make sure you perform the steps in the subsection Configuring Personalization Module Components for Linked Repositories.

Follow the directions exactly to set up the user view.

Determine the attributes you will use as the entryId and parentId LDAP attributes.

These must be attributes that exist in one of the object classes given as the object classes of a user. For example, the default LDAP repository implementation shows that a user has the object classes top, person, organizationalPerson, and inetorgPerson. Pick or create an attribute in one of these object classes to act as an entryId. Do the same thing for parentId.

The parentId attribute holds the entryId of an object’s parent object. For example, assume that the organizational unit People (ou=People,dc=atg.com) has the entryId 4. Also assume there is a user in the People organization whose userid is johnq. Johnq will have an entryId of 5, for example, and a parentId of 4. Make LDAP properties out of these attributes (see example).

Note: In some directory servers, this relationship is already set up. However, you may not be able to find entryId and parentId as attributes of any object class. The process described here should work successfully regardless of whether you can find the attributes.

If this relationship is not already defined in your brand of directory server, follow the instructions above to add the necessary attributes to your schema. Then set the values of those attributes for each organization and user that you want to expose in your ATG environment. Make sure that the values set up the relationship pattern outlined above: the root organizational unit has a particular entryId and an empty parentId. Then, all child organizational units and users of the root organization have unique entryIds and a parentId that is the same as the root organization’s entryId.

Turn the default organization SQL item descriptor into a linked item descriptor. Do this by using XML combination to add a new property, ldapOrganization, to the organization item descriptor. This property looks very much like the sample ldapUser property described in Linking SQL and LDAP Repositories.

Also, you must add a new view called organizationalUnit to the ldapUserProfile.xml file. See the sample userProfile.xml below for details. This configuration is produced by using the example in Linking SQL and LDAP Repositories as a model and substituting the organization item descriptor for user in the instructions. Pick a particular item descriptor in the LDAP repository which represents an LDAP organization.

Note: There is sometimes more than one object class that represents an organization in an LDAP system. For example, some people consider a domain to be a type of organization (dc=atg.com). In addition, a typical LDAP installation contains the object classes organization and organizationalUnit. As an ATG installation uses only one item descriptor for all organizations, there can be only one LDAP object class which represents implicitly linked organizations. The default is organizationalUnit, as this is the most commonly used LDAP organizational structure. Note that the root organization must also be an organizational unit. OrganizationalUnit is in the default installation—you can select any one object class to represent organizations in LDAP. Unfortunately, you cannot use your domain as your root organization for the reasons listed above. The key point is that there can be only one object class which corresponds to an organization in ATG.

Make sure there is a root organization in ATG that is linked to your chosen LDAP root organization. This step needs to be performed only if useGSARepositoryIdAsPrimaryKey is true (see the description of the ProfileUserDirectory component, and the important notes that follow it, for more information). If useGSARepositoryIdAsPrimaryKey is false, the SQL repository root organization will be created for you the first time it is accessed.

If no root organization exists in your SQL repository, create an organization item whose uniqueIdPropertyLocal property value matches the uniqueIdPropertyRemote property value of the LDAP repository item that corresponds to your chosen LDAP root organization. See Linking SQL and LDAP Repositories for explanations of these terms.

Example: Assume you pick the organization with the DN “ou=People,dc=atg.com” in LDAP as your root LDAP organization. You’ve set up your LDAP repository’s organization item descriptor to have a property, name, that corresponds to the LDAP attribute ou. If you used the instructions here as a guide, you would have an item in the organizationalUnit item descriptor of your LDAP repository whose name is People. You would also set up your SQL repository organization item descriptor to have a property named ldapOrganization that is a RepositoryLinkPropertyDescriptor. In the example, the uniqueIdPropertyLocal is name, and the uniqueIdPropertyRemote is also name. In order to link a SQL repository item with the previously mentioned LDAP item, all you would have to do would be to create a SQL repository organization item whose name is People. The RepositoryLinkPropertyDescriptor does the rest.

If there is a pre-existing root organization in your SQL repository, modify the default root organization to point to the LDAP root organization.

The following steps show how to modify the default root organization:

Alternatively, use a SQL editor to change the entry in the dps_organization table whose org_id is root. Change the name property to People.

Make sure your LDAP database is using a password encryption scheme supported by ATG’s NDSPasswordHasher component.

In addition, make sure that the passwordHasher property of the ATG installation’s PropertyManager component points to the NDSPasswordHasher component as follows:

passwordHasher=/atg/adapter/ldap/NDSPasswordHasher

And then set the encryption property of this component to the appropriate value (clearText, SHA, or SSHA), for example:

encryption=SHA

Notes: