One of the basic (but often forgotten) guidelines that should be followed whenever you consider importing any data into your ServiceNow instance is to only import the information that is actually necessary within the tool. Just because you CAN import the data into ServiceNow 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 ServiceNow, 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 ServiceNow LDAP Configuration wiki page.
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.
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
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.