Update 9th August: Authenticating directly to ADFS server works for both Jamf Connect Login as Verify. See new post here!

I was initially going to dedicate this post to deploying Jamf Connect Login with Okta. I wrote that Nomad Login+ Okta post a few months ago, so I assumed it would be a walk in the party to update my workflow now that Nomad Login+ moved under the Jamf Connect umbrella. Well, I still don’t know why but I ran into some roadblocks which I have to analyse first. Probably just due to my own doing, overlooking things or whatever it might be, but I’ll postpone writing about it till I have rock solid info to share. Stay tuned!

Hence, this post is going to be Azure related again. But because Jamf Connect is still fairly new to all of us, we can’t share too much information right! Jamf Connect truly is a beautiful tool to streamline the way end users authenticate to their Macs, apps and services, ensuring they only need 1 password to rule it all. Have a look at my previous post about how to do a basic deployment. Quite straight forward, no rocket science at all!

However it seems that some people ran into issues in environments with a mix of Azure and ADFS.

One of the features of Jamf Connect is the preference key to define if users are allowed to create a local password or not:

Set it to ‘true’, and Jamf Connect will prompt the user to create a local password:

Set it to ‘false’, and the user will be prompted to validate the existing Azure password:

With Jamf Connect Verify in mind, which you would deploy alongside Jamf Connect Login, the end goal is to keep both the local and Azure password in sync. Even if the user would choose a different password during the account creation process with Jamf Connect Login, Verify would detect the mismatch at the first following login in the ‘Verify app’. But it would indeed be best practice to have them in sync from the very beginning, hence the possibility to put the <OIDCNewPassword> key to ‘false’.

This all sounds great and works perfect in pure Azure environments. Even some hybrid environments don’t give us too much trouble, but things get a little more complicated if ADFS is playing a role in the mix. Why? Well, let’s dive a little deeper into the mechanics behind Jamf Connect!

When the end user is presented with the Jamf Connect Login screen, he/she will see the Azure login page. Authenticating through this screen performs a login in Azure over OIDC:

But, when setting the <OIDCNewPassord> key to ‘false’, the end user is asked to authenticate again… this, as said, with the idea to grab the password during the authentication and use that for the local account. The thing is, this can’t be done over OIDC, there is no way Jamf Connect could fetch that information out of the OIDC communication process with Azure. So we need another technique to perform this magic: ROPG or Resource Owner Password Grant.

To summarise it: OIDC = OpenID Connect, which is basically a web view of the Cloud Identity Provider (which also supports MFA), used to authenticate to the Identity provider. ROPG = Resource Owner Password Grant, which does not allow MFA but allows us to grab the plaintext password in the process.

Again, this works fine with Azure, but when Azure is federated with ADFS, it sends the auth request to ADFS. And this is where things go wrong. I might be over-simplifying things here, but there are multiple possible variables depending the environment, which can cause trouble. What happens is that, depending some federation variables, we basically loose the ability to grab the password during the process. As a result, Jamf Connect throws an “incorrect password” error:

So, that’s it? No Jamf Connect if you have an ADFS federated environment? Well, fortunately no, no panic! There are actually 2 options to get around this issue! Or actually 3.

The first option would be to force Jamf Connect Login to authenticate directly to ADFS, instead of Azure. As I don’t have a working ADFS test environment at the moment, I can’t test it at the moment, but the idea behind it is to deploy a custom config by setting the following keys in a plist/config profile for Jamf Connect:

<key>OIDCClientID</key>
<string>f7364cb1-2b34-4g64-9c83-38b827cd0a9e</string>
<key>OIDCROPGID</key>
<string>f7364cb1-2b34-4g64-9c83-38b827cd0a9e</string>
<key>OIDCDiscoveryURL</key>
<string>https://adfs.domain.com/adfs/.well-known/openid-configuration</string>
<key>OIDCProvider</key>
<string>Custom</string>
<key>OIDCRedirectURI</key>
<string>https://127.0.0.1/jamfconnect</string>

The get the values, we would need to go in our ADFS tool and grab the OIDCClientID and OIDCDiscoveryURL. We also need to set the Redirect URI, just like we did for an Azure app, to https://127.0.0.1/jamfconnect:

This would then all fit in a config profile like the example below.

NOTE: As said, due to the lack of an ADFS test environment at the moment, I can't test it. But in case you have trouble deploying this, Jamf Support should be able to assist (sorry guys :-) ). Or let me know, I might be able to help as well.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>OIDCClientID</key>
			<string>f7364cb1-2b34-4g64-9c83-38b827cd0a9e</string>
                        <key>OIDCROPGID</key>
                        <string>f7364cb1-2b34-4g64-9c83-38b827cd0a9e</string>
			<key>OIDCDiscoveryURL</key>
			<string>https://adfs.domain.com/adfs/.well-known/openid-configuration</string>
			<key>OIDCProvider</key>
			<string>Custom</string>
			<key>OIDCRedirectURI</key>
			<string>https://127.0.0.1/jamfconnect</string>
			<key>PayloadDescription</key>
			<string>Jamf Connect Login settings</string>
			<key>PayloadDisplayName</key>
			<string>Jamf Connect Login Settings</string>
			<key>PayloadEnabled</key>
			<true/>
			<key>PayloadIdentifier</key>
			<string>com.jamf.connect.login</string>
			<key>PayloadOrganization</key>
			<string>Jamf</string>
			<key>PayloadType</key>
			<string>com.jamf.connect.login</string>
			<key>PayloadUUID</key>
			<string>53464BE1-9B79-48E6-9875-82E82C1DCB99</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Jamf Connect Login Settings</string>
	<key>PayloadDisplayName</key>
	<string>Jamf Connect Login settings</string>
	<key>PayloadEnabled</key>
	<true/>
	<key>PayloadIdentifier</key>
	<string>com.jamf.connect.login</string>
	<key>PayloadOrganization</key>
	<string>Jamf</string>
	<key>PayloadRemovalDisallowed</key>
	<true/>
	<key>PayloadScope</key>
	<string>System</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>88F96360-D6B7-412E-BE6D-702E490BDFC4</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

So, as OIDC with ADFS is quite similar to OIDC with Azure, Jamf Connect should have no issues with authenticating directly to ADFS. Don’t hesitate to let me know how it goes if you would be trying this out!

That said, authenticating directly against ADFS is option 1 to fix the issue. But as said there are actually 2 alternatives which you might consider as well.

The first one is: “Password Hash Synchronisation”. And before any security guys reading this jump on their high horse, a quick disclaimer :-). No, I’m not a security expert, so I’ll not make any statements which could trigger an wave of security related comments or remarks. I’m well aware that putting any kind of sensitive information in any sort of cloud instance is a big ‘not done’ in many high security environments.

The only thing I’d like to mention is that, as far as I know, the password hashes sync to Azure is not only hashed, but also salted… so I would assume Microsoft took the necessary precautions to secure this correctly.

For what it’s worth, I tried deploying Jamf Connect, authenticating against Azure with “Password Hash Synchronisation” enabled and it works fine.

Azure Password Hash Sync: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs

Finally, there is option 3: “Pass Through Authentication”, and this is actually quite an interesting one. Diving into the matter I came across multiple discussions about “Is ADFS dead?”. Quite similar to “Is imaging dead?“. And as the answer to question 2 would definitely be “YES”, reading through some Microsoft articles and documentation I initially thought… yeah why keep ADFS, if there is PTA now?

Well, I’m not going to open this can of worms, but I definitely want to add this option to this discussion, because I do believe that PTA might be a good alternative for many organisations currently using ADFS. For a starter, have a look at the comparison regarding the weight on your infrastructure between ADFS and PTA. I’m not going to re-invent the wheel so, just have a look at the Architecture Diagrams in the following Microsoft article: https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn

As well as the process to migrate from ADFS to PTA: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-migrate-adfs-pass-through-authentication (Have a look at the considerations section !)

Discussing the choice between keeping ADFS or move to PTA would really surpass the scope of this post, but I definitely wanted to add this option to this discussion, because I do believe that PTA might be a good alternative for many organisations currently using ADFS.

In my opinion, unless you really need ADFS for 3rd party MFA (RSA SecurID, Vasco, YubiKey), MFA without conditional access compatibility, custom authorization logic or any other fancy complex auth mechanisms which don’t support Modern Authentication, moving away from ADFS might be something to at least consider. Have a look at the decision tree below:

And again, for what it’s worth, I reconfigured my AAD Connect setup, disabled “Password Hash Sync”, enabled “Pass Through Authentication”, made some new users, synced with Azure and deployed Jamf Connect… and it all works nicely as expected.

That’s it, I hope I didn’t open a can of worms here… Actually the more I think about it, I’m afraid I did, but yeah worst case scenario it would trigger some discussion and buzz from which we all learn 🙂

The main goal of this post was to share the info about the possibility of authenticating Jamf Connect directly to ADFS, and to add some alternatives to the discussion!

Happy to hear what your environment is and wether or not you would be considering to move away from ADFS (if possible), or allow “Password Hash Sync”.

Grtz,

TTG

Print Friendly, PDF & Email