Identity Attribute Rule - Lookup AD distinguishedName using sAMAccountName

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

Hello everyone,

I’m working on an Identity Attribute Rule(cloud) in ISC to populate the AD manager DN.

My identity attribute servicenowManager contains the manager’s sAMAccountName value, for example:

servicenowManager = CED123

The corresponding AD account attributes has:

sAMAccountName = CED123

displayName = Elswk, Christopher

distinguishedName = CN=Christopher Elswk (CED123),OU=xx,OU=xyz,DC=ds,DC=xyz

My current rule does:

import sailpoint.rule.Account;

String managerOPID = (String) identity.getAttribute(“servicenowManager”);

Account adAccount =idn.getAccountByDisplayName(“Active Directory”,

managerOPID.trim());

String resolvedDN =idn.getAccountAttribute(adAccount,“distinguishedName”);

The issue is that servicenowManager contains the manager’s sAMAccountName, not the AD displayName.

Questions:

  1. Is getAccountByDisplayName() the correct method in this scenario?
  2. What is the recommended ISC Rule API approach to locate an AD account using a sAMAccountName value such as CED123?
  3. Should I first locate the Identity and then retrieve its AD account before reading the distinguishedName?
  4. Are there any supported examples for resolving an AD account DN from an identity attribute that stores a manager’s OPID?

Any guidance or sample code would be appreciated.

Thank you!

2

Are you trying to populate an identity attribute? You can use the provided “Get Reference Identity Attribute” rule.

{
    "name": "get-manager-distinguishedName",
    "type": "rule",
    "attributes": {
        "uid": "manager",
        "name": "Cloud Services Deployment Utility",
        "attributeName": "activeDirectoryDn",
        "operation": "getReferenceIdentityAttribute"
    },
    "internal": false
}

In the above example, I’ve set an identity attribute that maps the DN from the Active Directory source for a given identity, called " Active Directory DN (activeDirectoryDn)". Now for any identity, I want to refer to the identity attribute of the manager. That’s where the getReferenceIdentityAttribute comes in. You can use this to reference any identity attribute of a manger.

By using an identity attribute, you can map this down to the Active Directory create account profile and use attribute sync. If you put a rule or transform directly in the create account profile, then you can’t use attribute sync to keep it up to date after changes occur.

Matt

3

@amithkumar1 I don’t think getAccountByDisplayName() is the right choice here since your servicenowManager attribute contains the manager’s sAMAccountName, not the AD display name.

If it were me, I’d first try to find the corresponding Identity using that value and then retrieve the manager’s Active Directory account to get the distinguishedName. That feels like a more reliable approach than trying to match on the display name.

4

Hello AMithkumar. @MattUribe getReferenceIdentityAttribute suggestion is probably the cleanest path here. If the manager relationship is already resolved in ISC through manager correlation, the approach is to map the AD distinguishedName to an identity attribute (say activeDirectoryDn), then use the Get Reference Identity Attribute transform:

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

If this is mapped to the AD manager attribute in your provisioning policy and attribute sync is configured, manager changes can be synchronized automatically.

To your first question, getAccountByDisplayName() is not the right fit here. It matches against the ISC account display name (the Account Name field in your source schema), not an arbitrary AD attribute like sAMAccountName. So passing CED123 would not return the correct account unless that field happens to be mapped to sAMAccountName.

If the ISC manager relationship is not available, there is no getAccountBySamAccountName() method in IdnRuleUtil. The supported approach would be to promote AD sAMAccountName as a searchable account attribute and run a non-optimized aggregation to seed existing accounts. Then in your rule, use idn.attrSearchGetIdentityName() to resolve the owning identity, and idn.getFirstAccountNativeIdentity("Active Directory", identityName) to get the DN directly (since AD’s native identity is the distinguishedName).

I would suggest trying the transform approach first since it avoids custom account lookup logic entirely and is easier to maintain long term.

5

Hi @amithkumar1 , If I’m reading your first question correctly, you’re all set — here’s my understanding of the flow:

  1. You’re pulling the serviceNowManager identity attribute, which holds the manager’s sAMAccountName.
  2. You’re then using that sAMAccountName to look up the manager’s account in your AD source via getAccountByDisplayName(), in order to retrieve their DN.

The key thing to note is that getAccountByDisplayName() doesn’t actually search on the literal “Display Name” account attribute — it searches on whatever attribute is configured as Account Name in that source’s Account Schema, which in your case is sAMAccountName.

Since the OOTB AD connector maps Account Name to sAMAccountName by default, the function is effectively looking up the manager’s sAMAccountName in the AD source and returning the corresponding DN.