Intune Autopilot – Part 2 – Moving in the right direction!
Cont.
So if you've read part one, then you're looking for a way to set up an Intune managed Autopilot device to be shared among multiple users.
The chances are that you're already using autopilot for your single-user devices. Which means that you already have an Azure AD Dynamic Group, probably using a dynamic query such as:
(device.devicePhysicalIDs -any (_ -contains "[ZTDId]"))
The problem with this approach is that it's going to lump all of our autopilot devices into one AAD Dynamic group, which is no good if we need multiple deployment profiles (User Driven + Self-Deploying profiles). So we need a way to separate these devices. Enter the OrderID field...
The OrderID field, also referred to as GroupTag will allow us to create different groups of Autopilot devices, so that we can deploy Single User laptops, Shared PCs, and Kiosk devices all with different profiles and policy sets. However, if we are using the ZTDId tag, the chances are that none of our existing computers has the order IT field populated.
Therefore we need to populate the OrderID value for all existing devices and change our Dynamic AD groups to match the OrderID, not all autopilot devices.
Thankfully, Nicola Suter has come to the rescue here. He has written a PowerShell script that will connect to Graph API, and allow us to change the OrderID field in bulk. https://tech.nicolonsky.ch/bulk-update-windows-autopilot/ In this example. I'm going to use a group tag of "autopilot" to signify a standard user-driven deployed device, therefore we will use Nicola's scripts to change the group tag to "Autopilot" on all existing devices.
In conjunction, with this, we also need to change the Dynamic group query in Azure AD from targeting ZTDid to something like this:
(device.devicePhysicalIds -any _ -eq “[OrderID]:Value”)
Where "Value" is the value, you want to put in the OrderID field.
Once we have done this, we can start building a new policy and profile set for our other devices. In part 3, we will explore a multi-user desktop and kiosk mode deployment alongside traditional user-driven deployments.
Intune Autopilot - Sharing the love - Part 1
Over the last 18 months, I've had great success deploying modern-managed devices for clients, using a mix of Azure Active Directory, Intune and Autopilot. Autopilot has always worked great in scenarios where one user = one workstation, but what about a replacement for that traditional domain-joined PC which you would deploy for shift workers or in multi-user situations where one computer = 5 users?
There are a few ways that I have found a multi-user device can be set-up, but these all have drawbacks.
Build a PC then AAD join it:
On the face of it, this seems like the most straightforward option. The PC can be AAD joined and added into AAD Device groups to receive policies. However, the drawback with this approach is that the machine will be listed in AAD as a device under the user that AAD joined it. This can lead to admin accounts with tens of devices listed under them and a potential requirement to lift the "per user device limit" within AAD.
It's also a royal pain in the backside to have to assign group memberships manually, and policy application appears to be a little spotty the moment you transition to a standard user.
SharedPC CSP
Microsoft has thought of this and created a SharedPC CSP policy. SharedPC CSP comes with several advantages such as Guest account Management, Local Storage Policies, Power Policies, Fast first sign-in and Education Policies, all of which make management and sign-in much easier. But for me, this CSP has one critical flaw - it disables the OneDrive client completely!!
If like me, you've been encouraging people to take advantage included 1TB OneDrive space per user in Office 365, then you've probably migrated users' documents to OneDrive and are using policies such as KFM (known folder move). OneDrive client is critical to a Shared PC; otherwise, users will are forced to use OneDrive online to access their documents. It also gives no easy way to roam documents between shared PCs, for example at a reception desk with two seats.
So, how do we deploy an Intune Autopilot device for multiple users with all of our usual Line of Business apps?
The answer is Intune Self-Deploying Mode but without SharedPC CSP!!
What, I hear you cry, that sounds counter-intuitive, but it works. We'll let the self-deploying mode take care of our AAD join and then layer some custom Policies on top to cover the other bits.
The self-deploying mode requires adding another Autopilot deployment profile, which means you must make some changes to your existing autopilot configuration. In Part 2, I'll go into the changes that you need to make to prepare your environment for multiple deployment profiles.
Is ADFS now dead?
For those of you keeping an eager eye on cybersecurity, NCSE published some new guidance for securing Office 365 earlier this year. This new guidance includes one significant change from Microsoft, which some may find a little controversial.
Microsoft now recommends that hybrid environments – i.e. those that use Active Directory Domain Services and Azure AD – should prefer native authentication against Azure AD rather than ADFS.
In Microsoft-speak this is ‘Seamless SSO with Password Hash Sync’, configured to use either per-user or Conditional Access MFA.
Password synchronisation with the cloud can feel like a scary thing to do, but in actuality, organisations using Azure AD as their primary authentication source will lower their risk compared with ADFS.
This is because:
- It’s the hashes of your password hashes that are sent to Azure AD, and not the reusable NTLM hashes commonly discussed in “pass the hash” attacks. This means that the credentials sent to Azure AD can’t be used to authenticate to any of your on-premise infrastructures that rely on Active Directory.
- We are already relying on Azure AD to make access control decisions regulating who can see which data, hosted in Office 365. So we already need to trust that it’s built and operated securely. Storing password hashes doesn’t change that security requirement.
- The availability of Office 365 will no longer be affected by any outages or downtime suffered by your on-premise ADFS or Active Directory infrastructure.
For those interested, the new Microsoft guidance can be found here: It’s a brave new world out there!