Deprov - Sleep

Thinking off the top of my head, there could be a different method, similar to Johnny's but utilising Sync Services also.

Customers something ask if there is a way to do some action of an onPrem user once they've been sync'd with Azure AD (via AAD Connect), one of the sure fire ways (that doesn't require scripts to wait) is after the Azure Backsync to ARS has configured the immutableID and Office365Enable flag (IE a change workflow on the user object, where if the ImmutableID is present, and the Office365Flag is true, we do something).

Ordinarily we're only looking for matching objects, and as at this point the the account still exists in Azure it would still be a matching record. If you were to sync an additional attribute from Azure back to Active Roles, into your own VA, you could have a workflow configured on change to that attribute, which would then trigger the deprovisioning of the account in full.

So the process would be something similar to the below:

1) Create a custom command which sets some AD Attribute (which AAD Connect sync's to the Azure USer Object)

2) Have a Change Workflow which triggers the when the AD Attribute is changed, where if its true, the onPrem account is disabled, if it cleared or set to false the account is enabled.

3) Let AAD connect sync to Azure

4) The Azure AD Backsync into Active Role would set a custom VA with the value sync'd from the onPrem user via AADConenct

5) Have another Change Workflow which is triggered on change to the custom VA, Within the workflow you'd have an If/Else Branch, where:

If <OnPrem AD Attribute> = True and <Custom VA> = True

Deprovision account

Else (<OnPrem AD Attribute> = False or Null) and (<Custom VA> = False or Null) and DeprovisionStatus = Deprovisioned)

Undo Deprovision the account

Clear both the OnPrem and Custom VA attribute values

JohnnyQuest 

Thinking off the top of my head, there could be a different method, similar to Johnny's but utilising Sync Services also.

Customers something ask if there is a way to do some action of an onPrem user once they've been sync'd with Azure AD (via AAD Connect), one of the sure fire ways (that doesn't require scripts to wait) is after the Azure Backsync to ARS has configured the immutableID and Office365Enable flag (IE a change workflow on the user object, where if the ImmutableID is present, and the Office365Flag is true, we do something).

Ordinarily we're only looking for matching objects, and as at this point the the account still exists in Azure it would still be a matching record. If you were to sync an additional attribute from Azure back to Active Roles, into your own VA, you could have a workflow configured on change to that attribute, which would then trigger the deprovisioning of the account in full.

So the process would be something similar to the below:

1) Create a custom command which sets some AD Attribute (which AAD Connect sync's to the Azure USer Object)

2) Have a Change Workflow which triggers the when the AD Attribute is changed, where if its true, the onPrem account is disabled, if it cleared or set to false the account is enabled.

3) Let AAD connect sync to Azure

4) The Azure AD Backsync into Active Role would set a custom VA with the value sync'd from the onPrem user via AADConenct

5) Have another Change Workflow which is triggered on change to the custom VA, Within the workflow you'd have an If/Else Branch, where:

If <OnPrem AD Attribute> = True and <Custom VA> = True

Deprovision account

Else (<OnPrem AD Attribute> = False or Null) and (<Custom VA> = False or Null) and DeprovisionStatus = Deprovisioned)

Undo Deprovision the account

Clear both the OnPrem and Custom VA attribute values

JohnnyQuest 

Thanks mate. I will keep this solution in the back of my mind for now.

I am trying to have the work flow update an attribute with a time stamp and its driving me nuts that its not doing it

Within a workflow you could use an "Update" activity step

Add that to your workflow, which would look like this:

Open the properties of the "Change object Properties" and provide a name and description

Define the activity's target

Which if inside an Automation Workflow, would likely be "Object Found by search Activity"

Within Target Properties, click "Add Property" and select your Azure-Deprovision-DateTime attribute, the click "Define"

If you're just setting it to the current time and day, then choose "Workflow date and time", select the string format. and Use the current data and time

if you wanting to set it 45 minutes from the current time, then you'd probably need a script, which you'd reference by choosing "Value generated by rule expression"

Then you'd click "Add Entry" and select "Value generated by script"

The link the script and the function in the script to call

That script would need to return a valid value back to the workflow.

Hope that helps

Thanks mate. your suggestion has been mega helpful and its now stamping the account with the time. Slight snag though. I only want the time and in the date and time string I selected HH:mm but when I look at the attribute its date and time. The VA for the date and time is UTC. not sure if thats whats doing it.

So need to over come that and then explore this script section that you have said about 

Looks to be down to the syntax type, the attributes I tried this on were GeneralizedTime

I tried both just setting the date using the OOTB calculation and with script, both were populated with a UTC value in there:

Script

OOTB

The script I used was super basic

 function Return-Date()
 {
     [string]$Time = Get-Date -format HH:mm:ss
     
     return $Time
 }

Huuuuum might need to rethink some of this. It might not be an issue, but So UserA has a time stamp and then say 10 mins later UserB runs it then stamps both accounts with the same time as UserB. Might need to look at this a different way. 

Hi Craig

Depending on how the Automation Workflow is configured, you're correct. If you had no control/criteria for a set of users to be included in the setting of the date/time value, yes run 1 of the workflow might set "UserA" to 16:55, but Run  2 ten minutes later which now included "UserA" and "UserB" would set the time to 17:05

SO you might consider modifying the filter condition in your "Search" activity, to filter the objects returned by the search so that if AttributeA = "Deprovison" and "Azure-Deprovision-DateTime" is empty. Naturally your filter could be whatever condition you need.

Top man that works. On the filter i set the Azure-Deprovision-Date-Time attribute and set it to is empty. It now stamps only new accounts and leaves the originals as is. I am learning so much about ARS again today. 100% loving it. 

So now i have UserA and UserB and UserC all in the managed unit all with different times they were run. This is fantastic. I have another workflow that is searching for users in the same managed unit  and is running the deprovision step. I just need this to only run on accounts that have a time stamp 45 mins or more from the time the deprov runs. Anything that has been in there say 30 mins will get picked up on the next cycles. This is the bit i am 100% not sure on how to achieve.  Can you call the deprov process from a powershell script? 

Save yourself the headache of doing the time calculation and just drop the user from the Managed Unit once you have processed them by clearing the original VA?  Unless you need them to hang around?

Yes you can - Deprovision-QADUser cmdlet.

In your script activity, you would initially need to do the math on your timestamp attribute to determine whether the above command should be fired.

Just be sure you to structure script in such a way that it's intended to be run on each object returned by the search.

The way you get the object name for each iteration is like this:

$CurrentObjectFromSearch = $workflow.FoundObject("My Search Name").get("distinguishedName")

Hi mate. Yeah i need them to hang around long enough in that managed unit for the Azure AD connect sync to run which I think is every 30 mins. Thats why I just need that second workflow to only action accounts that have been in there for 45 mins or more.