Fetching Non-Default Attributes from LDAP via VMMSync

Body

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:

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

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:

  <attributes>      <attribute>sAMAccountName</attribute>      <attribute>givenName</attribute>      <attribute>sn</attribute>      <attribute>displayName</attribute>      <attribute>streetAddress</attribute>      <attribute>homePhone</attribute>      <attribute>memberOf</attribute>      <attribute>telephoneNumber</attribute>      <attribute>mail</attribute>      <attribute>st</attribute>      <attribute>postalCode</attribute>      <attribute>c</attribute>      <attribute>l</attribute>  </attributes>  

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)

  cd /IBM/WebSphere/AppServer/bin  ./wsadmin.sh  

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

  AdminTask.addIdMgrPropertyToEntityTypes ('[-name physicalDeliveryOfficeName -dataType string -entityTypeNames PersonAccount]')  

Below is Windows equivalent of this command:

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

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

  AdminConfig.save()  

Again in Windows:

  $AdminConfig save  

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:

.../IBM/WebSphere/AppServer/profiles/AppServerName/config/cells/CellName/wim/model

Below you can see the auto-generated “wimxmlextension.xml” which should include a propertySchema element after adding “physicalDeliveryOfficeName” property.

  <?xml version="1.0" encoding="UTF-8"?>  <!--    Begin Copyright      Licensed Materials - Property of IBM      virtual member manager      (C) Copyright IBM Corp. 2005_2010 All Rights Reserved.      US Government Users Restricted Rights - Use, duplication or     disclosure restricted by GSA ADP Schedule Contract with IBM Corp.      End Copyright  -->    <sdo:datagraph xmlns:sdo="commonj.sdo"      xmlns:wim="http://www.ibm.com/websphere/wim">    <wim:schema>      <wim:propertySchema nsPrefix="wim" nsURI="http://www.ibm.com/websphere/wim" dataType="string"          multiValued="false" propertyName="physicalDeliveryOfficeName">        <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>      </wim:propertySchema>    </wim:schema>  </sdo:datagraph>  

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:

.../IBM/WebSphere/AppServer/profiles/AppServerName/config/cells/CellName/wim/config

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:

  <config:ldapEntityTypes name="PersonAccount"  

The property added to the entity looks like the following in the xml:

          <config:attributes name="physicalDeliveryOfficeName" propertyName="physicalDeliveryOfficeName">            <config:entityTypes>PersonAccount</config:entityTypes>          </config:attributes>  

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.

  <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>physicalDeliveryOfficeName</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">displayName</column>  	<column name="CITY" type="ALN">l</column>  	<column name="COUNTY" type="ALN">st</column>  	<column name="DEPARTMENT" type="ALN">physicalDeliveryOfficeName</column>  	<column name="LANGUAGE" type="ALN">{TR}</column>  	<column name="LOCALE" type="ALN">{tr_TR}</column>  	<column name="STATUSDATE" type="ALN">{:sysdate}</column>  	<column name="LOCATIONSITE" type="ALN">{UEDAS}</column>  </table>  

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.

References

ibm.com - Configuring user authentication

ibm.com - Adding more attributes to VMM

ibm.com - VMMSync: Adding the memberOf property to the entity type PersonAccount in Linux

ibm.com - Using the WSADMIN tool to add custom attributes to VMM