. 62
( 87 .)


370 Chapter 19

Given that the LDAP directory is hierarchical, changing the tree is very
dif¬cult and should be avoided. Choosing the appropriate naming structure
is very important and is usually dictated by the LDAP server. Most LDAP
servers base their naming models on either the X.500 methodology or the
DNS naming model. The X.500 methodology sets the root of the directory
to an organization and has a suf¬x like o=rigorconsultants, c=us. The DNS
model uses the domain name as the suf¬x like dc=rigorconsultants.com.
Microsoft™s Active Directory uses the DNS naming model.
When designing the DIT, you have to pay special attention to the branch-
ing methodology. If the root branch is based on departments, then a re-
org can cause an administrative nightmare. Branching based on geography
can restrict sharing organizational information. The branching methodol-
ogy should be designed to minimize changes to the directory tree. Also
make the tree as shallow as possible to maximize search performance.
Lastly, consult your security administrator to determine if there are parts
of the tree that compliance or organizational rules dictate and that must be
physically separated.

Designing the Infrastructure
Identity Management systems for large enterprise must be highly available
and able to handle large number of users. LDAP servers support these
requirements using partitioning and replication.
Figure 19-3 shows a highly available LDAP server solution. In this so-
lution we have one master server and three slave servers, each with dual
network cards. Each server is connected to two separate networks and the
connections are bridged together. Read queries are sent to any of the servers
while updates, create, and deletes are performed against the master, which
replicates the data to the slave servers. If the server fails, client redirection
can be done by DNS switchover or using load balancing through the router
or the LDAP server. This design eliminates any single point of failure and
since writes are infrequent on an LDAP con¬guration, performance is not
Scalability issues can be addressed partitioning the directory by geog-
raphy or some other methodology that accommodated the differences in
various network bandwidths and server performances. This also spreads
the risk by minimizing the area impacted by a server failure. You can also
replicate the LDAP servers to servers closer to the client™s geographical
Remember that the more complex you make the LDAP infrastructure,
the more dif¬cult it is to manage. Try to keep it simple and minimize the
input data sources.
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

Implementing Authentication for Large Enterprises 371

Figure 19-3 A highly available LDAP server con¬guration.

Implementing WebSphere Portal Enterprise
Identity Management
In the previous section we explored the reasons for using an LDAP server for
Enterprise Identity Management and discussed the general design issues.
Now it is time to leave the theory and deal with the practical aspect. In
this section we will explore how to implement Identity Management in
WebSphere Portal using the more popular LDAPs:

1. IBM Directory Server V5.1
2. Sun One
3. Microsoft Active Directory

What is conspicuously missing is Domino 6.0. Domino is required if you
want to implement collaboration. However, Domino is a lot more than
an LDAP server and introducing it in this discussion will cause many
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

372 Chapter 19

Figure 19-4 WebSphere Portal with LDAP server example con¬guration.

deviations that will cause us to lose focus on the topic. Instead, you will
get more value to read the sections on Domino in WebSphere Portal Info-
Center after you have read this chapter.
Figure 19-4 shows the con¬guration we will be implementing for each
LDAP server. The user registry is stored on a remote LDAP server. We
assume that you will not use a look-aside repository because it makes
the infrastructure unnecessarily complex and tends to have performance
issues. We are assuming that each LDAP in question has been installed
and tested on both the server and the client where the client is the Web-
Sphere Portal server. Due to the amount of information that needs to be
covered, we will only be discussing implementation of LDAPs in a Windows
2000 environment. The con¬guration differences between the Windows
2000 environment and Unix/Linux are minor and are documented in the

Setting Up Your LDAP Servers
The ¬rst step to getting WebSphere Portal working with your LDAP server
is to create the Portal Administrator User ID and WebSphere Administrator
User ID.
The ¬rst directory server we will discuss is IBM Directory Server or Tivoli
Directory Server, which comes with WebSphere Portal Extend or Experi-
ence. It is built on top of DB2 (tuned for read applications) and WebSphere
Application Server. The directory is full function and robust but cannot be
considered “light.”
There are two methods to create the user ids. The ¬rst (recommended) is
to modify the LDIF ¬le portalUsers.ldif on the ¬rst WP CD to conform
to your tree structure. LDIF or LDAP Data Interchange Format is a standard
format that enables data to be imported and exported between LDAP-based
directory servers. The second is to add it using LDAP Directory Web Ad-
ministrator. If you are going to create the portal administrator user in the
LDAP, use the Add Entry function under Directory Management instead of
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

Implementing Authentication for Large Enterprises 373

de¬ning it under a Realm using a template. You might ¬nd the templates
too restrictive especially when you want to associate multiple object classes
with the entry.
To create the administrators through an LDIF import, you need to modify
the ¬le with your suf¬x and conform it to your directory tree structure and
the naming structure. For IBM Directory we used:
LDAP suf¬x is set to dc=rigorconsultants,dc=com
user pre¬x is uid
group pre¬x is cn=users
group suf¬x is cn=groups
Portal administrator DN is uid=wpsadmin, cn=users,
dc=rigorconsultants, dc=com
Portal administrator group is cn=wpsadmins, cn=groups,
dc=rigorconsultants, dc=com of which wpsadmin is a member
WebSphere Security ID DN is uid=wpsbind, cn=users,
dc=rigorconsultants, dc=com
This resulted in the following portalUsers.ldif:
version: 1

dn: dc=rigorconsultants,dc=com
objectclass: domain
objectclass: top
# Add lines according to this scheme that correspond to your suffix
dc: rigorconsultants,dc=com
dc: rigorconsultants

dn: cn=users,dc=rigorconsultants,dc=com
objectclass: container
objectclass: top
cn: users

dn: cn=groups,dc=rigorconsultants,dc=com
objectclass: top
objectclass: container
cn: groups

dn: uid=wpsadmin,cn=users,dc=rigorconsultants,dc=com
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: wpsadmin
userpassword: wpsadmin
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

374 Chapter 19

sn: admin
givenName: wps
cn: wps admin

dn: uid=wpsbind,cn=users,dc=rigorconsultants,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: wpsbind
userpassword: wpsbind
sn: bind
givenName: wps
cn: wps bind

dn: cn=wpsadmins,cn=groups,dc=rigorconsultants,dc=com
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: uid=wpsadmin,cn=users,dc=rigorconsultants,dc=com
cn: wpsadmins

To import into IBM Directory Server, stop the directory server

1. Click Start ➪ Programs ➪ IBM Directory Server 5.1 ➪ Directory
2. Click Import LDAP, enter the location of the ¬le to import, and click
OK. A message will appear that states that you have successfully
imported six out of six items or 6 of 6 if your suf¬x is already
3. Exit and restart your LDAP server.

The next directory server we will look at is Sun One Directory Server
formally known as Netscape Directory Server. This is one of the oldest and
most popular LDAP directory servers. For Sun One Directory Server 5.2,
the process is pretty much similar. The only difference lies in the default
naming structure

group pre¬x is ou=People
group suf¬x is ou=Groups
Portal administrator DN is uid=wpsadmin, ou=People,
dc=rigorconsultants, dc=com
Portal administrator group is cn=wpsadmins, ou=Groups,
dc=rigorconsultants, dc=com of which wpsadmin is a member
WebSphere Security ID DN is uid=wpsbind, ou=Groups,
dc=rigorconsultants, dc=com
WY009-19 WY009-BenNatan-v1.cls May 13, 2004 22:21

Implementing Authentication for Large Enterprises 375

Do the following to import into Sun One Directory Server:
1. Start the Sun One Server Console.
2. Under Servers and Application, expand the tree and double-click
Directory Server.
3. Go to the Task tab and click Import LDIF.
4. Type LDIF ¬le (or browse to it) and click OK.
5. After the data has been imported, go to the Directory tab and
validate your directory tree.
The last directory server is the most popular directory server based on
market penetration, Microsoft Active Directory. This LDAP server is de-
signed to work very well within a Microsoft environment; however, due
to some its propriety features and lack of support for many objectclasses it
does not integrate easily to other environments.
To use Active Directory with WebSphere Portal, you must have the Win-
dows 2000 High Encryption Pack, Internet Information Services, and Cer-
ti¬cate Services using the standalone root CA option installed. Active Di-
rectory requires Secure Sockets Layer (SSL) enabled in order for WebSphere
Portal to use it as a user registry (more on this later).
The naming structure that we used with Active Directory is as follows:
LDAP suf¬x is set to dc=rigorconsultants,dc=com
user pre¬x is cn
group pre¬x is cn=users
group suf¬x is cn=groups
Portal administrator DN is cn=wpsadmin, cn=users,
dc=rigorconsultants, dc=com
Portal administrator group is cn=wpsadmins, cn=groups,
dc=rigorconsultants, dc=com of which wpsadmin is a member
WebSphere Security ID DN is cn=wpsbind, cn=users,
dc=rigorconsultants, dc=com
Normally you would import the data as an LDIF ¬le using LDIFDE utility.


. 62
( 87 .)