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.

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

Reply Children