This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using AZure Integration

I'm having issues understanding some of the documentation.

I'm bascially stopped at Configuring BackSync.  What is this for?  The details do not help me understand what is happening.  What is being synced?  Accounts from Azure back to my AD?  Doesn't ADConnect already do some of this?

I'm also trying to understand how the integration with AzureAD works in Active Roles.  I'm confused from the start with account creation.  I'm almost scared to even try it.  It feels like I'm creating two different accounts.  The wizard for a new user starts with creating an AD account then has a checkbox for creating an Azure account.  I don't want to create two different accounts I want them to be the synced by Azure.  Is this in relation to the BackSync from above?  I would like to know where I can read more about this.

  • The explanations of "why" for the Azure integration is definitely lacking.

    The purpose of the back sync is to help Active Roles to associate on-prem objects with their Cloud equivalents.  So essentially what you are configuring is a copying of the unique identifier of each Cloud object into a virtual attribute of the corresponding on-prem object stored in Active Roles.  This is a non-destructive process and will have no negative impact on either the Cloud object or the on-prem one.  It will however enable the Admin service to reach out to the Cloud object to read its properties and show them to you in the web UI.

    The object creation process you describe is indeed a bit peculiar given the realities of customer environments (most people do use AADC to keep their on-prem and tenant environments in sync).  It was likely originally designed for use cases where AADC was not present and so the "normal" provision on-prem-and-let-AADC-replicate flow of things doesn't apply.

    I hope this helps you a bit.

  • So far I feel like I wasted the day reading documentation on software that has no practical use.  I don't understand the thought process behind the integration.  So far it wouldn't even be worth attempting to use to administrate azure.  I'm super disappointed in the integration.  Wish I could put more extra bigger unhappy faces.

    I did open a support case with the same information in it.  I'm hoping they are interested in explaining the product.

    So far it seems easier to not use the web interface and have admins use the Exchange Control Panel if they need to do anything in Exchange Online.

  • Hello, Active Roles currently supports hybrid environments. This means that there is both an on-premise object and a corresponding object in Azure AD. The back synchronization process is used to populate an on-premise object's Active Roles virtual attribute (edsvaAzureObjectID) with that object's Azure AD object ID. This Object ID will allow Active Roles to map these objects together when performing queries against the Azure tenant to get and set attribute data.

    Your understanding of the creation process is correct. An on-premise AD object will always be created and if selected to do so, Active Roles will create the corresponding Azure AD object. This process will populate the edsvaAzureObjectID automatically once the Azure object is created. If you do not wish to have Active Roles create the Azure object then there is no need to select the option to do so. You can continue using AADConnect to handle this. However, without the edsvaAzureObjectID populated you will lose the ability to have Active Roles populate/update changes made to certain on-premise AD attributes. I hope this helps explain some these process a little better.

  • So the edsvaAzureObjectID copies the objectGUID?  Is that sort of how the mS-DS-ConsistencyGuid works?

    I'm still confused by the usage of the product.  If I created an AD Account and checked the box to create an Azure Account wouldn't I end up with errors from ADConnect?  I'd end up with two objects in two locations.  Doesn't seem right.



  • There won't be an error because AADC will perform a soft match of the objects.

  • The Azure integration in Active Roles is intended to allow viewing and performing simple administration on both on-prem and Azure cloud accounts through a single pane of glass. This saves time and reduces the complexity of using multiple tools to confirm a User's current status. The major benefit of how Active Roles implements the Azure integration is that everything Azure-related that you see within Active Roles is a live, real-time query. There is no sync delay. There is no data inconsistency. The Active Roles Azure BackSync needs to populate only the User's Azure object ID. Once that is obtained, every other Azure attribute is retrieved using a targeted Microsoft Graph API call.

    Because Microsoft locks direct access to cloud accounts when AADConnect is in play, there are some limitations to what modifications can be performed. Changes sometimes need to be made on-prem and then synced to Azure using AADConnect. Even so, being able to see a User's cloud attributes in Active Roles and trust that is their up-to-the-second state a is very valuable feature.

  • The Azure object ID is a unique identifier for objects in Azure. It has no relationship with any on-prem attributes. Active Roles needs this value so that it knows which object to query in Azure.

    When Active Roles creates an Azure object, it will ensure that the object's immutableID is set properly. An Azure object's immutableID is the base64-encoded value of the on-prem objectGUID (or a value stored in Microsoft-DS-ConsistencyGUID). This is how AADConnect matches objects, so it will simply see that the on-prem account has a matching cloud account and create a linkage between them, rather than creating a duplicate.