If you would like to be notified when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
If you would like to read the first part in this article series please go to Active Directory in the Cloud (Part 1).
Introduction
In this two-part article, we’re taking a close look at directory services in general and Azure Active Directory in particular, along with what Windows 10 will bring to the table in terms of integration with Azure AD. In Part 1, we covered the history and evolution of directory services in Windows, beginning with NTDS way back in Windows NT 3.1, all the way up to the advent of cloud-based directory services such as Azure AD.
Integrating your on-premises AD with Azure AD
“Hybrid network” has had many different meanings over the years. IT is an ever-changing field and the terminology changes with the technology. I remember back when hybrid network referred to one that included computers with different operating systems (both Windows and Linux servers, both Windows and Mac clients, etc.). Now in this age of BYOD, almost all networks support multiple computing platforms. To the infrastructure guys, “hybrid” once meant a network that combined both Ethernet and wi-fi client devices. Again, today that applies to the majority of business networks.
This is the era of the cloud – and most references to “hybrid network” mean a network that operates with a combination of on-premises and cloud-based services. This is also called a “hybrid cloud.” When you have an on-premises directory service along with an Azure subscription with Azure AD, you can integrate the two to simplify administrative tasks and manage both cloud and on-premises applications, identities and devices from one interface, and provide your users with an easier and smoother sign-in experience with single sign-on.
The first step is determining which type of directory synchronization is best for your organization’s needs. Your options include directory synchronization (DirSync) with password sync, DirSync with single sign-on, or multi-forest DirSync with single sign-on. These use the DirSync tool, which makes a copy of the local directory and then propagates to the Azure AD. You install DirSync on a server that is a member of the domain, either an on-premises server or one running in Azure.
Note:
Don’t confuse Microsoft’s DirSync with the open source utility called DirSync Pro, which is a synchronization and backup tool for Windows, Linux, Mac and other operating systems that run Java.
DirSync with password synchronization
This method will allow you to synchronize new users, contacts and groups that were created in the on-premises Active Directory automatically to Azure AD and sync incremental updates you make to existing accounts in your on-premises AD. You’ll also be able to set up a tenant for Office 365 hybrid scenarios (which I discuss in some detail in the article series titled Goodbye to on-premises Exchange over on our sister web site, www.cloudcomputingadmin.com). Users will be able to sign in and use their on-premises passwords to access the cloud services and you can enable cloud-based multi-factor authentication solutions (not on-premises). You’ll also be able to control the password policies from the on-premises AD.
DirSync with single sign-on
If you need a bit more functionality, then maybe DirSync with single sign-on is your best bet. With it, you can enable on-premises multi-factor authentication solutions and also ensure that user authentication occurs in the on-premises AD. You can implement single sign-on using corporate credentials, customize the user sign-in page and limit access to cloud services based on the location, client type or Exchange endpoint of the client.
Multi-forest DirSync with single sign-on
Multiple AD forests complicates matters when you move to the Azure cloud. Microsoft recommends that you set up single sign-on before you set up Active Directory synchronization using FIM 2010 and the Azure AD Connector. If you don’t, the account password won’t be synchronized with the account when an account syncs to Azure AD from the on-premises AD. You’ll need to deploy AD FS for single sign-on.
An important part of deploying multi-forest DirSync with single sign-on is to select a unique identifier for each user rather than use the AD objectGUID, in order to prevent duplication or ambiguity. This is essential in case a user is moved from one forest to another. This unique identifier should remain the same over the object’s lifetime, and must be populated in the Active Directory when the object is created. This unique identifier also must be retained if/when an object is moved from one forest to another.
Integrating your applications with Azure AD
There is a good chance that you might want some of your in-house applications to be able to use the Azure Active Directory for authentication. Before an application can do this, it has to be registered in a directory, so that Azure AD can communicate with it and send information after a user has been authenticated. If you want the application to be available to users in a different organization, then you’ll have to enable the application for extended access.
Registering an application with Azure AD is done via the Azure Management Portal. The process is pretty straight forward. After selecting Active Directory and then the applicable directory, you just click Applications and then Add an app, or take a shortcut and just click the Add button on the command bar. Follow the steps of the wizard, selecting to Add an application my organization is developing and entering the name of the application in the Tell us about your application dialog box. You’ll also need to enter the application type (web application and/or web API, or native client application). A native client application refers to an app that is installed on a phone or other device.
You’ll also need to enter the sign-on URL and App ID URI for web apps or the Redirect URI for native client apps. This is done on the App Properties page of the wizard. You can add options, depending on the type of application, then you can update it so that users can sign in or configure it so that users in other organizations can access it.
Multi-tenant applications
Multi-tenant applications are those that can be accessed by users outside of your organization (apps that only those in your org can access are called, logically enough, single-tenant applications). Single-tenant applications only have to be provisioned in one directory. Multi-tenant applications have to be provisioned in multiple directories. An SaaS application delivered by an SaaS provider is a multi-tenant application.
To make an application available to external users as a multi-tenant application, you have to update its application definition. You do this via the Azure Management Portal. When you select the application that you want to configure in Active Directory | Applications, expand the Configure multi-tenant application section and click Configure it now. Where it says “Application is multi-tenant,” just select Yes and then Save. That’s all there is to it on your end.
Now the users and admins in the other organizations have to grant access to your application. This can be done through a web sign-up page that uses Azure AD OAuth2.0 or OpenID Connect, where the application can get information about the new user. Web applications can also be constructed so that an administrator can sign up the whole company rather than individual users having to do so.
Windows 10 and Azure AD
In addition to the ability to become members of on-premises Active Directory domains as (some) Windows client operating systems have done for so many years, with Windows 10 Microsoft adds the ability to connect to Azure Active Directory. Users are able to log onto their Windows 10 devices with their Azure AD accounts. They can access business apps with their Azure IDs.
Windows 10 will also be optimized to work well within a hybrid on-premises AD and Azure AD environment. To join a Windows 10 device to Azure AD, you must first ensure that you’ve enabled Device Registration in your Azure Active Directory. To do this via the Azure Management Portal, you need to browse to your Azure AD and under Configure, select Yes for Enable workplace join.
Then you need to configure the settings on your Windows 10 device to enable it to connect to Azure AD. Note that the following instructions are based on preview code, so things could change before the final release of Windows 10. To do this, go to the System settings and under Join a domain, you’ll see the option to Connect to cloud. Choose this, and you’ll see a dialog box titled Cloud Experience Host. Click Continue on the first page and type in your Azure AD user name and password on the Set up Windows for this work or school PC page. Click the Sign in button.
You might be asked to update your password if this is your first time to sign in. After you do so, your device will be enrolled in the Azure AD and you should be able to see it listed in Devices in the Azure AD user account. The status should display as “Enabled” and the trust type as “AAD joined.” Now you can restart the Windows 10 device and log back in using your Azure AD credentials. You will need to enter a PIN; if you want a more complex PIN, you can uncheck Use a simple PIN.
Summary
Azure Active Directory gives users a seamless and simple experience working in a hybrid environment with almost any type of device and it gives admins more control and peace of mind with the ability to maintain secure integration between on-premises and cloud-based servers, apps and resources. In the months ahead, Microsoft will no doubt be fine-tuning the operation of Windows 10 and Azure AD to make it easier than ever for organizations to take some or all of their computing to the cloud.
If you would like to be notified when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
If you would like to read the first part in this article series please go to Active Directory in the Cloud (Part 1).
