Hi all!
As Jamf Connect 2.0 has been released, I want to go through updating (or installing), the new release. I’ll be using the Jamf Connect app which I already have configured in Azure, so please review the Jamf Connect documentation on how to configure this, or one of my previous blogposts on the matter.
So for this post, let’s go through the following topics:
What changed?
Release notes: https://docs.jamf.com/jamf-connect/administrator-guide/Release_History.html
First of all the most important change is the fact that both Jamf Connect Sync and Verify have been merged into one app, called Jamf Connect (aka the menu bar app)
Apart from that, Jamf Connect Login and Jamf Connect have been merged into one installer package.
This means that the Jamf Connect 2.0.0 package installs the following components on computers:
Some important changes:
- The browser extensions have been discontinued
- A new app icon for the menu bar app (Jamf Connect)
- Network Selection: The “Allow Network Selection” button has been replaced with a WiFi icon in the upper-right corner of the login window
- Local Login: The “Local Auth” button is now named “Local Login” and appears along the bottom of the login window.
- Error Messaging: Some error messages have been improved to help users troubleshoot configuration issues.
- Custom Login Window Message: You can now add a custom message to the login window by configuring the LoginWindowMessage preference key.
- Authchanger improvements: The commands arguments executed by the authchanger tool can now be read from a configuration profile. The Jamf Connect installer does not add any arguments to authchanger by default. More about the different methods to change the login window below.
- Licenses: The Jamf Connect menu bar app will now check both the com.jamf.connect and com.jamf.connect.login preference domains for a valid license.
- Menu bar launchAgent: A launch agent for the Jamf Connect menu bar is included as a separate installer package in the Jamf Connect DMG. When installed on computers, the launch agent will ensure that Jamf Connect remains open.
Note: Jamf may collect hashed data about license usage. This data is used to monitor the number of licenses in use with Jamf Connect in your organization and does not include any Personal Information.
Changes to the Preference Domains and Keys
Renamed Preference Domains
The Jamf Connect menu bar app is configured using a single preference domain:
com.jamf.connect
The com.jamf.connect.sync and com.jamf.connect.verify have been discontinued.
Note: Login window preferences will continue to be written to the following domain: com.jamf.connect.login
Renamed Preference Keys
Please check the following link for an overview of all the changed/renamed preference keys (see below for example configuration profiles): https://docs.jamf.com/jamf-connect/administrator-guide/Release_History.html
Additional Changes
- Custom URL scheme, see Jamf Connect URL Scheme. Administrators can perform actions with Jamf Connect using the command line.
- The CreateJamfConnectPassword key in Jamf Connect Login allows Jamf Connect to automatically populate the Sign In window in the menu bar app with a user’s network username and password that was used to log in or create a new local account with Jamf Connect. This setting is enabled by default and replaces the Create Jamf Connect Sync Keychain (CreateSyncPasswords) and Jamf Connect Verify Keychain (CreateVerifyPasswords) settings used in Jamf Connect 1.19.2 or earlier.
- The Jamf Connect loginwindow mechanism that enables FileVault now only runs if the Enable FileVault (EnableFDE) setting is enabled in the Jamf Connect login window configuration profile.
- The Retrieve Kerberos Tickets During Sign-in (GetTicketsAtSignIn) setting has been removed from the menu bar app. Jamf Connect now automatically retrieves Kerberos tickets for users if a Kerberos realm is configured with the Kerberos Realm (Realm) setting.
And last but not least, the design of the Login Window also changed. This gives you more control on branding the deployment and make the Jamf Connect Login Window feel a bit more familiar to the end users. Apart from a more modern UX for the login window itself, background image changes and a new Wifi symbol, the login window will now also include a progress bar allowing user to better understand what is going on when authenticating to their Macs. The login window can now show progress as: Authenticate -> Connect -> Verify.
Preparing the upgrade
As a good practise, starting with reading the official documentation is aways a good first thing to do: Upgrading to Jamf Connect 2.0
Once that’s done, let’s assume I have Jamf Connect installed on my Macs and I want to upgrade, what do I need to do?
- Customise the Jamf Connect installer package (optional, but needed for instance if you want to add custom logos and background images)
- Create a new configuration profile for Jamf Connect Login
- Create a new configuration profile for Jamf Connect (menu bar app)
- Configure the authchanger
- Create a smart group to remove the old configuration and push the new one
Customise the Jamf Connect installer package (optional, but needed for instance if you want to add custom logos and background images)
For a standard deployment test I could just take the Jamf-provided JamfConnect.pkg to install it. However, in view of the changes made to the login window interface, I’d like to test the custom backgrounds and logos as well. Yes, you could package those up into a separate package and deploy both, up to you. I’ll go for one custom package here. I want to have a look at the change in the installer anyway.
The change I’m referring to here is the fact that “The Jamf Connect installer does not add any arguments to authchanger by default“. Let’s check that by having a look at the postinstall script of the new Jamf Connect installer:
As you can see, there is no authchanger command added to this postinstall script, compared to previous Jamf Connect 1.x version:
If you want you can add this authchanger commands back into the post-install script, as per commented commands in the screenshot below. More about the authchanger below in this post.
I my example above I’m not configuring the authchanger (commented), I’m only telling the postinstall script to install the official Jamf Connect installer, which I deploy into the /tmp folder via the package content. This along with some custom images:
Now, apart from exporting the pkg, don’t forget to sign it with a publicly trusted code-signing cert, or the Jamf Pro built in CA, if you want to use the package in prestages for Automated MDM enrolment!
Via Composer:
Or via Terminal:
productsign --sign "[Signing Certificate]" ~/Desktop/example.pkg ~/Desktop/signed-example.pkgCreate a new configuration profile for Jamf Connect Login
With our custom package created and uploaded to our distribution point, let’s now have a look at the configuration profiles. My preferred way of doing this so far was to write my own plist. This is view of keeping the overview of all the keys which I want to configure.
However, the new Jamf Configuration tool now includes an XML editor which you can use to check the plist on the go when adding values to the keys you want to configure. Love it!
So, let’s start adding some keys to this. In view of the purpose of this post, testing out the new Jamf Connect 2.0, I’ll keep the configuration quite basic. Additional keys can be added depending your deployment scenario. I’m using Azure for this post (ok, my Azure is linked to my on-prem AD, but I have ADFS federation disabled and password hash sync enabled so my config will be a simple walk in the park).
- Set the Identity Provider to Azure
- Add the Client ID for the Jamf Connect app which I have in Azure
On the Login tab I set my Admin role (to force Jamf Connect to create accounts with admin privileges for those iDP account which have the ‘Admin’ role assigned in the Azure Jamf Connect App: see https://docs.jamf.com/jamf-connect/administrator-guide/User_Roles_for_Local_Accounts.html)
(Note: You could also check the 'Create Jamf Connect keychain' option to pre-populate the user info in the menu bar app, but Jamf Connect 2.0 actually enables that by default).
As I have PHS enabled (Federation disabled) I do not set anything in the Hybrid secion:
And finally, I allow the network selection, set a Login Window Message and add the path to the custom background and logo (see the package I created above):
That’s it for the Jamf Connect Login config, which we can now check in the plist:
Create a new configuration profile for Jamf Connect (menu bar app)
Now for Jamf Connect, aka ‘menu bar app’, I’ll keep things simple here as well.
The ‘ROPG Client ID‘ should already be filled in automatically:
For the fun of it, I’m adding my Kerberos Realm:
Next, I selected Automatic Sign-in and Require Sign-in (this to use the keychain to automatically log in, and enforce the sign-in window to stay open until the user successfully authenticates). I also defined the Sign In Logo, which I set to the same logo as the one for Jamf Connect Login. The pixel size is probably not optimal, but let’s see how it turns out.
This gives us the following plist:
With both plist configured, I can now hit the test button in the top right corner and test both OIDC and ROPG:
That looks good, so let’s export the plists. Is stick with .plist as I like to make changes directly to the file when needed. Don’t forget to save both plist as com.jamf.connect.login.plist and com.jamf.connect.plist.
Configure the authchanger
Instead of running the authchanger commands by default via the postinstall script, Jamf Connect Login 2.0 will now instead look at the following order of configuration sources to configure the Login Window:
- Commands executed via the command-line. This either manually in Terminal or via a Jamf Pro policy with a script or the Files & Processes payload. Consider the following scenarios:
- If a command is executed with arguments, any preferences found in a configuration profile will be ignored.
- If a command is executed without arguments, Jamf Connect will look for preferences in a configuration profile.
- Preferences found in a configuration profile written to com.jamf.connect.authchanger
- The Identity Provider (OIDCProvider) or Auth Server (AutherServer) preferences written to the com.jamf.connect.login domain. These pass the -JamfConnect argument to automatically enable OpenID Connect or Okta authentication.
- If no arguments or preferences are found, the default loginwindow mechanisms will remain unchanged
Hereby a quick example of a plist to set the com.jamf.connect.authchanger domain:
<?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>Arguments</key>
<array>
<string>-reset</string>
<string>-jamfconnect</string>
</array>
</dict>
</plist>More information about advanced authchanger configuration can be found here: https://docs.jamf.com/jamf-connect/administrator-guide/authchanger.html
I my test here I did not change anything to the authchanger (nothing in the postinstall script, no additional profile, no Terminal commands or Jamf Pro policy script), so it should enable the Jamf Connect Login Window via the OIDCProvider key in my plist.
Create a smart group to remove the old configuration and push the new one
As we are aiming to replace to old configuration of Jamf Connect v1.x, by configuration profiles for 2.0, we’ll use the following Smart Group to achieve this. This will be set as the target scope for the v2.0 config profiles, and as exclusion in the v1.0 profiles.
Deploying the upgrade
With our custom package and plists created, let’s now put this all together into Jamf Pro:
- Create a policy to update Jamf Connect for all required devices
- Upload the new configuration profiles and scope them to the v2.0 Smart Group
- Remove the old configuration profiles by putting the v2.0 Smart Group into exclusion
Create a policy to update Jamf Connect for all required devices
First thing we’ll do is creating a policy to install Jamf Connect 2.0. Upload the installer (and the LaunchAgent) to your distribution point, and create a policy to install them. Make sure to add an inventory update to make sure our v2.0 Smart Group is going to be updated. Scope this policy according to your deployment strategy for devices which are using Jamf Connect, for instance, a specific Computer Group, a Smart Group, or All Computers with the v2.0 Smart Group we created as exclusion. Once per computer.
In Jamf Connect Verify, there was a launchAgent installed by default which forced the app to open after login. In v2.0, the Jamf Connect installer does not include the launchAgent by default. Hence this needs to be deployed separately. I added it to the Jamf Connect installation policy (optional).
The launchAgent installer can be found in the Resources folder of the Jamf Connect DMG. Just upload it to your distribution point and deploy it with a policy.
Upload the new configuration profiles and scope them to the v2.0 Smart Group
As mentioned before, I prefer the .plist method for various reasons. The most important one is that I use the configuration tool to quickly give me the initial plist structure, and later on I add additional keys where needed via my favourite text editor (for testing or configuring additional features).
Remove the old configuration profiles by putting the v2.0 Smart Group into exclusion
Testing the upgrade
Run your policy to install Jamf Connect 2.0. This will:
- Install Jamf Connect 2.0
- Install Jamf Connect Login 2.0
- Install the LaunchAgent (optional)
- Remove Jamf Connect Sync and Jamf Connect Verify apps
- Stop and remove Jamf Connect Sync and Jamf Connect Verify launch agents.
- Any associated installer receipts will be removed from the installer system.
Next your v2.0 Smart Group will be updated and:
- Push out the v2.0 configuration profiles for Jamf Connect and Jamf Connect Login 2.0
- Pull the v1.x configuration profiles from the system
The result:
Our policy runs:
Jamf Connect Verify is replaced by Jamf Connect (menu bar app):
Our v2.0 Smart Group is updated (disregard the duplicate Macs, it’s my physical Mac and its alter-ego VM version):
Our old profiles are removed and replaced by the v2.0 versions:
And we have our new Login Window:
After logging in via Jamf Connect Login, which by default creates a keychain for Jamf Connect, the LauchAgent kicks in and automatically authenticates me. Including the generation of a Kerberos Ticket.
Installing a fresh 2.0
Well, not sure why I added this as a separate topic, because it’s basically the same as everything above, except the part of putting the the v2.0 Smart Group as exception on the (non-existing) v1.x configuration profiles:
- Create a custom package with backgrounds, wallpapers, authchanger postinstall settings, … (optional)
- Upload the installer and the LaunchAgent to your distribution point
- Deploy the installers via a policy or prestage package (for prestage: sign the package and use a Cloud / HTTPS distribution point!)
- Create a Jamf Connect Login 2.0 and Jamf Connect 2.0 plist
- Upload the plists to Jamf and scope them according to your deployment strategy
- Reconfigure the authchanger (where needed)
That’s basically it! Yes, there are so many other features you can enable in Jamf Connect, but elaborating any of them any further would take this long post again way too far. Don’t hesistate to reach out to me if you have any questions!
My conclusion? I love Jamf Connect 2.0! Really, you know me, I advocate free speech. If I did not like it, I would say so, or maybe just not blog about it and pretend it does not exist :-). To me Jamf Connect 2.0 really feels solid, easy to deploy and overall less confusing compared to V1.x. Mainly thanks to the renewed configuration/plist key logic.
That’s it for now! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!
If I missed something, or you see different behaviour to what I discussed above, let me know!
Brgds,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Senior Enterprise Support Engineer | Jamf
Hey, brilliant guide! Many thanks.. have you seen in your testing a scenario where it will only work when upgrading from v1? Sure I am missing something.. if I upgrade to v1 to v2 using the above guide, it works great. If I do a fresh install of v2 with same plists, I either don’t get the Jamf connect login window for azure, or sometimes it does show and after verifying password, the screen just goes grey with a mouse pointer. Mostly though, he login window doesn’t show up, just the FileVault login. I haven’t added anything to to authchanger, just basic setup as above. Any idea what’s going on here?
Hi, the grey login window is something requiring a deeper dive into the logs and setup (both plist and iDP app). FileVault however sounds like expected. If FileVault is enabled, default behaviour is to skip JC Login Window. Just like it skips the native login window: https://travellingtechguy.blog/understanding-the-macos-authentication-flow-with-filevault-and-or-jamf-connect/
great update
2 questions
I ( and also some other as I can see on slack etc) are expierencing issues when doing dep enrollment with Jamf connect. Instead of showing jamf connect window it just goes to normal account creation. If I wipe the machine, it may work next time and other times I have to do it more times, so seems very random that the jamf connect package kicks in. Is that a known issue ?
2. When changing the password in jamf connect it launches a webinterface. It is possible to set window size on browser there. On old version users have manually to rezise window to enter old and new password – not very user friendly
Hi!
For issue 1:
What type of distribution point are you using? And is Jamf Connect actually installed when it shows the native login window? You can check by logging in with your managed admin and see if the menu bar JC app is installed.
Are you using a custom package or a Jamf provided one?
If using the default package and JC is installed correctly, the fact that it shows the native macos login window is probably because the authchanger did not run.
As mentioned in the blog, 2.0 does not manually run a command to do so. It looks for config profile. So how did you configure the profile? Added to the prestage? Scoped correctly?
If the profile is added in prestage but not scoped correctly it may install and later be removed at end of enrolment before reaching the login window. Hence JC has no trigger to show the JC login window.
Or the profile installation was delayed for some reason, and you hit the login window before it installed… scoped via smart group by any chance?
For Q2, no keys to change the window to my knowledge unfortunately
Actually I used a custom package that you created in a old blog on your page that I followed. But I could actually try just to add the default package from jamf and config profile. I scope it to “all computers”
My only concern is that I only want the JCL login window to happen in pre-stage enrollment and not during normal login. If I apply the config profile to all computers I guess it will then give issues or ?
If you created a custom package, the reason it skipped installation can be a problem with then package. Did you sign it correctly? Are you using a Cloud Distribution point (I think there is a problem with HTTPS distribution points and prestage).
But you’d have to check if the issue is:
– package did not install
– or login window was not flipped to JC
I am using jamf Cloud and it is signed correctly the package.
If I scope the config profile to all computers in pre-stage should that be enough – or should the config profile also be scoped out-side the pre-stage, as again I don´t want the JCL window to appear after the mac has enrolled
No, if you add the configuration profile to a prestage without scoping it correctly to your computers, the following will happen:
– Before the Setup Assistant kicks in, the prestage is installing the profile.
– Next the Setup Assistant continues, and Jamf Pro is starting calculations on the scoping of all your profiles and policies
– Because the computer is not in the scope of the profile, Jamf Pro removes the profile again
– You reach the end of the Setup Assistant and the login window is triggered, but because there is no profile to tell JC 2.0 to flip the login window (because the profile was installed and removed by lack of scope) you get the native macos window
So you need to be sure to have the computer which is enrolling in the scope of the profile itself.
If you want to disable JCL after enrolment, you will need to disable the JC Login window later: https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/authchanger.html
This preferably by pushing another profile setting the com.jamf.connect.authchanger domain or command line
OK thansk – last question. Today none of the computers have jamf connect installed. So if I scope the new profile to all computers, will they have issues logging in, as I understand that the config profile change the auth to jamf connect
If JCL is configured correctly they should not have an issue logging in, you could just add the migrate key to migrate them to a JC linked account.
But if that is not what you want, then make a smart group linked to the prestage you are using and set that as scope for he profile. Then add a logic with command line or authchanger profile to reset JCL to native login window at the end of the enrolment
Sorry – I am not sure I understand or we are talking about something different
Today all our clients that already are enrolled is working without the JCL window and not jamf connect installed.
So If I add the new config profile for JCL 2.0 and push to all clients that are running, will that change it to JCL login window, which then will give issues as jamf conncet is not installed
No because the profile will do nothing. It changes the authhanger which is installed with Jamf Connect. If the authchanger is not installed, the profile does nothing. The authchanger is a Jamf Connect binary, not a built in macOS thing.
Arh ok – that was the mainpoint. Actually thought that authchanger was a binary in OS
thanks:)
I did a comment earlier I cannot see ..??
But can just add, I tried to login with the management account and afterwards depotify kicks in with the enrollment –strange ?
Org Tex for com.jamf.connect.authchanger
Arguments
-reset
-jamfconnect
Shouldn’t it be?
Arguments
-reset
-jamfconnect
Hi James, what am I missing? What is the difference?
Hi James, now I found what you ment. Typo in the key / string attributes! Corrected. Sorry the blog did not show < > characters in your comment.
I also only want only jamf connect window at pre-stage and not afterwards
But as also noticed in earlier post, you will have to scope the JCL config profile to both in pre-stage and in generel to all clients
But even I in my depnotify script at the end of pre-stage do a reset of the auth, the config profile will still overwrite it back as far I know config profiles work
So the only solution should be to do a trigger and remove the clients from the smart group the config profile is assigned to after pre-stage?
No, the authchanger is designed to give priority to instructions set by command line: https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Release_History.html
Note: Jamf Connect will look for authchanger arguments in this order.
Commands executed via the command-line. Consider the following scenarios:
If a command is executed with arguments, any preferences found in a configuration profile will be ignored.
If a command is executed without arguments, Jamf Connect will look for preferences in a configuration profile.
Preferences found in a configuration profile written to com.jamf.connect.authchanger
The Identity Provider (OIDCProvider) or Auth Server (AutherServer) preferences written to the com.jamf.connect.login. These pass the -JamfConnect argument to automatically enable OpenID Connect or Okta authentication.
If no arguments or preferences are found, the default loginwindow mechanisms will remain unchanged.
So, flipping the login window back to native macOS by command line should take priority.
OK I see. So if I just push a config profile to all mac´s that are enrolled (smart group) it should be ok. Just getting a little panic if suddenly wrecking login screens
Looking at the jamf connect configurator, it does not seem to be able to reset the author, so have to make a config profile outside
Yes, good point. But I’m sure the dev team is constantly working on improvements and additional features.
One thing about everything discussed above: as always, always test before mass deploying. I’m doing the same but can’t always catch all edge cases. I try, time permitting.
Hi,
Thank you for the great guide! Have you tried this with ADFS? We have JCL 1.x set up and Jamf Connect Verify is configured to do a ROPG against ADFS. This is working as expected with Jamf Connect Verify, but with JCL 2.0 it results in the following error:
“Error from request to URL: https://adfs.domain.com/adfs/oauth2/token/, ERROR: The operation couldn’t be completed. (JCAuthentication.JCAError error 15.), STATUS: Optional(403)”
However, when doing a normal JCL login everything works. The error appears after you login and try to sign in using the Menu Bar App.
Hi Carl, I saw that error indeed. A colleague asked me about it. However I have not test ADFS myself yet. So I need to get used to new type of error messages and challenges like ADFS. Just to be sure, in JCL 2.0 you also have OIDCNewpassword set to false right (to confirm ROPG is really used in JCL?). I’ll switch my Azure to Federated again and test ADFS asap.
Yes, I can confirm that I do have the OIDCNewpassword set to false. I have also opened a ticket regarding this with Jamf, but have not heard back from them yet.
Same error here.. password sync actually seems to work but I get that error every time. Also logged with jamf
I also had this. Change the provider from Azure to Custom in the plist. There’s not an option in configurator.
Hi I just refederated my Azure with ADFS and configured JC and JCL as a pure Azure config. No ADFS keys, no ADFS app or discovery URL.
I do have PHS enabled but now together with the user -sign in configured as Federation.
JCL: Auth against Azure in webApp, redirected to ADFS login window, additional window to do ROPG check. WORKS
JC: Authenticate with Azure account. WORKS.
Only problem, as stubborn as I am, I have this enabled:https://travellingtechguy.blog/jamf-connect-with-adfs-federation-and-allowcloudpasswordvalidation/
Works fine and allows me not to use any ADFS config in the plists.
Federation Enabled (so user sign-in is Federated)
PHS Enabled
AllowCloudPasswordVallidation Enabled
I will test again without CloudPasswordValidation
Ok, disabled AllowCloudPasswordValidation => Error 15 (and JCL fails)
But this is with a pure Azure PHS config for JC, which is not supported by Jamf.
So now, still with AllowCloudPassword Validation disabled, I’ll configure JC in the supported way with ADFS app and making it talk directly to ADFS for ROPG… Will keep you posted.
I have the correct keys set up (ROPGID and DiscoveryURL) but still getting the error 15.
Jamf responded that this seems to be a known issue (PI-008742)
Carl, sorry that’s not correct. I’d contact support again. It works fine for me after identifying the documentation typos with the key. As I did not test with ADFS before, and I copy pasted the keys from the manual… it had that issue. I can confirm I works fine with ADFS with the correct keys. I did however run into the same error as it seems my profile was not honoured by the menu bar app. Unscoped the profile, created a new one and it works.
UPDATE: Documentation issue.
This plist works. Note the following keys:
OIDCROPGID should be ROPGID
ROPGDiscoveryURL should be DiscoveryURL
Hi.. sorry, do you mean that plist works for you with AllowCloudPasswordValidation disabled? I am having this problem too with AAD phs, Error 15, Status Optional 400. Same using a plist of entering the details directly into Jamf Menu..
Tried entering as Custom with ROPG client id and secret, and also tried Azure with ROPG client id and secret. If I enter the discovery URL manually, as ‘https://login.microsoftonline.com/TENANTID/oauth2’ I see error ‘the data couldn’t be read because it isnt in the correct format’.
I feel I am getting a config wrong somewhere. Is the discovery URL required and am I using the correct url?
Hi Matt,
So, AllowCloudPasswordValidation is only when you configure JC against Azure. For both OIDC and ROPG. If enabled on the adfs server it allows Azure to validate the password via ropg against adfs. I’m still trying to find a Microsoft adfs guru to validate all consequences of enabling that…
But the official Jamf supported way of doing JC with adfs federated tenants is to configure JCL OIDC against Azure and JCL ROPG and the menu bar app directly against the adfs farm via an app in the adfs application group on the on prem server.
Do not try to do ROPG against Azure if the tenant is federated. It just does not work. Unless you have AllowCloudPasswordValidation enabled.
So for all ROPG actions in both login as menu bar app, you need to set the ropg provider to custom and define the discovery url. This should be the adfs server discovery url and can not be something with login.microsoft… it needs to be something like adfs.mydomain.com/adfs… your adfs discovery url. Ropg provider can not be Azure. Needs to be custom.
I’m planning to do a quick post with overview of my plists for adfs later today.
Thank, that would be really helpful, will read that when you do 🙂 We do have ADFS with Azure sso.
In our plist for V1 JCverify, we didn’t specify a discovery url, just client secret, OIDCprovider = Azure, OIDCropgid and tenant id, and it worked fine.
Yes doing the same in V2 doesn’t – well.. it actually does sync the password up fine in the menu, but always shows the error 15 first.
Ok just to understand your exact setup. If you go Azure -> Azure AD -> Azure AD Connect: you have Federation = enabled and above that PHS enabled too right? Like this:
Hey, thanks again..
Well, i was told by our azure team when i installed v1 we were adfs. this is what i see in azure ad connect
AD hybrid services. Learn more
PROVISION FROM ACTIVE DIRECTORY
Azure AD Connect cloud provisioning
This feature allows you to manage provisioning from the cloud.
Manage provisioning (Preview)
Azure AD Connect sync
Sync Status Enabled
Last Sync Less than 1 hour ago
Password Hash Sync Enabled
USER SIGN-IN
Federation Disabled 0 domains
Seamless single sign-on Enabled 1 domain
Pass-through authentication Enabled 5 agents
We have a hybrid aad setup
Ok you are not adfs federated. Sso ok but no federated. PTA/PHS instead. So for you there should be no need of doing anything with custom provider of adfs discoveryurl etc. For me (before I enabled federation again) the very basic plist with Azure as provider works just fine, but make sure to have the new plist structure with iDPsettings key etc. So I’d just try with the configuration tool and set it to Azure and test OIDC and ROPG.
Great, thanks again.
So recreated the plist, with idp settings, just azure, my ROPGID and tenant. tests fine in config tool with both OIDC and ROPG. saved plist and deployed to test macs.
changed AD password so mac local password and ad were different, waited for sync message.
When it showed, i got the jCAerror 15 status: optional (400) message. clicked ok, then if i type the wrong password i get the error back. if i type the right ad password, it syncs.
On another mac, with different local and ad password, if i dont use JClogin, and just deploy that menu plist – in menu, i click connect, enter username. if i type the wrong password i get the jCAerror 15 status: optional (400). if i type the right password it is fine and syncs.
So the error only shows when it detects the password it is using is not the right ad password. The full error is :
Error from request to URL : https://login.microsoftonline.com/TENNANTID/oauth2/token, ERROR: the operation couldn’t be completed. (JCAuthentication. JCAError 15.), STATUS: Optional(400).
What does yours show when the password is not correct?
thanks again
Interesting! Will be testing!
It is.. it is actually functioning, but giving that error every time it detects the password is different to what AD has – thanks for looking at this
How is it possible to disable the end user agreement step. Really not something users need to waste time on in our enviroment
Which agreement step are you referring to please? Within the Azure webapp window?
If you look at the configurator there is under jamf login there in the buttom is end user agreement. You can not remove this as I see ?
This is not mandatory. These are optional configurations you can add. If you don’t configure it, it doesn’t do anything.
In my testing it shows just a White page with no text and only a agree button as I haven’t entered anything. So don’t know how I can get rid of this
You must have added the keys by clicking into it or something. Check the plist or xml and remove them. Or start over with new config
So what exactly is wrong with the keys in the documentation? To me they seem to be correctly documented (ROPGID and DiscoveryURL)
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Menu_Bar_App_Preferences.html
In the page for federated setups the title in the left column is OK, but the actual code in the right column is different… and as lazy as I was I copy pasted.
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Federated_Integrations.html
See on the right it says ROPGDiscoveryURL and OIDCROPGID.
This is being corrected.
Ok, but I have all the correct keys defined and am still getting error 15 from the menu bar app. I don’t know what’s the difference in our setups, but for us defining the same values that work in Jamf Connect Verify results in error 15 although the keys have been correctly renamed to the requirements of JC 2.0.
You have the new plist stricture with iDPSettings dictionary? Does it work in the configurator app?
Hi, yes the plist structure is the new one with idpsettings etc. It does work from the configurstion tool and as mentioned after the jcl login when it wants to verify the password, that works as well. After login it seems that it has logged in the user to the menu bar app, but if I then do a sign in from the menu bar app it results in error 15 every time. Regarding the Product Issue jamf support mentioned, doesn’t that apply that they have confirmed that there is an issue with JCL 2.0 and ADFS?
No, contact me on mac admin Slack channel via PM if you want about that. But that PI you mentioned is not a Jamf Connect PI. I was about to open a PI myself yesterday, but after testing with the devs we found I had the wrong keys copied from the documentation (which is being updated). But ass Matt is reporting the same error in the comments here when passwords are changed in AD I’ll play with it again later today.
Hey yes Carl sounds exactly like what’s happening for my setups as well. Out of interest, does it actually do the sync if you OK the error and sync the passwords? Mine does, but gives the error anyway
I just tested and if I change the local password it does NOT sync it from the Menu Bar App (after the error message). However, if I logout and do a JCL login then after the password verification it states that the local password is not in sync and asks for it. After entering the local password, it does sync the passwords.
So for me it only syncs the passwords if I do a JCL login, not from the Menu Bar App.
Hi Carl, Hi Matt!
As promised, I’ve been testing. Moved it to the night time as there are moments, especially weekends, where I try to step away from the Mac from time to time.
The good news is that I found what is wrong!
If you configure the plist yourself, and you write it yourself in a text editor, all is good (if you put the keys correct as they should, without copying wrong things like I did).
If however you create the plists with the Configuration tool… that’s where the problem is. Even if you put ROPG Provider to Custom, the tool still writes it as ‘Azure’ in the XML. I noticed this by, as motivated as I was to confirm there is no ADFS issue, getting the error on my first attempt.
I checked the preferences in the Menu bar app… and I saw my ADFS config but with the provider set to Azure…. Next I checked my configuration tool which I still had open, and confirmed the ROPG Provider for Login was set to Custom. However, when I checked the XML/plist for Connect (menu bar app) I noticed that “provider’ still said Azure. There is no button or selection in the GUI to change that.
So, if you created the plist with the Configuration tool, have a look in Jamf Pro and check what the xml summary of the plist in your profile says. Azure? Custom?
Check the plist, and manually change it to Custom if needed.
Next I did the full test again:
– JCL: No problem at all
– JC Menu bar app: Login OK, changed my password in AD, logged in again -> JC notices the mismatch, asked for the current local password, boom all OK
Let me know what your plist value for “Provider” really says (check the file, not the config tool GUI)
I really appreciate all your efforts in helping us.
Sadly this is not the issue in our case. I noticed the issue with the xml generated by the config tool when I started testing and manually corrected the Provider value to Custom.
Ok, forgot to mention one thing. After noticing the issue with the provider I created a new Plist (or actually changed the value to custom) and updated the config profile. Hit save and I selected “distribute to all”. Checked the logs and confirmed it was completed on my test device. Closed the menu bar app, launched it again… same issue. Ok, closed the menu bar app, unscoped the profile, confirmed on the mac that the config profile was gone, launched menu bar app to confirm the settings were gone too… scoped the profile again-> all good
Also, don’t reupload a plist over an existing plist in the profile. Remove the payload and upload again. This has tricked me multiple times in the past. However here It seems I had to really unscope, save, rescope to make the menu bar take the new settings.
Brilliant, thank you will check this in the morning, though I have seen this even when not using a plist and inputing ids directly into the jamf connect menu app but am going to check the plist settings tomorrow, thanks 🙏
Let’s hope you get the same behavior as me now!
Well, I think you cracked it! Something in the plist created in the config tool must have been the culprit. Even though I had tried not deploying a plist before, and doing the config directly into the menu tool.
I downloaded your plist from the page you published last night. Edited them to make them azure, and add my ids, uploaded and deployed and it worked! no errors!
So, slowly started adding back my other configs. As soon as I added this in, it started erroring again :SignIn
AutoAuthenticate
RequireSignIn
Took it out and its one again. I had tried removing that previously too.
So a combination of using your plist, and not having that entry seems to be working! (not 100% sure what that entry does – it was in my v1 setup)
Thanks for looking at this, it had me baffled.
Matt
Awesome! Well, I’ll definitely check those additional keys as well, you never know. But I have a feeling that there might be something with changing the profile without really unscoping it, saving the profile (checking the settings are gone in the mac) and redeploying which is fooling JC to not take the correct updated settings.
I had some behavior like this, and indeed also when manually configuring it after pulling the profile. Maybe there is something stuck although I rebooted etc.
But yeah to me it’s definitely not ADFS breaking it. So yeah try the quit app, unscope, save, change, rescope approach and don’t hesitate to contact support when needed. I also continue testing.
I also tried all the tips you listed, but it didn’t solve the issue. Tried to recreate the plist, unscope the profile, recreated profile. I also downloaded the plist you published and edited it, but everything ends in the same error.
One thing I noticed is that the error message you mention on your new page differs from what I am seeing. Both you and Matt have an error message that ends with 400, however mine ends with 403. As a side note, we have PHS enabled. Just noticed it was disabled on the screenshot you published.
I tried with PHS enabled first. Forgot to disable that. It worked but it was only when taking the screenshot I realized it was still enabled. But I tested again and that resulted in the blog with that new screenshot to be sure it worked in a pure federated tenant. But it works with PHS too. That said, it should actually not mater if PHS is enabled or not, because you are pointing ROPG to the adfs discovery url so there is no Azure hash in the mix… you are talking to adfs directly.
So, if it works in JCL and it works in the config tool, there must be something else going on. Only logs will tell at this stage:
https://docs.jamf.com/jamf-connect/2.0.0/administrator-guide/Jamf_Connect_Logs.html
But I’m confident that it is not Jamf Connect failing to do ROPG against ADFS.
Error 403… forbidden… ? We’ll need the logs and maybe also worth checking adfs trace logs.
Compared to Error 400… bad syntax…
One additional thought, what happens if you put the discovery URL in a browser? Maybe compare it with mine (it’s in my plist).
Good news, I was able to resolve the issue. After pointing out that I was actually seeing error 403, it got me thinking. We have Azures Web Application Firewall in place and I don’t know what has changed behaviorwise between Jamf Connect Verify and the new Menu Bar App, but Azures WAF detects the new Menu Bar Apps request as a threat and blocks it.
I really appreciate all your hard work on the matter. Without your help I would still be waiting for Jamf to fix a non-existing problem.
Haha.. good news Carl
Matt, are you still getting the error if you deliberately enter the wrong password? Everything is fine for me as long as I enter the right password in the menu bar app, but if I enter a incorrect password then I get the error 15 (400).
Hey.. yes I do. Not the most friendly ‘wrong password’ message I have ever seen. No idea how to fix that
Something to be look at indeed. I’ll investigate further tomorrow morning.
Thanks Matt for confirming you are getting the same error and TTG for looking into this, really appreciate it.
This is luckily not a showstopper, but from a user’s perspective a more informative error message would be nice.
Carl, Matt,
Seems to be expected per design change in 2.0. If you want to see that reverted, I’d advise to open a feature request on Jamf Nation. If you do, let me know and I can personally back it.
Ok, this seems like a very odd design choice by Jamf. Jamf Connect Verify had a clear message to the user that either the username or password is incorrect. This new error message gives no information to the user regarding what is going on.
I just created the feature request.
Thank you. I voted it up. Will ask people to do the same as, and please understand this is my personal opinion, I agree.
Thanks, I also created another feature request to give us the option to define separate SignInLogo images depending if the user has light or dark mode enabled. The feature is currently there for the menu bar icon, but not SignInLogo
Happy to see all is good now Carl! Yeah, lesson learned here as well, it’s all in the details of the error message.
Hi,
Thanks for the update. I can see it may not only be me, but something confuses me regarding the JCL login
If I install basic jamf connect 2.0 package – it does not change the auth
If I install jamf connect login plist file – it does not change the auth
In the plist how is it even possible to add the JCL login window ?
I know by script it works like this below – but as I can read from the manual it seems like plist etc should also be able to modify the auth.
/usr/local/bin/authchanger -reset -OIDC -preAuth JamfConnectLogin:RunScript,privileged JamfConnectLogin:Notify
Hi Kim, with 2.0 you don’t need anything else than the plist with OIDCProvider, but you need to make sure that the plist is installed before you reach the login window. So if you are doing automated enrolment make sure to add the config in the prestage and scope the profile on it own correctly. If no script or terminal command or authchanger plist has been added JC 2.0 will read from it’s own plist and use the OIDCProvider key to change the authchanger.
Are you referring to prestage enrolment or already deployed devices?
Right now I am deploying to already installed clients where Jamf connect is not installed. And If I just deploy jcl package and plist it works fine and the login windows stay as OS default which is fine
In pre-stage I use same plist, and custom package with jcl PKG, and in post script I reset auth to jcl and it run depnotify and do package enrollment. End of enrollment I in script reset the auth to default again
Should that be ok ?
“And If I just deploy jcl package and plist it works fine and the login windows stay as OS default which is fine” => if the plist for JC Login is installed (which has the OIDCProvider key in it normally), the authchanger should execute the flip to JCL window.
“custom package with jcl PKG” => are you using a Cloud Distribution point? And is the custom package signed correctly by a publicly trusted CA (or the Jamf Pro internal CA). Both are mandatory for prestage packages. A normal SMB fileshare can not be used. HTTPS fileshare should be ok, but I’ve seen issue with that. The question is, is your custom package really installed or not? “which authchanger” command can show you the path if it installtd correclty, or the jamf.log file on the system
hmm – I have the OIDC provider key added in the plist.
I actually tried on a clean mac with no MDM installed just to install basic JCL pkg and jamf login plist file and work fine. Also if I restart it stay with native OS login window
What confuses me here is that you say “and work fine” versus “it stay with native os login window”. Also, with no MDM… where are you putting that plist? And what is the name of the file? Finally, when doing MDM, you have the custom domain set correctly? As I’m taking a break away from my Mac this evening, open a support ticket and provide the plist and above info.
What are the correct authchanger parameters to add to the postinstall script in the custom signed JCL2.0 package (for ADE) if you choose to enable Notify?
In your blog you have a screenshot of your custom package where you have:
/usr/local/bin/authchanger -reset -preAuth -JamfConnect:RunScript,privileged
However, the documentation states:
/usr/local/bin/authchanger -reset -NewLogin -preAuth JamfConnectLogin:RunScript,privileged JamfConnectLogin:Notify
I have not been able to get this to work with the information in the documentation and I got a bit further with the parameters you mentioned. We have Enrollment Customization against Azure and with your authchanger command I was able to get as far as Jamf Pro forwarding the user info to JCL and it asking for password verification. After this I would like to run the script and notify.
Hi Carl, time permitting I’ll test that as well. However, I’ll need to go through setting up a new Notify config etc so that will take time. Your fasted path to resolution for this will be support ticket. Hope you understand. But’s it’s on my todo list.
No problem, I just wanted to check if you have more information about what the correct parameters for authchanger is.
I’ll open a support ticket and see what they say.
Support seems also bit uncertain on this.
If I look at your “configure authchanger” section in your blog there is 1,2,3 and 4.
I have not done 1,2 and 4. But if I look at number 3 I have the com.jamf.login.plist in /library/managed preferences (deployed through jamf) and in this plist I also have my OIDC provider.
So if I deploy basic jamfconnect.pkg with that plist it should show the JCL window as far I can understand the documentation. Above has nothing to do with pre-stage, just normal deployment to existing mac´s
com.jamf.login is not the correct domain. It’s com.jamf.connect.login
Can you crosscheck that?
Sorry – yes if I check the name is com.jamf.connect.login
Ok, then there is something wrong with the plist or something else unknown going on. Send the plist to support to validate it. I justed tested again. Mac enrolled in Jamf, no JC installed.
Pushed my profile.
Installed 2.0
Logged out
=> JC login window immediately
No terminal commands / scripts or additional authchanger plist.
So I’m sure it must be the plist.
yes sorry – it is com.jamf.connect.login. Just mistyped it in here
hm – don´t think there can be much wrong ?
AllowNetworkSelection
CreateAdminUser
CreateJamfConnectPassword
DenyLocal
LocalFallback
OIDCClientID
xxxxxx-xxx-xxx-xx-xxxx
OIDCIgnoreAdmin
OIDCProvider
Azure
OIDCROPGID
xxxxxx-xxx-xxxx-xxx-xxxx
ROPGClientSecret
vxxxxxxx_
ROPGProvider
Azure_v2
ROPGTenant
xxxxx-xxxx-xxxx-xxxx-xxxxx
Yeah, the blog comments don’t play nice with the plist structure. I’ll assist internally to check it with support.
hmm – bummer. Think it is my VM that makes crazy stuff. Just tried on another mac whith exact same plist and there it works.
However, if i remove the login plist again and log-out it still shows the JCL window. If the plist is not there anymore it should reset to default login or ?
Oh!!! Yeah I stepped away from testing JC on VM! Too much inconsistent results. VM’s became weird with Catalina! To disable you need to run the authchanger reset command it seems indeed.
Yes — it is not the first time VM drive me crazy, specially about DEP enrollment you cannot trust anything
hmm – just tried to reset auth – remove jamf package.
Installed jamf package and added the plist file again – and now it still stay at the native OS window. This is driving me crazy
Expected. As from the moment you do anything with the command line, you are in “option 1… if a command is executed it ignores profile”.
So if you disabled with command line, you need to re-enable with command line.
authchanger -rest -jamfconnect
Think I just have overcomplicated this – but now at least i know how it works.
If I don´t want JCL window login on existing mac, then why not just deploy standard jamfconnect.pkg file with no jamf login plist and just use jamf connect plist, so the jcl client will work with password change etc
Yeah, or even better… repackage only the menu bar app and do not deploy the login app 🙂
OK seems I got it. When you install jamf connect the plist have to be there. If first jamf connect and then add the plist it will stay at native os login.
For reset yes – only manually auth command is needed
Hey, Thanks for this guide, as always its great.
But still having issues with the verify section. Using Password Hash in azure. The config tool gives us success, however, when in action it fails.
Not sure what we are missing. Notice we are having the same errors as others in your comments
Error from request to URL: https://login.microsoftonline.com/tennant-id-number/oauth2/v2.0/token, ERROR: The operation couldn’t be completed. (JCAuthentication.JCAError error 15.), STATUS: Optional(400)
Hi Rick. Is your Azure ADFS federated? As in “Federated Enabled + PHS”? If yes, make sure to check the Jamf Connect Menu Bar App plist so that the Provider key is set to custom. Known issue with the Config App. Change it manually before uploading to Jamf. And make sure the discoveryURL etc… is set correctly. If you did not configure it with ADFS discoveryURL etc when “Federation = enabled” it will not work. So yeah, to answer your question I’d need to know if your Azure is federated and see the plist. Don’t add the plist as text in the comment, blog does not play nice with it, add a screenshot or send me the plist via macAdmin Slack channel.
What is your recommendation for using only jamf connect in DEP enrollment. As I can read smart groups is not good, in case they are not updated fast enough, so JCL windows will not kick in when enrolling
I can scope it to all computers, but then I also will hit existing running mac´s , where I don´t want the JCL window to appear.
It would be easy if no config profile was needed and it could be build into package – but seems that config profile is a must as I can read
Hi John, you’re right on the Smart Groups. It depends the speed of the Jamf Binary download and smart group calculation. However, you can use a Smart Group linked to the prestage you used as that info is immediately available at first contact and does not require an inventory update. Next, I’d run a Jamf Pro policy with files and processes payload to disable the JCL window. Challenge here is to identify a point in time where you can be sure that the user went through the user creation with Jamf Connect. Finding the best trigger to do that depends your deployment. There might be something running or installing on the device which assure you that the enrolment and user creation is complete.
Alternatively and maybe preferred is to use the Notify script process and disable JCL window at the very end of the Notify process.
I am actually using depnotify
So first step is to assign jcl login plist config to pre-stage computers (But then existing clients that have been pre-stage enrolled will also be hit – so don´t I risk that the existing clients they will switch to JCL window) ?
I could of course run a policy on existing pre-stage clients that it will reset auth to default – but cannot understand how the config profile will then not apply. How can the config profile know that this command that has been run ?. Normally config profiles rules over any things done by command line
Maybe it is me that cannot just see it. :-/ ?
Yes, if command line has been used, it ignores the profiles. It is the authchanger deciding what to honor and if the command line has been used, it knows.
Keeping the profile on the Mac does bit bring it back to what is in the profile. If you disabled via command line, you need to re-enable via command line.
Authchanger -reset -Jamfconnect brings it back to honoring what is in the profile.
OK – got it, that it is authchanger binary that decides what to do.
Actually I could just remove the jamf connect binaries on the mac´s that has been pre-stage installed(being sure that native logon is active), If no binaries are there, then the configprofile will never do any harm
Indeed! Yeah, there are so many workflows depending the exact goal, so things can get complicated. It’s always easy for me: test Jamf Pro server with 1 test mac => walk in the park. The real world is another story indeed.
Just an additional question
Just had a test machine(not VM) installed jamf connect pkg and then added jamf connect login plist. For some reason, it still does not show the JCL window and to my knowledge I have not run any command line to reset the authchanger
Is there a way to see current status of the authdb, and if there has been any changes etc? – so I can see what the reason is that it does not show the JCL as it should
Hi TTG, thanks for all your amazing guides!
Hope you can help me with a few questions. Sorry if this is a long post.
We’ve been running JC1.x in our production environment for over 6 months with Azure as iDP. From the many DEP computers I enrolled through it, I can see FV sometimes enables randomly, sometimes upon the first login, and sometimes upon the second login.
So, case A, upon first login:
Turn on computer, goes through the Setup Assistant, Remote Management screen, JC Login, verify password screen, macOS desktop, I go to Sys Prefs, FV is enabled and encrypting. Next reboot I get the FV login and then directly to desktop. So this is for me the best experience and what I’d like to happen always.
Case B, upon second login:
Same as before but FV is off in Sys Prefs. So next reboot I get JCL window again, but this time I go local login, put user and pass and then directly to desktop. Now FV is on and all good. Not the best experience but works well.
Q1. Why could I be getting these 2 cases so randomly? Is this expected or might I have something not correctly setup.
Q2. In my JC2 testing environment I get the same 2 cases randomly, however on case B, after putting my credentials, I see a couple of FV warnings that I need to hit OK to continue. I must be doing something wrong here, cause it’s a worse experience than in JC1 where I get no FV banners at all.
Q3. There’s a case C, where after the setup assistant I go to the macos native login window. But after a restart I get the JCL window. Again, very random.
Q5. Is the EnableFDE key in the login plist the only responsible for enabling FV or do I also need a Configuration Profile or some other mechanism for enabling it?
Q6. I don’t quite understand the purpose of authchanger. If I don’t set any parameters to it in JC2, should I still see the JCL window or is authchanger the responsible of making the JC login window appear? I do have the key OIDCProvider key set to Azure in my login.plist. Isn’t this enough?
Notes:
– JC1 environment was set up by a colleague who is no longer with us. So it’s now only me trying to understand how it’s been setup and also trying to implement JC2.
– These FV cases happen regardless of the user being standard or admin. I’m using the LAPSuser key with a local admin to enable FV for standard users.
– I’ve been through your post about FV/JC authentication flow, this post and all the JC documentation, but I guess I’m just dumb 🙁
– I’ve been testing on several macbooks pro, a few VM (thanks to you other post), and a bunch of testing users and I always get these random behaviours, so they can’t be related to a computer or a user.
Sorry again for the long post.
Thanks a lot!
Hi Federico,
It can not be random for sure, there must indeed be something in the setup causing it.
Main things first:
– Do not use local snapshots (tmutil) during setup assistent when testing
– A standard account created by Jamf Connect can not enable FileVault if you do not use LAPS
– For LAPS to work, you need the additional profile installed when Jamf Connect goes through the EnableFDE mechanism:
https://www.jamf.com/jamf-nation/articles/708/enabling-filevault-with-jamf-connect-login-on-macos-10-15-or-later
This profile needs to be correctly scoped, not only selected in the prestage and a Smart Group needs to be avoided because if the Smart Group did not calculate in time, the profile might not be installed and EnableFDE fails.
Apart from that there is no other mechanism needed, except the configuration profile to escrow the recovery key, as Jamf Connect can not send the key on its own to Jamf Pro.
You case B does not really make any sense to me, because if FV is not enabled on the first login by Jamf Connect, there is no mechanism in local auth which will do that… unless there is something else enabling FV at login (policy or a custom profile).
To clear that up, you’ll need to check the logs to see why FV was not enabled on the first login… and the second login, there you need to find what enabled FV as it will not be Jamf Connect.
For Case C I suspect bad scoping of the Jamf Connect profile, just like the additional profile mentioned above.
The authchanger will look at the order of things as explained here: https://docs.jamf.com/jamf-connect/2.0.1/administrator-guide/authchanger.html
If no commands where used, and no authchanger profile has been added it will look for the normal Jamf Connect profile. If that is not there either, it will do nothing and you will get the native login.
If the Jamf Connect profile is not scoped correctly and not installed when you reach the login window, you also get the native login window.
If you run a command to enable or disable the Jamf Connect login window, it will configure the Mac as such, and you need to run the opposite command to change it again as it ignores the profile whenever you disabled the JC login window.
As there are a lot of factors playing here, it not easy to understand the exact setup. Only by looking at the exact config, the profiles, the scoping, the enrolment workflow (to understand the FileVault enablement) and the Jamf Connect logs you’ll be able to find what is causing the behavior.
I’d recommend replicating the issue, grab the logs: https://docs.jamf.com/jamf-connect/2.0.1/administrator-guide/Jamf_Connect_Logs.html
and send it to support for deep analysis.
TTG thanks a lot for your reply!
When you say:
“This profile needs to be correctly scoped, not only selected in the prestage and a Smart Group needs to be avoided because if the Smart Group did not calculate in time, the profile might not be installed and EnableFDE fails.”
I understand you’re referring to the PPPC Config Profile that’s required to enable FV on Catalina.
What do you mean by avoiding a Smart Group?
I have my CPs for JC2 scoped to my “JC2 PreStage” Smart Group, one for the JC License, one for the login window and the one for PPPC so far. They’re also seledted in the PSE. How else can I scope them correctly, to that PSE without using a SG?
Thanks!
A Smart Group linked to the prestage as criteria is ok. That info is available in the inventory as from the first moment of enrolment.
So that is ok. I was referring to more complex smart groups with criteria which needs an inventory update.
So we’ll have to replicate the behavior and check the logs to see the full mechanism Jamf Connect is doing.
Well I noticed that my case C, mostly happening in my VM, is due to being too quick in the setup assistant. If I get rid of the Select Location screen too fast, it goes to the native macOS login. This might be preventing from the login window CP to deploy on time. If I stay a few seconds in that location screen, it always goes to the JC login window. This case C hardly ever occurs in real macs, as I usually turn on automatic location and that takes a while.
Now, in regards to FV my LAPS user might not be created on time.
We deploy ‘localadmin1’ (let’s call generic names) with a fix pass in the account settings of the PSE. We, all mac admins in the company know its credentials, for support purposes. Thus I cannot set it to LAPS.
We set to LAPS ‘localadmin2’, which should get the password randomized, enable FV, etc.
To be honest, the only place in Jamf where I find this localadmin2 account, is in Settings > User Initiated Enrollment > Platforms > macOS. (Which is weird to me, cause UIE is not PSE, right? So there must be something else in my setup creating this localadmin2, right?)
Now when FV enables, case A, localadmin2 has a secure token status ENABLED, and localadmin1, DISABLED. This is expected.
When I get case B, the tokens are the other way round, so I suppose somehow localadmin1 gets created before localadmin2, so no token is assigned and LAPS doesnt work.
I’ll have a look at the logs…
Thanks again!
A couple of thing:
– Is stepped away from testing anything with SecureToken and or Jamf Connect on VM’s. I’ve been a big fan of using VM’s to test but since Catalina I avoid doing so for Automated Enrolment, FileVault and Jamf Connect. It’s not reliable as it shows some weird behaviour from time to time.
So that most likely covers option C.
– Regarding your ‘localadmin2’:
=> No, all UIE settings ALSO apply to Automated Enrolment. You define ‘localadmnin1’ in the prestage, which created by MDM and is what Apple calls ‘the managed administrator’. However, you also have the ‘Jamf Management account’ which is indeed defined in UIE. This one is created by the Jamf Binary “IF IT DOES NOT EXIST”. So if you set that accountname to the same as the ‘localadmnin1’ you define in the prestage, it will obviously not be created again. But if the account name is different, and you have the UIE settings configured ‘to create it when it does not exists’, the Jamf Binary will create it during enrolment.
You should not use that one for LAPS, as exactly like you described it, there can be some delay on the creation of it by the binary. Should be fine on physical machines, but on VM’s definitely a problem as the VM goes too fast through the setup.
Finally:
The creation of the account (if not done by the user during the setup assistant) should not create a SecureToken. You need to a login or a secure tokeen grant somehow to give such accounts a token. The fact that you get a token for localadmin2 when it works is indeed expected, as it is the FV enablement on a tokenless system which does that. Next LAPS gives the standard account a token.
Localadmin1 can NOT get a token if it is not the LAPS admin and it creations does not grant a token either. The fact that FV is not enabling is nothing more that what you described already… the localadmnin2 does not exist in time.
Now, when you check secure token holoders, you need to be very careful to avoid wrong conclusions. In your situation where it does not work, I’m pretty sure that there is NO secure token holder on the system (unless Jamf Connect creates an admin account, but then you are not using LAPS). If you do ANY kind of authentication with ANY local admin (localadmin1 for instance), via SSH, Command Line, Login Window or even unlocking the system preferences…. on a TOKENLESS Catalina System, macOS will immediately give that admin account a Secure Token.
Hence you will be tricked into conclusions like you made ‘the tokens are the other way around’. Well actually, NO. You have most likely forced macOS to give that account a Secure Token by doing any kind of authentication with that account while no other account had a secure token.
TLDR:
– Don’t use VM’s when testing initial deployments for FileVault or Jamf Connect
– Avoid using the admin account created by the Jamf Binary (UIE – Jamf Management Account)
=> Use the one created by the prestage, and if needed keep the Management Account for ‘known admin account which IT teams can use’.
One more thing:
(A Jamf Pro legacy thing… and to be 100% accurate… ok it is used for something: Jamf REMOTE and ‘Reissue Personal Recovery Key’ payload in policy. But apart from that: used for NOTHING else by the binary. Jamf Pro only needs to ‘think’ that account exist, but even if it does not exist on the system, it doe not break anything. Except Jamf REMOTE or the Reissue PRK payload – to use when no valid PRK is on file in Jamf Pro)
Awesome! Thanks for all the clarification. I swapped the admin and manage accounts and now, after testing all day in 3 real macs, every time FV gets enabled with standard users…
Unfortunately, now FV is not enabling for admin users. I though that LAPS mechanism took place only when the logged user was standard and just sort of ignore the mechanism when it was an admin. But apparently LAPS is now failing because now the token has been assigned to my logged admin user (let’s call it ‘support_user’). Manage and admin accounts have secure token disabled.
If I’m not mistaken, now I can see that the first user ever created is the one that logs in. Then the admin account is created and then the manage account. Am I right on this?
Is there a way to have FV enabled regardless of the user type?
Thanks once more!
No, the first account created is the one you define in the prestage. This is the Managed admin account (as per Apple’s definition).
This account does NOT get a secure token upon creation, but as it is the ‘managed admin’ it will received a secure token on it’s next login if Bootstrap is enabled.
Next the user account is created and/or the Jamf Management account. Here it depends on the speed of enrolment but it does not matter.
The creation of the Jamf Management account (if different from the ‘managed admin’) does not get a secure token, and can not use bootstrap during loging to get one.
The accounts Jamf Connect creates… here it depends. The creation as such does not create a secure token, but as you are creating and logging in on the fly in Jamf Connect it depends.
At this point there should be no secure token holder on the system yet. When JC creates a standard account and logs in it does not get a token, but the LAPS feature fixes this by enabling FV with the LAPS user, cycle/change it’s own password to the recovery key it received and then uses that PRK as password to give the standard account a secure token.
When JC is creating an admin account however, this does not work. Because, when it creates the admin account (while there is no secure token holder yet), and on the fly logs in…. macOS Catalina gives the admin account a secure token… remember the authentication of any admin on a tokenless Catalina system.
Now the admin account created by Jamf Connect has a token… and if you use LAPS, it tries to enable FV with the additional admin account…. but because this additional admin account does not have a secure token (while there is now an account with a token)… it can not enable FV.
You can enable FV with a local admin account without secure token.
You can not enable FV with a local standard account without secure token (ok for mobile accounts however).
BUT you CAN NOT enable FV with any account without secure token, if there is another account with a secure token on the system.
So it’s all a matter of order of things and it is expected that LAPS fails to enable FV if JC creates an admin. It does not ignore it.
So the only way around this is to make all accounts standard, and promote those you need to be admin later.
*** OR do not use Jamf Connect to enable FV (which I prefer) OR configure the Macs which need admin account with different Jamf Connect config ***
*** or make everyone admin and demote later ***
Very interesting. I guess for now, I’ll stick to the option of everyone get a standard account and gets elevation later by a policy. Which is what we are already doing anyway, as most of our end users get created as standard.
In your preference, you don’t enable FV with JC and I suppose you use a Policy later.
One last question, if I may. I have 5 separate CPs for JC2, one for the license key, one for the FV PPPC, one for Sec & Priv (escrowing), one for the login window and one for the app menu bar. Is there any disadvantage in merging a couple of them?
For example PPPC and Sec & Priv, which have different payloads. Also, the login and the menu bar app have the same custom payload but with different domains.
Thanks once more!
I would keep everything separate. If you ever need to change something it’s easy maintenance. Also if you eed to troubleshoot something by excluding a computer one day. Easier with separate profiles.
Hi! Great post! I’ve been making changes in our Jamf instance and was able to get the JCL window pop up in the prestage enrollment process, but on logging in I keep getting redirected to the login page. We’re using Okta as our IdP and the credentials I use work, as I get a step further in the login process and need to do 2fa next, but after approving the 2fa request, it just returns to the login window. I did notice that I can login with a local account that’s being created from prestage, so that feels kinda weird.. Any clue what is up?
Never mind, it’s working now! I forgot to set the “Require Network Authentication” key to “True”. That resolved it.
Hi Gerard, awesome, was about to look at this after working hours but happy to see you fixed it!
We are unable to make mac as compliance in Intune. When we deploy password policy from Jamf Pro , getting an error “Network password is not matching local password” during Jamf connect login. After removing the password policy from jamf pro users are able to login. So we are completely stuck and not sure how to make mac devices as compliance for password policy.
Hi Balaji, that is expected.
You need to make sure the passcode policy you push with Jamf Pro is exactly as strict as in Azure, or less strict. If Jamf Pro is setting a password policy which is stronger than what you have in Azure, then Jamf Connect can not sync the Azure Password to the local account and you keep the mismatch. You’ll need to review the jamf pro profile settings.
Thanks for quick respond. Yes we push the password policy exactly as in Azure. Even though we are facing same issue and unable make device as compliance.
Please advise its very critical for us.
In that case you’ll have to look at all logs. As it’s critical please open a ticket with Jamf Support. The team will have a look at the logs, settings, etc…
We already raised ticket with Jamf Support and provided details but still unable to address the issue. Just to understand generally how password policy will work in order to make device compliance in Intune when password policy manage by AD.
Either exclude the password profile from the compliance check in Intune, or make the profile less restrictive. The support team will be able to look the Jamf Connect logs if you provide them.
will try make the profile less restrictive and will see how it works. Thanks for the details.
Hello, do you also have problems with Jamf Connect 2.0 and Fileshares. I have done everything according to the manual. Then I tried your old blog article. But it just does not work. With com.jamf.connect.shares.plist….
I don’t get a share entry in the Jamf Connect menu.
I can generally connect the share..
https://macadmins.slack.com/archives/CCWGRUFKN/p1605957449208000
I’d need to check but no issue I’m directly aware of. Do you have a Kerberos ticket?
yes everything there, I have checked it with klist. I will now take a look at the debug logs.
Looks good for me. https://1drv.ms/u/s!AuM87d0aGyATkIFY2V0fVX_jGHnrcw?e=RYoiLa
But “ShareMounter” says no valid ticket 🙁
2020-11-21 16:57:40.195 I Jamf Connect[1845:73b3] [com.jamf.connect:ShareMounter] No valid ticket, not attempting to mount shares.
Mismatch between UPN and sAMAccountname in your environment? Or the @domain in Azure different from the Kerberos realm by any chance?
Yes our UPN is different from the samaccount name. Therefore we fill in the shortname in Jamf Connect. I get a valid token.
i have now opened a ticket at jamf. Let’s see what they say.
Just an question for jamf connect license:
If got the jamf connect licence in a .mobileconfig file – so just uploaded it and scoped it to “all computers” both in pre-stage and in configuration profiles
However, then the JCL window is launching at DEP it shows “this copy of jamf connect login is unlicensed”
What can be wrong ?
When you uploaded the .mobileconfig, did you change the bullet point selector to upload plist?
Hi,
Don´t know if you have any info on this, but we have been using jamf connect through DEP enrollment.
Default the user account created in jamf connect is not MDM capable, so we used to run the sudo jamf mdm -userlevelmdm command to approve so the account will be MDM capable after enrollment
But now this command does not exist anymore – is there any known workarround or should jamf connect just be scrapped in DEP ?
When you skip account creation macOS does not create an MDM capable account. This is not a Jamf Connect issue but purely macOS. Indeed the Jamf binary could fix this on Catalina but not on Big Sur. Only workaround is to create the account via setup assistant, install Jamf Connect later and migrate the account with the migrate key for Jamf Connect
OK thanks for the fast reply
To bad, the authentication part was best, so users where not creating all kind of strange usernames, that do not follow the standards
So when enabling account creation, the jamf connect Authentication window will not kick in afterwards and ask user to sign into azure that we use ?
No when doing user creation in setup assistant they end up straight to the desktop. You’ll need to install jamf connect in the mean time, log out and log in via Jamf Connect. The migrate key will add the azure account name as alias to the existing account
but If user on his own created a stupid username/fullame, then the JCL window afterwards where he authenticate, will that overwrite the account full name / account name that was created manually. I think I know the answer, would just like to be sure
No, it creates an alias. The original accountname remains untouched.
OK thanks – hmm – this is a step back security wise without any authentication from bootup.But guess I may not be the only one complain
well – I guess I could have the next interesting blog post for you.
Install through jamf connect without manual account creation – and when into the desktop use script to re-enroll mac so it again will be mdm capable – guess it should be possible. And a workarround I think
Funny you say that, yes, I have been working with a customer who did that. Actually still ongoing because there are some roadblocks like user interaction, supervision, jamf seeing the Mac as managed etc… works but it’s an interesting workflow…
Hi! Is there any way of configuring so that the welcome window of jamf connect is not showing on first launch? I know that via the plist I could configure with: ShowWelcomeWindow
But if I want to do it via the form? Is it possible?
If you mean the Jamf Pro config profile, don’t think that key is in there. I’d always use a plist. Easier maintenance and beter overview of configured settings.
Maybe I missed this in your post. But I am migrating from 1x to 2.x and do not want to force a reboot to enable the launch agent. Have you or anyone figured out how to launch the app after installation?
Hi Mateo. “Open /Applications/Jamf\ Connect.app” as extra files and processes on the policy?
I had it check for the app in applications and launch it if there.
Users will see a popup though.
Yeah, I tried that. Banner displays even if profile is loaded. I was hoping there would be a better user experience while migrating from1x to 2x. I would not want to force a reboot.
Which banner are you referring to exactly? The welcome screen? If so, do you have the
key configured?
yep, it’s configured. all works well if I manually launch it. I just wanted to drop this on the user’s machines with out requiring them to to into /applications and launch it or reboot.