attachment 14846970 tfg connecting maximo tpae to ldap v1 1

Document: Connecting Maximo TPAE to LDAP v1.1.doc Date: 31.10.2011 Version: V1.1 Owner: Marc Purnell Status: Final Connecting Maximo TPAE to LDAP - Project Experiences of 73

Connecting Maximo TPAE to LDAP

Project Experiences

Authors: Marc Purnell

Frank Nees

Bernhard Binzen

Hubertus Dapper

Customer: Cross Customer Experience


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 (date)

Revision Number

Revision Date

Summary of Changes Changes marked

(#) (-) (Describe change) (N)

1.0 30.09.11 Final initial version N

1.1 31.10.11 Final version after review N

Approvals

This document requires following approvals. Signed approval forms are filed in the Quality section of the PCB.

Name Title

(name) (title)

Distribution

This document has been distributed to

Name Title

(name) (title)


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 person’s 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


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


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.


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.


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?


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.


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.


See: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/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.

Tivoli

DatabaseLDAPSYNC

LDAP

LDAPTPAEWAS

VMMSYNC

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 don’t 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:


o The Header lines

o 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.

o 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

o By default these tables are: MAXUSER, PERSON, PHONE and EMAIL

o 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">


<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="PERSONID" type="UPPER">uid</keycolumn> <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="PERSONID" type="UPPER">uid</keycolumn> <keycolumn name="TYPE" type="ALN">{Home}</keycolumn> <keycolumn name="ISPRIMARY" type="YORN">{0}</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="PERSONID" type="UPPER">uid</keycolumn> <keycolumn name="TYPE" type="ALN">{Work}</keycolumn> <keycolumn name="ISPRIMARY" type="YORN">{1}</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


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 loginid personid

CN (1) (1)

sAMAccountName (1)

mail (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:


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 doesn’t exist anymore.

b. You can set the flag indirect yourself

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” don’t exist in LDAP anymore

c. Don’t use a flag, just perform the action for all users (just exclude some technical users like maxadmin)


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


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 1

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 person’s 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.


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 don’t 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">

<config:entityTypes>PersonAccount</config:entityTypes>

</config:attributes>

Now you replaced the standard defined fields by the fields we want to use.


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 don’t 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


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


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

c Country

l 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:entityTypes>PersonAccount</config:entityTypes> </config:attributes> <config:attributes name="samAccountName" propertyName="uid"> <config:entityTypes>PersonAccount</config:entityTypes> </config:attributes> <config:attributes name="streetAddress" propertyName="street"> <config:entityTypes>PersonAccount</config:entityTypes> </config:attributes> <config:attributes name="physicalDeliveryOfficeName" propertyName="postalAddress"> <config:entityTypes>PersonAccount</config:entityTypes> </config:attributes>


…

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"> <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">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://www-304.ibm.com/support/docview.wss?mynp=OCSSLKT6&mync=R&uid=swg21499970&myns=swgtiv

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

https://www-304.ibm.com/support/docview.wss?uid=swg21385052

https://www-304.ibm.com/support/docview.wss?mynp=OCSSLKT6&mync=R&uid=swg21499970&myns=swgtiv




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="PERSONID" type="UPPER">uid</keycolumn> <keycolumn name="LABORCODE" type="UPPER">uid</keycolumn> </table> <table allowdelete="true" name="LABOR"> <keycolumn name="PERSONID" type="UPPER">uid</keycolumn> <keycolumn name="LABORCODE" type="UPPER">uid</keycolumn> </table> <table allowdelete="true" name="LABORCRAFTRATE">


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 pre-filtered users differently in the TPAE database.


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:


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.


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!


Group Mapping:

<?xml version="1.0" encoding="UTF-8" ?> <!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:

<?xml version="1.0" encoding="UTF-8" ?> <!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.


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.


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:


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


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


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.


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:


Make sure that “Available realm definition” is configured to “Federated repositories”. Press Configure to

configure the individual LDAP repositories.


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:


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 doesn’t work anymore. The reason is that the instance now tries to get data also from the new added repository, but this doesn’t work because the principal isn’t 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.


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.


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


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. Base entry for the default parent Enter ou=groups,ou=ccmdb,ou=prod,ou=sysman,ou=unit,o=customer,c=de Relative Distinguished Name properties 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. Base entry for the default parent Enter ou=prod,ou=sysman,ou=unit,o=customer,c=de Relative Distinguished Name properties 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:


/<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopServer.sh MXServer -username wasadmin -password <pwd> /<instdir>/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopNode.sh -username wasadmin -password <pwd> /<instdir>/WebSphere/AppServer/profiles/ctgDmgr01/bin/stopManager.sh -username wasadmin -password <pwd> /<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


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

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:

 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>

<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

Comment the following section and set env-entry-value to 0:



mboweb\webmodule\web-inf\web.xml

Comment the following section:

 Comment the following section and set env-entry-value to 0:

meaweb\webmodule\web-inf\web.xml

Comment the following sections:

<!-- <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Enterprise Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to App Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint>

<description>Roles that have access to Workflow Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Object Structure Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Integration Web Services</web-resource-name> <description>Integration Web Services accessible by authorized users</description> <url-pattern>/services/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Integration Web Services</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-role> <description>MAXIMO Application Users</description> <role-name>maximouser</role-name> </security-role> --> 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-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>0</env-entry-value> </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 login-config section in all web.xml files.

 <login-config> <auth-method>FORM</auth-method> <realm-name>MAXIMO Web Application Realm</realm-name> <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 login-config section in all web.xml files.

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> <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>1</env-entry-value> </env-entry> Uncomment 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> <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

Uncomment the following section and set env-entry-value to 1:

<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>1</env-entry-value> </env-entry>

mboweb\webmodule\web-inf\web.xml

Uncomment the following section:

<security-constraint> <web-resource-collection> <web-resource-name>MAXIMO Report Tool</web-resourcename> <description>pages accessible by authorised users</description> <url-pattern>/reporttool/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to MAXIMO Report Tool</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> Uncomment the following section and set env-entry-value to 1: <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>1</env-entry-value> </env-entry>

meaweb\webmodule\web-inf\web.xml

Uncomment the following sections:

<security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method>


</web-resource-collection> <auth-constraint> <description>Roles that have access to Enterprise Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to App Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Workflow Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Object Structure Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Integration Web Services</web-resource-name> <description>Integration Web Services accessible by authorized users</description> <url-pattern>/services/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Integration Web Services</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-role> <description>MAXIMO Application Users</description> <role-name>maximouser</role-name> </security-role> Uncomment the following section and set env-entry-value to 1: <env-entry> <description>Indicates whether to use Application Server security or not</description> <env-entry-name>useAppServerSecurity</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>1</env-entry-value> </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:

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 login-config section in all web.xml files.

 <login-config> <auth-method>FORM</auth-method> <realm-name>MAXIMO Web Application Realm</realm-name> <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 login-config 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/AdminGuide/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

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp?topic=/com.ibm.taddm.doc_7.1.2/AdminGuide/t_cmdb_sec_configtaddmwebsphere.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp?topic=/com.ibm.taddm.doc_7.1.2/AdminGuide/t_cmdb_sec_configtaddmwebsphere.html


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.


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=service-netcool,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.file-

based to collation.properties and restart TADDM.

Within the file-based authentication configuration the following users were created:

Table 1: TADDM User

User Role Group

administrator administrator admin_users

… administrator admin_users

supervisor supervisor supervisor_users


… supervisor supervisor_users

operator operator 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.


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.


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


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.


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 can’t 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


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.


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

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>  <!-- Uncomment these lines to enable byte count filter. Remove init-param if desire is to see output in dos window. <filter> <filter-name>HttpThroughputFilter</filter-name> <filter-class>psdi.webclient.system.filter.HttpThroughputFilter</filter-class> <init-param>

Formatted: English (U.S.)

<param-name>output-filename</param-name> <param-value>c:\merlin\HttpThroughputFilter.txt</param-value> </init-param> </filter> -->   <filter-mapping> <filter-name>HttpMaxAgeFilter</filter-name> <url-pattern>/webclient/javascript/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>HttpMaxAgeFilter</filter-name> <url-pattern>/webclient/images/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>HttpMaxAgeFilter</filter-name> <url-pattern>/webclient/login/images/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>HttpMaxAgeFilter</filter-name> <url-pattern>/webclient/css/*</url-pattern> </filter-mapping>    <filter-mapping> <filter-name>HttpCrossSiteScriptingSecurity</filter-name> <url-pattern>/ui/*</url-pattern> </filter-mapping>  <!-- Uncomment these lines to enable byte counting of http requests <filter-mapping> <filter-name>HttpThroughputFilter</filter-name> <url-pattern>/ui/*</url-pattern>

Formatted: German (Germany)

</filter-mapping> <filter-mapping> <filter-name>HttpThroughputFilter</filter-name> <url-pattern>/webclient/javascript/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>HttpThroughputFilter</filter-name> <url-pattern>/webclient/images/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>HttpThroughputFilter</filter-name> <url-pattern>/webclient/controls/*/*.css</url-pattern> </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>

<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> <param-value>com.ibm.tivoli.maximo.report.birt.servlet.MXWebAppOSGiFrameworkLauncher</param-value> </init-param> <load-on-startup>2</load-on-startup> </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>

<param-value>/bridge/</param-value> </init-param> <load-on-startup>3</load-on-startup> </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> <param-name>bridgeservletmap</param-name> <param-value>/bridge/</param-value> </init-param> <load-on-startup>4</load-on-startup> </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> <param-name>bridgeservletmap</param-name> <param-value>/bridge/</param-value> </init-param> <load-on-startup>4</load-on-startup> </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> <servlet-name>ReportDownloadProcessServlet</servlet-name> <url-pattern>/download/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>ReportDownloadProcessServlet</servlet-name> <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> <url-pattern>/ui/*</url-pattern> </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>

</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> <security-constraint> <web-resource-collection> <web-resource-name>MAXIMO UI pages</web-resource-name> <description>pages accessible by authorised users</description>

<url-pattern>/ui/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <web-resource-collection> <web-resource-name>MAXIMO UI utility pages</web-resource-name> <description>pages accessible by authorised users</description> <url-pattern>/webclient/utility/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to MAXIMO UI</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>  <login-config> <auth-method>FORM</auth-method> <realm-name>MAXIMO Web Application Realm</realm-name> <form-login-config> <form-login-page>/webclient/login/login.jsp?appservauth=true</form-login-page> <form-error-page>/webclient/login/loginerror.jsp</form-error-page> </form-login-config> </login-config> <security-role> <description>MAXIMO Application Users</description> <role-name>maximouser</role-name> </security-role> <env-entry> <description>Indicates whether to use Application Server security or not</description> <env-entry-name>useAppServerSecurity</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>1</env-entry-value> </env-entry> <env-entry> <description>URL of the root of MAXIMO Application Help</description> <env-entry-name>helpurl</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <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> <ejb-ref-type>Session</ejb-ref-type> <local-home>psdi.security.ejb.AccessTokenProviderHomeLocal</local-home>

<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>  </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> <!--init-param>

<param-name>authurl</param-name> <param-value>http://localhost:80/meaweb</param-value> </init-param--> <load-on-startup>5</load-on-startup> </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-name>IntegrationMaximoServlet</servlet-name> <url-pattern>/esqueue/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>IntegrationMaximoServlet</servlet-name> <url-pattern>/es/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>ActionServiceServlet</servlet-name> <url-pattern>/ss/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>WFMaximoServlet</servlet-name> <url-pattern>/wf/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>MOSServiceServlet</servlet-name> <url-pattern>/os/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>VerificationServlet</servlet-name> <url-pattern>/verify/*</url-pattern> </servlet-mapping>   <servlet-mapping> <servlet-name>IntegrationResourceServlet</servlet-name> <url-pattern>/wsdl/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>IntegrationResourceServlet</servlet-name> <url-pattern>/schema/*</url-pattern> </servlet-mapping>  <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/servlet/AxisServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/services/*</url-pattern> </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>

<security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Enterprise Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to App Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Workflow Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>


<security-constraint> <web-resource-collection> <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> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Object Structure Service Servlet (HTTP POST)</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Integration Web Services</web-resource-name> <description>Integration Web Services accessible by authorized users</description> <url-pattern>/services/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <description>Roles that have access to Integration Web Services</description> <role-name>maximouser</role-name> </auth-constraint> <user-data-constraint> <description>data transmission gaurantee</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Integration Web Application Realm</realm-name> </login-config> <security-role> <description>MAXIMO Application Users</description> <role-name>maximouser</role-name> </security-role> <env-entry> <description>Indicates whether to use Application Server security or not</description> <env-entry-name>useAppServerSecurity</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>1</env-entry-value> </env-entry> <ejb-ref id="EjbRef_entsrv"> <ejb-ref-name>ejb/maximo/remote/enterpriseservice</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <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>


<ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <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> <ejb-ref-type>Session</ejb-ref-type> <local-home>psdi.iface.workflow.WorkFlowServiceHomeLocal</local-home> <local>psdi.iface.workflow.WorkFlowServiceLocal</local> </ejb-local-ref> </web-app>


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

attachment 14846970 tfg connecting maximo tpae to ldap v1 1

Documents

final connecting maximo

maximo tpae database

title document

ldap connection

online document

final version

mapping ldap content

marc purnell status