Maximo and LDAP - Configuration from Start to Finish

Maximo and LDAP - Configuration from Start to Finish

Body

Security is more important than ever, and securing applications is a priority to every company. Many clients ask for documentation on configuring Maximo for LDAP authentication. You end up having to review many different articles to address a single topic, so I've decided to lay out a basic LDAP configuration using WebSphere 7 and Maximo 7.5.0.5. This will walk through connecting WebSphere to your domain right down to the synchronization process and hopefully give a more clear understanding of the configuration process. For the purpose of this blog were going to discuss this configuration with Microsoft Active Directory (MSAD or AD). However these steps can be applied with Tivoli Directory Server (TDS) as well.

So, where do you start?

Your first thoughts should be who needs access to Maximo and how are we going to filter just these users into the environment. For our purpose here, we're going to restrict all users by using the memberOf attribute, and make sure our Maximo users are members of a maximousers group that will be filtered on.

For a new Maximo implementation, we need three users to exist in the directory

maxadmin – default administrative user

maxreg – default user registration security user

mxintadm – default integration framework user

If your environment is already running and your admin users have different IDs, you can replace the above with your own users as long as they are in the database and the LOGINID from your database matches the Common Name (CN) from the directory server. Add these users to your maximousers group along with the rest of your base Maximo users.

Now to get started with your configuration. When configuring Maximo for LDAP there are three parts.

1. Configure WebSphere to connect and authenticate against your directory server
2. Enable Maximo to authenticate logins with the Federated Repository, the user database maintained in WAS)
3. Configure Maximo to synchronize users from the Federated Repository configured in WebSphere which contains the users that are brought over from Active Directory.

Step 1: Configuring WebSphere

1. From the WebSphere Console, Expand Security in the left hand frame and click on Global Security. From the Global Security page choose Federated Repository as your available realm definitions and click configure.

     2. Once you click Configure you will be brought to the federated repositories page, this will show the current repositories configured with WebSphere. By   default the repository called InternalFileRepository will exist. This repository contains the wasadmin user and its group. For the purpose of this tutorial we are going to leave this intact so that the wasadmin DOES NOT need to be added to the directory server. Click on Manage Repositories to configure your realm.

Note – if wasadmin exists on your directory server you will need to remove the file-based realm or remove wasadmin from the realm.

3. From the Manage Repositories screen, click Add

4. Once you click add you will be brought to the properties page to configure your directory server. From the drop down menu, choose your directory type; here we chose Active Directory. Enter the hostname and port of your directory server and your principal user to make the connection between WebSphere and your directory. I created a user named “principal” for this purpose.

For Active Directory, we changed the login property to CN. This would be left as UID for TDS. Once done, click Apply and Save to the master configuration.

5. Once you have saved to the master configuration you will be brought back to the Manage Repositories screen that will show your newly created repository. From here head back to the main configuration screen for the repository by clicking on “Federated Repositories.”

6. Now we need to configure our base entries. This will be the container that WebSphere looks in on your directory for users and groups. You can configure multiple entries on this screen, but we are just going to point our realm to the top of the directory. To start click Add Base Entry to Realm.

7. From the Add Base Entry screen enter the DN you want WebSphere to look in, as mentioned earlier we are going to pull in the entire domain and filter at the Maximo level. So I've entered dc=mxeam13, dc=torolab, dc=ibm, dc=com for the top level of the domain. Once done click apply and save to your master configuration.

8. Once you have your Base entries configured you need to enable application security for WebSphere. You do this on the main Global Security page. Check 'Enable Application Security' and click on 'Set as current' so your Current Realm Definition becomes Federated Repositories. Then apply and save to the master configuration.

9. Now that your configuration is complete for WebSphere ,you will need to do a full node synchronization and restart your Deployment Manager (dmgr) and Node (nodeagent) Windows services before continuing to the Maximo configuration.
10. Once you have restarted your services, log into the WebSphere Console. On the left hand side, expand Users and Groups and click on Manage Users. Search for a known directory user to confirm that your configuration is correct

Step 2: Enabling Maximo authenticate against your directory server

Once WebSphere is configured for LDAP authentication we need to configure Maximo. This is done by enabling LDAP security in 4 XML files as well as the maximo.properties file or the maxpropvalue table.

1. The first XML file we will modify is the maximouiweb web.xml. By default, you will find it in \ibm\smp\maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml.

We first want to search for the <security-constraint> tag and uncomment to the bottom of </login-config> as seen below:

2. In the same file search for useAppServerSecurity and change the value from false to 1 as seen below.

3. If you wish to keep the BASIC authentication method, you can now save the file. If you want Maximo to display the normal login screen, you will need to update the file to use FORM authentication, by commenting out the BASIC login config and uncommenting the FORM login-config. Text in green below is the commented-out section:

4. Repeat the above step without the the auth-method in the following 3 web.xml files – that is, uncomment the <security-constraint> sections and change useAppServerSecurity=1:

• IBM\SMP\maximo\applications\maximo\mboweb\webmodule\WEB-INF
• IBM\SMP\maximo\applications\maximo\meaweb\webmodule\WEB-INF
• IBM\SMP\maximo\applications\maximo\maxrestweb\webmodule\WEB-INF

5. Now that your web.xml files are configured for LDAP we need to update the maximo.properties or the maxpropvalue table for application security.

If you want to set this in the database you can update the value with the following statement in a SQL tool connected to your database as the schema owner (default maximo):

update maxpropvalue set propvalue='1' where propname='mxe.useAppServerSecurity'

If you want to set this in your maximo.properties you will need to add the line mxe.useAppServerSecurity=1 to the properties file and save it If choosing this method you will need to re-encrypt before building your ear.

See http://www.ibm.com/support/docview.wss?uid=swg21314942 for complete information on modifying maximo.properties.

6. Once your file changes are made you can rebuild and redeploy your ear files
7. Before starting your application, you need to map the security role to the group of users you wish to authenticate. Our users are part of the maximousers group, so we have already mapped that role. If you don't have a specific group, you may choose “All Authenticated in Applications realm” to give all authenticated directory users the ability to connect to Maximo.

To map your role from the WebSphere console, click on Enterprise Applications then on your Maximo ear. Under Detail properties click security role to user/group mapping. Then click Map Groups to map the groups your users are contained in.

3. Configure Maximo to synchronize users from your repository.

Our final step is to setup the VMMSYNC crontask to bring users in to Maximo from the directory server.

1. Open System Configuration - > Platform Configuration and click on Crontask Setup. From here filter for VMMSYNC.
2. Enter the principal user that can access the repository to bring users into Maximo as well as the password for this user in the credential field.

3. Once you credentials are setup, you can set up your group mapping to sync the groups you want into Maximo.

4. Between the <basedn></basedn> tags specify the path on your directory to where your groups reside. In our case it will be in the SWG OU, see the example below.

         <basedn>ou=SWG, dc=mxeam13, dc=torolab, dc=ibm, dc=com</basedn>

5. Next, we need to do the same for our users, however at the same time we will be just bringing in users that are members of the maximousers group.

        <basedn>ou=SWG, dc=mxeam13, dc=torolab, dc=ibm, dc=com</basedn>

        <filter>PersonAccount' and memberof='cn=maximousers, ou=SWG, ou=maximo groups, dc=torolab, dc=ibm, dc=com</filter>

6. Once these changes are done, activate your crontask and reload it's configuration. If you are having problems with the memberOf filter, it is likely because it doesn't exist as a property under the PersonAccount entity in the repository. You can add it using the instructions below

Adding the memberof to the PersonAccount entity to VMM

1) From IBM\WebSphere\AppServer\bin run wsadmin.bat

2) Once the wsadmin command line displays run the following command

$AdminTask addIdMgrPropertyToEntityTypes {-name memberof -dataType string -entityTypeNames PersonAccount}

-name : This value is the name of the attribute on the directory server, for this example it will be  memberof

-dataType  : This is the database for the field, in our case string

3) After running the command you will see that your attribute was successfully added

4) Synchronize your node and restart the services.

You synchronization will now be able to use memberof as a filter.