Technical Blog Post
Fetching Non-Default Attributes from LDAP via VMMSync
I had a requirement to fetch a non-default attribute from Microsoft Active Directory (LDAP). Herein, I would like to list the necessary steps for this practice. I assume that all Maximo and Websphere configurations are done, so your users should have been uploaded to Maximo via a VMMSync Cron Task instance and you should be able to sign in Maximo using an AD user credentials. Below, you may see the default AD attributes derived from UserMapping property of VMMSync Cron Task Instance:
Note: If you were using LDAPSync Cron Task instead of VMMSync, then you would have some modifications in your properties. “uid” would be replaced with “sAMAccountName” and etc. In this case, you might also need to extend the default adapter class, which is specified as “psdi.security.ldap.DefaultLdapSyncAdapter” in SynchAdapter property value. Attributes part of UserMapping xml for LDAPSync is as follows:
So, my aim is to fetch an attribute from AD which is different than the ones listed above such as “physicalDeliveryOfficeName“. If this attribute had already been defined as a property in Websphere, then our task would reduce to a simpler one as only updating the UserMapping xml.
Now, let me list all the necessary steps for enabling a new LDAP attribute on Linux:
1) Open terminal (or command window) and log in as root (or an administrator user)
2) Run WebSphere administrative tool with wsadmin.sh (or wsadmin.bat in Windows)
3) Enter your WebSphere administrative username (e.g. wasadmin) and password respectively when prompted
4) Add “physicalDeliveryOfficeName” property to the entity type “PersonAccount” with the following command
Below is Windows equivalent of this command:
5) Verify this message: CWWIM0523I The new property 'physicalDeliveryOfficeName' was successfully added to the entity type '[PersonAccount]'.
6) Save the configuration with the following command
Again in Windows:
When the steps above are completed, we need to sync the Nodes and stop Server, Node Agent, Deployment Manager and start them in reverse order.
7) In order to validate our additional entity property, you may check the wim model definition files which are located under this path:
Below you can see the auto-generated “wimxmlextension.xml” which should include a propertySchema element after adding “physicalDeliveryOfficeName” property.
NOTE: You may also review the default elements by examining wimdomain.xsd file under the same folder path.
Since the new property is ready for use, we can continue with the Websphere configuration steps.
8) Go to Security -> Global Security -> Federated Repositories -> Configure...
9) Select the relevant repository in the realm by clicking on the “Base Entry” or “Repository Identifier” links (if there are multiple, you will repeat the same actions for each of the repositories)
10) For information purposes, you can check the properties and their values specific to your LDAP server. You can also review entity types defined under “Additional Properties” header by clicking the related link.
11) If you need, you may update the searching properties for the “PersonAccount” entity type which we modified via Websphere administrative tool.
12) Now, we need to turn back to the repository we are working on and click on the link related to property names under “Additional Properties” header.
13) On the redirected page, you will see a list of properties which are available for this repository. We are interested in the properties of “Supported” type. So click on "Add -> Supported" button to define our new property for the repository.
14) Populate the properties as suggested below and click “Apply” button. Then, Save the changes to Master Configuration.
NOTE: When the steps above are completed, we need to sync the Nodes. Again you might want to stop and start all WAS components to give a fresh start with the new configurations.
15) In order to validate these configurations, you may also check configuration files under Websphere wim folder which is represented with the following path:
After the configurations, “winconfig.xml” should include a “config:attributes” element generated for “physicalDeliveryOfficeName” property. To find it you can search the document for your repository id and find PersonAccount entity starting with the following tag:
The property added to the entity looks like the following in the xml:
16) Last step is modifying the UserMapping property of VMMSync Cron Task Instance to include physicalDeliveryOfficeName attribute. We add the lines below in bold to fetch the attribute and then set it to Department field on Person record. physicalDeliveryOfficeName LDAP attribute, PERSON object and DEPARTMENT field are chosen for demonstration purposes, indeed they are optional for different use cases.
After the updates, VMMSync Cron Task Instance needs to be activated and reloaded. When it runs at next scheduled time, it is expected to populate Department field of Person records with the physicalDeliveryOfficeName data from your LDAP server.