Preface: We’re currently planning the next phase of modernisation for our fleet of Windows devices. In our case, the environment already ticks a number of “best practice” boxes, and is already up-to-date according to Microsoft’s definition of “Modern Desktop”… but there is always more to learn, and new features which can help you and your team achieve more. I’m not about to suggest that you throw everything out and start again in the cloud; I believe schools and organisations should approach modern management and “the cloud” as a destination, and that the journey should be about transformation and not migration; I also firmly believe that hybrid environments can provide the best of both worlds, and that adding power through cloud connections is the key to a great modernisation strategy. In our particular case, we’re using our small Mac user-base to explore what’s next.
By now you’re probably asking “wait, back up, did you say Macs?”. Yeah, you read that correctly. It’s not a bad plan when you think about it. Let’s start with the obvious: Active Directory (AD) binding on a Mac is terrible. It’s been terrible for years, it’s just completely broken in certain MacOS updates/builds, and it seems to be getting worse over time. From slow logins, to HomeDrive mounting issues, to Mobile Account issues (and permissions), and even unreliable 802.1X Wi-Fi… its bad. If you are a Mac Admin, or know someone who is, you’ve probably heard it recommended that you avoid AD binding at all costs. With this in mind, why not explore options for replacing AD binding, and possibly powering the user experience with solutions such as Azure Active Directory (AzureAD)?
Unfortunately, for many years, the alternative to AD-binding was to just provide a Mac to a user in the retail box, let the user create and use a local account, and ask the user to run scripts or commands to authenticate to everything they need to use, just as they need to use it: A terrible user experience, especially for less technical staff. Fortunately, some incredible solutions have since come out to improve that experience, and some do a fantastic job of filling the gaps left by lack of directory binding – while also avoiding the terribleness of AD binding on a Mac. In our case, enter JAMF Connect (previously known as NoMAD, before the JAMF acquisition). The purpose of Connect is to still allow the user to the benefits of a “local account”, but to integrate with Directory Services to not only obtain a Kerberos ticket and enable Single Sign-On just like an AD bind would have provided, but to also synchronise the Directory and local account passwords so that it even behaves like a Directory account – without the terribleness of Mobile Accounts.
What does JAMF Connect have to do with modernising a Windows environment? AD-joining devices can be problematic and/or limiting in terms of modernisation, Windows 10 natively supports AzureAD-joining devices and signing in with AzureAD identities, and one of the first things you can explore, is whether you actually need to AD-join devices. One inconsistency that I hope is eventually solved, is how user identities and devices behave so differently in AzureAD: While user accounts can live in AD and be synchronised to AzureAD, and despite their Source of Authority (SOA) being an AD domain, those identities can do everything in the cloud without needing a Domain Controller (DC); Devices, on the other hand, become locked to a Domain even if you synchronise the device objects to AzureAD and enable Write-Back functionality in AzureAD Connect.What does this actually mean? Consider the following:
- You have a user account (Domain\JohnB) and a device (HT20JOHNB) in Active Directory.
- Both the user account and device have been synchronised to AzureAD via AzureAD Connect.
- The user, JohnB, is currently off-site. He changed his password earlier that day and can no longer remember it, so calls the IT Helpdesk for help.
- Even though the SOA for the user account is the on-premises domain, you are able to change JohnB’s password for him in AD Users and Computers. With this change, within mere seconds, JohnB is able to continue working in cloud applications such as Office 365 web apps and Outlook.com.
- Unfortunately, as the computer is also Domain-Joined, JohnB’s old credentials are cached on the device and the device is unable to authenticate JohnB against AzureAD even though his user account can. For JohnB to log on to his computer, he needs to bring it back to the campus so that the credential can be authenticated and cached via connectivity to a Domain Controller. This is terrible.
- One other little issue: In the above scenario, JohnB is considered to be in a hybrid configuration. While it would be great to offer JohnB the option of using Self Service Password Reset (SSPR) to regain access to his account, Microsoft requires that the user be licensed with at least AzureAD Premium (Plan 1) – a paid add-on license – in order to gain this functionality.
As you can see, despite all the power of Domain-Join, the act of doing so is currently very limiting – and expensive in the case of needing AzureAD Premium licenses – when operating in a hybrid configuration. I’ve spoken to Microsoft about this limitation in hybrid a lot, and while someone in the appropriate team might occasionally give me hope that the device can trust AzureAD and solve the SOA issue – in a similar way as user accounts – I often get conflicting information that crushes that dream, shortly after. New plan, make the SOA Azure AD instead. And yes, in case people are wondering: Logging on to a purely AzureAD-joined device (no AD-join), with a synchronised (AD) account, no longer has the limitations of normal hybrid configurations and the user account and device will act just like both are pure AAD objects. So despite the identity technically being synchronised, simply removing the AD-bind can make this solution “modern”.
Not AD-binding a device can be a big deal, though. Bigger than the Microsoft tends to suggest during their many “Modern” and “Put it in the cloud” sessions at conferences and events. A great place to start, are the following couple of articles by Michael Niehaus (Microsoft, Principal Program Manager on the Modern Deployment team):
- Afraid of Windows 10 with Azure AD join? Try it out (Part 1)
- Afraid of Windows 10 with Azure AD join? Try it out (Part 2)
Using these articles, I set up a couple of test devices and ran through everything from AutoPilot configuration and deployment, to Intune enrollment, and configuration profile deployment. Once deployed, I then signed in with my AD user account – which was acting as an AzureAD identity thanks to the synchronisation process – and I was up and running. Now I’ll be honest, this wasn’t all smooth sailing. I had some AutoPilot compatibility issues with Windows 10 version; I had prompts telling me I needed to refresh my credentials by locking the device and unlocking with my password instead of PIN or Facial Recognition (Windows Hello issue); I had some quirks with our Wi-Fi configuration (802.1X, PEAP/MSCHAPv2); Internet access wasn’t always reliable thanks to our transparent proxy; And then we had some printer issues as well. That being said, accessing network file storage and intranet servers that required Integrated Authentication… just worked. With the issues I mentioned, these were all also somewhat expected, and mirrored some of the quirks we experienced with our Mac users previously. Moving forward, we added Macs to the test device pool and continued working towards a bind-less future.
Continue to Part 2 (soon) to see how we solved the challenges above, and how we continue to evolve our test environment using Macs to help Windows work better.
Webber Zone 