Hello,
We have already used the official APIs with filters to retrieve a list of accounts from a specific system that have not logged in for more than 60 days. However, this approach currently works only with a PAT and manual execution.
If we want to automate this on the customer’s platform without storing data in a database, is this feasible?
Alternatively, anyone have successful use cases we could reference?
you can capture the field in SailPoint in identity attribute and can use a transform to calculate if the date is greater than 60 days using date compare transform .
Based on this attribute then you can create a search report
I would try the below considering you already have a source configured in ISC and you want to automate the above from ISC.
Get the lastLogon or whatever the account attribute you used to know about login date from your source.
Create a flag identity attribute and populate the value via transform by comparing your account attribute date with today’s date to set the flag value if the last logon greater than 60 days.
Using Search and subscription, you can send the report to the stakeholders.
You cannot get account attribute values in Search, so you need to map each required account attributes to individual identity attribute to get them in your report. Below is a sample transform, you can build your logic on top of it.
{
"name": "LastLogon Offset",
"type": "static",
"attributes": {
"day60": {
"attributes": {
"negativeCondition": "FALSE",
"positiveCondition": "TRUE",
"firstDate": {
"attributes": {
"input": {
"attributes": {
"values": [
{
"attributes": {
"attributeName": "LastLogonDate",
"sourceName": "SourceName"
},
"type": "accountAttribute"
},
"12/31/9999"
],
"ignoreErrors": "true"
},
"type": "firstValid"
},
"inputFormat": "MM/dd/yyyy",
"outputFormat": "ISO8601"
},
"type": "dateFormat"
},
"secondDate": {
"attributes": {
"input": {
"attributes": {
"expression": "now-61d/d"
},
"type": "dateMath"
},
"inputFormat": "yyyy-MM-dd'T'HH:mm",
"outputFormat": "ISO8601"
},
"type": "dateFormat"
},
"operator": "lte"
},
"type": "dateCompare"
},
"value": "#if($day60==\"TRUE\")60DayLastLogon#{end}"
},
"internal": false
}
Hope this helps you.
It would be good to know the source. What use case are you implementing? Only a report?
On top of other friends’ suggestions I must add that the scheduled report receiver should have proper user level to be able to reach the report. For these type of report requests, you can call Search API and create custom reports outside of ISC.
Hi @Dervish ,
We built a source (Web Service connector) to easily identify the inactive accounts for XX days and used it to launch certification (instead of generating report).
Our connector is configured with the following operations:
By renaming the entitlement, we are able to easily identify the inactive accounts on specific source and triggered certification campaign to ask reviewers if the account must be maintained.
The sources include GCP, Salesforce, SAP Basis, AD, Cato Networks, Azure AD (AAD), and Web Services.
Since each source uses a different time format, the values must first be normalized and converted. The goal is to identify accounts that have not logged in for more than 60 days across these sources and to generate individual reports for each system.
Hi @suresh4iam ,
May I ask whether the approach you mentioned can only be applied to a single Source? In other words, if there are multiple different Sources, do we need to create one for each Source? For example, if we have 20 Sources, would that require creating 20 separate connectors?
Hi @bastienprulhiere ,
We have discussed with our team the possibility of consolidating this data into a Web Service Source. However, since each Source uses a different time format, time normalization and conversion would be required.
In addition, the customer’s current certification process is not performed within ISC, but rather in their existing internal certification system. When needed, they call the ISC APIs to retrieve the required data.
Hi @Dervish
We have similar use case with the date format which is different between every sources so we added properties on source to manage this:
“lastLogonConfig”: {
“Groups Aggregation - APP XX Account”: {
“durationInDays”: 90,
“appName”: “APP XX”,
“format”: “dd/MM/yyyy”,
“attributeName”: “LAST_CONNECTION_DATE”,
“formatType”: “DATE_FORMAT”
},
“Groups Aggregation - APP YY Account”: {
“durationInDays”: 45,
“appName”: “APP YY”,
“format”: “dd-MM-yyyy”,
“attributeName”: “last_access”,
“formatType”: “TIMESTAMP”
}
}
Those properties help us to manage different date formats and duration account inactivity.
You need separate identity attributes for each source to get the date from each source. In case if you want to get the latest date among those sources, you can use transform to get the date from each source and compare between them to get the latest one.
Hi @Dervish
Please see this. This will help you identifying the users who have not logged into multiple target application. This approach can also handle the different types of date time format for each application.
The core idea here involves creating a new identity attribute and you can there store multiple applications where the user have not logged in.
I hope this works.
Regards
Vikas.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.