To enable secure access to apps and services, an organization may constrain access to only devices that are properly configured for work. When a device is setup for work, users can access securely and under compliance, apps, services and data using their work accounts (i.e. AD or Azure AD accounts).
Windows 10 offers three ways to setup a device for work: Domain Join, Azure AD Join and through Add Work or School Account for personal devices. In all cases, devices obtain an identity with Azure AD (a.k.a. register with Azure AD) and come under the control of the organization (i.e. devices are managed by the org.).
Using their work accounts on these devices, users will:
- Experience Single Sign-On (SSO) to Office 365 and SaaS apps from everywhere.
- Enjoy roaming of OS settings across joined devices.
- Be able to access the Windows Store for Business.
- Have the convenience of Microsoft Passport & Windows Hello to access work.
On the other hand, organizations will:
- Be able to restrict access to only devices meeting Conditional Access policy.
- Have piece of mind as settings and work data roam through enterprise compliant clouds. No Microsoft accounts are involved (e.g. Hotmail), and can be blocked.
- Reduce the risk of credential theft by implementing Microsoft Passport for Work.
This is the traditional way organizations have deployed Windows work devices for years. Devices are typically managed with Group Policy or System Center Configuration Manager (SCCM).
Windows 10 domain joined devices automatically register with Azure AD enabling new experiences to both users and admins. The process to join devices to the domain doesn’t need to change. Upon reboot the device attempts registration with Azure AD using its on-prem AD computer account identity. Expect a blog entry where I will describe in detail how this process works.
Azure AD Join
This is a new way for setting up work devices for work. Devices register directly with Azure AD. It provides a self-service experience for the user to setup the device from anywhere (in contrast with Domain Join which is typically done as part of an imaging process or by an admin). In a future update of Windows, Azure AD Join will offer a pre-provisioning experience for admins to prepare devices before handing them out to users.
As part of the device setup experience the device also automatically enrolls into Intune or the MDM system that has been configured in Azure AD.
Add Work or School Account
This is the way to enable personal devices to access work resources. It can be done via Settings (Accounts -> Your Account) or when the user configures an app for work. For example a user can choose to add the work account to Windows at the moment is setting up the Mail app to connect to Office 365. The user will enjoy SSO to work resources through apps and browser (Edge and IE).
In addition, adding the work account will enroll the device with Intune or the MDM system that has been configured in Azure AD.
Please note that Add Work or School Account is the replacement for the Workplace Join experience in Windows 8/8.1.
Please also note that both Domain Join and Azure AD Join allow users to sign-in/unlock devices using their work accounts. Personal devices are unlocked using Microsoft accounts (i.e. Hotmail, Live, Outlook, Xbox, etc.). Add Work or School Account doesn’t change this fact, but adds the work account on top of it (a.k.a. as a secondary account). The Microsoft account is still used for unlocking the device or for driving default Windows experiences like roaming of OS settings or Cortana.
That’s it for now. Please expect subsequent posts that describe in detail some of these concepts. See you soon!
Jairo (Twitter: @JairoC_AzureAD)
Pingback: Azure AD and Microsoft Passport for Work in Windows 10 | [Azure] Active Directory by Jairo Cadena
Does it work with an .onmicrosoft.com AD account?
I am trying to setup a Windows 10 / Azure POC Environment. I have created a Azure AD directory with the name mwstest.onmicrosoft.com and added a few users. Made the configuration on the Azure AD to allow devices to connect to it.
On my Windows 10 machine – I logged in using my local admin account and then attempted to Join Azure AD domain – which worked and I could see that it had connected successfully.
I logged off and then tried to use my Azure AD account to login but it failed? Do I need an On Prem AD with ADFS to achieve this?
Hi Ganesh, what is the error that you get when trying to sign-in with your Azure AD account? To troubleshoot you can sign-in first to a local account, enable debug logs for AAD and then sign-out/in again with the AAD account. After failure you can sign-in back with your local account and see the logs. To enable logs go to Event Viewer go to the AAD node under Application and Services Logs > Microsoft > Windows. Right-click > View > Show analytic and debug logs, then go to both Analytic and Operational nodes and right-click on each to enable the log. After trying signing-in again you can come back to Even Viewer to check the logs. If you need help with them please let me know.
For adding a work or School account, do you have to be logged in with a onprem Domain account or a Microsoft account? In other words: does SSO with registered devices (add w. or s. account) also work when you are logged on to win10 with a “local (machine) user”?
You can be logged on with a local user and add a work account and that should work fine.
One comment: the way to enable registration with Azure AD for a domain joined device should be using the Group Policy and not via adding the work account. Just wanted to mention it as your question includes an on-prem domain account.
Hi Jairo. We are a small business that have an existing on-prem exchange server, a domain controller and a DHCP server. We opted for Office 365 (50+ E3 subscriptions) so that we could go server-less. DHCP would be served by the Firewall, Exchange would be in Office 365. However we’re not sure about the DC.
I know that O365 provides Azure AD Free Edition with the subscription.
Our computers and laptops are currently setup to work on a domain.
I have a GPO policy – force users to change password every 6 months with password complexity enabled.
Most systems are Windows 7 Pro, and I am in the process of upgrading them to Windows 10 Pro using the free upgrade available at the moment.
How can I get rid of the DC and setup my systems to work with AAD Free directly? I would like to decommission my servers completely and have no dependency on the local office and its infrastructure i.e. VPN, DC, etc.
Going crazy with different vendors providing different solutions that simply add cost to a pre-budgeted purchase i.e. no wiggle room.
Thanks in advance for your help.
It’s funny I am in EXACTLY the same situation as Neil – And I read his post a few minutes after he wrote his! The only difference with us is that we’re a 25+ company( but with E3 subscriptions, too).
I was wondering at what were the impacts of leaving the computers in a workgroup and relying solely on Azure AD (Free). I am also considering Azure AD Domain Services, eventually. But just like Neil, we’re not relying much on any GPOs… And we’re planning to let go of our remaining servers by the end of the year (we have 3: SBS, SQL and terminal; all virtual)
As I mentioned to Neil, you can do Azure AD Join with a free subscription. I would recommend trying it out and see if that is enough. There are several features that you would miss but you can try and see. One consideration you might want to have is whether you want and how are you going to manage these devices (e.g. Intune).
Hi Neil and Sebastien,
I am in your situations. I wondered if you had done the transitions yet. If you had, how can you joined the Azure AD on the already joined local domain device? Did you need to disconnect local domain first and rejoin the Azure AD? if so, how did you handle user profiles?
Any guidance would be appreciated!
Minh Hoang, more then one year later, have you found a solution to this? We are in the same situation. and unsure, if this will work. How can we preserve the user profiles?
Neil, you can configure devices directly against Azure AD. Without a paid subscription you would have some limitations specially on the admin side, but without these you may be okay depending on your situation. I would recommend try one PC out and see what you are missing and if you feel it’s good enough you may roll out to other devices.
After joining a new Surface Pro 4 with Windows 10 to Azure AD, we cannot enable MDM. We get the following error:
“We couldn’t find your work or school. Check your internet connection, provide some additional info and try again”.
we are on a wifi network and have internet connectivity
You mentioned “Azure AD Join will offer a pre-provisioning experience for admins to prepare devices before handing them out to users”.
Have you seen this functionality become available yet?
Pingback: Windows Live Admin Center Add Domain | I love You Zones
Hi and thank you for this blog post. I have a question in regard to your MS Ignite presentation.
Is it correct that Azure AD Joined Devices will be able to get an PRT token from ADFS 2016 and then get SSO to applications that’s federated with ADFS 2016?
Hey Bjoervik, yes you are correct. Upon Windows logon, we send the creds to AD, Azure AD and AD FS if 2016 and obtain a Kerb TGT, Azure AD PRT and AD FS PRT respectively. Later on the AD FS PRT will be used for SSO to AD FS relying parties access.
Pingback: How SSO works in Windows 10 devices | [Azure] Active Directory by Jairo Cadena
Pingback: (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail « Jorge's Quest For Knowledge!
Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!
I am facing issue to enroll device automatically to Intune or MDM services.
I have local DC, which I synced with Azure AD with latest Azure AD connect and set the group policy to ENABLE for “Register domain-joined computer as devices”. It register the device with Azure AD but didn’t register with Intune. Under Azure AD, I set the rule to enroll all devices to Intune when join the Azure AD.
I want to register my devices with Azure AD and Intune by joining the local domain only.
Server OS – Windows server 2016
Client OS – Windows 10 Pro
Device enroll successfully to MDM services when I join the Azure AD from the device.
Excellent web site ʏou have ɡot hеre.. Іt’s hаrd tо find excellent writing like yօurs these days.
I truly appreϲiate individuals ⅼike you! Tаke care!!
I first want to echo the kudos from Gorden on these very informative pages. I would like to ask an AD object based question, which I believe may not be a concern, but wish to confirm that assumption. Windows 7 (on-prem) devices that attempt to perform AZ-AD join (we must stick with on-prem ADFS), where these objects may have already been provisioned into Azure via our AZ-AD Connector (ILM sync engine). I do believe that the WIN10 devices ‘join’ to their pre-existing objects, but is that also the case with Win7 objects or is there an additional object created in Azure. And if so, is there a potential issue with having duplicate objects representing that one device?
I have perfected this pure serverless roaming profiles (laptops). It’s working great tbh. But they are only using the base configurations to all roaming laptops.
Though I want to hardened all the roaming laptops and I wanted to control them remotely like SSCM for patches and updates.
Any thoughts? Should I go with Intune for adding more policies? And what about for pushing updates and policies remotely?
Inputs and advices are greatly appreciated.