[IdentityNow] Manager DN Transform for AD Create Policy

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

Hello all,

My team has been experiencing difficulties obtaining the DN value of an Identity’s manager that’s assigned and setting it to be the value of the Manager attribute in the Active Directory connection source. The data we are testing with is currently in a delimited file and we are making transforms for the Create Account provisioning policy.

We have tried firstValue transforms for the VDI that calls a static value of “value”: “$identity.manager.attributes.networkDn” and we have tried a firstValue nesting a rule transform.

“attributes”: {
“name”: “Cloud Services Deployment Utility”,
“attributeName”: “dn”,
“operation”: “getReferenceIdentityAttribute”,
“uid”: “manager”
},
“type”: “rule”

Each time we have tried, the value of the manager’s distinguishedName in the Identity Profile (which we had checked to see it filled) would return empty when a new user account is created for the AD account, and all values are filled except for manager.

Does anyone know why this might be? Thank you for reading.

2

Hi James,

Can you confirm if the dn attribute is an Identity Attribute which stores the DN of all identities?

3

Hi, Animesh! I can confirm that when I go to the list of identities that are in the delimited file auth source, each one has a DN value, and this includes the manager that is correlated with them.

4

The name of identity attribute where the dn is stored is networkDn or dn?
If it is networkDn then you will have to update the transform to:

    "name": "Get Manager DN",
    "type": "rule",
    "attributes": {
        "uid": "manager",
        "name": "Cloud Services Deployment Utility",
        "attributeName": "networkDn",
        "operation": "getReferenceIdentityAttribute"
    },
5

image
image1796×64 5.53 KB

It’s DN. The reason we used networkDn before is because the document for this page at the bottom said that the static value for networkDN pulls distinguishedName from the AD itself.

First Valid | SailPoint Developer Community

I’m also noticing that, for the Active Directory connection source, the manager correlation is blank.

2023-06-23_14-21-18
2023-06-23_14-21-181451×295 12.4 KB

Is this the cause? Do we need to correlate this in order for the rule transforms to find the manager in the Create Policy?

6

The documentation you quoted is just an example that if your Identity Attribute is “Network DN” and it is mapped to get the AD DN then you could use it like "$identity.manager.attributes.networkDn". In your scenario, it will be "$identity.manager.attributes.dn".

Think of Manager as a map of identity attributes.

No, you do not need to correlate this in order for the rule transform to work. The manager it is looking is from the identity attribute “manager”. If nothing is populated in manager field of Identity Cube, then the rule will not work.

7

I would suggest you to create a identity attribute to hold manager DN and plug this transform to the attribute mapping. This way, you will be able to see if the field is being populated or not.

8

I will try $identity.manager.attributes.dn and let you know the result.

1 Like
9

So I tried the following code to try and get the manager of the new identity that I put in.

{
	"name": "manager",
	"transform": {
		"attributes": {
			"ignoreErrors": "true",
			"values": [{
					"attributes": {
						"value": "$identity.manager.attributes.dn"
					},
					"type": "static"
				},
				""
			]
		},
		"type": "firstValid"
	},
	"attributes": {},
	"isRequired": false,
	"type": "string",
	"isMultiValued": false
}

I made sure to confirm that the manager name was in the Identity I put in and it is.
However, when I made an access request for the identity with an entitlement from the AD, it had failed and said that the account was created for AD but the values weren’t populated. So, I rewrote the code to be the following:

{
	"name": "manager",
	"transform": {
		"attributes": {
			"ignoreErrors": "true",
			"values": [{
					"type": "rule",
					"attributes": {
						"uid": "manager",
						"name": "Cloud Services Deployment Utility",
						"attributeName": "dn",
						"operation": "getReferenceIdentityAttribute"
					}
				},
				""
			]
		},
		"type": "firstValid"
	},
	"attributes": {},
	"isRequired": false,
	"type": "string",
	"isMultiValued": false
}

This time around, the request did pass and the information was filled out, but manager still remained blank when it ran the above code.

2023-06-23_15-18-37
2023-06-23_15-18-371784×56 2.19 KB

10

Just to confirm your manager correlation worked properly, can you try other ways of confirming same.

Try to request something which goes for manager approval and check if manager identity got it or not.

11

Hello @JamesMcClartyEY,

I believe the manager correlation has to be set on the authoritative source for the $identity.getManager() to return the manager successfully.

I tested this in my environment using a Delimited source.

The source info looks like:

id email first_name last_name hire_date manager
100010 [email protected] Lewis hamilton 2020-12-12
100011 [email protected] Frank Williams 2020-07-10 100010
100012 [email protected] Paddy Lowe 2020-09-20

The correlation is set Employee Number → manager where id in the table above is mapped to Employee Number.

image
image2318×362 23.2 KB

I can then use the transform to get that managers attributes. When I am testing out and developing transforms I use the cc preview API.

I can test this out by retrieving the id of the employee whose manager’s attribute I want to pull and providing the transform to test.

{
    "attributeTransforms": [
        {
            "attributeName": "personalEmail",
            "type": "static",
            "attributes": {
                "value": "$identity.getManager().getAttribute('email')"
            }
        }
    ]
}

The response returned will look similar to below, there will be quite a lot more preview attributes. You can search for the attributeName you provided above, I used personalEmail.

{
    "displayName": "Frank",
    "id": "2c918085840ffd580184155e40ea0966",
    "meta": {
        "created": "2022-10-26T17:36:49+00:00",
        "modified": "2023-06-26T00:08:19+00:00",
        "type": "identityProfiles"
    },
    "name": "Frank",
    "previewAttributes": [
        {
            "messages": null,
            "name": "personalEmail",
            "previousValue": null,
            "value": "[email protected]"
        },
    ]
}

The getReferenceIdentityAttribute from the Cloud Services Deployment Utility uses the same code to retrieve the manager identity so it does need to be correlated.

1 Like
12

@JamesMcClartyEY,

Did my latest reply resolve the issue for you?

13

We have found a workaround. Thank you very much.

1 Like
14

We would love to hear your solution!

15

We are using the Identity Profile mappings to get the DN through a transform there and put it as an identity attribute in the Create Account for AD account creation.

1 Like
16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.