Aggregate account on AD after successful account creation

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

Hi Experts,

I have created a netive BeforeCreate rule to calculate the DN, UPN & sAMAccountNAme as we wanted to avoid writing a before provisioning rule (as this is a cloud rule and intervention from Sailpoint is needed). This works perfectly but the account on IdentityNow is not aggregated and does not show up on the UI with the updated values, it looks like this:

image
image2506×561 42.5 KB

The “Name” should be the sAMAccountNAme and the nativeIdentity should be the updated DN.

Is there anything else I should consider adding to the before create rule?

Thanks and best regards
Tamalika

3

Hi @tamalika01
Is there a business reason as to why are you not using the OOTB CREATE profile to create the account and calculate all of those values?
It seems needlessly complicated to do it via an beforeCreate rule

1 Like
4

Hi @tamalika01, The issue is when sailpoint triggers to create user its DN (native identity is without the CN part) as this is generated by BeforeCreate rule.
Can you please provide below information -
Is the account creation is success in AD with all attributes as expected?
Did you try full aggregation after the account creation?
What is the correlation rule for AD?
How is distinguishedName mapped in AD CREATE Provisioning profile?

Thanks

5

Logic for UPN generation - to check in AD all historical proxyAddresses and then generate
Logic for sAMAccountName - increasing 5 character string for example QVDEF - where the first 2 characters are dependant on the employeeType. This was not straightforward. We decided not to use the cloud rules - Attribute Generation or Before Provisioning as that would require sailpoint to upload the rule and would restric us from editing and testing.

6

Hi @tamalika01 - As @anandan07 asks. Was the AD account created with the correct attribute values? The Native identity doesn’t appear to include the CN part. Are you mapping CN attribute correctly in the create account profile?

7

Hi @j_place @anandan07

I am updating the distinguishedName on the BeforeCreate rule, along with the sAMAccountName and the UPN:

# Update the request object with the new name

$attrsAMAccountName = New-Object SailPoint.Utils.objects.AttributeRequest;

$attrsAMAccountName.Name = "sAMAccountName";

$attrsAMAccountName.value= $prefixValue+$newName;

$attrsAMAccountName.Operation = "Add";

$requestObject.AttributeRequests.Add($attrsAMAccountName);

# Update the request object with the new native identity which is the DN

$requestObject.nativeIdentity = "CN="+$prefixValue+$newName+","+$oupath

# Assuming $oupath is the DN of the OU where the user is to be created and is configured correctly on the Create Account configuration

LogToFile "PS Script>>>>>> Request object modified successfully" $true

$newEmail = Generate-UniqueEmail -firstName $firstName -lastName $lastName -domain $domainname

LogToFile "PS Script>>>>>> New email: $newEmail" $true

$attrsUpn= New-Object SailPoint.Utils.objects.AttributeRequest;

$attrsUpn.Name = "userPrincipalName";

$attrsUpn.value= $newEmail;

$attrsUpn.Operation = "Add";

$requestObject.AttributeRequests.Add($attrsUpn);

I just added the snippets here as the script is too long. Yes the values are getting populated as expected and the user creation also works.

Here is the configuration from the Create Profile:

image
image862×404 23.4 KB

image
image851×254 14 KB

So I mapped the OU Path on the dn and the domain i.e. company1.com or company2.com on the upn on the create profile. This I then modify in the BeforeCreate rule with the actual logic.

8

Thanks @tamalika01 - I think you’re getting into problems because you’re altering fundamental attributes: nativeIdentity (Account ID) and sAMAccountName (Name) in the before create rule. ISC thinks its creating an account with DN and sAMAccountName as in the create account profile (ie no CN part in DN and disabled sAMAccountName) - that’s what you can see in the account list. On first aggregation there is no matching Account ID for the new account so it can’t update the ISC representation of the account. Also, how is correlation set up - did the new account get aggregated as an orphan?

9

No, the correlation is fine and the account looks perfect once I run a full aggregation.

What I did now is configure an AterCreate rule to print the $requestObject and from there I see that the AccountRequest does not contain the nativeIdentity or the updated AttributeRequests:

Request as XML object in AFterCreate is:

<AccountRequest application="Active Directory [source]" op="Create" nativeIdentity="OU=Users,OU=xxxxxx,OU=LXS Objects Test,DC=ad,DC=xxxxxx,DC=com">
  <AttributeRequest op="Add" name="memberOf" value="CN=TST_DE73_DE10,OU=Organizational Structure Groups,OU=Groups,OU=xxxxxx,OU=LXS Objects Test,DC=ad,DC=xxxxxx,DC=com" />
  <AttributeRequest op="Add" name="ObjectType" value="User" />
  <AttributeRequest op="Add" name="password" value="xxxxxx">
    <Attributes>
      <Map>
        <entry key="secret" value="true" />
      </Map>
    </Attributes>
  </AttributeRequest>
  <AttributeRequest op="Add" name="givenName" value="TIDN" />
  <AttributeRequest op="Add" name="sn" value="User116" />
  <AttributeRequest op="Add" name="pwdLastSet">
    <Value>
      <Boolean>false</Boolean>
    </Value>
  </AttributeRequest>
  <AttributeRequest op="Add" name="IIQDisabled">
    <Value>
      <Boolean>false</Boolean>
    </Value>
  </AttributeRequest>
  <AttributeRequest op="Add" name="description" value="Created by SailPoint IdentityNow as a part of testing" />
  <AttributeRequest op="Add" name="userPrincipalName" value="xxxxx.com" />
  <AttributeRequest op="Add" name="department" value="LXSD-BOMP-IT-AP-GHRS-IARM" />
  <AttributeRequest op="Add" name="userAccountControl" value="512" />
  <AttributeRequest op="Add" name="accountExpires" value="9223372036854775807" />
  <AttributeRequest op="Add" name="employeeNumber" value="10000116" />
  <AttributeRequest op="Add" name="co" value="DE" />
  <AttributeRequest op="Add" name="c" value="DE" />
  <AttributeRequest op="Add" name="comment" value="Normal User" />
  <AttributeRequest op="Add" name="employeeType" value="Regular" />
  <AttributeRequest op="Add" name="extensionAttribute4" value="false" />
  <AttributeRequest op="Add" name="preferredLanguage" value="en-US" />
</AccountRequest>

I did include this line in the BeforeCreate script which sends back the updated requestObject:

$requestObject.toxml()|out-file $args[0];

Here is the result object on the AfterCreate rule:

<?xml version="1.0" encoding="utf-8"?>
<ServiceResult>
  <Attributes>
    <Map>
      <entry key="returnRequest">
        <value>
          <AccountRequest application="Active Directory [source]" op="Create" nativeIdentity="CN=IDN_QIIBL,OU=Users,OU=xxxxx,OU=LXS Objects Test,DC=ad,DC=xxxxx,DC=com">
            <AttributeRequest op="Add" name="memberOf" value="CN=TST_DE73_DE10,OU=Organizational Structure Groups,OU=Groups,OU=xxxxx,OU=LXS Objects Test,DC=ad,DC=xxxxx,DC=com" />
            <AttributeRequest op="Add" name="ObjectType" value="User" />
            <AttributeRequest op="Add" name="password" value="xxxxx">
              <Attributes>
                <Map>
                  <entry key="secret" value="true" />
                </Map>
              </Attributes>
            </AttributeRequest>
            <AttributeRequest op="Add" name="givenName" value="TIDN" />
            <AttributeRequest op="Add" name="sn" value="User117" />
            <AttributeRequest op="Add" name="pwdLastSet">
              <Value>
                <Boolean>false</Boolean>
              </Value>
            </AttributeRequest>
            <AttributeRequest op="Add" name="IIQDisabled">
              <Value>
                <Boolean>false</Boolean>
              </Value>
            </AttributeRequest>
            <AttributeRequest op="Add" name="description" value="Created by SailPoint IdentityNow as a part of testing" />
            <AttributeRequest op="Add" name="userPrincipalName" value="xxxxx.com" />
            <AttributeRequest op="Add" name="department" value="LXSD-BOMP-IT-AP-GHRS-IARM" />
            <AttributeRequest op="Add" name="userAccountControl" value="512" />
            <AttributeRequest op="Add" name="accountExpires" value="9223372036854775807" />
            <AttributeRequest op="Add" name="employeeNumber" value="10000117" />
            <AttributeRequest op="Add" name="co" value="DE" />
            <AttributeRequest op="Add" name="c" value="DE" />
            <AttributeRequest op="Add" name="comment" value="Normal User" />
            <AttributeRequest op="Add" name="employeeType" value="Regular" />
            <AttributeRequest op="Add" name="extensionAttribute4" value="false" />
            <AttributeRequest op="Add" name="preferredLanguage" value="en-US" />
            <AttributeRequest op="Add" name="sAMAccountName" value="IDN_QIIBL" />
            <AttributeRequest op="Add" name="userPrincipalName" value="[email protected]" />
          </AccountRequest>
        </value>
      </entry>
      <entry key="requestProcessedOn" value="11/8/2024 3:19:26 PM" />
      <entry key="groupDCs">
        <value>
          <Map>
            <entry key="dc=ad,dc=xxxxx,dc=com" value="xxxxx.ad.xxxxx.com" />
          </Map>
        </value>
      </entry>
      <entry key="objectguid" value="{c7b44e40-c598-4a2a-9d47-a24a098c2deb}" />
      <entry key="createdOnServer" value="xxxxx.ad.xxxxx.com" />
    </Map>
  </Attributes>
</ServiceResult>

The only problem I see is that I need to remove the old AttributeRequest for the UPN which i missed, but as you can see both the nativeIdentity and the sAMAccountName are correctly set.

Is there anything else I missed?

10

Hi @tamalika01 - Not sure what you’re after here. You say the account gets created ok, and gets aggregated ok. Is the problem that the account doesn’t look correct until first aggregation?

11

@tamalika01 This is expected behavior, not an issue, so you haven’t missed anything. According to ISC, it creates an account with a native identity mapped from the xAD OU identity attribute. However, during creation, the script modifies the native identity (DN), which ISC is unaware of. As a result, when the account is first created in the account profile, the initial AD account displays with an incorrect DN and login ID. During the next scheduled or manual aggregation, ISC will remove the account from its profile, assuming the account doesn’t exist in AD, and will instead correlate it with the previously created account.

I’ve encountered a similar situation and resolved it by setting AD aggregation to occur every hour, ensuring the correct account is updated in ISC. Since you don’t want to use a cloud rule, If you have workflow license you can trigger an aggregation as soon as the account gets created in AD. Other that that i don’t see an workaround for this.

Can you let us know how this is impacting your other workflows? So, we can find a solution for that.

12

Agreeing with @anandan07

However

should, IMHO, read

the initial AD account displays the DN and login ID requested, which may not match the result of an operation outside ISC control (ie a connector rule).

1 Like
13

The creation policy is fundamentally incorrect here.

The DN needs to be a DN of the account to be created BEFORE the request is sent out over to the VA–>IQService, not the DN of the OU that’s to contain the account.

Your native script fills out what the account DN needs to be in the on-prem side…but ISC does NOT know about that. As such, ISC can’t carry out a Get-Object operation against what it knows…which is only the DN of the OU. It’s like “I have the DN of the OU…I’m looking…but that is ONLY an OU, not an account”.

Your current implementation also breaks low-level audit if we’re being specific: IDN did NOT request the account to be created with that DN. The DN was augmented / adjusted / calculated, out of band.

You’re essentially experiencing a “Is it done, vs, is it done right?” situation.

1 Like
14

Hi @anandan07 , thank you for your response, I will try to set up a workflow. Could you also let me know if you had any other impacts in your project if you ran an hourly aggregation?

15

I dont see any issue with hourly aggregation. One potential issue is if you are sending a notification to user/manager regarding account creation and if they try to set or reset their initial AD password through Sailpoint within that one hour, the password reset might failed.
If you have any other provisioning flow like OKTA which has dependency on generated upn, you may need to delay the provisioning by adding additional criteria in the birth right provisioning Sailpoint role.
Other than that i dont see any other issues.

16

Thanks for your feedback @anandan07 , you’ve given some valuable inputs. But also we are discussing internally what @IIQUserOnCompass wrote above, we will evaluate the pros and cons and we will come up with a solution.

17

Yes what @IIQUserOnCompass mentioned make sense, what i did is as a temporary DN I used users last name as CN. And made the rule to generate the CN during creation. But I used after create rule and pwd script to generate unique values and set/replace those values in AD

1 Like