Ldap Directory Servers - IBM BS029ML - WebSphere Portal Server Self Help Manual

One may wish to consider CARS as an alternative to exploiting the generic UNIX syslogd for
centrally collecting audit events in a distributed environment, as the standard syslogd does
not provide encryption or any guarantee of delivery by being based on UDP.

2.6.7 LDAP Directory Servers

There are several aspects to LDAP Directory Server design that make the topic a non-trivial
issue. Two of the most important aspects are described below.
LDAP directory structure
There are potentially a number of issues and considerations concerning the structure of the
Directory Information Tree (DIT) when using WebSphere Portal Server, particularly when an
existing populated LDAP directory is required to be used or when a new structure is to be
defined from scratch.
DIT example
The suffix of an LDAP directory server is usually defined as part of the installation and
configuration process. In the example illustrated in Figure 2-5 on page 44, the suffix has been
fixed as dc=uk, dc=acme, dc=com, which adheres to the domain name syntax-based
convention. Potentially, this could be revised to just dc=acme, dc=com or even dc=acme,
dc=co, dc=uk.
It is anticipated that a number of organizational units (OU) would be needed at the topmost
level to provide a degree of granular isolation between subordinate categories. As such,
ou=people and ou=groups are normally created. It is intended that ou=people will contain all
user entries and that the ou=groups will contain all the subordinate sub-groups that relate to
the various functional departments of an organization.
The ou=people organizational unit directly contains the many user identities for the Portal
solution. The hierarchy is totally flat with no boundaries between the users. The distinction is
not made as to which department or Line of Business (LOB) a users belong under ou=people.
Instead, the ou=groups organizational unit contains further sub-organizational units
representing the different departments of an organization, such as ou=GroupA or
ou=GroupB. This approach allows for greater flexibility when a user is assigned to work in a
new department and so on.
Users are required to be associated with a group depending on their Portal "Role".
Membership of a specific group therefore maps to a specific Portal "Role" and determines
what access the user will be privileged to experience.
43
Chapter 2. Architecture and planning