Hi there all!

To start with: Glad New Yr and all of the absolute best for 2022! Would possibly the power be with us…

I’ve been a bit of busy via the top of 2021 and took the top of December off to step clear of my Mac and servers for a bit of. Then again, with this new 12 months kicking off, it’s time to step up the sport once more. Therefore this primary blogpost of 2022!

As of late’s subject shall be about, what else to kick the 12 months off, Jamf Attach and MS Azure Conditional Get right of entry to, as I’ve not too long ago been running on some problem to determine some behaviour with the password alternate URL. By way of diving into the subject, I stopped up past the preliminary factor I used to be troubleshooting: the Azure Trade Password URL within the restricted browser by means of the Jamf Attach Menu Bar app, to a couple have an effect on on Jamf Attach Login.

I’ll cut up this publish in several sections, as I’ve a sense it’s gonna be a protracted one. So in case you’re studying this: rule no 1, caffeinate your self!

Sooner than kicking this off, I need to spotlight the adaptation between ‘Requiring MFA’ and ‘Requiring the system to be compliant’. In the event you’re handiest requiring MFA, you can be in a great spot with some good fortune codes added to the JC plists. Requiring ‘system to be compliant’ is on the other hand any other tale, which appears to be complicating issues and inflicting confusion. Therefore this blogpost.

Conditional Get right of entry to blocking off entry to the password URL

To start with, what are we speaking about? Smartly, not anything greater than the alternate password URL characteristic you’ll upload to Jamf Attach Menu Bar. On this case for Azure:

Surroundings this will have to permit the top consumer to open a webkit window to login to Azure and alter the Azure account password:

Now, that every one works wonderful, similar to while you would do it in any browser… so long as you wouldn’t have some particular Conditional Get right of entry to Insurance policies (CAP) enabled in Azure.

In the event you require MFA for your whole Azure sources, that will be wonderful because the webpage inside of this restricted browser would nonetheless be going during the MFA procedure.

Then again, issues get somewhat extra difficult in case you use different prerequisites at the CAP, for example: “Require system to be marked as compliant“. Let’s take a look.

I took my completely running Jamf Attach configuration, which used to be configured towards my Azure tenant which had NO MFA and NO Intune/MEM enabled. I didn’t also have a any Intune licenses on it… so I bought one 🙂 (Sure, I do have entry to different Azure Tenants with Intune licenses, but if seeking to spoil issues, I choose to do this alone take a look at circumstances… )

Subsequent, I configured the next CAP proscribing in to the only and handiest consumer with an Intune license:

Vital to copy are the settings for:

  • All Cloud Apps
  • Browsers decided on within the Shopper Apps
  • Require system to be compliant within the grant

Now, the ones amongst us taking note of warnings added via builders would possibly have already got spotted the next commentary/caution in one of the crucial screenshots above:

Don’t lock your self out! This coverage affects the Azure portal. Sooner than you proceed, make certain that you or any person else will be capable of get again into the portal.

Overlook this caution in case you are configuring chronic browser consultation coverage that works accurately provided that “All cloud apps” are decided on.

No, I’m now not going to fasten myself out, as this coverage is handiest enabled for 1 consumer… and now not my world admin :-). Then again, there’s a large clue right here in view of our password alternate URL: this coverage affects the Azure Portal. Extra about that later.

With that coverage enabled, I attempted the password alternate URL on a Mac which I in the past registered to Intune. Only for the file, this is the evidence that my take a look at Mac is Compliant, properly registered to Intune by means of the Jamf Professional integration:

Sooner than I in reality attempted to entry the alternate password URL I first checked if I may just nonetheless authenticate to Jamf Attach to begin with…

Within the first screenshot I’ve added right here above, you’ll see that I in reality had the good fortune code AADSTS50005 added.

<key>SuccessCodes</key>
  <array>
    <string>AADSTS50005</string>
  </array>

It is because with out this good fortune code, I stopped up with:

That is right away the primary have an effect on of getting a CAP set to all cloud apps requiring the system to be compliant. Then again, including the good fortune code within the plist allowed Jamf Hook up with paintings wonderful. That is very similar to how we in most cases paintings round ‘mistakes’ for MFA in this ROPG password validation take a look at (different good fortune code wanted: AADSTS50076).

Then again, once I attempted the password URL within the restricted webkit browser by means of Jamf Attach, I were given caught at:

Why? Smartly, if we have a look at the “Extra main points”, we see that the Azure Portal is complaining about the truth that the Mac isn’t registered to Azure….

To start with, the truth that this CAP is being evaluated is EXPECTED, as a result of I assigned it to the consumer I’m logging in with. As in keeping with my CAP configuration I confirmed previous. Then again, the truth that the Mac is blocked – reported as unregistered – fuels confusion right here.

You will be considering that the CAP will have to now not even observe right here, as we’re signing in by means of Jamf Attach… and in case you configured the Jamf Attach app in Azure accurately in keeping with the Jamf documentation, chances are you’ll understand that you configured it as a “Cellular and Desktop Software” and now not as a cloud / internet app…

So, the truth that the consumer account is triggering the CAP is predicted, and if I check in with any other consumer (assigned to the Jamf Attach app) I will be able to log in simply wonderful because the CAP does now not cause (anticipated). However why does the CAP observe right here if we set the CAP to “ALL CLOUD APPS”? Even supposing you could possibly attempt to prohibit the CAP to handiest decided on apps you’ll realize that you’ll now not even make a choice your Jamf Attach app… (as it’s a Cellular/Desktop app!)…

So, why does the CAP observe right here? Smartly, right here we return to the caution I mentioned previous… surroundings a CAP to “all cloud apps” IMPACTS THE AZURE PORTAL! And, if we glance carefully to the ‘Extra data’ segment at the password URL error message, we see that it’s NOT having access to our Jamf Attach app, however “Microsoft App Get right of entry to Panel” as a substitute!

This all mentioned, it’s utterly anticipated that this CAP is being evaluated…. however… my Mac IS REGISTERED to Azure and IS COMPLIANT ! So why is it being reported as unregistered?

Smartly, this brings me to the next Microsoft article, or particularly the know behaviour discussed right here: https://doctors.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-compliant-device#known-behavior

On Home windows 7, iOS, Android, macOS, and a few third-party internet browsers Azure AD identifies the system the use of a shopper certificates this is provisioned when the system is registered with Azure AD. When a consumer first indicators in during the browser the consumer is caused to make a choice the certificates. The tip consumer should make a choice this certificates earlier than they are able to proceed to make use of the browser.

Those that have some revel in with registering Macs to Azure/ Intune-MEM, is also accustomed to the Place of business Sign up for Certificates, which is the certificates this is being put in within the macOS Keychain when registering it to Azure. It’s this certificates this recognized behaviour is speaking about, and we will illustrate this via seeking to authenticate to Azure in a brand new browser (or by means of personal/incognito mode). Let’s attempt to entry the alternate password URL without delay from a browser:

As you’ll see, we first of all get the similar “error” or message as after we attempt to entry this URL by means of Jamf Attach, but when we hit proceed we get a pop-up prompting us to make a choice our WPJ certificates…. and… after that… all is okay:

If on the other hand we strive this once more in our restricted webkit browser… the app turns out to proceed, however we finally end up with being suggested to sign in our system.

If finish customers then try to observe those directions and sign in the system once more, we finally end up with plenty of headache inducing problems, replica Azure data, breaking compliance, and so forth…

Then again, AFAIK, the basis purpose for that is not anything greater than the truth that the restricted webkit browser cannot show the recommended soliciting for to make a choice the WPJ certificates, the method continues and finally end up with Azure (via loss of getting the cert and system main points) assessing the system as “now not registered”.

That mentioned, I’ve noticed eventualities the place to start with look an identical consumer accounts, on an identical units, inside the similar scope and settings of the CAPS, don’t cause the recommended to make a choice the cert. Now not within the restricted webkit browser and now not within the complete browser, whilst it does request it when making an attempt the similar authentication in a personal/incognito browser.

To me this should be associated with both SSO or chronic classes which may also be configured in Azure, however as this troubleshooting is already borderline via experience right here, I’d wish to discover this idea additional. Anyway, from inside my realm of experience, I’m assured to conclude that what I mentioned above is predicted behaviour for both Jamf Attach, the restricted webkit browser and the Azure CAP’s.

Please proper me if I’m fallacious.

Now, let’s transfer to how we will paintings round this and find out how to permit finish customers to entry the alternate password URL by means of the Jamf Attach Menu Bar app in subsequent segment of this blogpost.

Workaround opening a FULL browser by means of Jamf Attach

Sooner than we paintings round it from a Jamf Attach Menu Bar standpoint, I simply need to spotlight that you should imagine to not scope your CAP to “All Cloud Apps”, or exclude (or now not make a choice) the Microsoft Azure Control app…

The Microsoft Azure Control app contains the entry to the Azure Portal. However then this leaves us as to whether or now not you in reality want or need to prohibit entry to Azure Portal from Compliant units handiest or now not… which is I assume the explanation why you’ve got the CAP to begin with.

Similar is going for unticking ‘browsers’ within the Shopper Apps segment:

However that even is going additional towards any reason why for why you could possibly need it to be restricted to compliant units handiest… as no browsers in any respect would then cause the CAP.

Leaving this complete dialogue so that you can talk about internally, let’s take a look at what we will do from a Jamf Attach Menu Bar aspect to paintings round this.

If we agree on all of the above, concluding it’s the restricted webkit app breaking the recommended to make a choice the WPJ cert, and making an allowance for it really works in a complete browser… what if we disguise the in-built ‘alternate password’ characteristic for our finish customers, and create our personal by means of the ‘movements’ characteristic triggering it to open the URL in a complete browser?

Let’s take a look! I’ll attempt to stay this segment quick as it’s in reality directly ahead.

To begin, the documentation: https://doctors.jamf.com/jamf-connect/2.7.0/documentation/Custom_Menu_Bar_Action_Items.html?hl=motion

As in keeping with above, the one issues we wish to do are:

  • Create an ADDITIONAL plist for the motion pieces, set to the com.jamf.join.movements area
  • Configure the customized menu bar pieces
  • (Not obligatory) disguise the in-built alternate password merchandise

A easy instance of a plist for the com.jamf.join.movements can be:


<?xml model="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist model="1.0">
    <dict>
                <key>Movements</key>
                <array>
                    <dict>
                        <key>Motion</key>
                        <array>
                            <dict>
                                <key>Command</key>
                                <string>url</string>
                                <key>CommandOptions</key>
                             <string>https://account.activedirectory.windowsazure.com/ChangePassword.aspx</string>
                            </dict>
                        </array>
                        <key>Title</key>
                        <string>Click on right here to switch your Azure password</string>
                    </dict>
                </array>
    </dict>
</plist>

Scope that to your whole units the use of Jamf Attach.

Subsequent, upload the next for your present Jamf Attach Menu Bar plist:

	<key>CustomMenuItems</key>
	<dict>
                <key>movements</key>
                <string>Trade Password</string>
	</dict>
        <key>HiddenMenuItems</key>
        <array>
                    <string>changepassword</string>
                    <string>resetpassword</string>
        </array>

As you’ll see I additionally added the ‘resetpassword’ box to be hidden as the subject of this blogpost additionally applies to resetting the password by means of Azure.

Now, in case you push this transformation for your units you’ll see that the default alternate password choices are long past and the top consumer can alternate the password by means of our customized motion, which can open a FULL browser. Figuring out that they’re going to then be ready to make a choice the WPJ cert… all shall be wonderful!

Extending the dialogue at the factor to Jamf Attach Login

Now, as this all would possibly, imo, give an explanation for the behaviour and supply a workaround for Jamf Attach Menu Bar, I realised that scoping a CAP – set to “all cloud apps” and requiring the system to be criticism earlier than it will possibly entry the Azure Portal…. in reality additionally breaks Jamf Attach Login:

Making an attempt to proceed right here on the other hand finally ends up with a the web page now not progressing, being caught… looking forward to the cert recommended which cannot be displayed (in comparison to the webkit browser by means of Jamf Attach Menu Bar the place it does proceed and finally ends up with asking to sign in the Mac).

This this is on the other hand making a rooster or egg state of affairs… particularly in case you are putting in place the Mac for the primary time after going during the computerized enrolment. Your Azure CAP is obstructing the login as it does now not imagine the Mac to be compliant, however so that you could make it compliant and sign in it, you wish to have so that you could login… open Self Carrier… and run the registration coverage. And much more, if we have a look at our Menu Bar dialogue above, even making the system compliant does now not repair it because the restricted webkit browser in Jamf Attach Login would have the similar factor.

So this isn’t just right. Therefore the Jamf Attach documentation states: https://doctors.jamf.com/jamf-connect/2.7.0/documentation/Integrating_with_Microsoft_Azure_AD.html?hl=conditional

If you’re the use of Jamf Attach with Automatic Instrument Enrollment (previously DEP), take away this software from any conditional entry controls. The consumer shall be signing in to the pc earlier than conditional entry may also be instantiated.

Now, if we return to the “Setup your system” message and we have a look at the “extra main points” segment…

… we do see that Jamf Attach is on the other hand passing the ID of the JC Azure App… in comparison to our alternate password URL which is trying to entry Microsoft App Get right of entry to Panel (Azure Portal)…. so we will exclude it?

Smartly… NO as a result of if we set our CAP to “All Cloud Apps” and we attempt to exclude Jamf Attach….

… we will’t make a choice or to find our ‘Jamf Attach’ app…. as a result of… it’s now not a cloud / internet app…

This in reality brings me to some degree to conclude: don’t set your CAPs to all cloud apps in case you are requiring the units to be compliant. I feel proscribing it to these cloud apps which in reality want it will possibly simplify issues, however once more, I go away that dialogue as much as you and your Azure/safety workforce.

In subsequent and ultimate segment of this blogpost I’ll undergo making a customized app for Jamf Attach Login, which may also be excluded from any ‘all cloud app” CAPs and system compliance.

Workaround for Jamf Attach Login: customized cloud app

To try this I primarily based my steps on: https://neighborhood.jamf.com/t5/jamf-connect/jamf-connect-and-microsoft-azure-conditional-access/td-p/231944

This text used to be principally written in view of the ‘failure’ messages you get within the Azure sign-in logs when doing password validations with ROPG by means of Jamf Attach, when you’ve got MFA CAPs enabled.

Surroundings the mistake code AADSTS50076 as a good fortune code within the JC plist, lets in JC to look the mistake message as a good fortune and imagine the password to be legitimate. Then again, on Azure aspect, this will likely unsolicited mail the sign-in logs with ‘screw ups’ pointing out the customers attempted to authenticate with out MFA.

In any case, the good fortune code means that you can make Jamf Connection Menu Bar paintings with none issues, and prefer I discussed previous, in case you handiest have CAPs which might be imposing MFA, all is just right.

With a view to paintings across the have an effect on of CAPs with compliance necessities on Jamf Attach Login, I did on the other hand take this workflow as a baseline to mend JCL right here.

What I did used to be principally (in case you move to the Github pdf related in that article):

  • Step One: Create an software registration with a customized API
  • Step Two: Create an software registration the use of this new API permission
  • Step 3: Create an Azure Conditional Get right of entry to coverage

I didn’t do step 3 as in keeping with this blogpost I already had a CAP… which brought on this complete dialogue, so what I did right here, used to be to exclude the App I created in step One (so now not the local desktop app created in step two):

  • Subsequent, I assigned my endusers (in my case for trying out the CAP, the consumer to which the CAP applies) to the app created in step 2. As this would be the app for which I’ll configure the Jamf Attach plists. No wish to assign any customers to the app created in step 1.
  • I didn’t do step 4 (take away all CAPS scoped to ‘all cloud apps’) as doing so would principally make this complete blogpost unnecessary 🙂
  • I additionally didn’t do step 5. As a substitute I simply used the similar app I created in step 2 for each OIDC and ROPG. Once I did on the other hand take a look at it, even with out putting off the API permissions as in keeping with (non-compulsory) this step, and level ROPG to another ROPG app in Jamf Attach Login, I stopped up with an error ‘no consent’ when validating the password at login. So I stored it at identical app for OIDC and ROPG.
  • In any case I configured the Jamf Attach Login and Jamf Attach Menu Bar plists.

Jamf Attach Login plist, with OIDCScopes set to that further API app we created in step 1. OIDCClientID and OIDCROPGID set to the app we created in step 2 and the customized OIDCProvider and OIDCDiscoveryURL:

<?xml model="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist model="1.0">
  <dict>
    <key>AllowNetworkSelection</key>
    <true/>
    <key>OIDCClientID</key>
    <string>97d0a5fb-AAAA-BBBB-CCCC-530ff05e81c2</string>
    <key>OIDCNewPassword</key>
    <false/>
    <key>OIDCProvider</key>
    <string>Customized</string>
    <key>OIDCDiscoveryURL</key>
    <string>https://login.microsoftonline.com/af72a024-AAAA-BBBB-CCCC-fd66bf369fcc/v2.0/.well known/openid-configuration</string>
    <key>OIDCScopes</key>
    <string>api://9e690060-AAAA-BBBB-CCCC-2e68d657f2ac/jamfconnect</string>
    <key>OIDCROPGID</key>
    <string>97d0a5fb-AAAA-BBBB-CCCC-530ff05e81c2</string>
    <key>OIDCRedirectURI</key>
    <string>https://127.0.0.1/jamfconnect</string>
  </dict>
</plist>

I then additionally modified my Menu Bar plist to make use of that very same app from step 2:

<?xml model="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist model="1.0">
<dict>
	<key>IdPSettings</key>
	<dict>
		<key>Supplier</key>
		<string>Azure</string>
		<key>ROPGID</key>
		<string>97d0a5fb-AAAA-BBBB-CCCC-530ff05e81c2</string>
                <key>ChangePasswordURL</key>
                <string>https://account.activedirectory.windowsazure.com/ChangePassword.aspx</string> 
                <key>SuccessCodes</key>
                <array>
                <string>AADSTS50005</string>
                </array>
	</dict>
	<key>Kerberos</key>
	<dict>
		<key>AutoRenewTickets</key>
		<true/>
		<key>Realm</key>
		<string>TRAVELLINGTECHGUY.DEV</string>
	</dict>
	<key>SignIn</key>
	<dict>
		<key>AutoAuthenticate</key>
		<true/>
		<key>RequireSignIn</key>
		<true/>
	</dict>
	<key>CustomMenuItems</key>
	<dict>
                <key>movements</key>
                <string>Trade Password</string>
	</dict>
        <key>HiddenMenuItems</key>
        <array>
                <string>changepassword</string>
                <string>resetpassword</string>
        </array>
</dict>
</plist>

This allowed me to log in by means of Jamf Attach Login, validate the password by means of ROPG in Login and Menu Bar and use the alternate password URL by means of a complete browser.

The one factor I do see is that the above workflow, similar to when doing MFA for “All Cloud Apps” with out deploying the customized setup from the Jamf Country article, is logging sign-in mistakes with AADSTS50005 when Jamf Attach Login is validating the password at login by means of ROPG. Then again, the login and password validation succeeds, even with out including AADSTS50005 as a good fortune code. I see it first logging a failure towards the App we put within the plist (step 2 in my workflow above), adopted via a good fortune towards the app we created for the customized API. To me this may be anticipated because the app we in reality authenticate to continues to be the only we will now not exclude from the CAP.

Conclusion

I in most cases come throughout eventualities the place admins are imposing MFA for authentications to their iDP. And with MFA, even though a CAP is about to “All Cloud Apps”, we in most cases don’t see a lot problems.

Jamf Attach Login handles MFA by means of OIDC (the internet app auth) reasonably smartly, and for the ROPG password validation, the good fortune code may also be added to translate the mistake message (AADSTS50076) right into a validation of the password.

Similar is going for Jamf Attach Menu Bar.

Then again, using the good fortune codes does unsolicited mail the sign-in logs with ‘screw ups’ when MFA is brought on via unnoticed via Jamf Attach and the good fortune code. Therefore the cause of this newsletter: https://neighborhood.jamf.com/t5/jamf-connect/jamf-connect-and-microsoft-azure-conditional-access/td-p/231944

Now, I do wish to give this newsletter/workflow any other move in view of purely trying out MFA, as for my weblog publish right here I used a CAP requiring the system to be compliant as a substitute of triggering MFA.

Something I did see on the other hand is that in case you take away the API permissions as in keeping with step 5 in that article the ROPG in Jamf Attach Login hits a ‘no consent’ error when validating the password.

Now, this weblog used to be a unconditionally other setup.

  • By way of preserving the CAP set to “All Cloud Apps” and requiring the system to be compliant I used to be ready to paintings round it via including AADSTS50005 as good fortune code in Menu Bar, and transferring the alternate password URL to a customized motion.
  • By way of doing so, Jamf Attach Menu Bar app works utterly wonderful!
  • Then again, the truth of preserving the CAP to “All Cloud Apps” spams the logs with AADSTS50005 mistakes. This without reference to the extra exams with a customized API app (see Jamf Attach Login trying out)
  • For Jamf Attach Login, the truth of getting an “All Cloud Apps” CAP with “Require system to be compliant” breaks jamf Attach Login. If so you’ll wish to undergo a fancy setup as in keeping with above so that you could exclude the Jamf Attach Login app.
  • Similar as with MFA, you are going to have screw ups within the sign-in logs

This all leads me to conclude that surroundings CAPS for MFA or Compliance to “All Cloud Apps” is perhaps now not the most efficient method in case you are deploying Jamf Attach.

For MFA I might handiest use it on a make a choice workforce of apps, together with Microsoft Azure Control (Azure Portal). This will have to can help you observe the Jamf Country article about JC and MFA to steer clear of the unsolicited mail of sign-in screw ups within the logs, and the whole thing, together with the default alternate password characteristic, will paintings wonderful.

For CAPS with “Require the system to be compliant” I’m tempted to mention the similar. Restrict it to these apps for which you in reality need / want the system to be compliant, and don’t make a choice the Microsoft Azure Control or “All Cloud Apps” within the goal of the CAP. Your primary apps offering entry to corporate information shall be secure via the compliance requirement, and for the Azure Portal you’ll require MFA by means of a separate CAP for the Microsoft Azure Control app. Doing so there can be no use for any advanced setups like this for Jamf Attach Login or Jamf Attach Menu Bar.

In any case, vital to say may be the adaptation in the place you do put into effect MFA, as in keeping with the Jamf Country article:

Directors can allow multi-factor authentication necessities for a consumer account in two techniques:

– Multi-factor Authentication which is reachable by means of the “All products and services” listing within the Azure portal
– Conditional Get right of entry to which is reachable by means of Azure Lively Listing below Safety

Multi-factor Authentication is a machine large, all login makes an attempt, grasp transfer machine for imposing MFA at authentication. Whilst IP cope with levels may also be exempted, the principles observe to all authentications.

Conditional Get right of entry to lets in for wonderful grain main points to use for when MFA is needed together with exempting MFA for internet programs.

Lengthy tale quick, I’d say: Conditional Get right of entry to, MFA, Compliance, and so forth… reasonably a fancy subject, topic to how and the place you configure it.

Please, for any Azure Wizards in the market, please don’t hesitate so as to add feedback, remarks or corrections to anything else I’ve been writing right here, however as a TLDR I’d like to near this off with: steer clear of “All Cloud Apps” to your CAPs the place imaginable.

That’s it! As at all times, in case you appreciated the publish, hit the like button, inform your pals about it and go away a remark down underneath!

Brgds,
TTG

https://macbookblackfriday.com/