Attachment 14846970 TFG Connecting Maximo TPAE To LDAP v1 1

Connecting Maximo TPAE to LDAP
Project Experiences
Authors: Marc Purnell

Frank Nees
Bernhard Binzen
Hubertus Dapper
Customer: Cross Customer Experience
Document:
Connecting Maximo TPAE to LDAP v1.1.doc
Owner:
Marc Purnell
Connecting Maximo TPAE to LDAP - Project Experiences
Date: 31.10.2011
Version: V1.1
Status: Final
Page 1 of 73
Document History
Document Location
This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer
to the author if you are in any doubt about the currency of this document.
The source of the document will be found in Document2
Revision History
Date of this revision: 31.10.2011
Date of next revision
Revision Revision Summary of Changes

Number Date
(#)
(-)
(Describe change)
1.0
30.09.11 Final initial version
1.1
31.10.11 Final version after review
(date)
Changes
marked
(N)
N
N
Approvals
This document requires following approvals. Signed approval forms are filed in the Quality section of the
PCB.
Name
(name)
Title
(title)
Distribution
This document has been distributed to
Name
(name)
Title
(title)
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 2 of 73
Contents
1.
Introduction ............................................................................................................. 5
1.1
Intention of this document ............................................................................................................... 5
1.2
Expected knowledge of the audience ............................................................................................. 5
1.3
About the authors ............................................................................................................................ 5
2.
Planning the Maximo TPAE to LDAP connection ................................................... 7

2.1
Goals and Requirements ................................................................................................................ 7
2.2
Defining the technical details .......................................................................................................... 7
3.
Conceptual aspects of connecting Maximo TPAE to LDAP .................................... 8

3.1
Supported Authentication Methods ................................................................................................. 8
3.1.1
Use of local Maximo TPAE authentication or LDAP ................................................................ 8
3.1.2
Using local Maximo TPAE authentication ................................................................................ 8
3.1.3
Using LDAP via VMM (ITDS/AD) ............................................................................................. 8
3.1.4
Single Sign On ......................................................................................................................... 9
3.2
Mapping LDAP content to Maximo TPAE Database .................................................................... 10
3.2.1
VMMSYNC vs. LDAPSYNC .................................................................................................. 10
3.2.2
The default mapping .............................................................................................................. 10
3.2.3
Which attribute to use as personid/userid/loginid .................................................................. 12
3.2.4
What happens when key values are changed in LDAP ........................................................ 14
3.2.5
Mapping the persons Manager (Supervisor) ........................................................................ 16
3.2.6
Mapping additional fields from LDAP to Person / User Table ............................................... 20
3.2.7
Mapping additional fields from LDAP to other tables............................................................. 21
3.3
Aspects of design and connection alternatives ............................................................................. 23
3.3.1
Using LDAP filters to retrieve a specific set of users and groups only .................................. 23
3.3.2
Passthrough Authentication ................................................................................................... 27
3.3.3
Connecting multiple LDAPs ................................................................................................... 29
3.3.4
Changing the Base Distinguished Name in TPAE and WAS ................................................ 37
3.3.5
Connecting LDAP Servers other than ITDS and MSAD ..................................................... 41
3.3.6
Secured Connection WAS to LDAP using ldaps ................................................................... 41
3.4
Switching Authentication Methods ................................................................................................ 42
3.4.1
Switching LDAP authentication to local Maximo TPAE authentication ................................. 42
3.4.2
Switching local Maximo TPAE authentication to LDAP authentication ................................. 47
3.5
Configuring TADDM LDAP Authentication ................................................................................... 51
3.5.1
Connecting TADDM to WAS VMM ........................................................................................ 51
3.5.2
Connecting TADDM to MSAD directly ................................................................................... 53
3.6
Configuration ................................................................................................................................. 54
3.6.1
Saving the old configuration (maxdb71 & wimconfig.xml) ..................................................... 54
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 3 of 73
4.
Troubleshooting LDAP Configuration ................................................................... 56

4.1
Changing Logging Parameters ..................................................................................................... 56
4.2
Exceeding Limitations in Active Directory ..................................................................................... 57
4.2.1
Error in LDAPSYNC/VMMSYNC when replicating more than 1000 users ............................ 57
4.2.2
Error in LDAPSYNC/VMMSYNC when assigning more than 1000 users to a security group57
4.3
Disable Cache ............................................................................................................................... 57
4.4
Performance Issues ...................................................................................................................... 58
4.5
Users login Problems .................................................................................................................... 58
4.5.1
Login not possible after switching authentication method ..................................................... 58
4.5.2
Login Screen stays open ....................................................................................................... 58
4.5.3
Login Screen closes but login to TPAE fails .......................................................................... 60
5.
Appendix A ........................................................................................................... 61
5.1
web.xml Files ................................................................................................................................ 61
5.1.1
MAXIMOUIWEB web.xml for SSO ..................................................................................... 61
5.1.2
MEAWEB web.xml for SSO ................................................................................................ 68
6.
Appendix B ........................................................................................................... 73
6.1
List of abbreviations ...................................................................................................................... 73
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 4 of 73
1. Introduction
1.1 Intention of this document

This document describes multiple alternatives about the connection between Maximo TPAE (Tivoli
Process Automation Engine) and LDAP (Lightweight Directory Access Protocol).
Background:
Many companies have a central data store where their person or login accounts are managed. The most
common solution is to store this data in a LDAP Directory like IBM Tivoli Directory Server (ITDS) or
Microsoft Active Directory (MSAD).
Connecting Maximo TPAE to a LDAP repository is looking at it at high level a straight forward
approach. Potentially, a high amount of users log in to the Maximo TPAE system and if using Tivoli
Service Request Management usually all employees of the company need to be loaded into the
Maximo TPAE system in order to provide services to them like Service Request or Incident Management.
The challenge:
The product ships with a default support for a connection to a LDAP system. This works well, but the
challenge is to get the RIGHT DATA into the Maximo TPAE system. The team that has written this
document collected experience in a double digit number of projects facing new challenges in every
single one of these projects regarding this topic.
The intention of this document is to collect this combined knowledge in one place and to share this
information to a wider audience.
1.2 Expected knowledge of the audience

The reader is expected to have a fair knowledge about the product architecture of Maximo TPAE,
TADDM, WebSphere and LDAP.
1.3 About the authors

Marc Purnell is an IBM Certified IT Architect and ITIL V3 Expert at Tivoli Services, Germany. He started
his IT career in 1988 in an IBM Data Center. After spending several years in Application Development
and Systems Management Services, he moved to IBM/Tivoli Services in 1997. Since then, Marc has
designed and implemented availability and service management solutions in medium and large scale
customer projects.
Frank Nees is IT Architect at IBM ITS with the main focus Service Management. He designed numerous
service management solutions based on various tools, in last years with the focus Tivoli Maximo. The
scope includes all disciplines of the Service Management like Service Request including Service Catalog,
Incident, Problem, Change, Release, Asset, CMDB, SLA etc.
In the most cases Frank also acted as project leader of the implementation.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 5 of 73
Bernhard Binzen is an IBM Certified IT Specialist at IBM Software Group, Tivoli Services Germany.
He started his IT career and joined IBM in 1996. After spending several years in service projects (OS/2,
Windows, Unix, Tivoli Framework products amongst others), he joined IBM Software Group in 2007.
Bernhard is an IBM Certified Deployment Professional TADDM and is responsible for the
implementation of IBM Service Management infrastructure environments (TADDM, ITIC, TPAE
infrastructure, Deployers Workbench, Configuration Management).
Hubertus Dapper is an IBM Certified IT Specialist at IBM Software Group and joined Tivoli Services
Germany in 2000. He is responsible for services in the Tivoli Workload Automation area. In addition he
was assigned to services for reporting and service level solutions based on Tivoli Data Warehouse and
Tivoli Service Level Advisor before moving to the Tivoli ISM team where he is responsible for TADDM,
CCMDB, ITIC and TPAE Infrastructure in services projects.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 6 of 73
2. Planning the Maximo TPAE to LDAP connection

The intention of this chapter is to support you in making decisions about the requirements of your Maximo
TPAE to LDAP connection.
Answering the questionnaires will help you to identify the relevant topics in chapter 3.
2.1 Goals and Requirements

First of all you need to define your requirements about the Maximo TPAE to LDAP connection.
The following questionnaire helps to define the general requirements:
Why do you want to connect Maximo TPAE to LDAP (what do you want to achive)?
Which LDAP Server product are you using is it supported?
What is your LDAP architecture (single directory / multiple directory / meta directory)?
Is LDAP your primary personal/user data store?
Is the data in LDAP accurate and up-to-date?
Do you need personal data from all persons in LDAP in Maximo TPAE or only from a subset?
Do all person/users in LDAP need to login to Maximo TPAE or only a subset?
Is Single-Sign-On required?
2.2 Defining the technical details

The authors of this document recommend to become familiar with the capabilities of the Maximo to LDAP
connection (study chapter 3) before answering the technical questionnaire:
The following questionnaire helps to define the technical requirements:
Which authentication method suites best your requirements?
Which method suites best your requirements to load/replicate the LDAP data into your Maximo
TPAE environment (VMMSYNC or LDAPSYNC)
If only a subset of LDAP users is required, what is the criteria to identify the ones you need?
Which LDAP attributes do you require to use in Maximo TPAE? Are they mapped by default?
How do you manage organisational and personal changes in LDAP? Which key attributes are
changed? What is your expectation about Maximo TPAE to reflect these changes?
Do you require to store personal hierarchy in Maximo TPAE (A is manager of B)?
Where do you want to store the Maximo TPAE technical users (e.g. maxadmin) in your regular
LDAP data store?
Do you require different rights / passwords for these users in your different Maximo TPAE
environments (Development / Test / Production)?
Where do you want to assign users to groups (in Maximo TPAE or in LDAP)?
Do you require encrypted connections?
Do you require a TADDM to LDAP connection?
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 7 of 73
3. Conceptual aspects of connecting Maximo TPAE

to LDAP
3.1
Supported Authentication Methods
3.1.1 Use of local Maximo TPAE authentication or LDAP

There are two supported authentication methods: local Maximo TPAE authentication and authentication
using LDAP via WebSphere Virtual Member Manager (VMM). You cannot use both of them in parallel,
either local authentication or LDAP authentication has to be implemented.
During installation of your Maximo TPAE product you choose the used authentication method. You can
switch from local to LDAP authentication and vice versa after installation. This will be described later in
this document.
Benefit using local authentication:
No LDAP environment is needed
Useful for small and medium environments / customers, where no LDAP is available
Benefit using LDAP:
Users can login using their LDAP accounts
Single Sign On (SSO) is possible.
Please notice that using local authentication does not mean that LDAP cannot be integrated with your
Maximo TPAE environment. It is still possible to synchronize user and group information like contact data
from a LDAP environment.
3.1.2 Using local Maximo TPAE authentication

As mentioned before, you can choose local authentication during the installation of your Maximo TPAE
product. When you decide to use this method, all users and groups are created locally within your
Maximo TPAE application. This affects both technical and normal users. Password management is done
locally, too.
Please notice that user and group information can still be synchronized from a LDAP environment using
the LDAPSYNC cron task. This will be described later in this document.
3.1.3 Using LDAP via VMM (ITDS/AD)

As mentioned before, you can choose LDAP authentication during the installation of your Maximo TPAE
product.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 8 of 73
If you decide to use this method, the technical users wasadmin, maxadmin, mxintadm and maxreg can
automatically be created during the installation by the Maximo installer. Notice that the bind user
configured in the WebSphere VMM needs write access to LDAP in this case.
If it is not allowed to automatically create the required users, they have to be created manually in LDAP
before. In this case you have to deselect the option Create the required users in the appropriate installer
window.
Authorization / Group membership
There are 2 possible ways:
1. Create Maximo groups in LDAP

a. Assign users to security groups in LDAP
b. Both users and groups have to be synchronized to Maximo using VMMSYNC task which
is described later in this document
2. Create Maximo groups locally

a. Assign users to security groups locally
b. Only users have to be synchronized to Maximo using VMMSYNC task which is described
later in this document
3.1.4 Single Sign On

Maximo TPAE supports Single-Sign-On. Single-Sign-On is configured in WebSphere and the
configuration dependents on your SSO Infrastructure (e.g. SPNEGO). This chapter describes the Maximo
TPAE topics regarding SSO.
To use SSO, you need to use LDAP authentification in Maximo TPAE. Refer to chapter 3.4.2 for details
about changing the web.xml files and setting the database parameter mxe.useAppServerSecurity to 1.
3.1.4.1 SSO and Web Services Access

If you plan to use WebServices to connect to your Maximo TPAE environment in combination with SSO
then your configuration must be planned carefully and tested.
SSO requires FORM based authentication (see web.xml files) whereas WebServices requires (usually)
BASIC authentication.
The way we achieved this requirement was to do two different bindings to the URLs:
UI access
URL: <server>/maximo
Authentication Method = FORM
WebServices access
URL: <server>/meaweb
Authentication Method = BASIC
To achieve this behaviour the web.xml files have to be modified (to set the authentication method) and
the WAS SPNEGO Filter had to be used to separate the UI from the WebServices traffic.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 9 of 73
See:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/i
nfo/exp/ae/rsec_SPNEGO_tai_attribs.html
Details about the web.xml files for this example are attached to this document in chapter 5.1.
3.2
Mapping LDAP content to Maximo TPAE Database
3.2.1 VMMSYNC vs. LDAPSYNC

TPAE offers two different interfaces to connect a LDAP repository, these are VMMSYNC and
LPAPSYNC.
VMMSYNC
WAS
LDAP
TPAE
LDAPSYNC
Tivoli
Database
LDAP
Whereas VMMSYNC is connected to WAS, LDAPSYNC has direct access to LDAP repository. This has
the following impact:
LDAPSYNC can only be used as an interface for transferring user records to TPAE. Even if you
dont need to add new users in TPAE, the user administration is still active in TPAE. This includes
also the password administration, since the password will not be transferred from the LDAP.
Hence the user authentication will be still done by TPAE.
However, the security group assignment can be done within the LDAP repository.
VMMSYNC is very similar to LDAPSNC, but has one big difference: If you want to use
VMMSYNC, you need to switch to the LDAP authentication method. This means the user
administration in TPAE is disabled. You can not add any user in TPAE, and the user
authentication will be done by WAS VMM (using the password in LDAP).
3.2.2 The default mapping

This section explains the default mapping of the VMMSYNC Task see the Maximo TPAE 7.1.1.5 default
settings below.
Sections of the XML mapping file (see below or in Maximo TPAE: Cron Tasks VMMSYNC01 User
Mapping):
The first section contains:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 10 of 73
The Header lines
basedn Setting: A base DN can be specified here and will be mapped against
WebSphere VMM. A subtree of the WAS base DN might be specified.
Filter: You can specify a person filter to retrieve a subset of persons instead of all
persons. Common filters are real persons entries which contain a valid email address
in VMM or a group filter: e.g. all persons which are member of the group TIVOLIUSERS.
The recommendation is to use the LDAP Filter in WAS instead of the VMMSYNC Task.
But this filter is useful if you plan to setup multiple VMMSYNC Tasks for different
purposes and for a different set of users. See Chapter 3.3.1.2
The second section describes the VMM attributes which will be mapped in the next section to the
MBO attributes.
In the third section, the data mapping takes place:

o
This section contains attribute mappings for multiple tables
By default these tables are: MAXUSER, PERSON, PHONE and EMAIL
For each attribute line: first the name of the MBO attribute is stated followed by the
mapped name of the VMM attribute name
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE ldapsync SYSTEM "ldapuser.dtd">
<ldapsync>
<user>
<basedn>DC=intern,DC=adns</basedn>
<filter>PersonAccount </filter>
<scope>subtree</scope>
<attributes>
<attribute>uid</attribute>
<attribute>givenName</attribute>
<attribute>sn</attribute>
<attribute>displayName</attribute>
<attribute>street</attribute>
<attribute>telephoneNumber</attribute>
<attribute>mail</attribute>
<attribute>st</attribute>
<attribute>postalCode</attribute>
<attribute>c</attribute>
<attribute>l</attribute>
</attributes>
<datamap>
<table name="MAXUSER">
<keycolumn name="USERID" type="UPPER">uid</keycolumn>
<column name="LOGINID" type="ALN">uid</column>
<column name="PERSONID" type="UPPER">uid</column>
<column name="TYPE" type="UPPER">{TYP 2}</column>
<column name="FORCEEXPIRATION" type="YORN">{0}</column>
<column name="MAXUSERID" type="INTEGER">{:uniqueid}</column>
</table>
<table name="PERSON">
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 11 of 73
<keycolumn name="PERSONID" type="UPPER">uid</keycolumn>

<column name="FIRSTNAME" type="ALN">givenName</column>
<column name="LASTNAME" type="ALN">sn</column>
<column name="DISPLAYNAME" type="ALN">displayName</column>
<column name="ADDRESSLINE1" type="ALN">street</column>
<column name="STATEPROVINCE" type="ALN">st</column>
<column name="CITY" type="ALN">l</column>
<column name="POSTALCODE" type="ALN">postalCode</column>
<column name="COUNTRY" type="ALN">c</column>
<column name="PERSONUID" type="INTEGER">{:uniqueid}</column>
</table>
<table allowdelete="true" name="PHONE">
<keycolumn name="TYPE" type="ALN">{Work}</keycolumn>
<keycolumn name="ISPRIMARY" type="YORN">{1}</keycolumn>
<column name="PHONEID" type="INTEGER">{:uniqueid}</column>
<column name="PHONENUM" required="true" type="ALN">telephoneNumber</column>
</table>
<table allowdelete="true" name="PHONE">
<keycolumn name="TYPE" type="ALN">{Home}</keycolumn>
<column name="PHONEID" type="INTEGER">{:uniqueid}</column>
<column name="PHONENUM" required="true" type="ALN">telephoneNumber</column>
</table>
<table allowdelete="true" name="EMAIL">
<keycolumn name="TYPE" type="ALN">{Work}</keycolumn>
<column name="EMAILID" type="INTEGER">{:uniqueid}</column>
<column name="EMAILADDRESS" required="true" type="ALN">mail</column>
</table>
</datamap>
</user>
</ldapsync>
3.2.3 Which attribute to use as personid/userid/loginid

In the following example MSAD is used as LDAP repository to explore this topic.
When you plan your data mapping between TPAE and LDAP, there are three fields in TPAE that need
your special attention. These are:
1) userid The primary key in the maxuser table
2) loginid: The loginid or login name that is used when you want to log on TPAE
3) personid: The primary key in the person table
In AD there are usually three attribute which are candidates to use:

1) cn: The primary key in AD
2) sAMAccountName: The loginid in windows
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 12 of 73
3) mail: the Email address of the person
Since all three attributes in LDAP are unique, there is actually any combination possible. But you should
take notice about some things in order to prevent later problems:
1) First of all, userid and personid should always be the same value. There is not really a need for
that, but normally there is no reason to use different values. That applies especially to the LDAP
interface, since every user record has its person record.
2) For the userid (and personid) you consider the following:
a. Since the userid is key value in Maximo TPAE, you should use an attribute in LDAP
which will be changed very rarely. CN und Mail often contains the name of the person,
and if the person name is changed, the ID changes as well. But in some environments
the samAccountName will be changed even more often.
b. Even if CN and sAMAccountName are unique in one single LDAP, they are not
necessarily unique in the whole environment. That means, when you plan to connect
several LDAP repositories to TPAE, you need an attribute which is unique in general, this
is often only the mail address.
c.
The samAccountName is often a meaningless string. If you want to use this string as
userid, you should consider that this string is displayed and used in many panels in
Maximo TPAE. This may result in problems with the user acceptance.
3) For login you should consider the following

a. Often sAMAccountName is the first choice. Users are very familiar with that loginid,
because they are using that loginid in many other systems.
b. However, when you plan to connect severals LDAPs to Maximo TPAE, you should first
check if the sAMAccountName is unique in general. Otherwise you should consider using
the mail address.
Hint:
If you choose CN or email address for the userid, you most likely need to increase the field length of the
userid in TPAE
The following table shows two examples:

userid
CN
personid
(1)
sAMAccountName
mail
loginid
(1)
(1)
(2)
(2)
(2)
Example 1:
Assumptions: Single environment, CN contains the person name and changes only rarely
Impact: Userid is a meaningful value and login is familiar to the user (equal to the Windows AD login).
Example:2:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 13 of 73
Assumptions: Large environment with several LDAP repositories, mail address is the only really unique
attribute.
Impact: Userid is a reasonable value, but users need to familiarize to use their mail address for login.
3.2.4 What happens when key values are changed in LDAP

It is stated in the previous chapter that the LDAP attribute mapped to userid should not be changed. But
in an operational environment this is often not possible. For instance, when you use CN for the userid,
and CN is renamed in the LDAP for some reason, what is the impact now?
First of all you need to know is that VMMSYNC or LDAPSYNC perform always an Insert/Update Action.
This means, if the userid is not found in TPAE the user record will be inserted, whereas the userid already
exists the user record will be updated.
Hence, the above example will run as follows:

1) VMMSYNC/LDAPSYNC tries to insert a new user record into TPAE.
2) The old user record still exists in TPAE.
3) Most likely the insert of the new user record will fail, because the loginid and/or email address
already exist in TPAE (both are also unique in TPAE)
This means, you have to consider the following:
The first idea is often to delete the old user record, but this is not a product supported method
All you can do is to setup a mechanism to set the status to inactive (both, user and person
record)
In addition, you need to get rid of the existing unique values of the old user record
a. loginid (only in case it is not renamed as well)
b. email address (only in case it is not renamed as well)
The easiest way to do this is to setup an escalation, but again, there are many things you need to pay
attention:
1) Actually you want to perform the actions only for the old user records, but for this you need a flag.
There are three options:
a. The best way would be that the flag would be transferred via VMMSYNC/LDAPSYNC
from LDAP. But this is possible only when for instance, a record in LDAP is disabled, in
our case the record doesnt exist anymore.
b. You can set the flag indirect yourself
c.
i.
In the escalation set the flag for all users to yes
ii.
In VMMSYNC/LDAPSYNC set the flag for all users to no
iii.
Afterward all users flagged with yes dont exist in LDAP anymore
Dont use a flag, just perform the action for all users (just exclude some technical users
like maxadmin)
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 14 of 73
2) You can not clear the loginid since it is a mandatory field, likewise you can not set a fix value
since it is an unique field. Thus you have to overwrite the loginid with another unique value you
have: If you use the sAMAccountName for the loginid and CN for the userid, you can use the
userid to overwrite the loginid.
In following there are two examples for an escalation: (assumption: userid/personid is CN, loginid is
sAMAccountName)
EXAMPLE 1 (the simple but rough method, only applicable when VMMSYNC/LDAPSYNC runs each
night)
Escalation name: VMMSYNC_ADDON

Valid for: MAXUSER
SQL Condition: USERID NOT IN (MAXADMIN,)
Actions:
Type
Field
Value
Status change
status
inactive
Set field
loginid
userid
Status change
Person.status
inactive
Set field
Person.primarymail
userid
Important note:
The escalation must run very shortly before VMMSYNC/LDAPSYNC, in between all users are inactive.
Additionally ensure that VMMSYNC/LDAPSYNC has run, otherwise all users are inactive the next
morning.
EXAMPLE 2 (the softer way, applicable when VMMSYNC/LDAPSYNC runs several times per day)
This example uses a flag to indicate which users should be inactivated, you can choose an existing and
not used field or you can create a new one. In the example we call the flag ACTIONFLAG
Escalation name: VMMSYNC_ADDON

Valid for: MAXUSER
Escalation Point 1:
SQL Condition: USERID NOT IN (MAXADMIN,) AND ACTIONFLAG=1
Actions:
Type
Field
Value
Status change
status
inactive
Set field
loginid
userid
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 15 of 73
Status change
Person.status
inactive
Set field
Person.primarymail
userid
Escalation Point 2:
SQL Condition: USERID NOT IN (MAXADMIN,)
Actions:
Type
Field
Value
Set field
actionflag
Important notes:
The escalation must always run between VMMSYNC/LDAPSYNC runs, never two times direct
consecutively, otherwise all users are inactivated
In VMMSYNC/LDAPSYNC you need to map the actionflag to the fix value 0
3.2.5 Mapping the persons Manager (Supervisor)

Most LPAP repositories normally contain a manager attribute which is used by many customers. Also
Maximo has the field supervisor (manager) in the person table which can be used for instance in an
approval process. Thus it is a rather obvious idea to map the LDAP manager attribute to the Maximo
supervisor attribute, but this is not as simple as it might initially appear.
Problem:
In Maximo the supervisor field is a link within the person table and must be populated exactly with the
personid of the manager record. Instead in Active Directory the manager attribute is populated neither
with CN nor with sAMAccountName but with the distinguishedName of manager record in AD (The
distinguishedName is a kind of key in Active Directory). This means we cannot take the straight way to
map the LDAP manager attribute to Maximo supervisor attribute.
The following chapter shows a possible way to transfer the manager attribute from LDAP to Maximo.
Alternatively you can also ask the customer to add an additional manager field in LDAP and to fill it with
the corresponding value (CN, sAMAccountName or mail), but very likely he will refuse this.
Additionally it is very important this new manager field contains a valid personid and the person record
already exists in Maximo when you try to load that field.
3.2.5.1 Transfer distinguishedName and manager fields to Maximo

In the first step we transfer the LDAP attributes distinguishedName and manager into two new fields in
Maximo.
3.2.5.1.1 Add new fields distinguishedName and manager in Maximo

First of all add two new auxiliary fields in the person table with the database configurator.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 16 of 73
Table
Attribute
Type
Length
PERSON
DISTINGUISHEDNAME (1)
ALN
150 (2)
PERSON
MANAGER
ALN
150
(1) You can use your own naming convention

(2) The field distinguishedName can be pretty long, check the length of the largest value in your
environment.
3.2.5.1.2 Modify WIMCONFIG.XML

Since both fields (distinguishedName and manager) are not defined in the WAS standard configuration,
you need to enhance the mapping section in the WIMCONFIG.XML.
For this you need to choose two free fields. What this means is, that you need two fields which are
defined in standard configuration, but you dont use them in the current configuration.
To find two available fields take a look into the file wimdomain.xsd. This file describes among other things
which fields are defined for the LDAP repository. In the upper section the are many entries starting with
xsd:element name, these are the fields which are available in the standard. You can choose a field with a
similar sense, but most important is that you choose a field with the type="xsd:string". Likely you will see
the field manager, but you can not use the field since it has the type="IdentifierType".
In our scenario we use the fields localityName and businessCategory (not really good names, admittedly,
but this does not matter since you will never see this on the surface)
Add the following mapping to the WIMCONFIG.XML file:

<config:attributes name="distinguishedName" propertyName="localityName">
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>
<config:attributes name="manager" propertyName="businessCategory">
Now you replaced the standard defined fields by the fields we want to use.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 17 of 73
Since the field businessCategory is defined as propertiesNotSupported name, you need to delete the line.
<config:propertiesNotSupported name="businessCategory"/>
After this the fields distinguishedName and manager are available in the VMMSYNC Crontask.
If you dont like to use meaningless names, you can also modify the file wimdomain.xsd. But for this you
need the appropriate WAS skill, and as mentioned before it is not really necessary.
3.2.5.1.3 Modify VMMSYNC Crontask

Now we can expand the VMMSYNC Crontask in order to transfer distinguishedName and manager to
Maximo.
In the upper section <attributes> in the UserMapping add the following lines:
<attribute>localityName</attribute>
<attribute>businessCategory</attribute>
In the section <table name="PERSON"> add the following lines:

<column name="PA_DISTINGUISHEDNAME" type="ALN">localityName</column>
<column name="PA_MANAGER" type="ALN">businessCategory</column>
Now both AD fields, distinguishedName and manager, are mapped to the new Maximo fields.
3.2.5.1.4 Run VMMSYNC Crontask

Finally in step 1 run VMMSYNC Crontask to test whether the fields distinguishedName and manager are
transferred to Maximo. Either you can check this with a database tool or you can add both fields in
application person (List or Detail).
After you have ensured that both fields are transferred to Maximo you can continue with step 2.
3.2.5.2 Populate supervisor field in Maximo

In step 2 we now use the auxiliary fields distinguishedName and manager to populate the supervisor field
in Maximo
3.2.5.2.1 Add new relation in Maximo

Since we know that the manager field contains the distinguishedName field of the manager person record
we can now build a relation
Table
Relation
Where Clause
Child Object
PERSON
MANAGER (1)
DISTINGUISHEDNAME =
:MANAGER
PERSON
(1) You can use your own naming convention
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 18 of 73
Now you should test the relation. Add the field manager.personid temporarily for test purposes in the
application person (List or Details).
The field manager.personid should be filled in most cases, however in some cases it could be empty.
This could have one of the following reasons:
The manager field in LDAP is empty
The manager person record does not exist in Maximo for some reason
3.2.5.2.2 Replicate supervisor field in Maximo

After you have tested that the relation manager works, you can use the field manager.personid to fill the
field supervisor.
The best thing to do this is simply to setup an escalation with the corresponding action:
Add a new escalation
Add a new action
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 19 of 73
The escalation should run after each VMMSYNC run, in most cases this means once a day.
3.2.6 Mapping additional fields from LDAP to Person / User Table

As described in section 3.2.2 by default these attributes are mapped:
VMM Attribute Name
Short Description
uid
UserID
givenName
First Name
sn
Surname
displayName
<first name> blank <surname>
street
Street
telephoneNumber
Telephone number
mail
E-Mail address
st
State
postalCode
Zip code
Country
City
Important: If you want to map additional attributes, you have to take care of these two activities:
1. Map the attribute of your LDAP directory to a VMM attribute
2. Map the additional VMM attributes to your MBO attribute in the VMMSYNC task
Details for this scenario:

In this customer example the display name from the LDAP Directory will be used as Display Name in
Maximo instead of the concatenated first name and surname AND the office number of the employee will
be stored in the MBO attribute addressline2 of the person table:
First, you need to modify the wimconfig.xml file to map the attribute of your LDAP directory to a VMM
attribute. Look for the section <config:attributeConfiguration> and add a stanza for each new mapped
field (description was mapped by default, no activities were necessary). Here the attribute
physicalDeliveryOfficeName in LDAP is mapped to the VMM attribute postalAddress:
<config:attributeConfiguration>
<config:attributes defaultValue="544" name="userAccountControl">
<config:attributes name="samAccountName" propertyName="uid">
<config:attributes name="streetAddress" propertyName="street">
<config:attributes name="physicalDeliveryOfficeName" propertyName="postalAddress">
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 20 of 73

Second, the VMMSYNC task has to be modified to map the required fields to the database tables. Add
the two attributes to attributes section and map them to the database attributes in the person table:
<attributes>
<attribute>uid</attribute>
<attribute>givenName</attribute>
<attribute>sn</attribute>
<attribute>displayName</attribute>
<attribute>street</attribute>
<attribute>telephoneNumber</attribute>
<attribute>mail</attribute>
<attribute>st</attribute>
<attribute>postalCode</attribute>
<attribute>c</attribute>
<attribute>l</attribute>
<attribute>description</attribute>
<attribute>postalAddress</attribute>
</attributes>
<table name="PERSON">
<column name="FIRSTNAME" type="ALN">givenName</column>
<column name="LASTNAME" type="ALN">sn</column>
<column name="DISPLAYNAME" type="ALN">description</column>
<column name="ADDRESSLINE1" type="ALN">street</column>
<column name="ADDRESSLINE2" type="ALN">postalAddress</column>
<column name="STATEPROVINCE" type="ALN">st</column>
<column name="CITY" type="ALN">l</column>
<column name="POSTALCODE" type="ALN">postalCode</column>
<column name="COUNTRY" type="ALN">c</column>
<column name="PERSONUID" type="INTEGER">{:uniqueid}</column>
</table>
Additional sources of information:
Retrieve attributes from Active Directory:

https://www-304.ibm.com/support/docview.wss?uid=swg21385052
Mapping additional AD attributes within VMM

https://www304.ibm.com/support/docview.wss?mynp=OCSSLKT6&mync=R&uid=swg21499970&myns=swgti
v
3.2.7 Mapping additional fields from LDAP to other tables

A common requirement is that a customer wants to use the start and stop watch within service request /
incident / problem management application. To do that, each TPAE user needs to have a LABOR and
LABORCRAFTRATE entry to use this function. In larger environments, this user group might change
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 21 of 73
quite dynamically; therefore an automated management of these records was required in a customer
project.
Solution outline:
Use the VMMSYNC task to create the entries additional to the PERSON and MAXUSER table in the
LABOR and LABORCRAFTRATE table.
Challenges:
A record had to be created in the table LABOR and in the LABOR child-table
LABORCRAFTRATE.
These entries should be created only for a certain user group and not for all users: Only users
which belong to the group MAXIMOUSERS
Manipulation of the VMMSYNC User Mapping to include additional tables
Solution:
Create a second VMMSYNC tasks and specify a filter in order that these entries will be created
for this subset of users only (see filter specification below).
Additionally, the original VMMSYNC task is still executed for all users
The new VMMSYNC task (User Mapping) had to be expanded to contain new table mappings for
the two tables LABOR and LABORCRAFTRATE (see specification below).
Additionally new relationships between the MAXUSER and LABOR table (named LABOR) and
between the MAXUSER and LABORCRAFTRATE table (named LABORCRAFTRATE) had to be
created.
Hint: Creation of a new user and the LABOR and LABORCRAFTRATE in one transaction will fail
due to an insert error: The parent does not exist when creating the child entry.
Solution: Make sure, that the regular VMMSYNC Tasks (the one which creates/updates all
users) runs before the new Labor-VMMSYNC Task runs (which will create the additional
LABOR and LABORCRAFTRATE records only).
Example: The regular VMMSYNC Tasks runs at 11 PM, the Labor-VMMSYNC Task runs at
11:30 PM
Filter setting for the new VMMSYNC tasks (User Mapping) to limit the scope to the persons which belong
to the group MAXIMOUSERS:
<filter>PersonAccount' and
memberOf='CN=MAXIMOUSERS,OU=TIVOLI,OU=Spezial,DC=AREA01,DC=intern,DC=cust</filter>
This section was added to the new VMMSYNC task (User Mapping) below of the email mapping:
<table allowdelete="true" name="LABOR">
<keycolumn name="LABORCODE" type="UPPER">uid</keycolumn>
</table>
<table allowdelete="true" name="LABOR">
<keycolumn name="LABORCODE" type="UPPER">uid</keycolumn>
</table>
<table allowdelete="true" name="LABORCRAFTRATE">
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 22 of 73
3.3
Aspects of design and connection alternatives
3.3.1 Using LDAP filters to retrieve a specific set of users and groups
only
If WAS is connected to a LDAP Repository, then by default all users belonging to the specified base DN
will be available in WAS and Maximo TPAE.
It is important to understand that there is a hierarchy in the access to the LDAP data:
1. WAS to LDAP
The access to the LDAP system is configured in the WAS System.
Users and groups are retrieved from LDAP and are available in WAS VMM (Virtual Member
Manager).
2. TPAE to WAS VMM
The TPAE VMMSYNC task connects to the WAS VMM, but it does not connect to the LDAP
System directly. Therefore only the users and groups in WAS VMM are visible for TPAE.
Filters may be specified at both levels of this cascaded architecture in order to retrieve the required set
of users and groups, only.
Recommendations of the authors:

1. Use the LDAP filter in WAS to reduce result list to the expected users and groups only.
2. Use a LDAP browser to develop and verify the appropriate LDAP search string
3. Apply the verified search string to the Filter section in the WAS security definition
4. Make sure, that the required TPAE users (e.g. maxadmin) are included in that list or specify
them in a separate repository.
5. When the LDAP Filter in WAS is setup correctly, then there is no need to specify an additional
filter in the VMMSYNC task. Use this filter only if there are requirements to manage the prefiltered users differently in the TPAE database.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 23 of 73
3.3.1.1 Configuring LDAP filter for WAS to LDAP

3.3.1.1.1 Developing the LDAP filter
This section describes how to develop, test and configure a LDAP filter in WAS.
Use a LDAP browser like JXplorer to connect to your LDAP Server. With this tool you are able to browse
through the LDAP hierarchy and you can also specify search strings (filter) and view the results of your
query.
After connecting the LDAP browser to your LDAP Server open the search dialogue and enter a search
condition (e.g. search for surname that contains Nees)
Search results:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 24 of 73
Back to the filter definitions:

Use the Build Filter folder to build and verify single aspects of your LDAP search string. The generated
filter is displayed in the Text Filter folder. Join your search string aspects to one single search string
using the operators (& and !)
Active Directory example:

This search string will return all users which have a @ in their mail attribute, have at least one character
in the uid attribute and are member of the LDAP group MAXIMOUSERS.
Verify that the search string returns exactly what you require
3.3.1.1.2 Apply the LDAP filter search string to WAS

Login to the WAS Admin Console and navigate to the appropriate section and paste your search string to
the field Search filter.
Click Apply and save your configuration.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 25 of 73
Restart WAS to make the changes effective.
3.3.1.1.3 Testing the LDAP filter

After WAS restart, navigate to the Manage Users section in WAS Admin Console and ensure that the
displayed users in WAS are reduced to exactly the same users as displayed before in the LDAP browser
as the result of your search string.
Repeat this procedure for the group definitions if required.
3.3.1.2 Configuring LDAP filter VMMSYNC to VMM

As described before, the VMMSYNC task will only see the users and groups available in WAS VMM. If
the WAS filter is appropriately configured, then there is no need to specify a filter in VMMSYNC task
additionally.
In case you have the requirement to specify an additional filter for user group within VMMSYNC task
e.g. to define a different behaviour (or role) for a subset of the users/groups then you can do that within
the header section of the VMMSYNC task, section Group Mapping / User Mapping.
Hint 1: Additionally to the filter entry the basedn entry can be used as hierarchical filter.
Hint 2: Note, that the syntax for specifying filters in VMMSYNC is different to LDAP!
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 26 of 73
Group Mapping:
<!DOCTYPE ldapsync SYSTEM "ldapgroup.dtd">
<ldapsync>
<group>
<basedn>OU=TIVOLI,DC=ORG,DC=intern,DC=adns</basedn>
<filter>Group</filter>
<scope>subtree</scope> <attributes>
User Mapping:
<!DOCTYPE ldapsync SYSTEM "ldapuser.dtd">
<ldapsync>
<user>
<basedn>DC=intern,DC=adns</basedn>
<filter>PersonAccount' and
memberOf!='CN=MAXIMOUSERS,OU=TIVOLI,DC=ORG,DC=intern,DC=adns</filter>
<scope>subtree</scope>
3.3.2 Passthrough Authentication

In a customer engagement we were facing the requirement, that the customer wanted to have strict
control about the users which are allowed to access the TPAE system. A direct integration to the existing
MS Active Directory was not desired.
After discussing the alternatives, the customer decided to use the shipped ITDS system as user
repository. The new users in the ITDS system were created with the same userid as in the MS AD
System.
Later in the project the customer came up with the idea to replicate the password in MS AD to the ITDS
system. Unfortunately, this is not possible, as the passwords are encrypted in the data store and the
different systems and different platforms use different encryption methods. Therefore a replication of an
encrypted password was not possible in this situation.
But there is a different way to achieve this goal: ITDS supports a method to forward the password check
to another LDAP system. This method is called Passthrough Authentication (PTA). The following
configurations have to be performed:
Passthrough Authentication has to be configured in the ITDS System (which serves an user
repository for the TPAE system)
The user must be created in ITDS
The user must not have a password in ITDS!

Hint: The Passthrough Authentication is activated individually for users: If the user has a
password in ITDS, then the local password will be used and the Passthrough Authentication is
disabled for this account.
The user must exist (with password) in the LDAP server the Passthrough Authentication is
pointing to.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 27 of 73
3.3.2.1 Setting up Passthrough Authentication

The ibmslapd.conf file has to be expanded to activate the Passthrough Authentication (PTA).
Example:
dn: cn=Configuration
ibm-slapdPtaEnabled: true
dn: cn=Passthrough Server1, cn=Passthrough Authentication, cn=Configuration
changetype: add
cn: passthrough Server1
ibm-slapdPtaURL: ldap://msad.net.de:389
ibm-slapdPtaSubtree: ou=users,ou=itsm,o=it,c=de
ibm-slapdPtaMigratePwd: false
ibm-slapdPtaAttrMapping: uid $ cn
ibm-slapdPtaSearchBase: ou=org,dc=it,dc=de
ibm-slapdPtaBindDN: CN=LDAP_ITSM,OU=ORGUSERS,OU=ORG,DC=IT,DC=DE
ibm-slapdPtabindPW: maximo4msad
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt
Description of the configuration line (see above, ITDS is the TPAE user repository, MSAD is the remote
user repository which is the target of PTA):
dn: cn=Configuration
ibm-slapdPtaEnabled: true
dn: cn=Passthrough Server1, cn=Passthrough Authentication, cn=Configuration
changetype: add
cn: passthrough Server1
ibm-slapdPtaURL: ldap://msad.net.de:389
Enter MSAD address here
ibm-slapdPtaSubtree: ou=users,ou=itsm,o=it,c=de
Enter ITDS hierarchy here
ibm-slapdPtaMigratePwd: false
ibm-slapdPtaAttrMapping: uid $ cn
Mapping of key values uid/ITDS to cn/MSAD
ibm-slapdPtaSearchBase: ou=org,dc=it,dc=de
User search base in MSAD
ibm-slapdPtaBindDN: CN=LDAP_ITSM,OU=ORGUSERS,OU=ORG,DC=IT,DC=DE
previous line: User in MSAD used for authentication
ibm-slapdPtabindPW: maximo4msad
Password of this user in MSAD
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt
Hint: PTA is configured in ITDS only. The PTA configuration is not visible for WAS VMM. WAS VMM will
not notice if PTA is used in the ITDS system or not.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 28 of 73
3.3.3 Connecting multiple LDAPs

3.3.3.1 Connecting to a Meta Directory Server
The simplest way to connect to multiple LDAP Servers is to connect to a Meta Directory which is
connected to all required LDAP Servers. In this case the WAS VMM will be connected to the META LDAP
system only very similar to the connection to a regular LDAP Server.
Important Hint: WAS VMM will not accept duplicate users in the LDAP. The result is, that the user(s) with
the duplicate entries will not be able to log in. In case your META Directory does not take care of this
issue the WAS LDAP filter can be used to filter the correct userid (see chapter 3.3.1 for details).
3.3.3.2 Connecting to mixed Local-WAS-Repository and LDAP authentication

In the WebSphere Virtual Member Manager (VMM) you can use a mix of WebSphere built-in repository
and LDAP repositories.
This method provides the benefit that the technical users wasadmin, maxadmin, mxintadm and maxreg
do not have to be created in your regular LDAP user store. The user names cannot be changed for the
Maximo technical users and sometimes customers are not willing to create these users in LDAP due to
restrictions given by naming conventions.
In general you have to do the following:
1. Save WebSphere wimconfig.xml file. You can fall back later in case of failure and no logon to
WebSphere should be possible by restoring this file
2. Log on to WebSphere Admin Console
3. Add new LDAP repository for regular users
Add repository as described in the TPAE product manuals (e.g. CCMDB 7.2.1 - Planning and
Installation Guide Chapter 8: Manually configuring the J2EE Server Manually configuring
WebSphere Application Server Network Deployment - Manually configuring Virtual Member
Manager on WebSphere Application Server Network Deployment page 228 topics 1 -23)
Example:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 29 of 73
4. Add repositories to realm
Security Secure administration, applications, and infrastructure
Available realm definitions Federated repositories Configure
Add Base entry to Realm...
Add the created LDAP repository to the VMM realm
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 30 of 73
When you add one single LDAP repository it is recommended to use the same entries for both the base
DN in the realm and the DN of the base entry in the repository (see screenshot). This configuration is
easier to handle later, e.g. when adding the base DN to the VMMSYNC task in Maximo.
If not already done, add the WAS built-in repository to the VMM realm by clicking on Use
built-in repository
Ok
Select Set as current
Save
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 31 of 73
5. Create technical users in local WAS repository using the WebSphere user and group
management
User and Groups Manage Users
Create
Create users maxadmin, mxintadm and maxreg as described above. You do not need to
create the user wasadmin, because the user is already included in the WAS built-in
repository.
.
6. Restart WebSphere Deployment Manager
You can check your configuration by opening the users application again and press the 'Search' button.
All users (both the four technical users and the LDAP users) should appear.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 32 of 73
3.3.3.3 Connecting to multiple LDAP Servers

In large environments you will find often several LDAP repositories, whether the customer has big
locations with their own LDAP, or the customer has several subsidiaries.
The initial questions to customer would be always:
Has the customer a global catalog?
If not, are there any plans to build up one?
Since you can use a global catalog like any other LDAP repository, this would be the easiest and
smartest way to connect TPAE to multiple LDAP Servers. However, if there is no global catalog and the
costumer tries to avoid this effort, you can connect the individual LDAP repositories.
3.3.3.3.1 Configure LDAP repository in WAS

First of all, if you want to use VMMSYNC, you need to configure each LDAP repository in WAS. For this
log into WAS console and switch to Security / Secure administration, applications, and infrastructure:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 33 of 73
Make sure that Available realm definition is configured to Federated repositories. Press Configure to
configure the individual LDAP repositories.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 34 of 73
For the realm name you can choose any name, to add a LDAP repository press Add Base entry to
Realm.
Populate both fields with the base DN of your repository and press Add Repository to configure the
server.
Give your repository a name and choose the directory type, for instance Microsoft Windows Server 2003
Active Directory. Define the primary host with the corresponding port, at last specify your LDAP user to
access the LDAP in the Security section.
Hint:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 35 of 73
Before you start to configure your VMMSYNC Task, you should check under User and Group / Manage
users whether you can see the users from your various LDAP repositories. If necessary, you need to do
some manual changes in the wimconfig.xml.
3.3.3.3.2 Configure VMMSYNC Tasks

When you are satisfied with the outcome of your repository configuration, you can start to configure the
VMMSYNC task (this chapter applies more or less also to the LDAPSYNC task).
Even if you want to use the same mapping for each repository, you need for each repository its own
VMMSYNC instance. The reason is the different principals you need to specify for each repository.
Remember, that you can not define the same userid in several LDAP repositories, for instance wasadmin,
which is usually used as the principal. Hence you need an own principal for each repository, this can be
the same userid as you specify in the WAS repository configuration. Additionally you need to define these
users in WAS as Administrators under Users and Groups / Administrative User Roles.
However, there is a second pitfall. If you add a second repository now, you will possibly find that your
original VMMSYNC instance doesnt work anymore. The reason is that the instance now tries to get data
also from the new added repository, but this doesnt work because the principal isnt defined in that
repository. To make sure that each VMMSYNC instance only gets data from the corresponding repository
you need to specify the base DN in the user and group mapping.
In a nutshell this means:
First set up one VMMSYNC instance for one repository. Make sure that you specify the correct
principal and base DN. Afterwards run a test.
Duplicate the VMMSYNC instance, and change at least principal and base DN.
3.3.3.3.3 General Hints

Finally, some general hints:
As mentioned before, for userid and loginid you need key values which are unique across all
repositories. This often is only the mail address.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 36 of 73
Unfortunately you can not use the same security group names in each repository. The reason is
the behaviour of the VMMSYNC Task. In each run, all users of a security group are removed in
TPAE first, and afterwards are newly assigned. The result is that a security group contains the
users from one the last scheduled - repository only. You need to define different names to avoid
this, for instance different prefixes or suffixes. Of course then you have several sets of security
groups in TPAE.
3.3.4 Changing the Base Distinguished Name in TPAE and WAS

Follow the instructions below and adapt where appropriate when it is required to change the base
distinguished Name in TPAE and WAS.
3.3.4.1 Switch TDS base distinguished name from default to customer defined
This task consists of the following steps which were executed in a CCMDB 7.1.1 environment.
The DN ou=SWG,o=ibm,c=us should be changed to
ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de.
3.3.4.1.1 Add new Suffix DN to TDS

Add the new suffix using the TDS configuration tool.
# ./idsxcfg
3.3.4.1.2 Copy users and groups to the new DN

You can export and import a LDIF file using the TDS configuration tool and edit it with a text editor in
between.
Alternatively you can use a LDAP editor like Jxplorer to connect to TDS, to copy the users and groups to
the new DN, and to change the group member attributes to the new DN.
3.3.4.1.3 Backup configuration file of Virtual Member Manager on WebSphere

The Virtual Member Manager configuration is stored in the file wimconfig.xml.
This file is located in the following directories:
/<instdir>/WebSphere/AppServer/profiles/ctgDmgr01/config/cells/ctgCell01/wim/
config/wimconfig.xml
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/config/cells/ctgCell01/wi
m/config/wimconfig.xml
Copy the wimconfig.xml files to e.g. wimconfig.xml.IBM.
3.3.4.1.4 Manually configuring Virtual Member Manager on WebSphere

This procedure provides task information for manually configuring Virtual Member Manager (VMM) to
secure CCMDB.
During the installation process, the CCMDB installation program provided you with the option of
automatically configuring CCMDB middleware. If you elected to have the CCMDB installation program
automatically configure CCMDB middleware, then it will, among other tasks, perform Virtual Member
Manager (VMM) configuration for you. If you elected to manually configure CCMDB middleware for use
with CCMDB, you will have to manually configure VMM.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 37 of 73
VMM provides you with the ability to access and maintain user data in multiple repositories, and federate
that data into a single virtual repository. The federated repository consists of a single named realm, which
is a set of independent user repositories. Each repository may be an entire external repository or, in the
case of LDAP, a subtree within that repository. The root of each repository is mapped to a base entry
within the federated repository, which is a starting point within the hierarchical namespace of the virtual
realm.
Note that if you intend to configure VMM to use SSL with a federated LDAP repository, it must be done
only after a successful CCMDB installation. If VMM is configured to use SSL with a federated LDAP
repository prior to completing the CCMDB installation, the installation will fail. Do not configure a
WebSphere VMM LDAP federated repository to use SSL with a LDAP directory prior to installing
CCMDB. Configure SSL after the CCMDB installation program has completed successfully.
To add a LDAP directory to the VMM virtual repository, you must first add the LDAP directory to the list of
repositories available for configuration for the federated repository and then add the root of baseEntries to
a search base within the LDAP directory. Multiple base entries can be added with different search bases
for a single LDAP directory.
Important: Before you begin this procedure, ensure you have a wasadmin user created in your LDAP
repository.
To add the IBM Tivoli Directory Server to VMM, complete the following steps:
1. Login to the admin console, then navigate to Security -> Secure administration, applications,
and infrastructure.
2. Locate the User account repository section and pick Federated repositories from Available
realm definition, and then click Configure.
3. Click Manage repositories, located under Related Items.
4. Click Add to create new repository definition under the current default realm.
5. Enter the following values, and then click Apply and the click Save.
Repository identifier
Enter customer.
Directory type
Select the directory type IBM Ticoli Directory Server Version 6.
Primary host name
Enter the fully-qualified host name or IP address of the IBM Tivoli Directory Server.
Port
Enter 389.
Support referrals to other LDAP servers
Set this to ignore.
Bind distinguished name
Enter cn=root
Bind password
Enter the password for the bind distinguished name.
Login properties
Leave this value blank.
Certificate mapping
Select EXACT_DN
6. Return to the Federated repositories page by clicking Security -> Secure administration,
applications, and infrastructure, selecting Federated repositories from the Available realm
definitions drop-down list, and then clicking Configure.
7. Locate the Repositories in the realm section and click Add Base entry to Realm.
Note that if there is an existing file repository entry in the Repositories in the realm table, you
must select it click Remove, and save the change, after creating the new entry.
8. Enter the following values, and then click Apply and then click Save.
Repository
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 38 of 73
Select customer.
Distinguished name of a base entry that uniquely identifies this set of entries in the realm
ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de
Distinguished name of a base entry in this repository
ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de
9. From the Federated repositories configuration page, enter the following values and then click
Apply and then click Save:
Realm name
Enter ISMRealm.
Primary administrative user name
Enter wasadmin. This value should be a valid user from the configured LDAP repository.
Server user identity
Select Automatically generated server identity.
Ignore case for authorization
Select this check box.
10. Click Supported entity types, and then click PersonAccount.
11. From the PersonAccount configuration page, enter the following values:
Entity type
Verify that the value is PersonAccount.
Base entry for the default parent
Enter ou=users,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de
Relative Distinguished Name properties
Enter uid.
12. Click OK and then click Save
13. Click Supported entity types, and then click Group.
14. From the Group configuration page, enter the following values:
Entity type
Verify that the value is Group.
Enter ou=groups,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de
Enter cn.
15. Click Supported entity types, and then click OrgContainer.
16. From the OrgContainer configuration page, enter or verify the following values:
Entity type
Verify that the value is OrgContainer.
Enter ou=prod,ou=sysman,ou=unit,o=customer,c=de
Enter o;ou;dc;cn.
17. Click OK and then click Save
18. Navigate to Security > Secure administration, applications, and infrastructure.
19. From the Secure administration, applications, and infrastructure configuration page, complete
the following:
a. Enable administrative security.
b. Enable application security.
c. Deselect Use Java 2 security to restrict application access to local resources.
d. From Available realm definition, select Federated repositories.
e. Click Set as current.
20. Click Apply, and then click Save.
21. Restart WebSphere and the managed nodes:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 39 of 73
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopServer.sh MXServer
-username wasadmin -password <pwd>
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopNode.sh
/<instdir>/WebSphere/AppServer/profiles/ctgDmgr01/bin/stopManager.sh
/<instdir>/HTTPServer/bin/apachectl stop
/<instdir>/HTTPServer/bin/apachectl start
/<instdir>/WebSphere/AppServer/profiles/ctgDmgr01/bin/startManager.sh
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/startNode.sh
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/startServer.sh MXServer
3.3.4.1.5 Manually configuring the VMMSYNC cron task for TDS

This topic details how to manually configure the VMMSYNC cron task for Tivoli Directory Server.
VMMSYNC is the cron task that schedules the synchronization between CCMDB and the directory server
and is configured through the Maximo application user interface . This procedure is required if you use
TDS as your directory server.
To modify the VMMSYNC cron task for TDS, complete the following steps:
1. Log into the Maximo application user interface as maxadmin.
2. Navigate to the Cron Task Setup application by selecting Go To -> System Configuration
-> Platform Configuration -> Cron Task Setup.
3. Click the VMMSYNC cron task and configure the following values:
Active?
Enable the Active? option by selecting the checkbox.
Credential
Password for wasadmin in LDAP
GroupMapping
Edit the <basedn> entry of the XML file.
<basedn>ou=groups,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c
=de</basedn>
GroupSearchAttribute
cn
Principal
cn=wasadmin,ou=users,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de
SynchAdapter
psdi.security.vmm.DefaultVMMSyncAdapter
SynchClass
psdi.security.vmm.VMMSynchronizer
UserMapping
Edit the <basedn> entry of the XML file.
<basedn>ou=users,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=
de</basedn>
UserSearchAttribute
Uid
You will have to click the arrow located in the header of the Cron Task Parameters table
to view all parameters.
4. Click the save icon.
The updated parameters will be used at the next scheduled synchronization.
3.3.4.1.6 Testing the new base distinguished name
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 40 of 73
If you have problems to login to WebSphere or to CCMDB restore the wimconfig.xml file from the
backup file wimconfig.xml.IBM.
Create a new user in TDS and check if you can see it in WebSphere.
Check if the VMMSYNC cron task is running in CCMDB and if the new user is mapped to the CCMDB
user repository.
3.3.5 Connecting LDAP Servers other than ITDS and MSAD

In the TPAE 7.2 Releases there are only two supported LDAP Servers:
IBM Tivoli Directory Server (ITDS)
Microsoft Active Directory Server (MSAD)
But what to do if your organisation is using a LDAP System different to the named ones? WAS VMM
supports more LDAP systems as the ones which are tested with TPAE.
The recommended scenario is as follows:
Check if WAS VMM supports your LDAP system
Install/configure your TPAE System with ITDS (is shipped free for use with TPAE)
Backup your ITDS configuration and shut it down
Backup your WAS VMM configuration: wimconfig.xml - (will be used for PMR handling or during
upgrades only)
Configure WAS VMM to connect to your (not supported) LDAP system and test that the required
users/groups are visible in the WAS Admin Console Manage Users/Groups section
Most likely, you will need to modify the field mapping in the wimconfig.xml file in order to get the
required data into the required field in TPAE.
In case you are asked during a PMR process by the IBM support to recreate the issue without your
non-supported LDAP configuration (did not happen with multiple customers so far) you just need to
replace your wimconfig.xml file with the one corresponding to your ITDS server and restart the WAS cell.
3.3.6 Secured Connection WAS to LDAP using ldaps

In order to encrypt the connection from WAS to LDAP (ldaps) you need to do the following:
Open WAS Admin Console and go to the security settings
Enable SSL
Select TrustStore
Get the security certificate from your LDAP admin or the appropriate signer certificate.
Load certificate into TrustStore
Restart entire WAS cell
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 41 of 73
More details about this approach can be found here:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/cfg_msad_
ssl.html
3.4 Switching Authentication Methods

3.4.1 Switching LDAP authentication to local Maximo TPAE
authentication
To switch from LDAP to local Maximo authentication you have to do the following:
Tip: It is not required to change maximo.properties. There is a risk to edit this file due to encrypted
passwords. Additionally users often edit files using Wordpad on Windows. This can lead to hidden control
characters and avoid that the file can be used by Maximo TPAE later.
1) Stop MXServer
2) Backup Maximo database
3) On the Admin Server, backup all web.xml files under
\ibm\smp\maximo\applications\maximo\<subdirectory>\webmodule\web-inf
This affects the subdirectories maximouiweb, meaweb, maxrestweb and mboweb
4) Backup maximo.ear in \ibm\smp\maximo\deployment\default
5) Edit all web.xml files under \ibm\smp\maximo\applications\maximo
Tip: Uncommenting in xml files means removing the comment strings  at the
end of the section. Commenting means setting these strings at the beginning and at the end.
maximouiweb\webmodule\web-inf\web.xml
Comment the following section and set env-entry-value to 0:

<!-<env-entry>
<description>Indicates whether to use Application Server security or not</description>
<env-entry-name>useAppServerSecurity</env-entryname>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>0</env-entry-value>
</env-entry>
-->
Comment the following section:
<!-<security-constraint>
<web-resource-collection>
<web-resource-name>MAXIMO UI pages</web-resourcename>
<description>pages accessible by authorised users</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 42 of 73
<description>Roles that have access to MAXIMO UI</description>

<role-name>maximouser</role-name>
</auth-constraint>
<user-data-constraint>
<description>data transmission guarantee</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
-->
maxrestweb\webmodule\web-inf\web.xml

<!-<env-entry>
</env-entry>
-->
mboweb\webmodule\web-inf\web.xml
Comment the following section:

<web-resource-name>MAXIMO Report Tool</web-resourcename>
<url-pattern>/reporttool/*</url-pattern>
<auth-constraint>
<description>Roles that have access to MAXIMO Report Tool</description>
</auth-constraint>
<description>data transmission gaurantee</description>
-->

<!-<env-entry>
</env-entry>
-->
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 43 of 73
meaweb\webmodule\web-inf\web.xml
Comment the following sections:

<web-resource-name>Enterprise Service Servlet</web-resource-name>
<description>Enterprise Service Servlet (HTTP POST) accessible by authorized
users</description>
<url-pattern>/es/*</url-pattern>
<url-pattern>/esqueue/*</url-pattern>
<auth-constraint>
<description>Roles that have access to Enterprise Service Servlet (HTTP
POST)</description>
</auth-constraint>
<security-constraint>
<web-resource-name>App Service Servlet</web-resource-name>
<description>App Service Servlet (HTTP POST) accessible by authorized
users</description>
<url-pattern>/ss/*</url-pattern>
<auth-constraint>
<description>Roles that have access to App Service Servlet (HTTP POST)</description>
</auth-constraint>
<web-resource-name>Workflow Service Servlet</web-resource-name>
<description>Workflow Service Servlet (HTTP POST) accessible by authorized
users</description>
<url-pattern>/wf/*</url-pattern>
<auth-constraint>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 44 of 73
<description>Roles that have access to Workflow Service Servlet (HTTP

POST)</description>
</auth-constraint>
<web-resource-name>Object Structure Service Servlet</web-resource-name>
<description>Object Structure Service Servlet (HTTP POST) accessible by authorized
users</description>
<url-pattern>/os/*</url-pattern>
<auth-constraint>
<description>Roles that have access to Object Structure Service Servlet (HTTP
POST)</description>
</auth-constraint>
<web-resource-name>Integration Web Services</web-resource-name>
<description>Integration Web Services accessible by authorized users</description>
<url-pattern>/services/*</url-pattern>
<auth-constraint>
<description>Roles that have access to Integration Web Services</description>
</auth-constraint>
<security-role>
<description>MAXIMO Application Users</description>
</security-role>
-->
<!-<env-entry>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 45 of 73

<env-entry-name>useAppServerSecurity</env-entry-name>
</env-entry>
-->
6) Rebuild maximo ear file by running \ibm\smp\maximo\deployment\buildmaximoear.cmd
7) Manually deploy the new maximo.ear file to WebSphere don't start MXServer after deployment
(Manual deployment of the maximo.ear file is described in the Maximo product installation guide)
8) Launch a database command window on the database server and create a connection to the
Maximo database
9) Run the following command:
DB2: db2 update maxpropvalue set propvalue=0 where propname='

mxe.useAppServerSecurity'
For other databases please refer to appropriate database documentation
10) Start MXServer
Now only the technical users maxadmin, mxintadm and maxreg are available in Maximo.
Tip: You can decide to either use form-based or basic login to Maximo.
For using form-based login comment the BASIC login-config section and uncomment the FORM loginconfig section in all web.xml files.
<!-<login-config>
<auth-method>BASIC</auth-method>
<realm-name>MAXIMO Web Application Realm</realm-name>
</login-config>
-->
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/webclient/login/login.jsp?appservauth=true</form-login-page>
<form-error-page>/webclient/login/loginerror.jsp</formerror-page>
</form-login-config>
</login-config>
In order to use basic login, uncomment the BASIC login-config section and comment the FORM loginconfig section in all web.xml files.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 46 of 73
3.4.2 Switching local Maximo TPAE authentication to LDAP

authentication
To switch from local Maximo authentication to LDAP you have to do the following:
Tip: It is not required to change maximo.properties. There is a risk to edit this file due to encrypted
passwords. Additionally users often edit files using Wordpad on Windows. This can lead to hidden control
characters and avoid that the file can be used by Maximo later.
1) Ensure, that the WebSphere Virtual Member Manager is configured properly
2) Ensure, that the technical users are created either in LDAP or local WAS repository
3) Stop MXServer
4) Backup Maximo database
5) On the Admin Server, backup all web.xml files under
\ibm\smp\maximo\applications\maximo\<subdirectory>\webmodule\web-inf
6) Backup maximo.ear in \ibm\smp\maximo\deployment\default
7) Edit all web.xml files under \ibm\smp\maximo\applications\maximo
Tip: Uncommenting in xml files means removing the comment strings  at the
end of the section. Commenting means setting these strings at the beginning and at the end.
maximouiweb\webmodule\web-inf\web.xml
Uncomment the following section and set env-entry-value to 1:

<env-entry>
</env-entry>
Uncomment the following section:

<web-resource-name>MAXIMO UI pages</web-resourcename>
<url-pattern>/*</url-pattern>
<auth-constraint>
</auth-constraint>
<description>data transmission guarantee</description>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 47 of 73
maxrestweb\webmodule\web-inf\web.xml

<env-entry>
</env-entry>
mboweb\webmodule\web-inf\web.xml
Uncomment the following section:

<web-resource-name>MAXIMO Report Tool</web-resourcename>
<url-pattern>/reporttool/*</url-pattern>
<auth-constraint>
<description>Roles that have access to MAXIMO Report Tool</description>
</auth-constraint>

<env-entry>
</env-entry>
meaweb\webmodule\web-inf\web.xml
Uncomment the following sections:

<description>Enterprise Service Servlet (HTTP POST) accessible by authorized
users</description>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 48 of 73
<auth-constraint>
<description>Roles that have access to Enterprise Service Servlet (HTTP
POST)</description>
</auth-constraint>
<description>App Service Servlet (HTTP POST) accessible by authorized
users</description>
<auth-constraint>
</auth-constraint>
<description>Workflow Service Servlet (HTTP POST) accessible by authorized
users</description>
<auth-constraint>
<description>Roles that have access to Workflow Service Servlet (HTTP
POST)</description>
</auth-constraint>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 49 of 73
<description>Object Structure Service Servlet (HTTP POST) accessible by authorized

users</description>
<auth-constraint>
<description>Roles that have access to Object Structure Service Servlet (HTTP
POST)</description>
</auth-constraint>
<auth-constraint>
</auth-constraint>
<security-role>
</security-role>

<env-entry>
</env-entry>
8) Rebuild maximo ear file by running \ibm\smp\maximo\deployment\buildmaximoear.cmd
9) Manually deploy the new maximo.ear file to WebSphere don't start MXServer after deployment
(Manual deployment of the maximo.ear file is described in the Maximo product installation guide)
10) Launch a database command window on the database server and create a connection to the
Maximo database
11) Run the following command:
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 50 of 73
DB2: db2 update maxpropvalue set propvalue=1 where propname='

mxe.useAppServerSecurity'
For other databases please refer to appropriate database documentation
12) Start MXServer
Tip: You can decide to either use form-based or basic login to Maximo.
For using form-based login comment the BASIC login-config section and uncomment the FORM loginconfig section in all web.xml files.
<!-<login-config>
</login-config>
-->
<login-config>
<form-login-config>
<form-error-page>/webclient/login/loginerror.jsp</formerror-page>
</login-config>
In order to use basic login, uncomment the BASIC login-config section and comment the FORM loginconfig section in all web.xml files.
3.5 Configuring TADDM LDAP Authentication

In any case of connection problems please have a look to the TADDM log files (e.g. trace.log) and
check the ports you have configured for the WebSphere server.
The WebSphere port should be the bootstrap port of the WebSphere server. For WebSphere Application
Server and the embedded version of WebSphere Application Server, the default port is 2809. For
WebSphere Application Server Network Deployment, which IBM Tivoli CCMDB uses, the default port is
9809.
3.5.1 Connecting TADDM to WAS VMM

See the documentation for more detailed information:
http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp?topic=/com.ibm.taddm.doc_7.1.2/Admin
Guide/t_cmdb_sec_configtaddmwebsphere.html
Login as TADDM user to the TADDM server

Copy current collation.properties to collation.properties.file-based_repository
Copy current collation.properties to collation.properties.vmm
Change collation.properties.vmm as follows:
#com.collation.security.usermanagementmodule=file
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 51 of 73
com.collation.security.usermanagementmodule=vmm
#com.collation.security.auth.websphereHost=
com.collation.security.auth.websphereHost=<washostname>
#com.collation.security.auth.webspherePort=
com.collation.security.auth.webspherePort=9809
#com.collation.security.auth.VMMAdminUsername=
com.collation.security.auth.VMMAdminUsername=wasadmin
#com.collation.security.auth.VMMAdminPassword=
com.collation.security.auth.VMMAdminPassword=<password>
Copy current ibmessclientauthncfg.properties to

ibmessclientauthncfg.properties.sav
Change ibmessclientauthncfg.properties as follows:
#authnServiceURL=http://localhost:9080/TokenService/services/Trust
authnServiceURL=http:// <washostname>:9080/TokenService/services/Trust
Copy current sas.client.props to sas.client.props.sav

Change sas.client.props as follows:
#com.ibm.CORBA.securityServerHost=
com.ibm.CORBA.securityServerHost=<washostname>
#com.ibm.CORBA.securityServerPort=
com.ibm.CORBA.securityServerPort=9809
#com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginUserid=wasadmin
#com.ibm.CORBA.loginPassword=
com.ibm.CORBA.loginPassword=<password>
Copy sas.client.props to <washostname>:/tmp

Execute .../PropFilePasswordEncoder.sh /tmp/sas.client.props
com.ibm.CORBA.loginPassword to encrypt the password
Copy sas.client.props back to the TADDM server
In TDS create the user administrator
In TDS create the group taddmadmins with users administrator, and <others>
In TDS create the group taddmoperators with users operator, and <others>
In TDS create the group taddmsupervisor with users supervisor, and <others>
In the DomainManager create the above groups with the above users
Stop the TADDM server
Copy collation.properties.vmm to collation.properties
Start the TADDM server
In order to restrict access to collections of TADDM objects by user or user group, in

collation.properties set this value to true:
#com.collation.security.enabledatalevelsecurity=false
com.collation.security.enabledatalevelsecurity=true
You do have to restart the TADDM server to activate this change.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 52 of 73
3.5.2 Connecting TADDM to MSAD directly

Although the TADDM documentation describes that you can use Microsoft Active Directory as the
authentication method for TADDM using WebSphere federated repositories as an intermediary it might be
possible to use it directly.
Below you will find how TADDM was configured for user authentication with the Microsoft Active Directory
directly.
Copy collation.properties file to collation.properties.file-based.
Copy collation.properties file to collation.properties.ldap.
Change the following in file collation.properties.ldap:
#com.collation.security.usermanagementmodule=file
com.collation.security.usermanagementmodule=ldap
#com.collation.security.auth.ldapAuthenticationEnabled=false
com.collation.security.auth.ldapAuthenticationEnabled=true
#com.collation.security.auth.ldapHostName=ldap.eng.collation.net
com.collation.security.auth.ldapHostName=<msadfqdn>
#com.collation.security.auth.ldapBaseDN=ou=People,dc=Collation,dc=net
com.collation.security.auth.ldapBaseDN=DC=<one>,DC=<two>,DC=<three>
com.collation.security.auth.ldapBindDN=CN=servicenetcool,OU=Users,OU=DomainManagement,DC=<one>,DC=<two>,DC=<three>
com.collation.security.auth.ldapBindPassword=<password>
#com.collation.security.auth.ldapUserObjectClass=person
com.collation.security.auth.ldapUserObjectClass=user
#com.collation.security.auth.ldapUIDNamingAttribute=cn
com.collation.security.auth.ldapUIDNamingAttribute=sAMAccountName
#com.collation.security.auth.ldapGroupObjectClass=groupofuniquenames
com.collation.security.auth.ldapGroupObjectClass=group
#com.collation.security.auth.ldapGroupNamingAttribute=cn
com.collation.security.auth.ldapGroupNamingAttribute=sAMAccountName
For activating LDAP authentication you need to copy collation.properties.ldap to

collation.properties and restart TADDM.
For activating file-based authentication you need to copy collation.properties.filebased to collation.properties and restart TADDM.
Within the file-based authentication configuration the following users were created:
Table 1: TADDM User
User
administrator
supervisor
Role
administrator
administrator
supervisor
Group
admin_users
admin_users
supervisor_users
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 53 of 73

operator
supervisor
operator
supervisor_users
operator_users
All users do have the default password collation.
When changing authentication to LDAP users can login to TADDM if they have an Active Directory
account using their AD password.
Successfully authenticated users will have TADDM authorisation according to their configured TADDM
roles. Users which do not have a TADDM role configured do have operator authorisation by default.
3.6 Configuration
3.6.1 Saving the old configuration (maxdb71 & wimconfig.xml)
Before modifying authentication and synchronization methods you should save your existing
configuration.
This includes the following tasks:
3.6.1.1 Backup of Admin Workstation files
Backup all web.xml files on Admin Server in

\ibm\smp\maximo\applications\maximo\<subdirectory>\webmodule\web-inf before
switching from local to LDAP authentication and vice versa
Backup maximo.properties on Admin Server in \ibm\smp\maximo\applications\maximo\properties
Backup maximo.ear on Admin Server in \ibm\smp\maximo\deployment\default
Backup database
3.6.1.2 Backup of WAS VMM configuration files

The entire WAS VMM configuration is stored in the wimconfig.xml files. It is strongly recommended to
backup these files before changing the configuration because there is a fair chance to log yourself out of
the system when your new settings are incorrect.
See next chapter for restore instructions.
Changing the configuration
The files are located in the following directories:
/<instdir>/WebSphere/AppServer/profiles/ctgDmgr01/config/cells/ctgCell01/wim/
config/wimconfig.xml
/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/config/cells/ctgCell01/wi
m/config/wimconfig.xml
Copy the wimconfig.xml files to e.g. wimconfig.xml.IBM.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 54 of 73
3.6.1.3 Restore of WAS VMM configuration files

Perform these activities in the listed order to restore to a previous backup of the wimconfig.xml files.
1. Shut down the entire WAS cell including applications servers, node agents and Deployment
Manager (DMGR)
2. Restore the wimconfig.xml file on the DMGR
3. Restore the wimconfig.xml file on all other node agents
4. Start the DMGR
5. Start the other node agents
6. Start the application servers
Result: The previous WAS VMM configuration in restored.

Hint: You might skip step 3 in the previous scenario. But then you have to wait for the WAS cluster
synchronization process to complete (after step 5) before you start the application servers.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 55 of 73
4. Troubleshooting LDAP Configuration

4.1 Changing Logging Parameters
There are loggers available that you can modify for getting more troubleshooting information about
LDAPSYNC and VMMSYNC cron tasks.
You have to add them using the Logging application inside TPAE:
Log on to TPAE
Go to System Configuration - Platform Configuration - Logging
Open the crontask root logger
Add the loggers LDAPSYNC / VMMSYNC using the New Row button
Modify the log level using the magnifier icon right to the log level (choose DEBUG for the
maximum of information)
Optionally you can configure a dedicated file for the output (instead of SystemOut.log). For this
you can configure the appender Rolling.
Save the configuration and apply the settings via the Select Action menu
Per default the loggers will send their output to the SystemOut.log of the MXServer
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 56 of 73
4.2 Exceeding Limitations in Active Directory

The are some pitfalls with limitations in Active Directory
4.2.1 Error in LDAPSYNC/VMMSYNC when replicating more than 1000

users
When you try to replicate more than 1000 users in your crontask you potentially will get an error. In most
cases you can solve this problem by increasing the parameter MaxPageSize in Active Directory. The
default for that parameter is 1000. Check the value of the parameter and if necessary ask your customer
to increase the parameter to an adequate value.
4.2.2 Error in LDAPSYNC/VMMSYNC when assigning more than 1000

users to a security group
When you try to assign more than 1000 users to a security group in your crontask you potentially will get
an error. In most cases you can solve this problem by increasing the parameter MaxValRange in Active
Directory. The default for that parameter is 1000. Check the value of the parameter and if necessary ask
your customer to increase the parameter to an adequate value.
Important note:
Unfortunately this works only up to 5000 assignments. Even if it is possible to set the parameter
MaxValRange higher than 5000, the current versions of MS AD have a limitation that
LDAPSYNC/VMMSYNC can only assign up to 5000 users to a security group.
This means, if you have more than 5000 users in a group, you need to split them in groups with up to
5000 users. This is certainly not a perfect solution, but at this time the only practicable workaround.
4.3 Disable Cache

When using WAS as application server you might notice delays after adding or changing user or group
settings in LDAP until the change is effective in Maximo TPAE.
Obviously, the VMMSYNC task must run to replicate the changes to the Maximo TPAE system. But if the
changes still not appear in Maximo TPAE it is likely to be related to the caching in WAS.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 57 of 73
4.4 Performance Issues

In test environments it is common to have a very frequent schedule of the LDAPSYNC / VMMSYNC task.
Due to the load it causes on the systems which might cause a performance decrease with user
sessions it is recommend to schedule these tasks outside the service hours of the Maximo TPAE
system.
Most customers schedule these tasks once during night time.
4.5 Users login Problems

4.5.1 Login not possible after switching authentication method
When you cant login to TPAE after switching from local authentication to LDAP or vice versa it is very
likely that the configuration of the web.xml files has not been properly done. Additionally it is possible that
login is possible, but interfaces between TPAE and external systems (e.g. Import / Export using
Integration Framework, Web Services, Deployers Workbench) do not work any longer.
In this case double check the configuration as described in chapter 3.4.
4.5.2 Login Screen stays open

If the login screen from WAS stays open then very likely the AD authentication has failed
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 58 of 73
This could have one of the following reasons:
1. The password is not correct

a. Check whether you use the correct password from AD or whether the password is
expired.
2. The user name is not correct
a. Check whether the user has been set up correctly in AD, also remember which attribute
you have chosen for the loginid.
b. Check whether the user is locked in AD.
c.
Check whether the user is available in WAS, check under User and Group / Manage
users whether you can find the user. If not, check your filter you have defined in WAS
VMM.
3. The user name exists more than once.

a. If you have connected multiple LDAPs, it is possible that the same userid exists in
several LDAPs. In this case you can modify the filters in WAS, to ensure that the userid
exists only once.
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 59 of 73
4.5.3 Login Screen closes but login to TPAE fails

If the login screen from WAS has been closed then very likely the AD authentication has worked. In this
case there is something wrong with the user in TPAE.
1. The user name is not recognized
Check in TPAE whether the user name or better the loginID exists.
If not, configure the logger for your LDAPSYNC / VMMSYNC cron tasks to see whether there is a
problem with that user.
If no user record is replicated to TPAE by LDAPSYNC / VMMSYNC, check whether the defined
principal has the appropriate rights in WAS. For this login to the WebSphere administration
console and check the following:
Go to: User and Groups - Administrative User Roles
Click on user name used as principal
User should have Administrator role only
2. The User ID is not currently active
Check in TPAE whether the user has the status ACTIVE
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 60 of 73
5. Appendix A
5.1 web.xml Files
5.1.1 MAXIMOUIWEB web.xml for SSO
<?xml version="1.0" encoding="UTF-8"?><web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="WebApp_1165873169281" version="2.4"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>MAXIMO Web Application</display-name>
<context-param>
<param-name>loginpage</param-name>
<param-value>../jsp/common/system/login.jsp</param-value>
</context-param>

<filter>
<filter-name>HttpMaxAgeFilter</filter-name>
<filter-class>psdi.webclient.system.filter.HttpMaxAgeFilter</filter-class>
<init-param>
<param-name>Cache-Control</param-name>
<param-value>max-age=2764800</param-value>
</init-param>
<init-param>
<param-name>Pragma</param-name>
<param-value>max-age=2764800</param-value>
</init-param>
</filter>



<filter>
<filter-name>HttpCrossSiteScriptingSecurity</filter-name>
<filter-class>psdi.webclient.system.filter.HttpCrossSiteScriptingSecurity</filter-class>
<init-param>
<param-name>script</param-name>
<param-value>script</param-value>
</init-param>
</filter>




<filter-mapping>
<url-pattern>/webclient/javascript/*</url-pattern>
</filter-mapping>
<filter-mapping>
<url-pattern>/webclient/images/*</url-pattern>
</filter-mapping>
<filter-mapping>
<url-pattern>/webclient/login/images/*</url-pattern>
</filter-mapping>
<filter-mapping>
<url-pattern>/webclient/css/*</url-pattern>
</filter-mapping>
Formatted: German (Germany)




<filter-mapping>
<filter-name>HttpCrossSiteScriptingSecurity</filter-name>
</filter-mapping>




<servlet>
<description>Scheduler Servlet</description>
<display-name>Scheduler Servlet</display-name>
<servlet-name>SchedulerServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.skd.servlet.SKDServlet</servlet-class>
</servlet><servlet>
<servlet-name>ipcsystem</servlet-name>
<servlet-class>psdi.webclient.servlet.IpcClientServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>wfmapservlet</servlet-name>
<servlet-class>psdi.webclient.servlet.WFMapServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>webclient</servlet-name>
<servlet-class>psdi.webclient.servlet.WebClientServlet</servlet-class>
<init-param>

<param-name>char_encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</servlet>
<servlet>
<description>This servlet is used for secure attachment link</description>
<servlet-name>secureprovider</servlet-name>
<servlet-class>psdi.webclient.servlet.RedirectServlet</servlet-class>
<init-param>

<param-name>char_encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</servlet>
<servlet>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 63 of 73
<description>This servlet interfaces with Maximo controls.</description>

<servlet-name>ControlInterfaceServlet</servlet-name>
<servlet-class>psdi.webclient.servlet.ControlInterfaceServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>SilentPrintServlet</servlet-name>
<servlet-class>psdi.webclient.beans.report.SilentPrintServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>chartservlet</servlet-name>
<servlet-class>psdi.webclient.servlet.ChartServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>sessionservlet</servlet-name>
<servlet-class>psdi.webclient.servlet.SessionServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>recordimageservlet</servlet-name>
<servlet-class>psdi.webclient.servlet.RecordImageServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>migration</servlet-name>
<servlet-class>psdi.webclient.servlet.MigrationServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>intdownload</servlet-name>
<servlet-class>psdi.webclient.servlet.IntegrationFileDownloadServlet</servlet-class>
</servlet>

<servlet>
<description>Starts and sets up Report platform</description>
<display-name>Report Web Application Startup Servlet</display-name>
<servlet-name>ReportWebAppStartupServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.report.birt.servlet.ReportWebAppStartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<description>Report Bridge Servlet</description>
<display-name>Report Bridge Servlet</display-name>
<servlet-name>ReportBridgeServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.report.birt.bridge.launcher.BridgeServlet</servlet-class>
<init-param>
<param-name>frameworkLauncherClass</param-name>
<paramvalue>com.ibm.tivoli.maximo.report.birt.servlet.MXWebAppOSGiFrameworkLauncher</param-value>
</init-param>
</servlet>
<servlet>
<description>Processes all report requests</description>
<display-name>Report Request Process Servlet</display-name>
<servlet-name>ReportRequestProcessServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.report.birt.servlet.ReportRequestProcessServlet</servlet-class>
<init-param>
<param-name>bridgeservletmap</param-name>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 64 of 73
<param-value>/bridge/</param-value>
</init-param>
</servlet>
<servlet>
<description>Allows the executed report contents to be downloaded</description>
<display-name>Report Download Process Servlet</display-name>
<servlet-name>ReportDownloadProcessServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.report.birt.servlet.ReportDownloadProcessServlet</servlet-class>
<init-param>
</init-param>
</servlet>
<servlet>
<description>Allows the executed report contents to be extracted</description>
<display-name>Report Extract Process Servlet</display-name>
<servlet-name>ReportExtractProcessServlet</servlet-name>
<servlet-class>com.ibm.tivoli.maximo.report.birt.servlet.ReportExtractProcessServlet</servlet-class>
<init-param>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>SchedulerServlet</servlet-name>
<url-pattern>/skd/*</url-pattern>
</servlet-mapping><servlet-mapping>
<servlet-name>ReportBridgeServlet</servlet-name>
<url-pattern>/bridge/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ReportRequestProcessServlet</servlet-name>
<url-pattern>/report/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>/download/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>/output/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ReportExtractProcessServlet</servlet-name>
<url-pattern>/extract/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>webclient</servlet-name>
</servlet-mapping>
<servlet-mapping>
<servlet-name>secureprovider</servlet-name>
<url-pattern>/servlet/secureprovider</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ControlInterfaceServlet</servlet-name>
<url-pattern>/ControlInterfaceServlet/*</url-pattern>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 65 of 73
</servlet-mapping>
<servlet-mapping>
<servlet-name>wfmapservlet</servlet-name>
<url-pattern>/wfmap/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ipcsystem</servlet-name>
<url-pattern>/servlet/ipcsystem</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>chartservlet</servlet-name>
<url-pattern>/servlet/chartservlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>sessionservlet</servlet-name>
<url-pattern>/servlet/sessionservlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>recordimageservlet</servlet-name>
<url-pattern>/recordimage/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>SilentPrintServlet</servlet-name>
<url-pattern>/servlet/SilentPrintServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>migration</servlet-name>
<url-pattern>/migration/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>intdownload</servlet-name>
<url-pattern>/intdownload/*</url-pattern>
</servlet-mapping>
<session-config>

<session-timeout>30</session-timeout>
</session-config>
<mime-mapping>
<extension>xls</extension>
<mime-type>application/vnd.ms-excel</mime-type>
</mime-mapping>

<welcome-file-list>

<welcome-file>/ui/maximo.jsp?welcome=true</welcome-file>
</welcome-file-list>
<web-resource-name>MAXIMO UI pages</web-resource-name>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 66 of 73
<web-resource-name>MAXIMO UI utility pages</web-resource-name>
<url-pattern>/webclient/utility/*</url-pattern>
<auth-constraint>
</auth-constraint>
<!-<login-config>
</login-config>
Uncomment this login-config if you want to use form authentication and make
sure the BASIC based login-config above is commented out. NOTE: You still need the
security-constraint about uncommented too.
-->
<login-config>
<form-login-config>
<form-error-page>/webclient/login/loginerror.jsp</form-error-page>
</login-config>
<security-role>
</security-role>
<env-entry>
</env-entry>
<env-entry>
<description>URL of the root of MAXIMO Application Help</description>
<env-entry-name>helpurl</env-entry-name>
<env-entry-value>/maximohelp</env-entry-value>
</env-entry>
<ejb-ref id="EjbRef_1077125230246">
<description>Remote Access Token Provider</description>
<ejb-ref-name>ejb/maximo/remote/accesstokenprovider</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>psdi.security.ejb.AccessTokenProviderHomeRemote</home>
<remote>psdi.security.ejb.AccessTokenProviderRemote</remote>
</ejb-ref>
<ejb-local-ref id="EJBLocalRef_1077125215444">
<description>Local Access Token Provider</description>
<ejb-ref-name>ejb/maximo/local/accesstokenprovider</ejb-ref-name>
<local-home>psdi.security.ejb.AccessTokenProviderHomeLocal</local-home>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 67 of 73
<local>psdi.security.ejb.AccessTokenProviderLocal</local>
</ejb-local-ref>
</web-app>
5.1.2 MEAWEB web.xml for SSO

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_1165934353343" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>MEA Web Application</display-name>

<context-param>
<param-name>IntegrationPostSize</param-name>
<param-value>5242880</param-value>
</context-param>

<servlet>
<display-name>Integration Servlet for inbound HTTP Transactions</display-name>
<servlet-name>IntegrationMaximoServlet</servlet-name>
<servlet-class>psdi.iface.servlet.MEAServlet</servlet-class>
<!-<load-on-startup>5</load-on-startup>
-->
</servlet>
<servlet>
<display-name>Integration Servlet for App Service Invocation</display-name>
<servlet-name>ActionServiceServlet</servlet-name>
<servlet-class>psdi.iface.servlet.ActionServiceServlet</servlet-class>
-->
</servlet>
<servlet>
<display-name>Workflow Servlet for inbound HTTP Transactions</display-name>
<servlet-name>WFMaximoServlet</servlet-name>
<servlet-class>psdi.iface.servlet.WorkFlowServiceServlet</servlet-class>
-->
</servlet>
<servlet>
<display-name>Integration Servlet for Object Structure Transactions</display-name>
<servlet-name>MOSServiceServlet</servlet-name>
<servlet-class>psdi.iface.servlet.MOSServiceServlet</servlet-class>
-->
</servlet>
<servlet>
<display-name>Verification Servlet for Web App</display-name>
<servlet-name>VerificationServlet</servlet-name>
<servlet-class>psdi.iface.servlet.VerificationServlet</servlet-class>
-->
</servlet>


<servlet>
<display-name>Apache-Axis Servlet</display-name>
<servlet-name>AxisServlet</servlet-name>
<servlet-class>
psdi.iface.servlet.MEAAxisServlet</servlet-class>

</servlet>


<servlet>
<display-name>Integration Web Services Resource Servlet</display-name>
<servlet-name>IntegrationResourceServlet</servlet-name>
<servlet-class>psdi.iface.servlet.ResourceServlet</servlet-class>

</servlet>


<servlet-mapping>
</servlet-mapping>
<servlet-mapping>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ActionServiceServlet</servlet-name>
</servlet-mapping>
<servlet-mapping>
<servlet-name>WFMaximoServlet</servlet-name>
</servlet-mapping>
<servlet-mapping>
<servlet-name>MOSServiceServlet</servlet-name>
</servlet-mapping>
<servlet-mapping>
<servlet-name>VerificationServlet</servlet-name>
<url-pattern>/verify/*</url-pattern>
</servlet-mapping>


<servlet-mapping>
<url-pattern>/wsdl/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>/schema/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<url-pattern>/servlet/AxisServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<mime-mapping>
<extension>wsdl</extension>
<mime-type>text/xml</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xsd</extension>
<mime-type>text/xml</mime-type>
</mime-mapping>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 69 of 73


<description>Enterprise Service Servlet (HTTP POST) accessible by authorized users</description>
<auth-constraint>
<description>Roles that have access to Enterprise Service Servlet (HTTP POST)</description>
</auth-constraint>
<description>App Service Servlet (HTTP POST) accessible by authorized users</description>
<auth-constraint>
</auth-constraint>
<description>Workflow Service Servlet (HTTP POST) accessible by authorized users</description>
<auth-constraint>
<description>Roles that have access to Workflow Service Servlet (HTTP POST)</description>
</auth-constraint>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 70 of 73
<description>Object Structure Service Servlet (HTTP POST) accessible by authorized users</description>
<auth-constraint>
<description>Roles that have access to Object Structure Service Servlet (HTTP POST)</description>
</auth-constraint>
<auth-constraint>
</auth-constraint>
<login-config>
<realm-name>Integration Web Application Realm</realm-name>
</login-config>
<security-role>
</security-role>
<env-entry>
</env-entry>
<ejb-ref id="EjbRef_entsrv">
<ejb-ref-name>ejb/maximo/remote/enterpriseservice</ejb-ref-name>
<home>psdi.iface.gateway.MEAGatewayHome</home>
<remote>psdi.iface.gateway.MEAGateway</remote>
</ejb-ref>
<ejb-local-ref id="EjbRef_entsrvlocal">
<ejb-ref-name>ejb/maximo/local/enterpriseservice</ejb-ref-name>
<local-home>psdi.iface.gateway.MEAGatewayHomeLocal</local-home>
<local>psdi.iface.gateway.MEAGatewayLocal</local>
</ejb-local-ref>
<ejb-ref id="EjbRef_actsrv">
<ejb-ref-name>ejb/maximo/remote/actionservice</ejb-ref-name>
<home>psdi.iface.action.MAXActionServiceHome</home>
<remote>psdi.iface.action.MAXActionServiceRemote</remote>
</ejb-ref>
<ejb-local-ref id="EjbRef_actsrvlocal">
<ejb-ref-name>ejb/maximo/local/actionservice</ejb-ref-name>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 71 of 73
<local-home>psdi.iface.action.MAXActionServiceHomeLocal</local-home>
<local>psdi.iface.action.MAXActionServiceLocal</local>
</ejb-local-ref>
<ejb-ref id="EjbRef_mossrv">
<ejb-ref-name>ejb/maximo/remote/mosservice</ejb-ref-name>
<home>psdi.iface.mos.MOSServiceHome</home>
<remote>psdi.iface.mos.MOSServiceRemote</remote>
</ejb-ref>
<ejb-local-ref id="EjbRef_mossrvlocal">
<ejb-ref-name>ejb/maximo/local/mosservice</ejb-ref-name>
<local-home>psdi.iface.mos.MOSServiceHomeLocal</local-home>
<local>psdi.iface.mos.MOSServiceLocal</local>
</ejb-local-ref>
<ejb-ref id="EjbRef_wfsrv">
<ejb-ref-name>ejb/maximo/remote/wfservice</ejb-ref-name>
<home>psdi.iface.workflow.WorkFlowServiceHome</home>
<remote>psdi.iface.workflow.WorkFlowServiceRemote</remote>
</ejb-ref>
<ejb-local-ref id="EjbRef_wfsrvlocal">
<ejb-ref-name>ejb/maximo/local/wfservice</ejb-ref-name>
<local-home>psdi.iface.workflow.WorkFlowServiceHomeLocal</local-home>
<local>psdi.iface.workflow.WorkFlowServiceLocal</local>
</ejb-local-ref>
</web-app>
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 72 of 73
6. Appendix B
6.1 List of abbreviations
Abbreviation
Stands for
AD
Active Directory
CCMDB
Change and Configuration Management Database
CN (LDAP)
Common Name
DMGR
Deployment Manager
DN (LDAP)
Distinguished Name
IBM
International Business Machines
ID
Identification
ISM
IBM Service Management
IT
Information Technology
ITDS
IBM Tivoli Directory Server
ITIC
IBM Tivoli Integration Composer
ITIL
IT Infrastructure Library
LDAP
Lightweight Directory Access Protocol
MBO
Maximo Base Object
MSAD
Microsoft Active Directory
PMR
Problem Management Record
PTA (ITDS)
Passthru Authentication
SPNEGO
Simple and Protected GSSAPI Negotialtion

Mechanism
SSL
Secure Sockets Layer
SSO
Single Sign On
TADDM
Tivoli Application Dependency Discovery Manager
TDS
Tivoli Directory Server
TPAE
Tivoli Process Automation Engine
VMM
Virtual Member Manager
WAS
WebSpshere Application Server
Document:
Owner:
Marc Purnell
Date: 31.10.2011
Version: V1.1
Status: Final
Page 73 of 73

Attachment 14846970 TFG Connecting Maximo TPAE To LDAP v1 1

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Attachment 14846970 TFG Connecting Maximo TPAE To LDAP v1 1

Diunggah oleh

Hak Cipta:

Format Tersedia

Connecting Maximo TPAE to LDAP

Authors: Marc Purnell

Connecting Maximo TPAE to LDAP v1.1.doc

Date of next revision

Revision Revision Summary of Changes

Connecting Maximo TPAE to LDAP v1.1.doc

Intention of this document ............................................................................................................... 5

Expected knowledge of the audience ............................................................................................. 5

About the authors ............................................................................................................................ 5

Planning the Maximo TPAE to LDAP connection ................................................... 7

Goals and Requirements ................................................................................................................ 7

Defining the technical details .......................................................................................................... 7

Conceptual aspects of connecting Maximo TPAE to LDAP .................................... 8

Supported Authentication Methods ................................................................................................. 8

Use of local Maximo TPAE authentication or LDAP ................................................................ 8

Using local Maximo TPAE authentication ................................................................................ 8

Using LDAP via VMM (ITDS/AD) ............................................................................................. 8

Single Sign On ......................................................................................................................... 9

Mapping LDAP content to Maximo TPAE Database .................................................................... 10

VMMSYNC vs. LDAPSYNC .................................................................................................. 10

The default mapping .............................................................................................................. 10

Which attribute to use as personid/userid/loginid .................................................................. 12

What happens when key values are changed in LDAP ........................................................ 14

Mapping the persons Manager (Supervisor) ........................................................................ 16

Mapping additional fields from LDAP to Person / User Table ............................................... 20

Mapping additional fields from LDAP to other tables............................................................. 21

Aspects of design and connection alternatives ............................................................................. 23

Passthrough Authentication ................................................................................................... 27

Connecting multiple LDAPs ................................................................................................... 29

Changing the Base Distinguished Name in TPAE and WAS ................................................ 37

Connecting LDAP Servers other than ITDS and MSAD ..................................................... 41

Secured Connection WAS to LDAP using ldaps ................................................................... 41

Switching Authentication Methods ................................................................................................ 42

Switching LDAP authentication to local Maximo TPAE authentication ................................. 42

Switching local Maximo TPAE authentication to LDAP authentication ................................. 47

Configuring TADDM LDAP Authentication ................................................................................... 51

Connecting TADDM to WAS VMM ........................................................................................ 51

Connecting TADDM to MSAD directly ................................................................................... 53

Saving the old configuration (maxdb71 & wimconfig.xml) ..................................................... 54

Connecting Maximo TPAE to LDAP v1.1.doc

Troubleshooting LDAP Configuration ................................................................... 56

Changing Logging Parameters ..................................................................................................... 56

Exceeding Limitations in Active Directory ..................................................................................... 57

Error in LDAPSYNC/VMMSYNC when replicating more than 1000 users ............................ 57

Disable Cache ............................................................................................................................... 57

Performance Issues ...................................................................................................................... 58

Users login Problems .................................................................................................................... 58

Login not possible after switching authentication method ..................................................... 58

Login Screen stays open ....................................................................................................... 58

Login Screen closes but login to TPAE fails .......................................................................... 60

web.xml Files ................................................................................................................................ 61

MAXIMOUIWEB web.xml for SSO ..................................................................................... 61

MEAWEB web.xml for SSO ................................................................................................ 68

List of abbreviations ...................................................................................................................... 73

Connecting Maximo TPAE to LDAP v1.1.doc

1.1 Intention of this document

1.2 Expected knowledge of the audience

1.3 About the authors

Connecting Maximo TPAE to LDAP v1.1.doc

Connecting Maximo TPAE to LDAP v1.1.doc

2. Planning the Maximo TPAE to LDAP connection

2.1 Goals and Requirements

Which LDAP Server product are you using is it supported?