- IBM Maximo LDAPSYNC Overview of Concepts and IBM Document References (Part 1 of 4)
- Converting LDAPSYNC from Unencrypted to Encrypted, LDAP to LDAPS (Part 2 of 4)
- Maintaining LDAPSYNC with SQL (Part 3 of 4)
- IBM Smart Cloud Control Desk: IBM Service Desk Licensing Resolved with Second LDAPSYNC (Part 4 of 4)
IBM SmartCloud Control Desk: IBM Self Service Center licensing resolved with second LDAPSYNC in windows environment.
IBM states that folks using the Self Service components of the SmartCloud Control Desk do not need entitlements. Read that to mean they don’t need an IBM Maximo named user license to use. But to the implementer it leaves you with a problem of how to manage those users separate from your normal Maximo ASM, Asset Management users. If you are using the LDAPSYNC CRON task to provide authorization to Maximo ASM you can use a second LDAPSYNC CRON task to separate out the Self Service users and you will then be able to prove your license compliance if need be.
See this IBM article regarding licensing: http://www-01.ibm.com/support/docview.wss?uid=swg21965782
This article assumes you have already implemented application level security via LDAP(s) or SPNEGO in WebSphere to active directory for authentication and an LDAPSYNC to active directory for authorization. SSO, single sign on can also be implemented without affecting this process.
There are a number of areas that have to be updated in order to make this all work. Not only do you have to implement a second LDAPSYNC CRON task. But you will also need to update your authentication process. At the application level in WebSphere and you will have to coordinate with the Maximo application level security person to establish the necessary roles and permissions to make it all work. So I will address the work starting with authentication in WebSphere then transition to authorization via an LDAPSYNC and finish with roles in Maximo.
The concept that must be kept in mind when setting up the WebSphere application authentication is that you will need a security group in active directory that has everyone in it that needs to be able to access the Self Service components. This group may already exist or it may need to be created. This is important so you will want to have a discussion with management and the active directory administrator about what group to use for authentication. Once that is established the actual implementation can be easy or hard, depending on how you previously set up your authentication in WebSphere. WebSphere has a nice feature at the application level that we are going to take advantage of. That is you can point to multiple active directory groups in the application level security. Below is an example for a simple implementation.
WebSphere console > Applications > Application Types > WebSphere enterprise applications > Blue Maximo Link > be patient, wait for screen change
Under Detail Properties > Blue Security role to user/group mapping
In the Mapped groups section just have two groups, one that’s your Maximo ASM folks and a second that is your Self Service folks. For Example:
Special Subjects: None ( Note this then restricts authentication to just the mapped groups)
Mapped Users: blank
If you have restrictive group or user filters in your LDAP(s) configuration you may need to expand your group or user filters to include the Self Service users.
WebSphere console > Security > Global Security > Standalone LDAP Registry
Configure Button > Advanced Lightweight Directory Access Protocol (LDAP) user registry settings link at bottom.
You will need to be very familiar with LDAP conventions in order to get these filters correct to include both groups.
If you are using SPNEGO then again configure the Application level security like mentioned previously. If you have any special SPNEGO filters you will want to verify they do not restrict the new group of users you wish to include in the authentication process for the application.
WebSphere console > Security > Global Security
Expand Web and SIP security on right
Select SPNEGO web authentication blue link
Select and review SPNEGO filters.
At this point you can do the work necessary to implement a second LDAPSYNC CRON task to get the new group of users into Maximo. You will first need to create the new LDAPSYNC CRON in Maximo, then update the parameters, and lastly load the CRON task. An example of the steps are below:
- Signon Maximo
- Goto System Configuration > Platform Configuration > Cron Task Setup
- Find “LDAP”, select LDAPSYNC
- Select the new row button
- Give it an instance name of your choosing: SELFSERVICESYNC (for example)
- Schedule it.
- Run as MAXADMIN
- ACTIVE: Checked
- Keep History: Checked
- Number of History Records: 100
At this point you have created the CRON task so now the parameters need to updated, most will be exactly the same as the original with the following exceptions.
- The sAMAccountName in the GroupMapping will need to be updated to your Self Service active directory group.
- The Description in the MAXGROUP table of GroupMapping should be updated, to words of your choice.
- The memberof value in the UserMapping will need to be updated to your Self Service active directory group.
If you are using a SQL text file to maintain your LDAPSYNC CRON task then be sure to update the where clauses to specify the correct name for the CRON InstanceName column or you will over right both CRONs.
Once the parameter updates are complete you are ready to reload the CRON task in order to get it running. Once it runs you should find all the new folks have been added to the MAXUSER table, PERSON table, and the new group created in MAXGROUP and entries made in GROUPUSER to include the new folks in the aforementioned group.
At this point you are ready to start updating the roles and permissions in Maximo to reflect their restricted access. It’s important to remember that these folks in this new group should only have access to those components of Maximo for which no entitlement is required in Maximo. I actually went through an independent audit of IBM Maximo licensing and this is how we got through the audit in spite of the large number of users in the MAXUSER table of Maximo. Though it did require educating the auditors on the setup as they had not previously encountered it. Once explained then there was no issue with license counts.
The Maximo application security names for roles and applications may vary tremendously based on what your Maximo security administrator and application developer create. Below is an example, illustrated from the database point of view.
MAXAPPS.APP = “SRMSSCTR”
APPLICATIONAUTH.APP = ‘SRMSSCTR” and GROUPNAME = “MAXIMO-Self-Service”
Below is a simplified example to give you an idea of the work in Maximo:
- Signon Maximo
- Goto Security > Security Groups
- Find your new A/D Self Service group and select
- Select the applications tab
- Filter on “self”
- Find the self service application of interest, for example: “Self Service Center” and select.
- Grant the permissions applicable to your user community.
- Don’t forget to save.
At this point you will want to find a user that is not an ASM user but is a Self Service user and have them test their access to the system.
Obviously this does not cover all the possible scenarios you may encounter in your environment. The intent of the document was to let you know what is possible to be accomplished using Maximo without purchasing additional ASM licenses.
Note this same process is applicable for any Maximo product with an embedded component that does not require entitlement to use. For example it is my understanding that the base Maximo Asset Management software comes with Self Service components that do not need entitlement. But with application level security enabled this process give you another way to manage the new class of users, and restrict them to the appropriate components.