LDAP Search - Ignoring records older than a year

[ras2247]

I have a client that wishes for us not to import their student LDAP accounts that haven't been modified in over a year. They have an extensionattribute that contains a date in 'yyyy-mm-dd' format. That field contains the last modified date.

Now, from my research on LDAP Search filters I only see method of doing this on specific dates. For example, if I wanted to omit all accounts that were last modified on 2004/08/09 I would use a filter similar to this: (pwdLastSet<=127365120000000000).

So, is there a method to create a search filter to filter out all accounts that haven't been modified in over a year?

Thanks..

[Jay_Ford]

Couldn't you convert extensionattribute into a Glide Datetime in the transform then use a transform script to filter out ones where the last modified is over one year.

[bburdick]

We are looking to do something similar, but we want to filter on any person records that were modified in the last 24 hours. This will make our query a lot faster. Any suggestions?

[Kumar35]

I can see there is a field "whenchanged" in AD that has the last update timestamp, it has value like '20130702013539' but could be another format in your setup.
As you can see initial characters represent date of last update so it should be possible to do a date difference.

[bburdick]

Shout out to my buddy Toon Chandee on this solution. This works well and we are now running our script every 25 minutes.

First, let me specifiy that we do not have the ability to enable the listener. Ideally, this is what we would want to do.

Second when we do a full import of our all users the most we pull in at a time is around 15k records. We would run a scheduled LDAP job every four hours. 75% of the users we would import in would be ignored because there was no modification to their accounts. The job would take 15 minutes on average to run.

We wanted to run it more often, but we wanted to limit it to only the records that had been modified in the past 24 hours. With the script below we were able to run the job under 15 seconds and pulling back just the records that had been modified in that time period. 24 hours is probably excessive, but the load is so minimal, we figured we would stick with that. We tested with 2 hours and the job took less than 5 seconds.

What you want to do is modify the your Scheduled Data Import Job by enabling the Execute post-import script. See the screen shot attached below for how it would look in your SN instance.

I broke out the code information below with additional comments.

gs.sleep(30000);  // pause for 30 seconds before executing the following codes to ensure LDAP import process has already started

// This is just for logging purposes
dt = gs.nowDateTime();
// Define how long you want to go back
nt = gs.hoursAgo(24);

setLastRun(nt);

function setLastRun(nt){
// Looking for any user that is not employee type of other and was modified after a tbd date
var bf = '(&(objectclass=person)(!(employeetype=Other))(erlastmodifiedtime>=';

// Clear out all the DateTime info this important so the correct date format is sent back to the filter
var desired = nt.replace(/[^\w\s+]/gi, '');
var newdt = desired.replace(" ", "");

var ou = new GlideRecord('ldap_ou_config');
// Find the specific OU RECORD that you have defined your filter on
if(ou.get('20024fde94d8e40064f778bf4ca78ac7')){
ou.filter = bf + newdt.toString() + '*))';
ou.update();
}
// Logging to see the new filter we have updated and when the import was completed
gs.log("LDAP Filter Updated with " + bf + newdt.toString() + '*))';
gs.log("LDAP Import Ended on " + dt);
}

Just to note, your last modified date field name may be different than ours so you will need to work with your LDAP admin to find out what the name of that field is. Ours happens to be erlastmodified.

This fixed our issues with time outs we were getting and enabling the data in our system to be more up to date.