Converting accountAttribute date to ISO8601

[mcheek (Mark Cheek)]

I am working with the Azure AD connector and want to leverage the lastSignInDateTime and lastNonInteractiveSignInDateTime on identities, but I’m having an issue in the identity profile mappings coming up with the correct transform. It looks to be formatted correctly without a transform, but it sounds like I have to do a transform to explicitly tell IdentityNow it’s ISO8601

Here’s what the account data looks like

            "lastNonInteractiveSignInDateTime": "2023-07-31T20:22:07Z",
            "userType": "Guest",
            "signInNames": null,
            "lastSignInDateTime": "2022-10-17T21:57:33Z",

Here’s what my transform looks like

{
    "name": "CHK AADSignInDate",
    "type": "dateFormat",
    "attributes": {
        "input": {
          "attributes": {
            "sourceName": "Azure Active Directory - Guests",
            "attributeName": "lastSignInDateTime"
          },
          "type": "accountAttribute"
        },
        "inputFormat": "yyyy-MM-dd'T'HH:mm'Z'",
        "outputFormat": "ISO8601"
    }
}

What am I doing wrong?

[tyler_mairose]

Hey @mcheek,

I noticed that your input has seconds as well which are missing from your inputFormat. Try using this inputFormat and see if that helps!

"inputFormat": "yyyy-MM-dd'T'HH:mm:ss'Z'"

[mcheek (Mark Cheek)]

Can I use this for multiple account attributes using something like a firstValid?

[mcheek (Mark Cheek)]

Oh, it actually looks like I don’t need to reference a specific account attribute, I can just do it like

{
    "name": "CHK AADSignInDate",
    "type": "dateFormat",
    "attributes": {
        "inputFormat": "yyyy-MM-dd'T'HH:mm:ss'Z'",
        "outputFormat": "ISO8601"
    }
}

[tyler_mairose]

I wasn’t sure what you meant until you posted this last message… Yes! With the code you posted it will use implicit input which uses whatever is mapped in the UI as the input to the transform.

[mcheek (Mark Cheek)]

@tyler_mairose my search logic is correct here, right? It doesn’t seem to be searching correctly on these newly converted date fields

[tyler_mairose]

Hmmm, It looks like you have everything correct to me. I tried this on a source I setup in our tenant and it was filtering correctly. The only difference between the query I used and yours is I used .exact on the identityProfile.name to match my identity Profile.

To search on attributes your name must be the technical name of the attribute (the one in parentheses) in the identityProfile mappings tab, in my case below startDate. With that being said it looks like you have that correct as well…

attributes.startDate:<2023-01-01 AND identityProfile.name.exact:"CSVSourceNew"

[mcheek (Mark Cheek)]

It appears I have the technical name correct

And even when I leave off the identity profile, I still get invalid identities

[nsorlien (Nathan Sorlien)]

Try recreating the identity attribute with name Last Sign In Datetype (lastSignInDatetype).

There’s a small note in the search documentation about the “dateType” feature here: Searchable Fields - SailPoint Identity Services

This thread has some more info as well:

dateType IdentityProfile attribute issue

Hi everybody, Our requirement : We are getting 2 different dates from a source (Last logon from AD) We want to compare it to take the most recent one and set it in a dedicated third custom Identity Attribute called “Last Login” This part is working fine, but we have encountered a “side effect” which is we can’t do any date-type queries on this field in the “Search” module (e.g. attributes.lastLogin:<2022-01-01 returns all the Last Login dates) In the documentation it is said that we need …

For anyone else that might come across this page in the future, this wiki page on Compass details the format your date/datetime identity attributes must be in to be searchable: How to Format Identity Attribute Date Values to Be Searchable in Search - Compass

[mcheek (Mark Cheek)]

@nsorlien that seems to work!