What is the best way to regularly generate a report of system accounts that have not logged in for more than 60 days?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

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?

2

@Dervish

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

2 Likes
3

I would try the below considering you already have a source configured in ISC and you want to automate the above from ISC.

  1. Get the lastLogon or whatever the account attribute you used to know about login date from your source.

  2. 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.

  3. Using Search and subscription, you can send the report to the stakeholders.

  4. 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.

1 Like
4

It would be good to know the source. What use case are you implementing? Only a report?

5

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.

6

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:

  • Get Accounts Operation: API Search to list all the identities who own an account of the sources to monitor
  • Get Entitlements Operation: API Account to list all the accounts on monitored source (ID account is stored as entitlement) and we use an after operation rule to identify the inactive one and rename the entitlement in something readable (Standard App_Name Inactive Account)
  • Remove Entitlement: API Account to disable it

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.

7

Hi @ts_fpatterson

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.