Lightweight Directory Access Protocol (LDAP) is a system and protocol that enables various applications to exchange information with an organization’s central directory of information. Several vendors offer implementations of LDAP; Microsoft’s LDAP implementation is called Active Directory. While the Primavera Portfolio Management Active Directory Synchronization Tool should work properly with any compliant LDAP system, it has been tested only with Microsoft Active Directory.
LDAP implementations such as Microsoft Active Directory allow organizations to define, organize, modify and manage objects such as domains, organizational units, servers and computers, groups of users and users, and others, in one central location. LDAP-aware applications can connect to the central LDAP directory and manage objects that are relevant to them there, or they can periodically connect to the central LDAP directory and synchronize their local lists of relevant objects with the objects found in LDAP.
Note that the functionality of Single Sign-On is not handled through LDAP. LDAP is simply a repository of objects, including users. Allowing those users to login once and then have access to all of their (authorized) applications is a different issue. For more information about the support for Single Sign-On in PPM, see “Enabling Single Sign-on”.
LDAP systems arrange the objects of an entire enterprise in tree-like structures. Usually it is not appropriate for specific applications to access or synchronize with the entire content of the LDAP system. A given application typically looks at a specific sub tree within the LDAP system.
Synchronization typically takes place based on a strict “parent-child” pattern: the LDAP system is the “parent”, and the application is the “child”.
PPM follows this same pattern and hence can be configured to synchronize with a sub tree residing under a specific container in the LDAP system. Any object within the LDAP system can be considered a container for this purpose; therefore, PPM can be made to synchronize with a sub tree residing under an Organizational Unit, a group, a folder, or any other object. When synchronizing, all users and user groups residing under this container will be created within PPM (if they did not exist) or will be updated to have the same properties as their counterparts in LDAP (if they already existed). Users in PPM that do not exist under the specified container in LDAP will be disabled in PPM, whereas PPM groups that do not exist under the specified LDAP container will be deleted in PPM (except for specific users and groups that the synchronization process was instructed to ignore).
Note that for the purposes of LDAP synchronization, users that are members of a group which is going to be synchronized according to the rules outlined above, will be synchronized, even if the users themselves really reside elsewhere in the LDAP system (i.e. reside under a different Organizational Unit). In other words, users belonging to a group are considered to “reside” under that group, even though, strictly speaking, the user objects reside elsewhere and the group only contains a reference to these objects.
The above is not true for user groups: user groups that are members of another user group which is going to be synchronized according to the rules outlined above, will not be synchronized unless they themselves also reside under the container that PPM is going to synchronize with. In other words, user groups belonging to a user group will be synchronized only if these groups actually reside under the specified LDAP container.
For example, let's assume the following hierarchy:
PPM Root Container
User One
User Two
User Three
Group 1 Residing under PPM's Root Container
Group 2 Residing under PPM's Root Container
- “PPM Root Container” is a container created somewhere in the LDAP hierarchy;
- “User One”, “User Two” and “User Three” are users that reside under the “PPM Root Container”;
- “User Four” and “User Five” (not shown above) are users residing elsewhere in the LDAP hierarchy;
- “Group 1 Residing under PPM's Root Container” and “Group 2 Residing under PPM's Root Container” are user groups that reside under the PPM's LDAP Root Container”;
- “Group 3 Not Residing Under PPM's Root Container” (not shown above) is a group that resides elsewhere in the LDAP hierarchy;
- “Group 1 Residing Under PPM's Root Container” has as members: “Group 2 Residing Under PPM's Root Container”, “Group 3 Not Residing Under PPM's Root Container”, “User One” and “User Four”;
- “Group 2 Residing Under PPM's Root Container” has as member: “User Two”;
- “Group 3 Not Residing Under PPM's Root Container” has as members: “User Three” and “User Five”;
In this example, the following users will be created/updated in PPM:
“User One”, “User Two”, “User Three” and “User Four”.
The following user groups will be created/updated in PPM:
“Group 1 Residing Under PPM's Root Container” and “Group 2 Residing Under PPM's Root Container”.
Note that “User Five” will not be created in PPM, and if this user already existed it will be deleted.
Also note that “Group 3 Not Residing Under PPM's Root Container” will not be created in PPM, and if it already existed it will be deleted. Within PPM, “Group 1 Residing Under PPM's Root Container” will contain “Group 2 Residing Under PPM's Root Container” and “User One” and “User Four”. “Group 2 Residing Under PPM's Root Container” will contain “User Two”. “User Three” will not be residing in any user group in PPM because the group it is a member of (“Group 3 Not Residing Under Primavera Portfolio Management's Root Container”) does not reside under the PPM's LDAP Root Container”.
Synchronization is one-way only: users created in PPM that do not exist under the specified container in LDAP will be disabled upon the next synchronization. Properties of users and/or groups that were updated in PPM will be overwritten by the values of these same properties in LDAP upon the next synchronization.