Convert GlideDate to LDAP/AD Date

Michael M1
Giga Expert

I have an Orchestration workflow that wants to see the AD user account expiration in a particular format, but not sure what microsoft is looking for...

I am doing this in my workflow:

var gdt = new GlideDateTime(expiry);
gdt.addDaysUTC(extend);
workflow.scratchpad.extend_date = gdt.getDate();

If I log/print the workflow.scratchpad.extend_date I can see "2019-02-01"

When I send this to AD to update the user accountExpires field it changes to:  1601-01-01

Is there a way to convert to microsoft time? 

1 ACCEPTED SOLUTION

Michael M1
Giga Expert

So after banging my head on the wall and then finding some code to do the reverse of what I want for Python (convert MS to UNIX) - I got this to work in my workflow...

 

Objective: Add days to AD accountExpires attribute to extend valid account dates.

 

//Calculate expires date
var gdt = new GlideDateTime(expiry);
gdt.addDaysUTC(extend);

//Here I convert GD to AD date

var gdt2 = new GlideDateTime(gdt);
var gdt_num = gdt.getNumericValue() * 10000;
var gdt_ms = gdt_num + 116444736000000000;
gdt2.setNumericValue(gdt_ms);
//

workflow.scratchpad.extend_date = gdt2.getNumericValue(); //pass to Orchestration

It can be cleaned up and made more efficient but this way shows it off better. 

Next, I will probably try and create a script include and put it in dtUtils...If I get a chance 🙂 

 

View solution in original post

8 REPLIES 8

Michael M1
Giga Expert

so workflow.scratchpad.extend_date.getDisplayValue() does not work.

When I pass the value to Orchestration it blows up:

The specified directory service attribute or value does not exist.
HRESULT: [-2147016694]

It even crashes when I send the variable directly (workflow.scratchpad.extend) which contains a date/time string.

The only thing that works is workflow.scratchpad.extend_date = gdt.getDate();

What exactly is Active Directory looking for format-wise in user expiration field?

Michael M1
Giga Expert

When I look on the LDAP server attribute accountExpires for the user I changed, it reads '2019'.

If I look at another user that I didn't touch the format is as follows:

accountExpires131986635531110000

ryan_pope
Mega Guru

You might need to share more of your script for us to understand where some of your values are coming from (like gdt, for example).

However, it turns out AD uses a different time tracking method than unix (which is what SN can grab. See below to for a quick example on how you can grab the epoch time as a value in JS. Then you'll just need to follow this article to convert that value to one that LDAP can interpolate: https://stackoverflow.com/questions/48224097/how-to-to-convert-from-ldap-time-format-to-js-date-form...

find_real_file.png

var gdt = new GlideDate();
var date = gdt.getDate();
gs.print(date);
gs.print(date.getNumericValue());

 

Hopefully this helps!

Michael M1
Giga Expert

So after banging my head on the wall and then finding some code to do the reverse of what I want for Python (convert MS to UNIX) - I got this to work in my workflow...

 

Objective: Add days to AD accountExpires attribute to extend valid account dates.

 

//Calculate expires date
var gdt = new GlideDateTime(expiry);
gdt.addDaysUTC(extend);

//Here I convert GD to AD date

var gdt2 = new GlideDateTime(gdt);
var gdt_num = gdt.getNumericValue() * 10000;
var gdt_ms = gdt_num + 116444736000000000;
gdt2.setNumericValue(gdt_ms);
//

workflow.scratchpad.extend_date = gdt2.getNumericValue(); //pass to Orchestration

It can be cleaned up and made more efficient but this way shows it off better. 

Next, I will probably try and create a script include and put it in dtUtils...If I get a chance 🙂