Setting up and using Azure Active Directory
Twin Service
Azure Active Directory is Microsoft's centralized identity system for services in the cloud. The directory is certainly no longer intended just for in-house Office 365 systems like Exchange Online, SharePoint Online, or Lync Online; it also aims to facilitate the use of cloud services from other manufacturers. In this article, I will show you how to set up the service and synchronize local user data.
Microsoft officially released Azure Active Directory (Azure AD) for production use in September 2014. Now that the service has been available as a preview for several months, Microsoft is offering a commercial version with support services for the online directory.
In this article, I describe how Azure AD is configured, demonstrate what the directory can do, describe how to integrate it into an existing Active Directory infrastructure, and show how powerful the system is in conjunction with well-known software-as-a-service (SaaS) offerings – all of which will provide the overall picture needed to understand Azure AD.
Azure AD should not be seen as a blend of domain controllers (DCs) to be migrated and executed in Azure. Instead, Azure AD provides advanced authentication and connection (federation) services (ADFS) for both the Microsoft online product range and for other manufacturers' online offerings.
Federation is an important buzzword: Azure AD can be used for single sign-on (SSO) solutions with cloud software, if so desired. Other SaaS offerings can be used on the Internet once Azure AD is authenticated for the online directory. The trick behind this is that Microsoft prepared Azure AD and various interfaces in such a way that this SSO feature works with a variety of SaaS offerings.
Currently there are more than 2,500 software offerings, so chances are high that the desired software supports Azure AD. A significant advantage for users within a company is that if someone is sitting at the computer in the office and is connected to the local network, it is possible to access an application (e.g., Salesforce) without logging in again on one of the systems. One SSO login already occurred when logging into the domain – the connection with Azure AD handles the others.
Azure AD's second focus is on identity and access management. Access to applications can be controlled using group membership or access via certain company devices – optionally using a self-service feature for users or an approval process controlled by managers or application owners.
It quickly becomes clear that Azure AD is not a service that offers virtualized domain controllers on the Internet – or even copies all the domain controllers in the enterprise. Instead, Azure AD is a cloud-based identity solution with which selected objects from the local Active Directory can be synchronized.
Three Editions of Azure AD
Microsoft distributes Azure AD in three license types: Free, Basic, and Premium. Users of Office 365 automatically receive the Free license, so they can use their Cloud Office in standard scenarios, including directory synchronization and multifactor authentication (MFA). With the commercial Basic version, users receive a service-level agreement from Microsoft that promises 99.9 percent availability. Additionally, there is group-based access to applications and options for customizing the portal and login logos. The Premium license delivers the full range of functions: It supplies the administrator comprehensive usage reports, allows configuration of all MFA settings and makes them available to users, and can provide even more self-service functions.
Those who want to map complex identity scenarios should take a closer look at the Premium version, because it contains licenses for Microsoft's Identity Manager. The number of connected SaaS applications is therefore unlimited, although the number of licenses and the associated functions can be mixed arbitrarily. If you do decide to choose Azure AD, you can run any number of users as free users, whereas only some of the users are equipped with Basic or Premium. Depending on the usage scenarios, this approach provides flexibility and saves costs.
Office 365 customers can test Azure AD for 90 days, and Microsoft allows the Free offer to be extended to up to 100 users. For testing purposes, you can set up an Office 365 trial subscription, and you can upgrade Azure AD to a Premium trial version.
Keeping Data Synchronized
The directory must be populated with user objects to use Azure AD, to handle group memberships and connect with SaaS providers. The online directory supports two types of users: synchronized users from Active Directory and users who only exist in the cloud (and who are also created and managed there).
You need to set up synchronization between Active Directory and Azure AD, because SSO is only possible with accounts that have been upgraded from the local Active Directory to the cloud. The use of SaaS offerings is also possible for cloud-only users. In that case, however, the users have to remember two passwords: one for the local domain and logging in to the PC and one for their account in Azure AD. Users who only reside in Azure AD can connect to SaaS offerings.
As well as user accounts, you can also synchronize contacts and group objects from Active Directory. Microsoft recommends the tailored Azure AD Sync (AADSync) [1] for the synchronization. The tool is based on the foundations of Microsoft's Identity Manager, which is already used in some companies for synchronizing directory objects between different systems. However, AADSync is intended for the use of Office 365 and Azure AD. The required objects and attributes from the local AD can be quickly synchronized with the cloud without prior knowledge.
First, you need to enable synchronization in the Azure Management Portal. To do this, select the desired domain under Active Directory and then select Directory Integration . There, you can set the slider for Directory Sync to Activated . Click Save to apply the settings. Further steps that are interesting for synchronization are listed at the bottom of the page.
You need a service account with read privileges for the local AD and a global administrator account in Azure AD to install the sync tools. One feature in Azure AD is the option for users in the cloud to change their passwords – this self-service requires more privileges in the local AD to be able to change local accounts there accordingly. To execute the AADSync install, you need local administrator rights on the target server. AADSync stores the objects for synchronization in a database. The installer comes with an SQL Express database for this.
The Matching Database
If you want to synchronize more than 100,000 objects, including users, computers, and contact objects, you will need a full-blown instance of SQL Server – SQL Server 2008 up to and including 2014 are possible. SQL Express reaches its limits with a database size of 10GB, which corresponds to about 100,000 objects. Microsoft only provides support for more than 100,000 objects if the data is stored on SQL Server. The requirements for the operating system, however, are quite moderate: All server systems as of Windows Server 2008 are supported. AADSync only needs .NET Framework Version 4.5 and PowerShell 3.
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.