In my last blog post here, I wrote an introduction to Azure Resource Manager (ARM). ARM is the toolset Microsoft has added to Azure for provisioning and controlling resources in Azure.
Azure Resource Manager (ARM) is Microsoft's platform for deploying and managing resources within Azure. ARM allows you to build resource deployment templates using PowerShell and JSON scripts to build repeatable and consistent deployments in Azure.
Since the introduction of Office 365, and even before that with the ironically named “BPOS,” Microsoft has had several different solutions for cloud identity management. These solutions have ranged from bad to confusing. The solutions that have been easy to use have lacked good functionality, and the solutions with enterprise functionality have been difficult and costly to deploy.
Consider the following scenario: you are about to implement directory synchronization for Office 365. You have multiple Active Directory sites across several, geographically dispersed, locations all over the world. Unsurprisingly, some of these locations have better connectivity than others and you might not want AAD Connect to connect to Domain Controllers in locations with a slow or high latency connection at the risk of slowing down the entire process.
When Azure AD Connect connects to a new forest, it uses DNS to locate domain controllers it needs to connect to. Without additional configuration, it is very difficult to control or know exactly which Domain Controllers AAD Connect will connect to. I believe that within the domain it is installed in, AAD Connect will try and connect to Domain Controllers within the same site first –but I’m still waiting on getting that confirmed. Even if that is true, that would not necessarily be the case for remote forests as there is no way for AAD Connect to know which site in the remote forest is closest.
Once AAD Connect is installed, you will find that it is relatively easy to define a (static) list of Domain Controllers that AAD Connect should connect to.
Welcome to the fifth part of this article series about Azure AD Connect. In the previous article, we've taken a look at some of the optional features you can enable for directory synchronization. In this article, we'll cover a few more features -- more specifically the User and Group write-back capabilities.
Before discussing these features, note that they are currently in preview. You can test the features, but should not use them in production unless you have explicit permission by Microsoft.
Now that the disclaimer is out of the way, let's have a look at the User write-back feature.
Welcome to the fourth part of this article series about Azure AD Connect. In the previous article, I discussed permissions for a custom installation, and we dived a little deeper into the upgrade capabilities. Before jumping into the 'advanced' customization options such the filtering abilities, I wanted to take a look at some of the additional (preview) features that Azure AD Connect offers to date.
Welcome to the third part of this article series about Azure AD Connect. In the previous article, I discussed the various custom installation options and the implications of using a separate SQL database.
Following that article, I received a few interesting questions that warranted some follow-up. More specifically, I had a few people call out that documentation regarding the required permissions for Azure AD Connect is scarce. Although the requirements are documented as depicted in the image below, I agree that there might be some confusion, depending on your deployment configuration.
In the previous part of this article series, we've taken a first look at Azure AD Connect and reviewed what a default installation looks like using the express settings. In this part, we'll dive deeper into the advanced options of the installation wizard. The express settings option likely meets the needs for most organizations looking into deploying directory synchronization alone. However, if you are looking at a more complex synchronization scenario, like a multi-forest environment or if you would like to deploy and configure Active Directory Federation Services, the advanced options are what you are looking for!
Note: The advanced options, especially the ones related to the advanced synchronization scenarios, are very powerful and can create potentially disastrous consequences. Even though we will be discussing the various options throughout the next few articles, do not attempt to make any changes if you are not completely familiar and comfortable with the option and its effects on your deployment and environment!
As reported earlier, Microsoft released Azure AD Connect to the public on June 24. The long-anticipated tool is the successor to Azure AD Sync and DirSync. But it’s much more than that.
Although a large part of Azure AD Connect still revolves around directory synchronization, I like to look at it more as a "Cloud Identity Enablement" — a solution rather than just a synchronization component. This is because Azure AD Connect not only allows you to deploy directory synchronization for almost every possible identity scenario you can dream of, but it also enables you to set up and configure identity federation through Active Directory Federation Services from within the same wizard.
Configuring identity federation for your Office 365 tenant consists of three key steps: