How to fix this issue.
To understand this, Could you please explain How did you configured the AD source for AccountExpires attribute? and Are you using any transform on AccountExpires attribute?
yes it is using one transform
Can you post the Sanitized Transform here? or you can if that transform is updating the value.
in the past, we found this was because of a date type mismatch epoch)
created:[now-31d TO now] AND attributes.sourceName:" " by using this seach we found few users updating many times
If you have a transform that is associated with an identity attribute, it will update the value with every identity refresh.
Do you have another value to calculate the expiry on such as contractor end date? This way the value would only change if the user is extended.
Alicia
Yes we have that attribute link to this transform
If you are using the created date, the transform and thereby attribute sync is going to update at least once per day.
Do you have another attribute like End Date?
Alicia
The issue is largely due to time zone offsets and date format conversions. See my transform below it calculates 4 values:
“expirationDateCompare” - the end date from the auth source +30 hours then rounded down to midnight on the day after termination (assumes that they will be working through their end date) and converted to EPOCH_TIME_WIN32
“retrievedLDAP” - accountExpires from AD converted to EPOCH_TIME_WIN32 - but also handling accounts that never expire
“ADMatch” - the value retrieved from AD to store in the identity if no change is required
“expirationDateLDAP” - similar to “expirationDateCompare” but leaves hours and minutes intact in the final calculation
I suspect that “expirationDateCompare” and “expirationDateLDAP” could be collapsed into one variable. It made sense as two in previous iterations and has stayed as two.
Once those values have been converted it does some comparisons and writes the appropriate value to the identity:
if the expiration date is not set in the auth source - the write “never”
if expirationDateCompare matches retrievedLDAP (no change required) then write the ADMatch value
else (change required), write the “expirationDateLDAP” value
{
"id": "0e73faad-1e10-4e0c-9569-c72162192a33",
"name": "Calculate AD Expiration",
"type": "static",
"attributes": {
"expirationDateCompare": {
"attributes": {
"input": {
"attributes": {
"input": {
"attributes": {
"input": {
"attributes": {
"values": [
{
"attributes": {
"attributeName": "expiration_date",
"sourceName": "Non-Employees"
},
"type": "accountAttribute"
},
"2070-12-12"
],
"ignoreErrors": "true"
},
"type": "firstValid"
},
"inputFormat": "yyyy-MM-dd",
"outputFormat": "ISO8601"
},
"type": "dateFormat"
},
"expression": "+30h"
},
"type": "dateMath"
},
"inputFormat": "yyyy-MM-dd",
"outputFormat": "EPOCH_TIME_WIN32"
},
"type": "dateFormat"
},
"retrievedLDAP": {
"attributes": {
"input": {
"attributes": {
"attributeName": "accountExpires",
"sourceName": "Active Directory"
},
"type": "accountAttribute"
},
"table": {
"0": "0",
"never": "never",
"default": {
"attributes": {
"input": {
"attributes": {
"attributeName": "accountExpires",
"sourceName": "Active Directory"
},
"type": "accountAttribute"
},
"inputFormat": "MM/dd/yyyy",
"outputFormat": "EPOCH_TIME_WIN32"
},
"type": "dateFormat"
}
}
},
"type": "lookup"
},
"ADMatch": {
"attributes": {
"ignoreErrors": "true",
"values": [
{
"attributes": {
"attributeName": "accountExpires",
"sourceName": "Active Directory"
},
"type": "accountAttribute"
},
"0"
]
},
"type": "firstValid"
},
"expirationDateLDAP": {
"attributes": {
"input": {
"attributes": {
"input": {
"attributes": {
"input": {
"attributes": {
"values": [
{
"attributes": {
"attributeName": "expiration_date",
"sourceName": "Non-Employees"
},
"type": "accountAttribute"
},
"2070-12-12"
],
"ignoreErrors": "true"
},
"type": "firstValid"
},
"inputFormat": "yyyy-MM-dd",
"outputFormat": "ISO8601"
},
"type": "dateFormat"
},
"expression": "+30h"
},
"type": "dateMath"
},
"inputFormat": "yyyy-MM-dd'T'HH:mm",
"outputFormat": "EPOCH_TIME_WIN32"
},
"type": "dateFormat"
},
"value": "#if ($expirationDateLDAP == \"148301460000000000\")never#{elseif}($expirationDateCompare == $retrievedLDAP)$ADMatch#{else}$expirationDateLDAP#{end}"
},
"internal": false
}```Yes, we have normal Enddate attribute as well.
after the daily aggregation we can be able to see few sources repeatedly modified accounts pass 2 times or more than 1times
Are you getting values for the expression: “expirationDateCompare”?
I’m asking because it looks like your outputs and inputs are not aligning:
And its a similar thing for “expirationDateLDAP”:
Also, 30 hours added to 2070-12-12 = “2070-12-13 06:00:00”, where as “148301460000000000” = “2070-12-13 05:00:00”.
Is the output ‘never’ getting written back for the users without an end date?
source is repeatedly updating some users 1-2 times daily. The events appear to say the previous value is null, but SN is showing a value (or vice versa).
we have two attributes showing their
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.