In part 1, which was posted a long time ago now (oops), I discussed how there’s a push to move more workloads to the cloud, and for sites to switch the Modern Desktop via Mobile Device Management (MDM) solutions. In this part, I’ll cover what I’ve recently learned and implemented, in the hope that others might find this useful. While I’ll be talking about MacOS configurations, the lessons learned are applicable to Windows device migration as well… and in fact, that’s what this series of articles is all about: Preparing to modernise our Windows devices.
The first thing we need to discuss, is Directory membership. Whether talking about Windows or MacOS and Directories, we will discuss three primary methods:
- Domain-Join, or Directory Bind on MacOS
This is now considered the ‘legacy’ model, and relies on the configuration of Directory trusts on the device so that it may use secure authentication methods and establish the various tokens (such as Kerberos Ticket Granting Tickets (TGTs) – used to automatically sign in to various on-premises solutions such as printers and file shares. On Windows devices, this join fundamentally changes how the Operating System behaves, not least of which is the setting of the Source of Authority (SOA) of the system so that it will only trust admins and servers in the domain/forest, and will set a requirement of direct line-of-sight to a Domain Controller before the device will be permitted to perform a number of operations such as authenticating a new user account, caching credentials for offline use (similar to the MacOS mobile accounts), etc. It’s a big deal performing a Domain-Join, which is why many are investigating the migration to cloud authentication/join. - Azure AD-Join
This is the modern authentication mechanism, and where most Identity Provider (IdP) platforms are focusing their attention and improving identity security, such as introducing Password Protection, User Risk Policies, Conditional Access (CA), and Multi-Factor Authentication (MFA). While Windows can natively perform either an Azure AD enrolment or Workplace Join process to establish the cloud environment as a trusted source for authentication, MacOS devices will require a solution such as JAMF Connect to handle the authentication. With this in place, the device has no Source of Authority issues like Domain-Join, and has gains a significant amount of new security and functionality. This, however, requires that your site either has all of their identities in Azure already (not synchronised), that the credentials from on-premises directories are made available to the cloud for authentication (more on that later), or that you switch to a Hybrid model to allow local authentication. - Hybrid Join, otherwise known as “both of the above at the same time“
While the Hybrid-Join scenario is usually only discussed with Windows devices, it also applies to MacOS in that you can still bind the device to the Domain for local authentication, and use a solution like JAMF Connect to authenticate and synchronise the cloud account details to the local device. Unfortunately, for Windows devices, the Source of Authority for Hybrid-Joined devices is still Active Directory, and this means that while you gain some of the benefits from the cloud authentication, you’re also still limited in that you need line-of-sight to a Domain Controller to perform some functions. Again, this is why some sites are using Hybrid as an interim solution while they investigate a native Azure AD Join solution. For MacOS, however, joining and binding are merely add-on functions and not really integrated into the Operating System, so we have a little more flexibility.
When operating in Hybrid-Join, there are some other things that need consideration as well: Where are the credentials going to be stored, and how do you verify a login? When you synchronise a user object from AD to Azure AD with a solution like Azure AD Connect, you have a few options:
- You can provision separate accounts in the cloud with the same User Principal Name (UPN) and a separate password. This is generally a pretty terrible idea and I’ve not seen many sites go down this path.
- You can provision separate accounts in the cloud with the same UserPN, but synchronise the password via Password Hash Sync (PHS) so they can use “same logon” functionality.
- Or you can Federate your domains – or use Seamless Single Sign-On connectors, as is the new recommendation – and essentially tell the cloud service to refer to the on-premises solution for authentication and use Single Sign-On (SSO).
NOTE: There are other options, such as using different UPNs in the cloud compared to on-premises, but that is beyond the scope of this post.
A lot of our early struggles with MacOS relate to the fact that we are technically a Hybrid site, with all our users and devices stored locally within Active Directory (AD), and then cloud-enabled via the Azure AD Connect sync tool that creates a cloud version of the objects, which is achieved via an Immutable ID: This means that, even if an account looks like it is purely an Azure AD cloud account, it’s Source of Authority (SOA) is still set to AD and must be managed in both environments. To help with authentication of our user objects, as the credentials were all securely stored on-premises via AD, we also used a hybrid-compatible Identity Providers (IdP): We use Active Directory Federated Services (ADFS) as our IdP, and this meant that the JAMF Connect setup required a complex hybrid configuration to work. But here’s the key: Those identity provisioning methods I described above can be somewhat linked… you can enable Password Hash Sync (PHS) at the same time you enable your Federated sync. And if you use PHS, a solution like JAMF Connect can use that to authenticate against the cloud object without being redirected to or needing to authenticate through ADFS… and this massively simplifies the configuration.
A quick sidebar to talk about Password Hash Synchronisation (PHS)
I’ve seen a lot of confusion around this feature, and some people pointing at it as a weak point in identity security because they believe the synchronised content can be intercepted, replayed, or otherwise compromised. I’m here to say, this is not the case at all. The way this works is as follows:
- Active Directory Domain Service stores user passwords in the form of a hash value. A hash value is a result of a one-way mathematical function, which means that the hash cannot be manipulated to return the original password.
- When synchronizing passwords via PHS, the plain-text version of your password is never read, exposed to the password hash synchronisation feature, to Azure AD, or any of the associated services. A PHS object is actually created as a hash of the original AD hash before being synchronised, so not only can it not be reversed, it also can’t be used on-premises if intercepted.
- In fact, to help protect your identities against bad or leaked passwords and to provide a fallback mechanism in case of disaster, Microsoft actually recommends that you enable PHS even if you use another solution such as ADFS for authentication. So it’s not only secure, but improves your site’s overall security.
Apple have long since recommended against any for of Directory binding, and strongly suggest the use of local accounts where you authenticate to solutions when you need them. The benefit of MacOS, which was previously considered a curse by many IT Admins, is that they really want to use local accounts and any Directory binding or integration is merely a suggestion at best (it barely works, or breaks all the time). So, this is where JAMF Connect comes in: It will be configured as a pure Azure AD solution; It will use the Password Hash Synchronisation solution to perform the authentication in the cloud without needing to hit ADFS; It will allow the Mac to create a local user account, profile and Keychain; It will allow those local accounts to be accessed in case there is no Internet access, acting as local accounts just like Apple wants you to do; And it will synchronise any password changes to Azure AD if changed locally, or via synchronisation back to the device if changed online. And because the password changes in AD immediately trigger an update to Azure AD (well, within 15 seconds, typically), this provides a real cloud user experience while technically using a synchronised identity.
The downside to this, is that we still need to define a solution to help MacOS systems obtain Client Authentication certificates from our Public Key Infrastructure (PKI), we need to finish all of our local printer and file share migrations because this solution doesn’t support obtaining Kerberos tickets for that type of authentication, and we’ll need to switch our Wi-Fi configuration so that we leverage certificates… because without a Domain binding right now, the devices aren’t connecting at the login screen, which means they are unable to authenticate users. This last point is less of a problem with the solution we’ve identified above, but it’s still something to consider for anyone else heading down this path.
The new JAMF Connect configuration
The first thing I realised when looking over our complex Hybrid JAMF Connect configuration , is that an Azure AD-only configuration apparently needed two values in the payload:
- Identity Provider = “Azure”
- Client ID = <Your_AAD_Enterprise_App_ObjectID>
And that works. We created a new configuration, distributed that to a test device, and it just works. The key here, as I said above, is that you need to have Password Hash Sync enabled so that the Azure AD connection can fully authenticate the users. This configuration didn’t require split OIDC and RPOG settings, none of the Hybrid ID URL/URI or Client IDs… just a single change in Azure AD Connect, and a JAMF Connect configuration with two items in the PLIST and it works.
That’s not to say we should only keep two items in teh configuration, I’m just saying it is possible. In my case, I slowly, setting by setting, went through and added things back from our Hybrid configuration to make life easier and more consistent with our old setup. Here are the other settings I suggest, in the order they should be considered (according to me, anyway):
- Create Jamf Connect Keychain
Enable this option and set it to True. Managing Keychains isn’t a fun exercise, keeping passwords in sync is even less fun, and you don’t want to nag users for this while they are trying to log in and get work done. - Tenant ID
With the above settings, the first JAMF Connect screen you see will be the standard Azure AD login window with the Microsoft logo at the top. By specifying your Tenant ID, this will save you a refresh and will immediately load the login page with your company branding (if you’ve configured that). - Allow Local Fallback
Set this option and mark it True so that your accounts are permitted to use local authentication if a network is unavailable. This effectively works like the local account or mobile account you’re probably familiar with, but because of the magic of JAMF Connect, this will be an account that shares the same/synchronised password from the cloud account. This is important for troubleshooting. - Allow Network Selection
Enable this option and set it True. You don’t always know where your users will be authenticating from, so you should probably allow them to select or configure their network connection preferences from the login window. By default, as JAMF Connect takes over this user interface component, this option is likely disabled by default and can cause issues with authentication. - Demobilize Accounts
Enable this setting and set it to True, especially if you have an old Bind or Hybrid configuration in place where mobile accounts may be used. The last thing you want to do is orphan a user profile or introduce wild inconsistencies with the user experience, so setting this will help you convert your users to local, JAMF Connect-managed accounts. - Connect existing local accounts to a network account
Enable this setting and set it to True. Use this in conjunction with the next item in the list to allow automatic connection between any existing local accounts – such as those demobilised or previously created as local – to be used with the new JAMF Connect configuration. This will bring everything forward to the cloud-managed solution and allow passwords and Keychain updates to occur. Without this setting, you may be prompted to select an existing profile to merge with when authenticating via Azure AD, and this can lead to some tricky privacy//security concerns. - Local accounts prohibited from network account connection
Enable this setting and fill in the option with any local accounts you need to hide from the merge list or automatic connection via the above option. This is handy if you have a local “IT Support” account that may have scripts and other content locally, as you really don’t want users merging their cloud account with that profile. This is also handy to separate out any local work accounts, especially if there’s a chance the account will by synchronised to Azure AD. - Account Roles (Admin roles, Admin attribute)
Admin accounts are handy for troubleshooting purposes, and there may be cases where the user you allocate the device to needs a new role. JAMF Connect supports defining an admin role (i.e. “Admin”) and an identifying attribute (i.e. “roles”) to help make this happen automatically. To set this up, you will need to modify the JAMF Connect Enterprise application in Azure AD and create these first. I recommend you generate the GUIDs for a “Standard” and “Admin” role, which will then let you manage access via the Users and Groups setting. Once defined, enable “Admin roles” and “Admin attribute” within the JAMF Connect configuration and distribute it: Any user/group added to the app as an “Admin” will become an admin on the device this configuration is applied to. Super cool.
What does this mean for Windows?
With the above configuration in place, we are moving one more step towards experiencing our environment without Domain or Hybrid-Join, and that means an environment without Kerberos TGTs, home drives, and without device account authentication to solutions like Wi-Fi. This, while greatly minimising the the complexity of the configuration needed, and allowing us to consider the removal of ADFS and Federated domains while relying on Password Hash Sync to authenticate the users client the cloud instead. This… is great news. But, I obviously have a lot more to work out, so stay tuned for Part 3 of this series: Hopefully it won’t take so long to get the next update.
Webber Zone 
You must be logged in to post a comment.