Devices have become cheaper and more affordable over the last few years and unsurprisingly proliferate: netbooks, laptops, smartphones, phablets, slates and tablets. Same is true for both cellular and wireless networks that have become ubiquities. Social networks (Facebook, Google+, Yammer, etc.) are changing how people get information and communicate. People want content and services to work seamlessly across these all these devices and environments. They are becoming connected all the time: at home, at work and everywhere in between… up to the point where personal and work communication can become indistinguishable.
As technology plays an increasingly important role in people's personal lives, it is having a profound effect on their expectations for and use of technology in their work lives. People have access to powerful and affordable personal computers, laptops, and tablets, are using mobile devices more and more, expect "always on" connectivity and are connecting with each other in new ways using social networks. Ultimately, they have more choice, more options, and more flexibility in the technology they use every day, and as that technology spills over into their professional lives, the line between personal and professional time is blurring. People want to be able to choose what technology they use at work, and they increasingly want to use that same technology in all aspects of their lives. In fact, according to a study by Unisys (conducted by IDC), a full 95 percent of information workers use at least one self-purchased device at work.
"Consumerization of IT" (CoIT) is the current phenomenon whereby consumer technologies and consumer behavior are in various ways driving innovation for information technology within the organization. As people become more comfortable with technology innovation in their personal lives, they expect it in their professional lives.
Without any doubt, employees as well as contractors will demand access with anything anywhere:
While CoIT has remarkable potential for improving collaboration and productivity, many organizations are grappling with the potential security, privacy and compliance risks of introducing consumer technologies into their environment. However, there are also many benefits to the CoIT trend that organizations can capitalize on with the right approach. Managing the CoIT challenge requires striking a balance between users' expectations and an organization's requirements. People love their consumer technology because it makes it easier for them to connect with each other, access and share information, and collaborate. Those same benefits are there for the taking for businesses.
Microsoft believes there is power in saying "Yes" to users and their technology requests in a responsible way – responsible meaning here that you embrace these trends but also ensure the environment remains secure and well managed.
Azure Active Directory (Azure AD) plays a central role in such a context to provide relevant technological answers for both corporate owned devices and personal devices in order to adequately and thus to smoothly accompany both corporate owned, personally enabled (COPE) and Bring Your Own Device (BYOD) initiates for organization of any size.
Azure AD is Microsoft's vehicle for providing Identity Management as-a-Service (IDaaS) capabilities in a cloud or hybrid environment. Microsoft's approach to IdMaaS for organizations of all sizes is deeply grounded in – and extends – the proven concepts of on-premises Active Directory (AD).
Active Directory (AD) is a Microsoft brand for identity related capabilities. Microsoft has earned widespread adoption of its on-premises identity technology, a suite of capabilities packaged and branded as Windows Server Active Directory (WSAD).
In the on-premises world, AD provides a set of identity capabilities. AD is used extensively by organizations world-wide. AD is widely deployed in the Fortune 1000 and the Global 5000 today as their authoritative identity and access management system as well as in small and medium organizations and we will not describe it further here.
Azure AD has been designed to easily extend AD (in whole or in part) into the public Azure cloud as a directory whose content is owned and controlled by the organization providing the information.
Azure AD is NOT a monolithic directory of information belonging to Microsoft, but rather, at the time of writing, more than three million different directories belonging to and completely controlled by different organizations.
This architecture and commitment is called "multi-tenant" and great care has been provided to insulate tenants (organizations) from each other and from their service operator – Microsoft.
Azure AD is the directory behind Microsoft Online Services subscriptions like Office 365, Dynamics CRM Online, Intune, etc. and is used to store user identities and other tenant properties.
Note For additional information on Azure AD, see the white paper Active Directory from on-premises to the cloud.
Azure AD lets you achieve all your Identity and Access Management needs in an easy to configure environment. With your Azure AD tenant, you can create a private identity directory in the cloud, similar to the look and feel of a traditional Active Directory from the user's perspective.
Like WSAD, your Azure AD tenant allows you centrally control access to applications and resources. You can easily add existing resources (cloud services and/or on-premises applications with the Azure AD Application Proxy, a feature of Premium edition of Azure AD) as well as integrate applications and APIs you are developing.
Note Azure AD is available in three different editions you can choose from: Azure Active Directory (free), Azure Active Directory Basic, and Azure Active Directory Premium. For a description of each edition below and a comparison table, see the Microsoft MSDN article Azure Active Directory editions. For more information on usage model, see the Microsoft MSDN article Azure Active Directory Pricing. For information on the usage constraints and other service limits for the Azure AD service per edition, see the Microsoft MSDN article Azure AD service limits and restrictions.
Your Azure AD tenant can be used as a standalone cloud directory or can be an extension of your on-premises identity and access management solutions to the cloud. In such cases, you can continue benefiting from your existing investments and on-premises capabilities while leveraging Azure AD to gain identity and access management in the cloud. You may hear these defined as cloud-only or hybrid Active Directory. This is the terminology we will use later in this document.
Windows 10 Pro, Windows 10 Enterprise, and Windows 10 Education editions enable a device to join an Azure AD tenant without needing the traditional WSAD domains on-premises if you want to. (Windows 10 mobile doesn't support this capacity as of this writing.) Both aforementioned cloud-only and hybrid Active Directory environments will be supported.
This provides a series of benefits for the end-users like a seamless Single Sign-On (SSO) experience to all the resources protected by your Azure AD tenant.
In addition, from an IT professional perspective, this allows to set rules and policies that control who has access and under what conditions. For example, you can require Azure Multi-Factor Authentication (MFA), and manage access based on the device.
Beyond those capabilities more devoted to corporate owned devices, personal devices will allow to add an Azure AD account in a BYOD context.
This document is intended as an overview document for discovering and understanding the benefits of using Azure AD and Windows 10 together for work and school accounts. As the introduction suggests, such an overview is given from both a corporate owned device perspective and a personal one in a BYOD context.
Built on existing Microsoft's documentation, knowledge base articles, and blog posts, this document provides a complete walkthrough to build a suitable test lab environment in Azure, test, and evaluate the above scenarios. It provides additional guidance if any.
This document is not intended as an overview document for the Azure AD offerings.
Note For additional information, see the Microsoft MSDN article Getting started with Azure AD. As well as the white paper An overview of Azure AD as part of the same series of documents.
Likewise, it doesn't provide either in-depth description nor detailed step-by-step instructions on how to implement a specific covered feature or capability. Where necessary, it instead refers to more detailed documents, articles, and blog posts that describe a specific feature or capability.
Note Please make sure you periodically check the Azure AD community forum as well as the MSDN Azure blog for notification of upcoming enhancement and changes that relate to Azure AD.
The same consideration applies to Windows 10 as well.
To cover the aforementioned objectives, this document is organized in the following four sections:
These sections provide the information details necessary to (hopefully) successfully build a working environment for the new capabilities enabled by combining Azure AD and Windows 10. They must be followed in order.
This document is designed for system architects and IT professionals interested in trying out the next version of Windows on behalf of their organizations. Some features and functionalities covered in this document may require additional hardware or software.
As already shortly introduced, Azure AD and Windows 10 bring new capabilities for corporate owned and personal computers and devices. The next sections will give you an overview of these new capabilities for both corporate owned devices and personal devices.
Note For additional information, see the webcast Microsoft Azure Active Directory and Windows 10: Better Together for Work or School.
First of all, Azure AD and Windows 10 together provide an evolution of the traditional WSAD Domain Join. Indeed, on domain joined computers, the connected Windows services (backup and restore, roaming of settings, live tiles and notifications, Windows store, etc.) work natively with work or school accounts. There will be no longer the requirement to use a personal Microsoft Account (MSA).
Windows 10 uses Azure AD as a relay to power these experiences, which means that organizations must have a hybrid Active Directory environment in-place and thus have connected their on-premises WSAD to Azure AD to make this happen. Both synchronization and federation models are supported in terms of identity model.
For organizations that do not have on-premises AD or do not use it for all their users (e.g. EDUs, seasonal workers, and temps): users are able to log on to Windows with their work account powered by Azure AD to enjoy single sign-on (SSO) from the desktop to Azure AD-backed applications and resources such as Office 365 and other organizational apps, websites and resources.
Auto-registration of these devices in Azure AD and auto-enrolment in an Azure AD supported Mobile Device Management (MDM) solution (Microsoft Intune, Mobile Device Management for Office 365, or 3rd party solution) are all supported. This is called Azure AD Join. With this new feature of Windows 10, Windows authenticates directly to Azure AD, and no WSAD domain controllers (DC) are needed. You can enjoy a cloud-only environment and this only requires that your organization provisions an Azure AD tenant.
This also works on mobile devices that do not have Domain Joined capabilities, and it works for managed and federated Azure AD accounts. This makes it easy for information workers to use their existing work credentials to log in to phones, tablets, and phablets that are owned by their organization and rehydrate their personalized work environment on these secondary devices.
Users are also allowed to set up shrink-wrapped Windows devices with their work or school account (managed or federated in Azure AD) and configure them as corporate-owned assets right in the Windows first run experience, a.k.a. out-of-box experience (OOBE), without the need for IT to spend time and money on device imaging. IT have the choice between imaging and allowing the corporate users to configure corporate owned devices by themselves during OOBE.
Note For additional information, see the blog posts Azure Active Directory and Windows 10: Bringing the cloud to enterprise desktops!, Azure AD joint on Windows 10 devices, Managing Azure Active Directory joined devices with Microsoft Intune, Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility, and Windows 10, Azure AD and Microsoft Intune: Automatic MDM enrollment powered by the cloud.
Azure AD Join described in the previous section is for computers and devices owned by your organization and is NOT a replacement of Workplace Join. In Windows 10, the Workplace Join world of Windows 7 and Windows 8.x is now replaced by the ability to add a work account to Windows.
For personal computers and devices, this new provided feature will be making Bring-Your-Own-Device (BYOD) simpler and more powerful. Users are able to add their work or school account to an application, and make this account available to other applications and web sites. Moreover, adding a work or a school account to a Windows 10 device also both registers and enrolls the device in MDM (if configured), all in one step. Think of this as "Workplace Join on steroids".
Compared to the previous section, both "Azure AD Join" and "add a work account to Windows" register the device in the directory but devices are respectively marked as "Azure AD joined" or "Workplace joined" (deviceTrustType attribute in the device object), which can be then used in turn for conditional access. In the former case, this helps providing guidance to IT that the device is corporate-owned and they can apply full management on the device. This is as opposed to the latter case, where IT makes the assumption that the device is a personal device and may apply lighter management in recognition of personal ownership.
With the above, user of a personal device enjoys SSO to work resources, via apps and on the web. This enables to build apps that cater to both enterprise and personal contexts with shared programing stack.
Note For additional information, see the blog post Azure AD on Windows 10 Personal Devices.
In both corporate owned and personal device cases, it's easy to configure additional accounts, both work or school and personal, on a Windows 10 device. This includes adding a personal MSA on a work device or a work or school account on a personal device.
This is enabled in a way that makes compliance much easier and reduce user confusion about which data is work vs. play. For example, users may be able to add their personal MSA to a domain joined computer to enable SSO to their personal resources (e.g. personal OneDrive) while connected Windows services continue to be backed by the user's work account in WSAD/Azure AD.
As its title suggests, this section guides you through a set of instructions required to build a representative test lab environment that will be used in the next section to configure, test, and evaluate the new capabilities introduced by Azure AD and Windows 10 in various situations.
As we keep mentioning Azure AD from the beginning of this document, you won't be surprised by the need to have an Azure AD tenant provisioned. Let's start with that.
An Azure AD test tenant can be created through a Microsoft Azure Subscription.
Note You can sign-up for your free Azure AD tenant and trial Azure account by following the link https://account.windowsazure.com/signup?offer=MS-AZR-0044P.
The first user you generate as part of the sign-up process based on the fields below will also be an administrator of the directory. This user will be declared in the default domain of the directory tenant <domain name>.onmicrosoft.com. You will sign in to Azure with this account.
However, the easiest way to provision both an Azure AD tenant and a Mobile Device Management (MDM) environment for the purpose of the test lab certainly consists in signing up to a Microsoft Office 365 Enterprise tenant.
Indeed, such an approach enables to leverage the MDM features built in to Office 365. Thanks to these MDM features, you can view an inventory of all enrolled devices that connect to your organization, create and manage device security policies, remotely wipe a device, and view detailed device reports. These MDM capabilities built in to Office 365 are powered by Microsoft Intune, the Microsoft comprehensive device and app management solution for devices.
Note For more information on Mobile Device Management for Office 365, see the Microsoft TechNet article Overview built-in Mobile Device Management for Office 365 as well as the blog posts Introducing built-in mobile device management for Office 365 and Built-in mobile device management now generally available for Office 365 commercial plans.
Important note Organizations that need protection beyond what's included in Office 365 can subscribe to Microsoft Intune and get additional device and app management capabilities. The built-in MDM for Office 365 service, the advanced protection available with Microsoft Intune, or a combination of the two may be right for your organization depending on your needs.
To sign up to a free 30-day Microsoft Office 365 Enterprise E3 trial, follow the instructions at http://office.microsoft.com/en-us/business/redir/XT104175934.aspx.
Note For more information, see the article Sign in to Office 365.
For the course of this walkthrough, we've provisioned an Office 365 Enterprise (E3) tenant: litware369.onmicrosoft.com. You will have to choose in lieu of it a tenant domain name of your choice whose name is currently not in use. Whenever a reference to litware369.onmicrosoft.com is made in a procedure, it has been replaced by the tenant domain name of your choice to reflect accordingly the change in naming.
The on-premises test lab environment allows to test scenarios that pertains to a hybrid Active Directory environment such as:
If you are not interested in the above listed scenarios, you can skip this section.
Every walkthrough that may require this optional on-premises test lab environment later in this document will have an explicit mention for this dependency and in addition will be explicitly identified as "Optional".
A hybrid Active Directory environment implies as its name suggest a cross-premises configuration between WSAD and Azure AD.
Considering the involved services, products, and technologies that encompass such a cross-premises configuration, the test configuration should feature:
The following diagram provides an overview of the overall test lab environment with the software and service components that need to be deployed / configured.
A challenge in creating a useful on-premises test lab environment is to enable their reusability and extensibility. Because creating a test lab can represent a significant investment of time and resources, your ability to reuse and extend the work required to create the test lab is important. An ideal test lab environment would enable you to create a basic lab configuration, save that configuration, and then build out multiple test lab scenarios in the future by starting with the base configuration.
Moreover, another challenge people is usually facing with relates to the hardware configuration needed to run such a base configuration that involves several (virtual) machines.
For these reasons and considering the above objectives, we have tried to streamline and to ease as much as possible the way to build a suitable test lab environment, to consequently reduce the number of instructions that tell you what servers to create, how to configure the operating systems and core platform services, and how to install and configure the required core services, products and technologies, and, at the end, to reduce the overall effort that is needed for such an environment. Thus, this document will leverage the Microsoft Azure environment along with the Azure PowerShell cmdlets to build the on-premises test lab environment to test and evaluate the above scenarios at the beginning of this section.
We hope that the provided experience will enable you to see all of the components and the configuration steps both on-premises and in the cloud that go into such a multi-products and services solution.
Once you have signed up and established your organization with an account in Office 365 Enterprise E3, you can then add an Azure trial subscription to your Office 365 account. This can be achieved by accessing the Azure Sign Up page at https://account.windowsazure.com/SignUp with your Office 365 global administrator account. You need to select Sign in with your organizational account for that purpose.
Note You can log into the Office 365 administrator portal and go to the Azure Signup page or go directly to the signup page, select sign in with an organizational account and log in with your Office 365 global administrator credentials. Once you have completed your trial tenant signup you will be redirected to the Azure account portal and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.
Note This notably enables you to empower your Office 365 subscription with the access management and security features that Azure AD is offering. While there are and will be ongoing investments in the Office 365 management portal, rich identity and access management capabilities are and will be exposed through the Active Directory section in the Azure management portal first. For example, the Application Access Enhancements for Azure AD, which provides a streamlined access to thousands of cloud SaaS pre-integrated applications like Box, GoToMeeting, Salesforce.com and others, (and even and more in the coming months,) can be only managed today by accessing the directory through the Azure management portal.
At this stage, you should have an Office 365 Enterprise E3 trial subscription with an Azure trial subscription.
The whitepaper Azure AD/Office 365 Single Sign-On with AD FS in Windows Server 2012 R2 - Part 2bis fully depicts the setup of such an environment.
In order not to "reinvent the wheel", this document leverages the instrumented end-to-end walkthrough provided in the above whitepaper to rollout a working single sign-on configuration for Azure AD/Office 365 with AD FS by featuring the Azure Active Directory Connect (Azure AD Connect) tool.
Note Azure AD Connect provides a single and unified wizard that streamlines the overall onboarding process for directory synchronization (single or multiple directories), password sync and/or single sign-on, and that automatically performs the following steps: download and setup of all the prerequisites, download, setup and guided configuration of the synchronization, activation of the sync in the Azure AD tenant, setup, and/or configuration of AD FS – AD FS being the preferred STS, etc. Azure AD Connect is intended to be the one stop shop for sync, sign-on and all combinations of hybrid connections.
For additional information, see the blog post Azure AD Connect & Connect Health is now GA!, and the Microsoft articles Integrating your on-premises identities with Azure Active Directory and Azure Active Directory Connect.
By following the instructions outlined in this whitepaper along with the provided Azure/Windows PowerShell scripts, you should be able to successfully prepare your Azure-base lab environment based on virtual machines (VMs) running in Azure.
Important note Some more advanced features may specifically require Windows Server 2016. When available, this document will be updated in accordance to reflect such dependencies. As of this writing, Windows Server 2016 is a prerelease software. You can start investigating Windows Server 2016 Technical Preview 4.
Important note Individual virtual machines (VMs) are needed to separate the services provided on the network and to clearly show the desired functionality. This being said, the suggested configuration to later evaluate the "Azure AD Join" is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab networking environment.
Any modifications that you make to the configuration details provided in the rest of this document may affect or limit your chances of successfully setting up the on-premises collaboration environment that will serve as the basis for the previously outlined scenarios.
Microsoft has successfully built the suggested environment with Azure IaaS, and Windows Server 2012 R2 virtual machines.
Once completed the aforementioned whitepaper's walkthrough, you'll have in place an environment with a federated domain in the Azure AD tenant (e.g. litware369.onmicrosoft.com), the whitepaper has opted to configure the domain litware369.com (LITWARE369). You will have to choose in lieu of a domain name of your choice whose DNS domain name is currently not in used on the Internet. For checking purpose, you can for instance use the domain search capability provided by several popular domain name registrars.
Whenever a reference to litware369.com is made in a procedure later in this document, it has to be replaced by the DNS domain name of your choice to reflect accordingly the change in naming. Likewise, any reference to LITWARE369 should be substituted by the NETBIOS domain name of your choice.
The Azure-based test lab infrastructure consists of the following components:
Note Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft TechNet Windows Server 2012 R2 homepage.
The above VMs expose one public endpoint for remote desktop (RDP) and another one for remote Windows PowerShell (WinRMHTTPS) as illustrated hereafter.
The EDGE1 VM exposes in addition a public endpoint for HTTPS (HttpsIn).
These VMs will enable you to create snapshots so that you can easily return to a desired configuration for further learning and experimentation.
The integrated test lab consists of:
For the sake of simplicity, the same password "pass@word1" is used throughout the configuration. This is neither mandatory nor recommended in a real world scenario.
To perform all the tasks in this guide, we will use the LITWARE369 domain Administrator account AzureAdmin for each Windows Server 2012 R2 VM, unless instructed otherwise.
The base configuration should now be completed at this stage if you've followed the whitepaper's walkthrough.
To avoid spending your credit when you don't work on the test lab, you can shut down the 3 VMs (DC1, ADFS1, and EDGE1) when you don't work on the test lab.
To shut down the VMs of the test lab environment, proceed with the following steps:
To resume working on the test lab, you will then need to start in order the DC1 computer, then the ADFS1 one, and finally EDGE1.
To start the VMs of the test lab environment, proceed with the following steps:
You are now in a position to notably configure the Azure AD Join capability with federated identities thanks on your on-premises test lab environment.
The new Azure AD Join feature notably illustrated in this document requires Windows 10 Pro or Windows 10 Enterprise editions. Windows 10 Home isn't able to join a domain. Each version works with a different identity provider with the Professional version straddling both the Microsoft Account (MSA) and the "Azure AD Join" world with the Work or School account in Azure AD:
Important note The above does not mean that Pro and Enterprise cannot join a traditional WSAD domain on-premises in the traditional manner. During the out-of-box experience (OOBE) illustrated later in this document, you can bypass Azure AD Join, create a local account, and join your device in the traditional manner.
To build a Windows 10 Pro edition ISO file, proceed with the following steps:
Important note As stated on the page, you will need Windows product key. For information about product keys and when they are required, see Frequently Asked Questions.
Note For additional information, see Installing Windows 10 using the media creation tool.
To ease the evaluation of the various user experiences, we advise building an individual virtual machine (VM) with the technology of your choice. For that purpose, this document will leverage the Hyper-V virtualization technology as available in Windows and Windows Server products, and more specifically Client Hyper-V.
Note The Windows 8.x Client Hyper-V enables to run more than one 32-bit or 64-bit x86 operating systems at the same time on the same host computer. But instead of working directly with the computer's hardware, the operating systems run inside a VM. Client Hyper-V is the same computer virtualization technology that was previously available in Windows Server. In Windows 8.x, the technology is built into the non-server version of Windows, often called the "desktop" version because it does not run on server-class hardware. Client Hyper-V provides the same virtualization capabilities as Hyper-V in Windows Server 2012 (R2). For additional information on Client Hyper-V, please refer to the eponym Microsoft TechNet article Client Hyper-V.
For the sake of brevity, we do not illustrate how to create such a virtual machine via the ISO file download in the previous step.
Note For information on how to create a virtual machine with the Client Hyper-V, see the Microsoft TechNet article Install the Hyper-V role and configure a virtual machine.
The rest of the document supposes that you have an up and running Windows 10 virtual machine with an Internet connectivity along with adequate Name/IP resolution.
This walkthrough provides instructions for testing the new capabilities provided for corporate owned devices for joining Azure AD. As already noticed, joining a Windows 10 device to Azure AD allows you to simplify Windows deployment and access to your organizational apps and resources from that corporate owned device. This represents a new way to configure and deploy corporate owned Windows devices.
With Azure AD Join, a new feature of Windows 10, Windows authenticates directly to Azure AD, and NO WSAD Domain Controller (DC) are needed unless you want to use one of course. For that reasons, and as previously covered, two models are provided to organizations:
This section covers the two models.
Please ensure that all the prerequisites mentioned earlier in section Building a test lab environment are fulfilled at this stage.
Indeed, whilst the former model only supposes that you've provisioned your Azure AD test tenant – unless you'd like to conduct some testing with a federated identity -, the latter requires and leverages the optional "on-premises" test lab environment deployed in Azure as per section entitled Building an on-premises test lab environment (Optional).
Before considering these two models, let's start by configuring the common settings for the Azure AD test tenant.
Joining a corporate owned device to your Azure AD tenant requires in addition the followings:
The next sections guide you through the related steps.
For an Azure AD user to be able to join their Windows 10 device to the Azure AD tenant (regardless of the chosen identity model (e.g. cloud identity, synchronized identity or federated identity), an IT professional must configure the Azure AD Device Registration Service.
Note For additional information, see the Microsoft MSDN article Azure Active Directory Device Registration Overview.
To configure the Azure AD Device Registration Service via the Azure management portal, proceed with the following steps:
Note Enrollment with Mobile Device Management for Office 365 (or Microsoft Intune or) requires Workplace Join. If you have (already) configured either of these services, ALL is selected for USERS MAY REGISTER THEIR DEVICES WITH AZURE AD.
As stated in the previous section, enabling multi-factor authentication for the Azure AD Device Registration Service requires a prior configuration of the related solution.
The configuration depends on the option you've opted for your test lab environment:
Specifics instructions are provided in the Microsoft MSDN article Adding Multi-Factor Authentication to Azure Active Directory as well as in the whitepaper Leverage Multi-Factor Authentication with Azure AD as part of the same series of documents on Azure AD available on the Microsoft Download Center.
Note For additional information, see the Microsoft TechNet article Using Multi-Factor Authentication with Active Directory Federation Services.
Beyond the above links to the relevant documentation, this document doesn't further illustrate the related configuration. For the sake of brevity, we do not illustrate this optional feature in the "Azure AD Join" process.
By default, Mobile Device Management for Office 365 is not activated when you sign up for your Office 365 account. To activate and setup Mobile Device Management for Office 365, proceed with the following steps:
Note For additional information, see the Microsoft TechNet article Overview built-in Mobile Device Management for Office 365 along with Manage mobile devices in Office 365.
Note For additional information, see the Microsoft TechNet article Create and deploy device security policies.
If you don't have a custom vanity domain associated with your Azure AD/Office 365 subscription, you can skip this section.
This is the case in the suggested test lab environment if you've decided not to implement the optional steps outlined in section Building an on-premises test lab environment (Optional). In this case, you only have the default domain (e.g. litware369.onmicrosoft.com in our illustration).
Otherwise, if you've rather opted to configure the equivalent of the vanity domain litware369.com (LITWARE369) in our illustration with the domain name of your choice whose DNS domain name that is currently not in used on the Internet, you'll need to add DNS records for the domain at your DNS host.
If you've added the records already, you're all set. After you add these records in your domain registrar, users in your organization who sign in on their device with an email address that uses your custom domain can register to your Azure AD tenant and then be redirected to enroll in Mobile Device Management for Office 365.
To add these record, proceed with the following steps:
To create a test user, proceed with the following steps:
Our new user email@example.com is created and we have our temporary password. You can copy and paste the password from here or email it to the user.
Note Passwords emailed from this screen are sent as clear text and may not be secure. In a production environment, encourage the user to change their password as soon as possible.
Note If you would like to test the accounts before evaluating the new capabilities in Windows 10 in the rest of this document, try logging on to http://manage.windowsazure.com with the new account and test. If this is the first time you have used the account, you will be prompted to change your password.
If you'd like to optionally configure a multi-factor authentication, you'll have to allow the users to prove who they say they are when performing the "Azure AD Join" process. If so, proceed with the following additional optional steps:
Your Azure AD tenant (along with additional services) are now configured at this stage. This allows a user to join their Windows 10 device to Azure AD.
This section provides instructions for configuring and testing the "Azure AD Join" model for corporate owned devices.
As already noticed, joining a Windows 10 device to Azure AD allows you to simplify Windows deployment and access to your organizational apps and resources from that corporate owned device. This represents a new way to configure and deploy corporate owned Windows devices.
As Windows authenticates to Azure AD in the cloud, one should note that this model works with both cloud and federated identities. As far as the latter is concerned, it requires and leverages the optional "on-premises" test lab environment deployed in Azure as per section Building an on-premises test lab environment (Optional). In this case, the authentication is delegated to the on-premises identity infrastructure
The next sections guide you through these two scenarios and their pre-requisites if any and describe in the context of our test lab environment each of these related steps.
This section will take what you've learned and configured so far and build upon it by demonstrating how you can join a Windows 10 device to your corporate owned Azure AD tenant. As you will see, this brings significant flexibility and cost savings to the deployment process within the organization. End-users will be able to automatically Azure AD join during the initial startup experience, i.e. the out-of-box experience (OOBE), which will register the device in the organization's Azure AD tenant and enroll it in their Mobile Device Management (MDM) solution, for example Mobile Device Management for Office 365 in our configuration.
As a reminder, only Pro and Enterprise versions of Windows 10 can join Azure AD. The experience will be slightly different for both. See later in this section.
This section requires a new installation of Windows 10 so you can walk through the out-of-box experience (OOBE).
Note Based on the image you may have built as part of the setup of the test lab environment, you can manage the various installations suggested in this document by leveraging for instance the checkpoints features of the Client Hyper-V environment on your local Windows machine.
A sign-in to the Azure AD tenant will automatically authenticate cloud users. For this to work, this new installation of Windows 10 will simply need an Internet connectivity with Name/IP resolution.
With all the above in mind, let's walk through the out of box experience (OOBE). Proceed with the following steps:
The above two options and depending upon your choice will determine what resources you can access:
The above two options and depending upon your choice will determine how to connect Windows 10 to your organization:
Note This would be a good place to create a checkpoint of your virtual machine in the event you make a mistake or would like to see what a mistake looks like.
Windows 10 registers the device in the organization's Azure AD tenant and enroll it in the MDM solution.
Note Some organizations may choose to download apps and policy as part of the "Azure AD Join" process, once the device is enrolled in the MDM solution, and as per solution features.
| || |
| || |
| || |
We illustrate here the latter one. You can off course select the one that is the most appropriated in your own context.
Note The Azure Authenticator allows you to secure your account with two-step verification. With two-step verification, you sign in using something you know (your password) and something you have (your mobile device). For additional information on Azure Authenticator app, see the blog post Try the new Azure Authenticator application!,
Note Microsoft Passport, formerly called Next Generation Credentials or NGC constitutes a long-term initiative for Microsoft to aid in securing credentials making Windows 10 the most secure Windows Microsoft have shipped. Microsoft Passport is specifically to remove the need to enter user name and passwords for all compliant websites, applications, and resources. For that purpose, Microsoft Passport seeks to change the raw user credential from a symmetric, memorized secret to an asymmetric, hardware (TPM 1.2 or 2.0) bound or software (based on policy) key. Unlocking this key with a gesture will provide users access to resources without using passwords. Supported gesture are PIN as well as biometric gestures with Windows Hello, a new feature of Windows 10.
For the IT professional, Microsoft Passport means an ability to get strong authentication guarantees similar to virtual smart cards from both corporate-owned (and personal, a.k.a. BYOD) devices, with a significantly reduced deployment and management burden. Microsoft Passport adds the ability to manage various aspects of this, such as PIN complexity and reset.
From a technology perspective, Microsoft Passport is a container of keys. The keys and container are managed as securely as the platform permits, which means hardware-bound where possible. Each key requires authentication at key-specific intervals (ranging from per transaction to once every set amount of time). The keys stored in the Microsoft Passport container will be used to authenticate at a supported Identity Provider – like Azure AD and WSAD in Windows Server 2016 Technical Preview 4 or a non-Microsoft service that supports the FIDO 2.0 Technical specifications of the Fast IDentity Online (FIDO) Alliance - in this manner, not requiring the users to type in their passwords.
For additional information on Microsoft Passport, see the blog post Microsoft Passport and Azure AD: Eliminating passwords one device at a time!, the Microsoft MSDN article Microsoft Passport overview the webcasts The End Game for Passwords and Credential Theft?, and Secure Authentication with Windows Hello.
Note For additional information, see the blog post Azure Active Directory and Windows 10: Bringing the cloud to enterprise desktops!.
The main difference with the previous section lays in the fact that a sign-in to the Azure AD tenant will automatically authenticate federated users with their on-premises corporate identity infrastructure. For this to work with our on-premises test lab environment, the computer will need the following:
Important note Administrator have the ability to require a multi-factor authentication (MFA) of the end-users during a device registration process such the "Azure AD Join" or the "Add a work account to Windows" (Workplace Join).
These settings are configured using the Azure AD extension in the Azure management portal if you recall the REQUIRE MULTI-FACTOR AUTH TO JOIN DEVICE setting earlier in this document. There are separate policies for allowing users to perform "Azure AD Join" or "Add a work account to Windows") but the MFA policy is global for all device registration processes.
Using MFA during the OOBE join experience WILL FAIL with a federated account if a Federation Property flag called SupportsMFA is set to true.
(When this flag is set to true, a second factor authentication – in addition to the password - is expected to be performed by the organization's identity infrastructure on-premises. Conversely, if the flag is set to false then the second factor authentication is rather expected to be performed by Azure MFA service. Likewise, if the flag is not set, it is assumed to be false. This flag is set with the Set-MsolDomainFederationSettings cmdlet.)
In such situation (SupportsMFA == true), the Azure AD Join will NOT complete. This is because the on-premises multi-factor authentication server is attempted to be used rather than the Azure MFA service.
Let's walk through the out of box experience (OOBE). Proceed with the following steps:
You are then automatically redirected to your on-premises identity infrastructure.
In our optional configuration for the test lab environment, the AD FS sign-in page is then displayed after a successful redirection.
If the user doesn't have network connectivity during OOBE, and wants to join the corporate owned device to Azure AD once a network is available, the user can leverage the system Settings.
Note There will be also times when the above OOBE domain join experience may fail for some reasons and in lieu of a local account may be created. Should the process fail, on should note that there is a hidden command that can be used to allow access to the event logs. During OOBE, pressing Shift F10 will launch a command window that allows simple shell commands to be executed. This will require the machine to be rebooted, because the command is only available on the first screen. Once the command window is open, normal connectivity tests can be performed as well as launching the Event Viewer. Test the network connectivity and troubleshoot as normal, using the errors in the event logs as a starting point.
To joining a device to Azure AD from the system Settings proceed with the following steps:
A standard dialog to create a local account begins. Like earlier versions of Windows, administrator is a reserved account so choose your first name and a password that you will remember.
Important note You cannot be a member of two domains. If your device is already a member of a traditional WSAD domain, following the Join Azure AD dialog will result in an error and be logged in the netsetup.log file.
Regardless of the above methods used to join the corporate owned device to Azure AD, the user can actually use their Azure AD work or school account during their normal logon. Windows 10 uses then Azure AD to authenticate the user for login.
Note If network connectivity is not available at that time, Windows 10 will use cached credentials, assuming that there is no policy applied that prevents it. The access will be available as long as the token has not expired.
To sign-in with your Azure AD work or school account, proceed with the following steps:
The user will enjoy the following benefits:
Note SSO to resources protected by Azure AD like Office 365 or even on-premises resources via Azure AD Application Proxy does not requires any specific deployment in the on-premises. In absence of Azure AD Application Proxy, the user will also enjoy SSO to modern applications on-premises that trust AD FS (not Kerberos-based). This will require AD FS in Windows Server 2016 in order to adequately leverage the Primary Refresh Token (PRT) issued by Azure AD after a successful logon. The PRT can be seen as the cloud "equivalent" of the well-known Kerberos Ticket Granting Ticket (TGT) in the on-premises. For more information on the next version of AD FS, see the webcast What's New in Active Directory Domain and Federation Services in Windows Server vNext. As previously noticed Windows Server 2016 is a prerelease software. You can start investigating in parallel Windows Server 2016 Technical Preview 4
Note The device can participate in conditional access as "domain joined" and "registered/managed" devices.
Note For more information, see the webcast Using the Business Store Portal with Windows 10 Devices.
Let's see how to verify a successful "Azure AD Join" process from the above Windows session.
One should note the traditional System properties does not demonstrate a successful Azure AD Join. When viewing the System dialog (sysdm.cpl) the information for domain status is not reflected correctly and can be misleading. System Properties will indeed show that the device is in a workgroup as illustrated hereafter under Computer name domain and workgroup settings.
Using a simple whoami from a command window displays the user's domain and the user executing the command. Proceed with the following steps:
Note This display format is different from what you will see with a traditional WSAD domain join whoami command. Whoami on traditional WSAD domain will return a NetBIOS format such as litware369\janets but on an Azure AD joined machine the command returns a combination of givenName + SN without a space.
The Accounts page under the Settings option in Windows 10 also shows you what type of account is being used.
To open the Accounts page and verify the process, proceed with the following steps:
The AAD Token Broker plugin is underneath used for this account. This plugin is designed for a seamless Single Sign-On (SSO) experience.
Note Token Broker in Windows 10 is a new authentication framework that improves upon the former Web Application Broker in Windows 8.x and which is designed to provide Single Sign-On (SSO) for browser, modern business applications, and services.
If you think of the aforementioned Microsoft Passport as a locked box of secrets then the Token Broker is the master of keys, matching credentials with identity providers. The Token Broker enables identity providers like Azure AD in this illustration but also Microsoft Account (MSA), Facebook, etc. to natively plug into Windows in order to provide apps and services with tokens to access web resources.
As a result, users like Kelly enjoy a seamless authentication experience when connecting to online services for Azure AD here, and other identities and don't have enter their credentials multiple times. For example, this enable in our illustration seamless access to protected Azure AD resources wherever they reside and where Kelly can enjoy modern applications that integrate with their favorite web services in a secure and frictionless way.
This also provides in terms of additional benefits Web authorization experience consistency and higher-level integration into account management, selection, switching, etc.
Once a device is joined to Azure AD, a certificate is issued to that device by the Azure AD Device Registration Service as part of the process.
Note For additional information, please refer to the specification [MS-DVRE]: Device Registration Enrollment Protocol.
To view this certificate, proceed with the followings steps:
The "Azure AD Join" process does not write to the netsetup.log like a traditional WSAD domain join of a Windows machine to the on-premises Active Directory. In fact, the netsetup.log will be blank so determining a successful join will require other clues to aid the IT professional.
However, Windows 10 allows you to confirm via the User Device Registration Admin log. Proceed with the following steps:
Examine your own event logs and compare them with what you see in this above illustration.
Let's wear the IT professional clothes to verify a successful "Azure AD Join" process in the Azure AD tenant as well as in the Mobile Device Management for Office 365 if you've activated this solution.
If you know your hostname you can verify a successful Azure AD Join by reviewing the Devices tab on the user account who joined the Windows 10 device to Azure AD.
Proceed with the following steps:
Proceed with the following steps:
There may come a time when you wish to leave the organization.
To leave the organization, proceed with the following steps:
Important note Failing to create a local or Microsoft Account (MSA) account with administrative rights on the computer before leaving the organization will cause the user to lose all access to the machine and leave it in an unusable state.
A Disconnect from the organization dialog shows up.
This section is intended to provide instructions for configuring and testing the "Domain Join" in a hybrid Active Directory environment as the title indicates. It thus will require the optional "on-premises" test lab environment deployed in Azure as per section entitled Building an on-premises test lab environment (Optional).
Windows 10 domain joined computers (build 10551 and above) will automatically and silently connect to the cloud. They will do so by contacting and authenticating directly with Azure AD Device Registration Service.
The article Connect domain-joined devices to Azure AD for Windows 10 experiences fully described how to update the above optional "on-premises" test lab environment deployed in Azure.
This requires to:
Note For more information, see the article Custom installation of Azure AD Connect.
Note For version release history on AAD Connect, see the article Azure AD Connect: Version Release History.
Note Windows 10 domain joined computers will authenticate using Windows Integrated authentication to an active WS-Trust endpoint hosted by AD FS. You must ensure this endpoint is enabled. Since the optional "on-premises" test lab environment deployed in Azure is using the Web Authentication Proxy, you must also ensure this endpoint is published through the proxy. You can do this by checking that the adfs/services/trust/13/windowstransport shows as enabled in the AD FS management console under Service > Endpoints.
Note As noticed earlier in this document, WSAD in Windows Server 2016 is needed to enable Microsoft Passport and Windows Hello. As of this writing, Windows Server 2016 is a prerelease software. You can start investigating Windows Server 2016 Technical Preview 4. For more information, see the webcast What's New in Active Directory Domain and Federation Services in Windows Server vNext.
Thanks to the above steps, and excepted the fact that the user will sign with their "regular" WSAD account, they will enjoy the same benefits as the ones outlined in section Signing in with the Azure AD account.
This walkthrough provides instructions for testing the new capabilities provided for personal devices by combining Azure AD and Windows 10 features.
Please ensure that all the prerequisites mentioned earlier in section Building a test lab environment are fulfilled at this stage.
Adding an Azure AD account to a personal device has the same additional requirements as the one outlined in the eponym section of the section Testing the new capabilities for corporate owned devices.
Please refer to this section and its instructions to configure your test lab environment in accordance if you've not already done it.
Let's walk through from the out of box experience (OOBE). Proceed with the following steps:
Note While application experiences may differ from on to another, one can expect that most applications will have a Sign in button or an Add Account in the application settings as illustrated here with Word Mobile.
Kelly's work account is configured to be used with the Litware369 organization's OneDrive for Business where as Kelly's personal MSA account is configured to use her personal OneDrive.
Compared to what we already have covered in this paper regarding the "Azure AD Join" and "Domain Join" processes and related user experience, the major difference here resides in the fact that you will use your personal account to sign in and open a Windows session.
In other words, once an Azure AD account has been added, users will enjoy many of the same benefits on their personal device as they would on a corporate owned device joined to Azure AD.
This notably includes:
Note The device can participate in conditional access for user.
Modern Windows services (a.k.a. Windows connected services) such roaming of personal settings will continue to be driven by your personal MSA account.
Note For additional information, see the blog post Azure AD on Windows 10 Personal Devices.
We hope that you are now equipped with a better understanding of the benefits that Azure AD and Windows 10 can provide together where: