Technical Blog Post
Maximo and LDAP - Switch it up, filter in WebSphere.
So you've configured or are configuring Maximo to authenticate with a directory server. You've set the base entries to determine which Organizational Unit's you will be bringing into your repository and you realize; you don't want all the users in each of the OU's to have the option to authenticate (in all authenticated mapping), you don't want to configure base entries for many different OU's bringing in users you don't need to exist in the repository, you may just want users from a specific group be brought in to WebSphere that exist throughout the directory in a number of different locations to have the ability to authenticate to Maximo.
Rather then bringing all your users into WebSphere and then filtering users from your repository with VMMSYNC, why not switch it up? Lets only bring the users we want to see into the WebSphere repository so we don't have to setup a filter on the crontask and worry about having to filter on attributes that don't exist in the Virtual Member Manager.
This blog assumes you have configured your repository and realm in WebSphere to authenticate against your domain. If you haven't done this head on over to my previous blog: Maximo and LDAP: Configuration from start to finish
So lets begin.
For the purpose of this tutorial, I've created one user called 'blog' and added that user and my wasadmin user to the 'support' security group on my directory server. I've also configured my repository to the top level of my domain: maximovm.com as you can see below it is pulling in all users currently from the top level.
The users we want brought into our repository going forward are wasadmin (Primary Administrative User) from the directory so we can access WebSphere and run the VMMSYNC crontask and the blog user. These will be our only users that require access to Maximo, but we want to leave the repository configured to the top level as new users could be added to the support group at any time, to many different locations on the directory. To achieve this we will want to setup our filter on the PersonAccount entity.
1. From the WebSphere console expand 'Security' and click on 'Global Security'
2. Click on 'Configure' beside your Federated Repository
3. Under related Items Click on 'Manage Repositories' then click on your 'Repository Identifier'.
4. Under Additional Properties click on 'LDAP entity types' and then 'PersonAccount'
You will now see the following screen, this is where you setup your filter for the users that need to come into WebSphere.
In this scenario we want only users that are members of the support security group under the entire maximovm.com directory tree to be seen in WebSphere and authenticate to Maximo. So we would set our search base to the top level of dc=maximovm, dc=com and because this is filtering from the directory itself we can use all of the directory properties to filter. To bring in all the users of the support group we will use the memberof filter: memberof=cn=support, ou=swg, dc=maximovm, dc=com.
Once the above change is made and applied you will need to do a full synchronize of the node and restart your DMGR and Node Services. Once the services are back up you can expand 'Users and Groups' from the WebSphere console, click on 'Manage users' and search on *. You will now only see the users that match the filter criteria specified in WebSphere.
When filtering in WebSphere you can just set your crontask to the top level. There is no need to setup a filter as the users will already be filtered in the repository, however you can still do this if you require further filtering from the users currently in the repository. You can also set the security group mapping to all authenticated, knowing that all the users that will be attempting authentication will be users that require it.
For more information on synchronization with the crontask and using custom attributes on the filter, please check out the blog link at the beginning of this post, which describes how it's done.