Share all details about your problem, including any error messages you may have received.
We are facing an issue with the accountexpires attribute in Active Directory (AD) during the provisioning process in SailPoint IdentityIQ. Specifically, the problem occurs when we send the 18-digit LDAP timestamp for the accountexpires attribute in our provisioning plan. While the correct value is present up to the Before Provisioning Rule, it gets altered during the provisioning process. Here’s a breakdown of the issue:
Before Provisioning Rule:
The 18-digit LDAP timestamp (e.g., 132589728000000000) is correctly passed in the provisioning plan.
After Provisioning Rule:
The value of accountexpires is unexpectedly converted to a human-readable format (e.g., MM/dd/yyyy),
Access Request Analysis:
When analyzing the access request in the Access Request page, the 18 digit accountexpires attribute value appears to be filtered out. This makes it difficult to determine whether any action was taken on the accountexpires attribute.
Furthermore, the human-readable value (e.g., MM/dd/yyyy) is provisioned to the target system
@nkishor1995 Usually value gets filtered out if the previous value is also same. Are you converting AD time format to human readable format in customization rule ? If yes, that’s the one which is causing your value to get converted to readable format, as part of post provision activity i.e., get account operation will be triggered at backend after the provision is done.
For Active Directory (AD) attribute accountexpires should be defined as a string in account schema. Kindly check create provisioning policy if value is being altered there.
You can define below code to convert string date value to long value:-
import java.text.SimpleDateFormat;
import java.util.Date;
String inputDateStr = "07/31/2025"; // from request or calculated
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy");
Date date = sdf.parse(inputDateStr);
long ldapTimestamp = (date.getTime() + 11644473600000L) * 10000;
plan.add("accountExpires", String.valueOf(ldapTimestamp));
If the accountexpires value is correctly visible in the Before Provisioning Rule but gets altered or filtered out in the After Provisioning Rule, it’s likely due to a data type mismatch or format transformation during the provisioning flow. One should verify that the accountexpires attribute in the application schema is defined as a Long, not a String, to prevent implicit conversion or filtering. This issue generally surfaces only in specific provisioning scenarios where an account expiration date is explicitly set, as most accounts are typically configured to never expire.
Also, To convert a human-readable date (e.g., MM/dd/yyyy) to an LDAP timestamp and pass it as a String in case of termination/disablement let’s say
import java.util.Date;
Date now = new Date();
long ldapTimeNow = (now.getTime() + 11644473600000L) * 10000L;
return String.valueOf(ldapTimeNow);
Or for new account where you need to set the value as never expires
long neverExpires = 9223372036854775807L;
return String.valueOf(neverExpires);