Mover - Update DN in AD

[jacobshoe]

Hello,
My company has been working on a project to get our Contractors into Workday as they use to be created in our authoritative source (ServiceNow). This action has been completed, however when contractors get hired on full time as associates they are generated a duplicate account. This has been the case for the past 9 years.

To solve this, myself an coworkers from the Workday and ServiceNow team have been working on troubleshooting this issue. ServiceNow is out authoritative source, Workday modifies the user type from Contingent to Associate.

In my transform I have the DN listed to adjust the Primary OU based on this user type and I can confirm that when previewing the account in question the Primary OU is correct however the ADOU is still our contractors OU so the account was not moved.

In my create account configuration in AD, we have the generator Create Unique Account ID with the pattern - CN=$(lastname),$(firstname)$(uniqueCounter),$(primaryOu)

I believe my issue here is this attribute calculation is only processed once during account creation but is not triggered again. Please help point me in the right direction to have the distinguishedName change when users switch user types.

[phil_awlings (Phil Rawlings)]

Hi Jacob,
Take a look at this post where I use the UPDATE function of AD to move the users OU:

Substring Transform within Workflow

This is an elegant solution, but why not take it a step further and incorporate it into the UPDATE function and have Sailpoint move the user to the correct OU instead of raising a ticket: Create 2 identity attributes ActiveParentOU - where they should be (use a transform to concatenate their CN with their Manager’s DN) ActualParentOU - where they are then: { "name": "Update Account", "description": null, "usageType": "UPDATE", "field…

[jacobshoe]

Phil,
I will test this, thank you for sharing your knowledge!

[sup3rmark1 (Mark Corsillo)]

i wasn’t aware we could use the AC_NewParent to move the user outside of the Services Standard Build Rule, that’s great to see. does this mean we can use it in a Disable profile as well?

[phil_awlings (Phil Rawlings)]

Here you go…

 {
      "name": "Account",
      "description": null,
      "usageType": "DISABLE",
      "fields": [
          {
              "name": "AC_NewParent",
              "transform": {
                  "attributes": {
                      "value": "OU=Leavers,OU=User Accounts,DC=ad,DC=domain,DC=com"
                  },
                  "type": "static"
              },
              "attributes": {},
              "isRequired": false,
              "type": "string",
              "isMultiValued": false
          },
          {
              "name": "msExchHideFromAddressLists",
              "transform": {
                  "attributes": {
                      "value": true
                  },
                  "type": "static"
              },
              "attributes": {},
              "isRequired": false,
              "type": "boolean",
              "isMultiValued": false
          }
      ]
  }

[jacobshoe]

Phil,

After reviewing what you have provided, I am still running into issues. I think it’s due to me not fully understanding this update type.

I think some of my issue might be in the fact that the distinguishedName is my Account ID in the AD connector Schema. I am currently testing if I modify this Account ID to be employee number and if this allows me the ability to have the distinguishedName be included in my attribute sync to correct the accounts location since my Primary OU was changed.

[phil_awlings (Phil Rawlings)]

DONT change the accountID from the distinguishedName. You will break soooooo many different parts of the connector.

What problems are you running into, and I’ll try to help

[jacobshoe]

Okay, so I have two different attributes. Primary OU and ADOU, Primary OU is a transform that determines where the account should go in the distinguishedName based on the users account type. Pretty much only matters for Associates and Contractors and they go to their own dedicated OUs.

Primary OU plays into the part of the create account under attribute mappings. This is set up with the radio button Generator, Create Unique Account ID and the Pattern is CN=$(lastname),$(firstname)$(uniqueCounter),$(primaryOu)

When the account is created, they are placed in the correct OU. We are changing our process so users keep their current accounts when hired full time which changes their user type but they remain in the wrong OU. We pull in ADOU from the AD connector and I was trying to find a way to basically do an attribute sync to update their accounts location in AD if the Primary OU did not match the ADOU.

[phil_awlings (Phil Rawlings)]

This is what I have used to move user to the correct OU. Just amend the referenced attributes to match yours:

{
  "name": "Update Account",
  "description": null,
  "usageType": "UPDATE",
  "fields": [
    {
      "name": "AC_NewParent",
      "transform": {
        "type": "static",
        "attributes": {
          "value": "#if($activeParentOU != $actualParentOU)$activeParentOU#{else}#end",
          "activeParentOU": {
            "type": "reference",
            "attributes": {
              "id": "Active Parent OU"
            }
          },
          "actualParentOU": {
            "type": "reference",
            "attributes": {
              "id": "Actual Parent OU"
            },
            "ignoreErrors": false
          }
        }
      },
      "attributes": {},
      "isRequired": false,
      "type": "string",
      "isMultiValued": false
    }
  ]
}

activeParentOU is where they should be - created
actualParentOU is where thay are - taken from their DN attribure from AD

[jacobshoe]

Phil,

Appreciate all of your help to my question.

So after reviewing your transform here and figuring out where this logic needs placed, I was brought to before provisioning rule - “Move users to a specific organizational unit (OU) in Active Directory based upon attribute criteria”.

I submitted a ticket with SailPoint support with a reference to your transform asking for guidance to make sure I was being pointed in the right direction. I was informed I need to pay even more money to involve expert services to make this type of change.

All I need to do is move associates that are in the wrong OU because they were once a contractor. To fix this, I wrote a simple powershell script that will run daily and it will Move-ADObject if an account is in the wrong place.

[phil_awlings (Phil Rawlings)]

Hi Jacob,
That works just as well. But just to point out, you didn’t need to go down the route of a before provisioning rule as you can use the UPDATE function from the OOB AD connector.

I often use PS as a back up to the code written in ISC for these two reasons:
1 - ISC should instant, whereas PS will scheduled
2 - ISC is often ‘fire&forget’, so PS will catch those that have fallen through the gaps

[TPA_SP_ARCH (AD DEL)]

Hi Phil,

I did seee this and was trying this but tinging my confusion with this is where do I put the AC_parent?

On the identity Profile and mapped to ? Or do I just add this policy and when the system updates / disables it will place the user in the OU that is corresponding to that lifecycle?

Also just for my Clarification I cannot do it before provision rule without expert services help because it’s a cloud rule? I did not see a before provisional rule in VS code outside the web services one to create this rule either. Thank you for all your help. This is the last thing I need to do to roll this out And it’s driving me, bananas

[phil_awlings (Phil Rawlings)]

You put the AC_NewParent in the UPDATE function on the AD connector. The same place as the CREATE, ENABLE & DISABLE functions

Yes, cloud rules require expert services, so to be avoided because they cost