I am often asked, what actually is this Azure-AD? I thought I could dedicate a blog series to this question, after all it is becoming more and more important. In this series, I will also write about authentication methods, types of identities and objects, licenses and compatible services. In short, everything about Azure Active Directory.
Articles on the Azure AD series
What is Azure-AD?
The Microsoft Azure-AD (also abbreviated to AAD) is an authentication service in the Microsoft cloud. It is operated globally and is highly available. A distinction according to geographical regions is not made for this service compared to other Microsoft cloud services. This service is used as the primary authentication option for the business cloud applications of Microsoft. A special feature is that it can be partially synchronized with the Local Active Directory. Synchronized and non-synchronized objects are treated differently. This brings us to the next topic:
Types of objects
The most important objects in the Azure-AD are the same as in an Active Directory inside your organization: Users, Groups, and Computers. The focus of the Azure AD is clearly on identity, for other functions Microsoft sees alternative solutions in the cloud.
What is missing from functions and objects?
Because Azure-AD is an identity-based product, it misses some of the functionality that is available in an enterprise Active Directory. For these functions, there are partly alternative products in Azure, but these are rarely identical. Here are a few examples:
There is an AzureDNS service, but it is aimed at public DNS zones and is not suitable for private zones. According to Microsoft’s idea, there are no private networks in an Azure-AD any more, but all are in the Internet.
What comes closest to the GPO in the Azure world are guidelines in the MDM solution Intune. They also contain a function based on the administrative templates.
Types of objects
Objects that exist from the local Active Directory on-premise can be synchronized into the Azure-AD. The objects can be limited, for example, only the members of a group are synchronized. But it is also possible to restrict the replicated attributes of the objects. This also enables data minimization by synchronizing only the required attributes and objects. The only difficulty with this idea is that there is no list of which service uses which attributes. At least I don’t know them, if you found such a list, please let me know.
Another special feature is that these objects must be maintained in the local AD, at least to the synchronized attributes. An example of this is the attribute “ProxyAddresses” which is also used by Exchange for e-mail addresses and aliases. The Exchange specific attributes are maintained in Office365 but in the cloud.
This can present the administration with a few challenges. Therefore I recommend to always use the PowerShell for hybrid scenarios. An example is the creation of new users, which I already described in the article “Creating Users Easily with PowerShell“.
However, there are also attributes that can be written back from the cloud if set up by the administrator. An example is a password, which can provide a way for users to reset their password themselves.
As far as login options are concerned, I will come back later to this topic.
THE CLOUD-BASED OBJECTS
In addition to the synchronized objects, I can also create purely cloud-based objects. These are completely managed in Azure-AD. The possible uses correspond to the synchronized ones. Only no SSO with company local accounts is possible, because the link with the local accounts is missing. More on this topic when it comes to authentication.
Typical scenarios are external employees who should use certain online resources, but not resources in the local infrastructure. There are also first companies that work completely without local IT and have everything in the cloud. Admittedly, only a few, because for most of them this way is not yet technically possible due to dependencies.
Another example of cloud-based objects is Azure-AD groups. These are used, for example, for teams or Office365 groups. There are also Dynamic Groups in Azure-AD that are used for example for Intune or Autopilot that are not synchronized to Local AD. Sometimes the right nesting with Local Groups can be one of the challenges. However, it is not possible to use it in Local AD for these groups.