Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Bring identities from disconnected ADs into Azure AD with just a few clicks!
Published Dec 05 2019 10:30 AM 36.7K Views

Howdy folks,

 

Today we’ve got some amazingly cool news to share.

 

If you work in a large enterprise, you probably already know how big the challenges can be when your company makes an acquisition and you suddenly get asked to provide cloud identity services to an entirely new business group, usually one with their own set of Active Directory domains and forests.

 

If this is a challenge you face, I’m excited to let you know about the public preview of Azure AD Connect cloud provisioning!

 

With cloud provisioning, customers can easily provision identities from multiple disconnected AD forest to Azure AD. Azure AD Connect cloud provisioning moves the heavy lifting for provisioning from AD to Azure AD to the cloud with lightweight agents on-premises and provides the following benefits:

  • Helps with provisioning from disconnected AD forests to Azure AD—Organizations may have disconnected AD forests due to mergers and acquisitions or remote office locations. Whatever the reason may be, cloud provisioning allows you to quickly integrate these multiple disconnected AD forests into an Azure AD tenant.
  • Reduces on-premises footprint—The provisioning agent is a lightweight agent with the sync complexity (configuration and processing) in the cloud.
  • Enterprise grade high availability—Multiple provisioning agents can be deployed to ensure high availability for provisioning especially for password hash sync.

Give cloud provisioning a try

Setting up cloud provisioning is a two-step process. The first step is to install the lightweight provisioning agent on a domain joined server (or server VM). The second step is to configure cloud provisioning in the Azure portal.

Step 1: Install the provisioning agent

Before you install the Azure AD Provisioning agent, complete the prerequisites.

  1. In the Azure AD Connect experience, click Manage provisioning (preview).

    Azure AD Connect cloud provisioning 1.png

  2.  On a domain joined Windows server, click the Download agent button to download the Azure AD provisioning agent.  

    Azure AD Connect cloud provisioning 2.png
  3.  Follow the wizard steps to install the provisioning agent package.

    Azure AD Connect cloud provisioning 3.png

4. Once the agent is installed, you’re ready to configure provisioning in the Azure portal. 

Azure AD Connect cloud provisioning 4.png


Step 2: Configure cloud provisioning

  1. In the Azure AD Connect experience, click Manage provisioning (preview).

    Azure AD Connect cloud provisioning 5.png
     
  2. Click + New configuration.

    Azure AD Connect cloud provisioning 6.png

  3. Click Enable to apply the configuration.

    Azure AD Connect cloud provisioning 7.png

  4. Save the configuration. The AD changes are now provisioned to Azure AD every two minutes. For more guidance on how to get started, checkout the Azure AD Connect cloud provisioning tutorials.

 

Now that you’re familiar with cloud provisioning, let’s take a look at what features are currently supported.

Azure AD Connect cloud provisioning capabilities

Azure AD Connect cloud provisioning public preview supports the following capabilities:

Azure AD Connect cloud provisioning 8.png

 

To learn more, check out the Azure AD Connect cloud provisioning documentation.

Let us know what you think

We’re just getting started and would love to get your feedback on the current set of capabilities and what more you need. Please give us your feedback in our Azure AD UserVoice feedback forum or in the comments below. We look forward to hearing from you!

Best regards,

Alex Simons ( @Alex_A_Simons )

Corporate VP of Program Management

Microsoft Identity Division

38 Comments
Copper Contributor

Can we use this as another Azure AD connect as our HA strategy?

Microsoft

@Ron Argame  - This is a great scenario which we currently do not support. In the current co-existence model, the user must be in scope for only one tool (either sync or cloud provisioning).

Copper Contributor

@Nitika Gupta  Thanks for the reply. Will there be an option to have HA on Azure AD Connect? Having 300K+ objects to sync from on premise AD to Azure AD is really a big down time if you only have one Azure AD Connect (excluding the staging).

 

Can we replace Azure AD Connect with this?

Brass Contributor
Great work for the early stage. I see two pain point that should be addressed very quickly in order implement that at customers: 1. Support Sync of devices, otherwise we are not able to do hybrid AAD join of devices when using PHS/SSO 2. Support writeback of passwords, otherwise we cannot user Azure SSPR which is an requirement also to go password-less a smaller pain point is the support of synchronize nested groups because lot of customer have nested groups as they followed the good old onPrem AD "rules" and do AGDLP (or AGLP) ;)
Brass Contributor

I tried to configure this in my lab environment this morning and get an error when creating the provisioning task.

 

Cloud provisioning configuration
An unexpected error occurred. Please refresh and try again. Request id: b52590ef-ca33-405c-b089-37f1d096d75e, Time: 2019-12-06T10:15:19
Brass Contributor

I also get this error, but if I tried it again (save again), it worked.

Brass Contributor

Have tried quite a few times and still get the error, will keep trying.

Copper Contributor

Looks great and I have long been waiting for this!

Brass Contributor

Got it working after re-installing the provisioning agent

Brass Contributor

Would be great to have some technical deep dive documentation on this, so mainly how does the Connector work exactly, how does (if) the connector get the config on what to do. How does it read AD data and how is that written to AAD (seams to be SCIM from the binaries I found in the install folder)

Microsoft

@Richard Innes  - thanks for sharing the error details. We will investigate why it failed and improve the experience.

Microsoft

@Peter Stapf - Thanks for the feedback! We will get a technical deep dive document published soon. 

Microsoft

@Ron Argame  - We are just getting started with cloud provisioning. As we GA cloud provisioning and add more capabilities, you can evaluate if cloud provisioning meets all your feature needs and migrate from sync to cloud provisioning. 

Microsoft

@Peter Stapf - Thanks for the feature asks. Both password writeback and syncing computer objects to Azure AD are top of mind feature improvements for cloud provisioning. Keep the feedback coming!

Brass Contributor

What also comes to my mind is filtering, currently I see a lot of log entries of Type: Other with Status: failure.

I assume that are all the objects from AD that do not fit into the scope filter (OU based on my config).

Would be great if that filter already would work on the connector where you read the objects, so they will not transmitted to the sync engine in the cloud.

 

There might be lot of objects onPrem that never will synched to AAD, I have lots of customers that for example only need to sync 10-30 percent of all groups to AAD, there are also lots of service accounts onPrem never need an sync.

Good first option could be to configure an additonal OU filter on the connector, while later on the config done in AAD (filtering/scoping part) should be replicated down to the connector.

Brass Contributor

I’m hugely excited for this... as I have been since first hearing about it at Ignite.


One of the biggest challenges we face - and obviously we’re not alone - are merger / acquisition scenarios that involve distributed Active Directory environments. The prep work required to connect environments to a single AADC instance is often complex, and not always desired by organisations (who increasingly want to use the cloud to collaborate vs. traditional migration focussed coming togethers). This is such a significant step forwards in addressing, simplifying, and providing flexibility to organisations who face consolidation challenges. 

Thank you Identity team! :thumbs_up:

Copper Contributor

I am looking for documentation on how to enable seamless SSO with PHS in AAD Connect Cloud Provisioning. Can someone share a link?

Copper Contributor

Currently we sync users from multiple domains to AAD and all the users use the tenant.onmicrosoft.com usernames. I cant seem to see the source domain for a particular user in AAD. Would be great to have this capability in a production environment.

Brass Contributor

For SSO you can follow the steps of Resetting the SSO feature, but without the "Disabled" part.

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso#manual-reset-of-th...

 

But you need to extract the Azure AD SSO Module from an installation of AADC.

AzureADSSO.psd1

Copper Contributor

Great Feature, couple of questions so we can start to use it in production environment

 

  1. Estimated date on when device Sync for Hybrid Devices will be available
  2. Estimated date on when Password WriteBack will be available
  3. When is GA scheduled ?
Copper Contributor

Example:
A Company makes an acquisition and Azure AD is already in use there.
How can the aqirierte company be integrated?
Is there an Azure AD to Azure AD migration scenario?

 

Goal:
Subsidiary Company migrate Azure AD to Headquarters Azure AD
Subsidiary Company is integrated with AAD Connect Provisioning Agent

Copper Contributor

Hi,

The documentation clearly states that "Matching across forests does not occur with cloud provisioning". This would be a great feature.

 

Scenario:

Headquarter AAD already has users from all subsidiaries synced from HQ AD.

Now we would like to install Cloud Provisioning agents in the subsidiaries AD's to allow the subsidiaries users to use Seamless SSO & PHS.

They should use their existing User in HQ AAD though. So matching would be neccessary.

 

This would allow the subsidiaries users to access HQ On-Prem applications as well, using Citrix or AAD App Proxy for example.

Microsoft

@Peter Stapf  - good feedback on the provisioning logs and scoping. We are looking into product improvements to address the lack of clarity of the log entries of Type:Other. Also, we will document how scoping in our public documentation.

Microsoft

@MuellerMartin  - thanks for the feedback. To ensure I understand the ask, you'd like to see the source domain in the Azure AD user management experience, right?

Microsoft

@adalgeirsson - Unfortunately, I cannot share timelines for the feature improvements and GA.

Microsoft

@MuellerMartin  - This is a great use case. It will allow customers to not just enable PHS but also use Azure AD Premium features like self-service password reset (once cloud provisioning supports it). 

Brass Contributor

@Nitika Gupta coming back to one of my previous answers, I have a feature request:

The Azure-ADSSO (AzureADSSO.psd1) Module from AADC should be made available as a stand-alone module downloadable from the PS gallery.

So enabling Seamless SSO in Cloud Provision scenario without having an full AADC installed somewhere is made possible.

Of course some documentation enhancements on how to use them in Cloud Provision scenario.

 

/Peter

Copper Contributor

@Nitika Gupta 

Yes exactly. As long as users are not matched, there is the potential to have multiple users from multiple source domains for the same person. So visibility into the data source would be helpful.

 

Regarding the matching of users: Thanks for recognizing the use case. Do I understand correctly that you are planning to implement matching in the future?

 

Please think about groups in this context as well. In my case it would be great to have the user authenticate against the subsidiaries domain but use groups from HQ domain for authorization in the Azure Portal, Apps and so on.

 

@Peter Stapf thanks for your help, using AzureADSSO.psd1 worked great.

 

Copper Contributor

Password hash sync seems to be broken right now. Existing users work fine, new users do not get their passwords and password changes are not reflected.

Does anybody else experience issues?

Copper Contributor

@Nitika Gupta - Taking the current restriction "Matching across forests does not occur with cloud provisioning" takes me to the following asumption: in an Exchange Resource-Forest Scenario (central Exchange-Forest, connected with 10 User Forests) , Cloud Provisoining currently cannot help me to provision all the involved User-Forests, right?

Microsoft

@MuellerMartin - We will look into this issue for your tenant. 

Microsoft

@Reto Krebs  - We do not support the account-resource forest topology. Checkout the list of supported topologies here: https://docs.microsoft.com/en-us/azure/active-directory/cloud-provisioning/plan-cloud-provisioning-t...

Copper Contributor

I am currently testing the installation and configuration.

 

Install the Azure AD Connect cloud provisioning agent

Step 8 : "On the Connect Active Directory screen, select Add Directory. Then sign in with your Active Directory administrator account. This operation adds your on-premises directory. Select Next"

 

Question:  What are the smallest on-prem AD permissions that work? (With Password hash sync)

 

 

 

 

Copper Contributor

Is attribute filtering possible? I want to exclude the Exchange attributes (Exchange on-prem installation)

Microsoft

@namor38 - You can use Microsoft Graph API to remove the attribute that you do not want to sync. Check this out: https://docs.microsoft.com/en-us/azure/active-directory/cloud-provisioning/how-to-transformation

Copper Contributor

@Nitika Gupta  - Thanks for the info and link.

 

I understand correctly, that applies to Azure AD schema for provisioning.

I can't configure this for every cloud provisioning agent? 

 

I should be able to make the setting (exclude sync of Exchange attributes) for each agent since the migration scenario is not always the same.

Subsidiary sometimes with an Exchange and sometimes without an Exchange Server

Microsoft

In cloud provisioning, all the configuration is done in Azure AD. The agent is lightweight and stateless.

 

The schema updates are for a provisioning configuration and will only apply to the domain in scope. Each domain (subsidiary) can have their own configuration with different schema.  

Brass Contributor

Hi Team,

 

is it still in public review?

Version history
Last update:
‎Jul 24 2020 01:27 AM
Updated by: