Filtering Disabled Accounts in Certification

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hey All,

I’ve come across a weird case that I think isn’t possible, but wanted to see if anyone has found a solution for this.

I’m trying to create 1 certification for multiple Microsoft SQL Server sources and I want to exclude disabled accounts from the campaign. I recognize the two most common ways of doing this is by filtering based on the Identity lifecycle state and also using a campaign filter to include only the account attributes that show as “ACTIVE” or “ENABLED”, etc…

Problem with this is the source I’m working with does not have an account attribute that indicates the status of the account, but it has IIQDisabled in the background (I can see accounts are disabled/enabled in the UI). I’m assuming in the backend there is an is_disabled flag, but this OOTB connector does not display the actual account attribute for me to do a filter on.

So I’m wondering if anyone has any magic or customization that I haven’t thought of to make this possible. Thanks in advance!

2

You could utilize a workflow and the create-campaign endpoint to run a search campaign

Prior to the call to create the campaign, run a get identities action to get the list of eligible identities

@access(source.name:"SQL SOURCE") AND @accounts(source.name:"SQL SOURCE" AND disabled:false)

This query pulls back identities that have an active account in that source with entitlements assigned

Then in your create search campaign API call, make the body like (my syntax is probably off but you get the idea)

{
  "name": "Search Campaign",
  "description": "Search Campaign",
  "deadline": "2026-12-25T06:00:00.468Z",
  "type": "SEARCH",
  "emailNotificationEnabled": false,
  "autoRevokeAllowed": false,
  "recommendationsEnabled": false,
  "searchCampaignInfo": {
    "type": "ACCESS",
    "query": "source.name:\"SQL SOURCE\"",
    "identities": {{$.getIdentities[*].id}}
  },
  "mandatoryCommentRequirement": "NO_DECISIONS"
}

ETA: I realized this was for MULTIPLE sources, so IMO you’d have to separate out each source into its own campaign

3

Let me ask some questions to make sure that I understand what you are asking first:

  1. You would like to have a Certification that includes multiple MSSQL Server sources?
    For Example:
  • MSSQL_01
  • MSSQL_02
  • MSSQL_03

  1. Do you want to exclude account on those servers that are disabled, or Identities in IIQ that are disabled? or both?

  2. Do you want to only certify the access from MSSQL, and not all access these users have?

4
  1. Correct.
  2. I want to exclude accounts on those servers that are disabled. Identity state is not relevant.
  3. Only certify access from MSSQL.

@mcheek’s suggestion is basically exactly what I want, but with multiple sources instead.

5

Giving this thread a bump.

I think Mark’s solution is the best I’m going to get although it doesn’t handle multiple sources.

6

Hey @trettkowski - If you try an exclusion filter with Criteria Type Account Attribute, then the source, you are saying that IIQDisabled does not show in the Attribute list? If not, they you may have to add it to the schema with a SQL query if you know what value(s) can determine what it should be. ISC is definitely looking at some background value if it is displaying it in the UI.

7

Thanks for the response @ryan_toornburg.

Unfortunately, IIQDisabled is not included in the account attributes. Since this is an out of the box Microsoft SQL Server connector, it’s also not possible to add it to the schema. If you do add it, the aggregations will fail.

You gave me the idea to see if I could find the attribute it’s doing this calculation on and apparently it’s is_disabled. I added that to the schema and the aggregations work and it pulls it in. So it looks like I’ll be able to use the campaign filter after all.

8

@trettkowski That’s awesome! We sometimes have to zig and zag a bit don’t we! Glad to hear you worked it out.

9

Great suggestion by @ryan_toornburg to get your to is_disabled.

Do follow up and let us know if you were able to get this working for multiple sources and if there were any other issues you ran into. I feel others may have similar issues.

10

Yes, this worked! I ended up creating a script to update the source schema’s as well as the campaign filter as typing them all manually was painful, but after doing that and running the campaign via the API, it seemed to work really well!

11

So does your script add all the specific access items you want to certify to the Campaign Filter and then use a query to get the users? I didn’t see a reference to the Campaign Filter in Mark’s suggestion, but he does mention adding the identities to the Search Campaign individually from the results of the query

12

It uses a query to get all the access associated with the sources, then uses the campaign filter to only bring in the accounts with the is_disabled == false

Here is my payload:

$CampaignPayload = @{
    name = "$sourceName Access Review - Status: Active - $(Get-Date -Format 'yyyy-MM-dd')"
    description = "Filtered campaign for $sourceName sources via PowerShell script."
    type = "SEARCH"
    searchCampaignInfo = @{
        type = "ACCESS"
        query = "source.name:" + $sourceName
        reviewerType = "MANAGER"
    }
    filter = @{
        id = ""
        type = "CAMPAIGN_FILTER"
        name = "Remove Disabled Accounts - MS SQL"
    }
    schedule = @{
        type = "ONCE"
    }
} | ConvertTo-Json -Depth 10
13

Nice. Does it run individually for each source, or were you able to get it to combine users from all sources so you had a single certification? Or did I misunderstand your initial requirements?

14

It runs for all sources.

The searchCampaignInfo section might be a little misleading and may look like I’m only using one source for the access items, but that $sourcename variable actually has the word SQL in it. Thankfully all of my SQL Server Sources have the name SQL somewhere in the name so that search query picks them all up when doing that query, so all SQL related sources are included :slight_smile:

15

Ahh, that makes sense then.

I recommend that you document this someplace in case someone else comes along and adds “MySQL DB” or “PostgreSql DB” as a source down the road.