AR Azure/O365 BackSync is disabled?

Is it required to have scheduled and running AR Sync Azure/O365 BackSync (GUIDs etc.) from AAD/O365 to onprem\AD objects (VAs) with AADConnect in place (AD/O365 Hybrid Mode)?

Is it supported scenario for AR by design?

IF AR BackSync Scheduled job is required THEN for which supported scenario:

1) Non Federated Domain (AADconnect is not configured)
2) Federated Domain (AADconnect and ADFS is configured)
3) Synchronized Identity Domain (AADconnect is configured)

(*) My customer got AR 7.4.3 with (3) Synchronized Identity Domain (AADconnect is configured) and AR BackSync jobs are disabled (not scheduled) at all, and it seems like there is no problem, so far.

thank you,

Aidar K.

  • I wouldn't say it is a "requirement" but if they are creating hybrid users outside of Active Roles and want to use Active Roles to help manage these hybrid users, then the back sync is required. As long as all hybrid users are being created through Active Roles, then I don't see a need for the back sync to run on a scheduled basis.

  • Yes, it's a requirement in a hybrid environment with AADConnect in play. It's most important in a Federated or Synchronized Tenant configuration, where most or all Azure-enablement is performed by AADConnect.

    Even in a Non-Federated Tenant, an administrator might be creating objects manually. I'd still recommend the Back Sync be configured to account for that.

  • - so your customer is able to examine Azure object properties through the Active Roles UI even though no back sync is configured?

    If yes, then I am wondering how this is possible for "legacy" objects - i.e. objects that were not created through Active Roles.  I have always understood that in order for AR to be able to display Azure properties, that the Azure Object GUID VA must be populated so that AR can find the object in Azure.  Typically, it is the back synch that does this.  Or so I always understood...

  • The edsvaAzureObjectId Virtual Attribute needs to be populated in order for Active Roles to query the rest of the object's Azure attributes. The Back Sync is the included method of doing this, but it could also be done via a custom method as well. One of my customers has AADConnect modified to write the Azure cloudAnchor to an attribute and has a Policy Script which grabs that attribute and inserts a modified value into edsvaAzureObjectId. They don't have the Back Sync configured.

  • That makes sense - I just wasn't sure if there hadn't been some kind of magical built-in policy added that had made the back-synch redundant.

  • You know... now that you mention it, it is entirely possible to replace the Back Sync with a custom policy in Active Roles 7.4.x. We just need to use the new "O365 script execution configuration" activity to tie into the configured Azure credentials, then periodically query Azure and update any on-prem objects which are lacking the edsvaAzureObjectId.

    Should be only a few lines of code.

    I'm going to test it out in my lab and see if I can get something working.

  • Seems like a good idea.  I would use a scheduled Automation workflow just to make it more visible.

  • I did not investigated deeply AR behavior against legacy AD objects with AAD/O365. 

    It is possible customer create AAD/O365 via AR provision only, or maybe and very possible, there is some issues with displaying AAD/O365 value in AR Website.

    Is is possible BackSync GUID sync is configured in ADConnect (as per Terrance comment below).

    At least the story is clear for me know.

    thank you!