How to get pdm_ldap_sync to synchronize the ldap-enabled/disabled status with contact's active/inactive status in servicedesk?

Document ID : KB000025238
Last Modified Date : 14/02/2018
Show Technical Document Details


For a given LDAP integration, it may be desirable to have the ldap_sync functionality synchronize between the hosting LDAP attributes for enabled/disabled contacts with Service Desk’s own active/inactive status field for contact records.  This document describes a procedure to allow for this synchronization to take place



  1. Open web screen painter -> Go to 'Tools' -> Open Schema Designer,

  2. For the 'cnt' object add a new 'INTEGER' column 'userAccountControl'. This gets added as zuserAccountControl.

  3. Click on 'Save and publish'.

  4. Stop the CA Service Desk Manager Server.

  5. In the command prompt of the server, run 'pdm_publish' and it publishes the schema and DB changes with an entry in ddict.sch.

  6. Next create a LDAP.mod file with content as :

    OBJECT ldap LDAP {
    zuserAccountControl "!userAccountControl:1.2.840.113556.1.4.803:" INTEGER;

    and save it into NX_ROOT\site\mods\majic

  7. Restart the services. The LDAP.mod file is now ready for use. 

    When you run the pdm_ldap_sync command in the future, use the command flags as detailed below to ensure that the enable state of the LDAP user will be synchronized to the active/inactive state of the SDM contact:

    pdm_ldap_sync -l "id = ? AND zuserAccountControl=2"

Additional Information:

A previous version of this document referenced instructions to create a “cnt.mod” file that contains a reference to the attribute “userAccountControl”.  Such a change may prevent the xFlow functionality from allowing user authentication.  The above instructions are designed to allow the intended LDAP integration to run while allowing xFlow authentication to proceed.

When we receive an LDAP attributes we try to match that with contact attribute.  Since we are explicitly asking the pdm_ldap_sync to look for userAccountControl value, the ldap returns this attribute but the contact object does not have the matching attribute and hence it complains.

Since we are just using this attribute for filtering, we do not need to persist the userAccountControl and hence the errors are completely harmless. 

In pdm_ldap_sync, we filter by users with LDAP_dn is not null. 
E.G. say user 'user1' is imported from ldap as active user, the user's LDAP_dn is recorded in the Service Desk.

Later when the user is disabled in ldap and a pdm_ldap_sync is performed, because of the !userAccountControl:1.2.840.113556.1.4.803:=2 filter, the user 'user1' is not returned from ldap, and since the user is not found in ldap and the user's LDAP_dn is not null in service desk, service desk treats the 'user1' as deleted from ldap and sets the status to inactive.