• State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 4530 views
  • Users 0 members are here
Options
Related
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

david.jenkins-photomask.com
over 5 years ago

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.

Parents
  • 0 over 5 years ago

    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.

  • 0 over 5 years ago in reply to Richard.Lambert

    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.



Reply
  • 0 over 5 years ago in reply to Richard.Lambert

    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.



Children
  • 0 over 5 years ago in reply to david.jenkins-photomask.com

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

  • 0 over 5 years ago in reply to david.jenkins-photomask.com

    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.