THURSDAY, JANUARY 19, 2017

The Best LDAP Integration Tip You’ve Never Heard Of

O

ne of the basic (but often forgotten) guidelines that should be followed whenever you consider importing any data into your Service-now instance is to only import the information that is actually necessary within the tool. Just because you CAN import the data into Service-now doesn’t necessarily mean that the data SHOULD be imported or that it has any value. Even if somebody thinks the data has value within Service-now, you should also consider if that value outweighs the work and trouble of importing and maintaining that data going forward. This is particularly true for CMDB and old ticket data but is also true of user data imported from LDAP. One thing that a lot of people don’t realize is that you can end up with ‘garbage’ data from LDAP but that it is also very simple to configure your system to prevent this from happening.

LDAP configuration is typically one of those “Set it and forget it” type of tasks. You connect to the LDAP server, specify the OUs and transform maps, and run the scheduled import. Even though your LDAP integration may be working just fine, chances are that you are actually bringing way more user information into your system than is necessary or useful. This is because by default, an LDAP map brings in ALL available attributes from the LDAP server for each object. Usually, the majority of these attributes aren’t necessary but they end up getting imported and stored for each import in the temporary import set table before potentially being transformed into your user table. The real tragedy with this is that because you still have to bring all of the ‘garbage’ data into the system before the transform, it can actually slow the import time considerably if you have a very large set of data coming over (probably anything above the ‘hundreds’ range of records).

It’s actually very simple to prevent this unnecessary data from coming into your system at all and cluttering up your import table and slowing down your LDAP import. This can be done by adding a comma-separated list of attributes to be brought over from your LDAP server to the LDAP Server record in your instance. To completely minimize the amount of data brought over, this list should contain only those fields used in your transform map. This method has been documented on the Service-now LDAP Configuration wiki page.

department,employeeid,givenname,l,mail,manager,sn,source,telephoneNumber,title,uid,dn,cn,o,street,postalCode,mobile,samaccountname

Cleaning up existing clutter

If you’ve already had an LDAP integration running without this setup, you’ve not only got a bunch of garbage data, but a bunch of garbage columns in your import set table as well. Once you modify the attributes for your LDAP server you should go back and clean up the table and data by using the ‘Cleanup’ module under the ‘System Import Sets’ application. You’ll want to have BOTH checkboxes un-checked so that you remove both the data and the table structure. This table structure will be re-created the next time you run your import! Since this is an LDAP import, you’ll want to make sure you go back to the newly-created import table and adjust the column lengths of the ‘DN, Source, and Manager’ fields on your import table to 255 so that the manager mapping and login information doesn’t get truncated during the import.

Tags: 

2 Comments

Ayush Saxena 27-06-2014, 10:51

Hi Mark,

I have a doubt, I understand we can populate data using Mid server but how will User authentication take place. Unfortunately cannot find much about this on wiki.

Thanks and Regards,
Ayush Saxena

Reply
Mark Stanger 27-06-2014, 11:12

Good question! The MID server LDAP setup is for record import only, it does not impact the authentication piece at all. You’ll still have to authenticate via the standard LDAP setup or, more commonly in the MID server scenario, via SAML or some other SSO mechanism.

Reply

Leave a Reply


Latest Comments

  • David: It appears that I can hit sys_properties table with REST. This works, but I haven’t yet discovered the...
  • Mark Stanger: Hey David, It doesn’t surprise me that scoped apps have made this more difficult. I’m not...
  • David: Mark, do you have an example of how to do this in a scoped app? It seems there are many hoops to jump through...
  • Mark Stanger: The only possibility is to create a system property to override this in your application. Check out the...