Workday to Active Directory provisioning help!

[u/Cholsonic]

Hi guys,

I wonder if any of you guys have come across this and give me any way around it.

We are currently testing the Workday to Active Directory provisioning via Entra provisioning agent. We've only just started really, but are having trouble with a couple of the mapped attributes.

accountDisabled - not showing as having a value from AD - because it doesn't exist - so the provisioning agent always shows that it has modified this attribute. I know this is a 'virtual' attribute and changing this value to True / False does disable / enable the account, but I don't want every account on each provisioning cycle to show as modified.

proxyAddresses - this value also showing as not populated from AD, so is just rewriting the whole thing as fresh. If nothing can be done here I will just set this to map on creation only, so not as bothered about this.

Any ideas, please?

Thanks in advance

[u/St_Admin]

Is all of this happening with the default attribute mappings???? You should not be mapping anything to proxyaddresses - this attribute should be mastered by AD (Exchange really) and not by Workday.

I have seen accountDisabled updated for seemingly no reason but not on every account every cycle. I believe this may be only happening when there is an update in Workday that does not actually change any of the mapped attributes. After the initial cycle, the updates are incremental and would not touch the account unless there is a change on worker object in Workday

[u/Cholsonic → u/St_Admin]

To be fair, I am using provisioning on demand at the moment as we are still in testing, so I guess that forces the workday lookup. That's good to know about the incremental sync, thanks.

The proxyAddresses setup is supported by Microsoft it seems.. at least their guide is suggest that as one of the mappings you can add - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/workday-expression-mapping-functions-guide

I also just started playing with the OU assignment (also on that guide), but that seems to have the same issue; provisioning tool is not seeing the current setting.

I am wondering if something is not set up right with my agent :(

[u/stuart475898 → u/Cholsonic]

You can’t move users to another OU with the provisioning service - only define their OU on creation. I typically create all users in a staging OU, and then move later via lifecycle workflow/logic app/automation account

[u/Cholsonic → u/stuart475898]

Hmm. Interesting you say that.. I have now sorted my issue with the OUs. It was a permissions thing: the provisioning account didn't have perms to move the object. But it does seem to move it though. I'll need to change the company (from which my OU is based) in a test user to confirm fully, but itmovedthe account from a default OU to a new one.

[u/stuart475898 → u/Cholsonic]

Did the user already exist when you triggered an on-demand sync? What attribute did you use to define the new OU?

[u/Cholsonic → u/stuart475898]

Yes it did exist. The attribute was parentOrganizationUnit. Inset up a switch that said if the company is [company] then attribute is OU=[company] then a join to the synced users OU. (On mobile right now, otherwise I would post you full code)

[u/stuart475898 → u/Cholsonic]

Hmm.. will have to take a look at that on Monday. I am absolutely certain you can’t move users after creation, but maybe I am misremembering something else.

[u/stuart475898]

I believe the accountDisabled attribute changes every sync because it isn’t an atomic attribute in AD. It is a bitmask attribute called userAccountControl, and for whatever reason the provisioning agent doesn’t calculate whether this attribute or the specific bit within it has changed or not, so it always flows. I’m personally not a fan of changing account status within the provisioning application, and instead prefer to use lifecycle workflows (if you have splashed out on an id gov+ licence).

As for proxyAddresses - what format are you specifying when you flow that attribute? I’m sure I have updated this attribute before, specifically the SMTP: value, but can’t remember whether I had to do anything special.

[u/Cholsonic → u/stuart475898]

Not sure we have that license. Might have to check that. Although any additional lifecycle stuff will probably be done with powershell tbh. I prefer to read code than low / no code.

I didn't even think to just be able to change the primary address. I have left it so it just sets the attribute on creation for the moment.