Deprov - Sleep

Guys. 

I have a need for my deprovision policy to pause for 45 minutes. Let me give you some background so that it might help. maybe you have a better way of handling this?

We have onPrem AD and we synchronise our users up to Azure AD via the Azure AD connect application. 

I have a AR dynamic group that puts a user account in to a security group. This security group is then part of a Azure license. Just as an example Dynamic GroupA gives members access to MS Teams. 

Now what I need to happen during the deprov process is that it removes the user account from all security groups which it does. I then need it to wait 45 minutes until the Azure AD connect sync runs. This will then remove Azure user from the groups and give the license back to the pool. 

After 45 mins continue with the rest of the deprov process. 

Basically if we simply deprov and disable the account and the Azure Sync runs then the account is moved in to the Azure recycle bin for 30 days with all license still assigned. I see this post but i am unable to comment if a solution was found. 

 Pause/Wait in a script during deprovision? 

Thanks in advance for any suggestions. 

Parents
  • 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

     

  • Hi  I am actually going to look at this. Part 1 we have working now. 

    So part 1

    Custom command which sets a VA to TRUE. This put the account in the Managed Unit and removes the account from all the Azure groups. Within 30 mins Azure AD connect will run and do the Azure parts. 

    Now I think what you have suggested is the best way to look at running Part 2 which is the deprovision step. What i would like to do and i think its similar to your suggestion. I don't want to disable anything just yet. 

    However as a step of Part 1 I can have another attribute AD attribute and synchronise this to Azure AD via the AD Connect. That part is not a problem. The bit i am unsure about is your step 4. Are you saying i need an AD attribute and also AR VA? or is this custom VA already created? 

    If we can clarify step 4

    What i am thinking is that this VA that comes back as part of the back Sync is that i can link that to Managed Unit and then have the deprov work flow run every 20 mins or so. As if i am following right the account wont have the VA set until it comes back as part of the back sync. If this is correct then i am on to a winner with this. 

    Thanks for your help so and your suggestion. I think this is the best step

    Edit / Update 1: So I have the AD attribute from onPrem AD that I am now synchronising up to Azure AD via the AD Connect.

    Edit / Update 2: When i look in Sync Service I can see that i now have extension_GUID-HERE_Name-Of-My-onPrem-Attribute. I have Forward Sync rule from that attribute in to another AR VA. However when the Sync run the attribute does not get updated? Am i supposed to to the extension_ attribute in Azure AD as an attribute i can select? 

  • Edit / update 3. I’ve got this working now. When I setup sync service I must had set it up in a manual way. Went back and used the back sync wizard and everything made sense to me. Thanks for your help. I now have a solution that is based on sync times rather than me trying to second guess with sleep scripts. 

  • Hi Craig

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

    Some value you change in ARS, which is then written to Azure would be back-synced into an ARS Virtual Attribute, this is done to that their is a change to be picked up by Sync Services (that VA you write into doesn't need to be stored, as long as you have appropriate filtering to prevent the follow-on workflow from triggering every time it syncs some value from Azure back into QARS).

  • Thanks mate. Got all this setup and the back sync working perfectly. 

  • So let's say you set EA10 on prem to "Deprov".  AADC syncs this to the Cloud.  Your back sync then copies this back to a VA which your second workflow reacts to.

    That second VA needs to be stored or else your second workflow will keep getting triggered forever for the user.

Reply Children
  • I agree the second VA will continually be updated on every run of the Sync Workflow if the VA is not stored (unless the follow on workflow clears the first attribute), however if your start conditions of the workflow are produced in such a way that it excludes objects that are already deprovisioned, it would be good.