Clear ‘Manager’ and ‘ManagerDN’ identity attributes for inactive users

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Greetings,

I would like to find a way to clear the ‘manager’ and ‘managerDN’ identity attributes from users in the ‘inactive’ Lifecycle State. Is there a simple way to do this?

The situation:
We have attribute sync enabled for source Active Directory. It works well, a little too well. When users leave the company our rule clears the manager field from the user’s AD account… and then attribute sync puts it right back.

The problem:
This causes inactive users to show up as direct reports when their former manager logs in to IDN. In addition, since it’s also applied to the AD account the inactive users show up on the former manager’s team in Outlook calendar and the company Org charts.

I need to clear the manager and managerDN attribute from the identity so that the attribute sync will clear the field in Active directory and solve both issues.

Thank you.

2

Hi Mike,

Welcome to the community. When you say you have a rule to clear the manager field, is that an IDN rule or an active directory rule (if there is such a thing). I just want to be clear what other processes are in place so any potential solutions aren’t stepping on the existing processes.

1 Like
3

Hi Colin,

It’s an active directory rule that, when the user is fully terminated (transitions to the inactive LCS) there is a list of tasks performed against the user account. Clearing AD groups, moving to a different OU, changing attributes like title, and clearing the manager field in the AD account attribute.

All that works fine… except when I enabled attribute sync of the managerDN identity attribute it re-populated that AD account attribute and that affects downstream systems like Outlook and anything else that draws on that attribute.

4

Hmmm. So you clear the manager field directly in AD, but attribute sync adds it back because it the manager field still exists in the identity cube in IDN. Rather than using a rule to clear the manager field directly in AD, try creating a transform on the managerDN identity attribute that will take the lifecycle state into account when determining the value. This should clear the managerDN in the identity cube when the LCS is inactive, and then attribute sync should propagate that to active directory.

You can use the conditional transform operation to accomplish this. lcs should use the same transform logic you use to calculate the lifecycle state attribute so we know if the user is active or inactive. Here is a starting point for the transform, but you may need to modify it to fit your environment, especially if you already have a transform on your managerDN attribute.

{
  "attributes": {
    "expression": "$lcs eq inactive",
    "positiveCondition": "",
    "negativeCondition": "$managerDN",
    "lcs": {
      <logic to calculate lifecycle state>
    },
    "managerDN": {
      "attributes": {
        "sourceName": "AD Source",
        "attributeName": "managerDN"
      },
      "type": "accountAttribute"
    }
  },
  "type": "conditional",
  "name": "Calculate Manager DN"
}
2 Likes
5

Colin,

I think that’s exactly what I was looking for. I do have an existing transform to translate ‘managerUsername’ to ‘managerDN’ which is what is needed to assign a manager to a user in AD. I’ll track down that transform. If I can get it to work I’ll mark this as the solution.

Thanks!
Mike

6

Great! If you can get it to work, would you mind sharing your transform logic in this post? It could help others. Feel free to redact any sensitive portions of it if necessary.

7

Hello Mike,
Hope you are doing well!

We have similar requirement where we need to append “zzz” infront of the distinguishedName and change the OU upon termination. Can you pls help us with the logic to achieve this.

8

Hey hey, chiming in as well since we have the same requirement of clearing the manager field in IDN for inactive users (for the same reason as the original post explained).

I also went for a transform and tried a simple conditional transform first (pretty much identical to your example, @colin_mckibben) but this failed since the positiveCondition needs to be a string/object and can’t be left empty.
This was my first attempt (which caused identities to error due to the transform failing):

{
  "attributes": {
    "expression": "$status eq ACTIVE",
    "positiveCondition": "$manager",
    "negativeCondition": "none",
    "status": {
      "attributes": {
        "sourceName": "AS01-OKTA",
        "attributeName": "status"
      },
      "type": "accountAttribute"
    },
      "manager": {
        "attributes": {
          "sourceName": "AS01-OKTA",
          "attributeName": "manager"
        },
        "type": "accountAttribute"
    }
  },
  "type": "conditional",
  "name": "Test Conditional Transform",
  "requiresPeriodicRefresh": true
}

We also have identities in active states that might not have a manager attribute (service accounts) so I ended up expanding on the conditional transform a bit:

{
  "attributes": {
    "expression": "$status eq ACTIVE",
    "positiveCondition": "$manager",
    "negativeCondition": "none",
    "status": {
        "attributes": {
            "sourceName": "AS01-OKTA",
            "attributeName": "status"
      },
        "type": "accountAttribute"
    },
    "manager": {
        "attributes": {
            "values": [
                {
                    "attributes": {
                        "sourceName": "AS01-OKTA",
                        "attributeName": "manager"
                    },
                    "type": "accountAttribute"
                },
                {
                    "attributes": {
                        "value": "none"
                    },
                    "type": "static"
                }
            ]
        },
        "type": "firstValid"
    }
  },
  "type": "conditional",
  "name": "Manager if active (and provided)",
  "requiresPeriodicRefresh": true
}

This example will output the $manager attribute from your Okta source if the user is active and has a manager - if the user isn’t active or is active but doesn’t have a manager, the output will be “none”. I’d prefer to leave it NULL for cleanliness sake but haven’t figured that out yet.

This seems to work fine (at least in preview) but I’ve had some trouble getting the identities to properly refresh - will see if the daily cycle will take care of that or if I need to do a full non optimised Okta account aggregation.
Hope this might be helpful to someone :).

2 Likes
9

Hey Mahesh,

Essentially you’d need to do something similar like I shared in the example above - find an account or identity attribute in IDN that will tell if you a user is terminated or not and build a conditional transform around that.

Does that help or would you need a more concrete example?

10

This is great! Thank you! I fear I will need to solve the ‘Null’ situation. It is my understanding that AD will not update the manager field to anything other than a known user DN. One Idea I had is to create a ‘termination manager’ user account and set that as the manager, similar to how we change the user’s position to ‘default position’ upon termination. Since no one will be logging in as ‘termination manager’ it will solve the problem. Maybe that could help you too? I’m going to play around with this. Thank you for your advise!

1 Like
11

Glad it was helpful!

Thanks for the tip re termination manager - I’ll have a look and see if it’s applicable for us as well but our architecture is slightly different and flows from HRIS → Okta → IDN so the only place we need to set the manager is in IDN itself. This seems to accept the “none” value my transform outputs (at least in preview). But for your AD solution, this seems like a valid solution. Similar to how files in a cloud drive would be assigned to a service account upon termination, for example.

12

Hey Mike - sorry to open up the topic again, but did this end up working for you?

I could only get this to work in the preview under the identity profile mapping but the linking would never change, despite multiple identity refreshes & full aggregations.

This documentation suggests that the attribute mapping should have an effect but a member of the professional services team in this post states that the mapping under identity profile is purely cosmetic and doesn’t have any actual effect over the linking of manager identities to reports.

It seems like if this is to be done in IDN, the manager correlation rule should be used instead.

@colin_mckibben perhaps some feedback that the manager correlation documentation is quite confusing and the second section that suggests that the correlation is defined under identity profile mappings is incorrect.

For my own solution, I’ll probably look at Okta now instead and see if I can create a more dynamic manager field using Okta expression language since I’m not very handy with IDN rules and leave that as the last option.

1 Like
13

Thanks @M_rtenH . I created a docs ticket to look into this.

1 Like
14

Heya I’ve been trying to solve this issue for a long time now and also always get it to work in the preview state, but never actually works when I do a full sync or aggregation.

Our authoritative source is connected to a JDCB connector, here I have also tried configuring the query to empty the manager attribute when LCS = terminated. The attribute is emptied correctly in the source account for that particular source, however the cube stays intact with the old manager. I have also tried setting the value to a dummy-manager through a transform, this also only works in preview.

Do we have a fix for this issue or any ideas on how to go forward? We want to keep all terminated identities in IDN as a history database, but we don’t want all of these inactive identities to show up in the managers “My Team” tab.

@colin_mckibben perhaps you have an update on this matter?

Best regards,
Sebastian

15

Good morning @Swegmann ,

There is some work being done on the My Teams functionality to exclude inactive identities, but it probably won’t be released until Q3 this year.

In the meantime, you could try something like this:

  • Create a “dummy” account on the authoritative source, such as “Inactive Manager”
  • Set up a transform on the Manager account attribute, which would change the identity’s manager to “Inactive Manager” based on the identity LCS

If you want to track who the manager was at the time of termination, you could create a new identity attribute, something like “Historical Manager”, and populate that attribute with the current manager when the identity moves into an inactive state before setting manager to the “dummy” manager account.

You could possibly also leverage Workflows with a trigger to handle this use case.

16

Hi there Richard, I’ve tried this use-case with a transform to a dummy manager but it also only works in the “preview” state and is not being synced into the cubes manually or by default. Going to try a workflow, perhaps we have better luck there!

all the best,
Sebastian

17

On 2nd note, it isn’t possible to update identity attributes through workflows I’m afraid.

18

I have now managed to have a workaround which changes the manager attribute to a dummy manager when an identity goes into the terminated LCS. We do this however in the SQL query as the authoritative source uses a JDCB connector.

I’m wondering, however, why this doesn’t work when changing the attribute to a value that has no correlation to a cube. For example we want to empty the manager attribute entirely on termination so instead of updating the attribute to a different ID we simply write "Terminated: " + managerID in order to delete the correlation but keep the id of the old manager in the string for the source account attribute. This however doesn’t seem to update the actual manager attribute in the Cube.

It seems as IDN has some kind of safety net, however I can’t confirm it. We correlate on EMPID for manager but when we override that attribute with a fake value as described above it seems to correlate on the next unique identifier for the (old) manager identity cube(even though we have not stated any other manager correlations). For example if the manager attribute is usually a string of numbers like: “123456”, when updated to a fake or empty value through the authoritative source it correlated on the username for example: “TEST01”.

Is this some kind of safety/fallback feature that IDN has that we aren’t aware of and is there any way to tackle this? We want to avoid using dummyidentitites in our production environment and would much rather prefer to just empty/null the manager attribute for terminated identities.

Best regards,
Sebastian

19

Hi Sebastian,

You have hit the nail on the head – manager correlation won’t change on the identity unless it is replaced by a different manager (a change to a null or invalid manager is ignored). This is the safety net you suspected.

In the meantime, using this (valid) dummy manager is the only solution, at least until the changes are made to My Team to ignore direct reports if they are inactive.

Rich

20

Thanks for answering Richard!

It does seem, like you say, that changing the value of the manager won’t work for an invalid manager value. For example changing the manager attribute to anything else but a null value. IDN tries to correlate on this value and therefore catches an error and attempts to stick with the last correlation it could find. It also correlates on the CUBE’S uid instead of the actual authoritative source attribute for manager correlation.

However, nulling out the value entirely DOES in fact work!(?). Yes. IDN seems to understand that we want to clear the attribute when we send in an empty string via our SQL query (jdbc connector). I have tried this plenty now and it works perfectly. Placeholder values like I have stated earlier, however, will not work as IDN tries to correlate on that value and when finding itself lost falling back on the previous manager cube.

I’m not sure if clearing manager attributes is able in the same manner via transforms however. Might be that our specific use-case using a JDBC connector is helpful in this case as we can build a case in the SQL query.

Thanks for all the responses, going to proceed with this solution in our production environment shortly.

All the best,
Sebastian