07-16-2024 11:19 AM - edited 09-04-2024 07:58 AM
Edited 4SEPT2024: Updated information with the release of Jamf Pro 11.9 for PSSO and Device Compliance. Also added link to Jamf Pro documentation.
https://learn.jamf.com/en-US/bundle/technical-articles/page/Platform_SSO_for_Microsoft_Entra_ID.html
With this method, when a user registers a device with the Platform Single Sign-On flow, the device compliance will automatically be sent to Entra.
In the event that an organization deploys PSSO first and then later configures and deploys Device Compliance, the user must run the "Register Device with Microsoft" policy from Jamf Self Service or the administrator must deploy a policy to run the gatherAADInfo command at least once before device compliance will be reported.
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>AppPrefixAllowList</key>
<string>com.microsoft.,com.apple.,com.jamf.trust,com.jamf.management.,com.jamf.protect,com.jamfsoftware.</string>
<key>browser_sso_interaction_enabled</key>
<integer>1</integer>
<key>disable_explicit_app_prompt</key>
<integer>1</integer>
</dict>
</plist>
Posted on 08-01-2024 01:36 PM
What do you set for the Registration Token field?
Posted on 08-01-2024 01:41 PM
Posted on 08-21-2024 02:52 PM
so if 11.7 is not going to work with PSSO, what version will?
Posted on 08-21-2024 03:10 PM
Jamf Pro will work with device registration, but you must manually run the gatherAADInfo command. You also need to make sure a specific order of operations occurs:
A) Device Registration is configured in Jamf Pro. The computer can be in a registered or unregistered state.
B) Push the PSSOe configuration profile to the device
C) Follow the user enrollment steps to activate PSSOe
D) Manually run either through policy or on the device in terminal the following command:
/Library/Application\ Support/JAMF/Jamf.app/Contents/MacOS/Jamf\ Conditional\ Access.app/Contents/MacOS/Jamf\ Conditional\ Access gatherAADInfo
A future version of Jamf Pro will automatically run this command with a LaunchDaemon after the device and user has registered PSSOe. I recommend joining the Jamf Pro beta to learn more.
Posted on 08-28-2024 12:22 PM
Do you mean you have to go through the Jamf/Intune integration and set up that Device Registration before attempting to set up PlatformSSO?
@rabbitt wrote:Jamf Pro will work with device registration, but you must manually run the gatherAADInfo command. You also need to make sure a specific order of operations occurs:
A) Device Registration is configured in Jamf Pro. The computer can be in a registered or unregistered state.
Posted on 08-30-2024 06:05 AM
Not sure if I totally understand your question. When you deploy the configurations to a device for PSSOe you have to manually run the alternative jamfAAD command listed above on that computer to get it registered with Entra for the device compliance to start working. Hope that helps.
Posted on 08-30-2024 10:05 AM
If you were to deploy PSSO first THEN deploy the device registration settings to machines via Jamf Pro (aka enable it in the Jamf Pro Settings -> Global -> Device Compliance), then the expected behavior would still be that you need to open Self Service and select the "Register device with Microsoft" policy.
When you do that, the device has a registration in Entra ID's directory already, so most of the "hard work" is done. But that policy will then run the gatherAADInfo command and link the newly deployed compliance policy with the existing Entra ID UUID for the computer.
When Jamf Pro 11.9 drops, there will be a launchdaemon loaded onto the computer when you enable Device Compliance. The daemon watches for the status of PSSO registration.
But, if you enroll the device in PSSO and THEN deploy Device Compliance, the state of the PSSO registration never changes - it was already registered. So when deploying Device Compliance starts up that launchdaemon, it never sees a change to PSSO status. So therefore you need to run the Register policy again to "force" it to register.
Posted on 08-21-2024 03:15 PM
doh, its not jamfAAD gatherAADInfo, thanks I did not look closely enough
Posted on 09-03-2024 11:15 AM
@rabbitt I thought I sent a question earlier but don't see it here. Do you know if we just need to add all the kerberos keys to the existing custom plist that we add to the PSSOe profile? If we do that will it cause re-registration of all devices that have the profile? https://learn.microsoft.com/en-us/entra/identity/devices/device-join-macos-platform-single-sign-on-k...
Posted on 09-03-2024 01:39 PM
The answer is "It depends." Unfortunately I've seen two different behaviors when a PSSO profile is updated (which really is two separate commands - remove profile, add a new profile with a new identifier).
Authentication type set to "Password" - usually prompts user to re-register
Authentication type set to "Secure Enclave key" - Usually keeps the device registered when profile is removed until reboot.
So if you make any changes to the existing PSSO config profile in any way, it will probably require the user to re-register.
Posted on 09-17-2024 01:23 PM
Has anyone ran into an issue with Microsoft apps constantly asking to be logged into again? It seems like everything is talking correctly, as logging into the Mac uses the Entra ID password credentials, but all the Microsoft applications (Teams, Edge, OneDrive, etc.) keep logging out and ask to be logged into again frequently throughout the day. I feel like I'm missing something, but can't figure it out.
3 weeks ago
Check your Entra Conditional Access policies around session duration. Also this is one where getting MS support in is 1000% the right answer. You're paying them for the service, so... :)
Posted on 09-24-2024 04:02 AM
We have setup for PSSOe Jamf+MS Entra and running jamf pro 11.9.1 server, After PSSOe enabled in mac, under keychain - login - MS Organization access certificate in removed. After this Specific certificate removed, we cannot able to open any organization sites. Can idea?
Posted on 09-24-2024 07:59 AM
Posted on 09-24-2024 08:10 AM
we are running jamf pro 11.9.1 and we are not facing non compliance issue. yes we know , above command will help to make mac compliance.
Posted on 09-24-2024 08:18 AM
only Question, once enabled PSSOe, why certificate removes from keychain, we know this specific certificate will help to access intranet site. we have compared 2 macs, one with PSSOe and another without PSSOe enabled. Once PSSOe registration completed, MS workplace join key (Private key) removes and not blocks the intranet access.
3 weeks ago
With PSSO in Secure Enclave key authentication mode, the workspace join certificates are removed from the user's keychain and stored instead in the Secure Enclave of the device. This effectively makes the key non-exportable and hardware bound. The workspace join key should not be relied on for things like network access.
Posted on 09-24-2024 08:23 AM
Once PSSOe registration completed, MS workplace join key (Private key) removes and it blocks the intranet access.
Posted on 09-24-2024 11:33 AM
because it moves from keychain to the secure enclave, find a different cert to use. My guess would be to deploy a pkcs device/user cert from your CA would probably be the better thing to do. Or change your intranet policy to ask the device if it is compliant and use MSAL auth stuff.
Posted on 10-02-2024 04:38 PM
Thanks for this @rabbitt!
Question: with the WPJ cert/key removed, what marker or identifier can we look for on the endpoint to verify a healthy and successful registration? When moving to PSSOe, we see the device record flip from "Microsoft Entra registered" to "Microsoft Entra joined" in Entra, with a new Device ID to boot. However, there is no cert in the keychain that matches the new Device ID (since it's presumably stored in the Secure Enclave). How can we check for this cert/registration on the endpoint?
Posted on 10-02-2024 10:53 PM
Thanks, I have same question. @rabbitt Can you ?
Posted on 10-08-2024 09:54 AM
The `/usr/bin/app-sso profile -s` command should give some details on the state of device registration and user registration on the device. Be forewarned that it produces a LOT of information so you'll need to dig through and pull the information relative to your needs.
You will not be able to directly search for the cert, as you said, as it will be in the Secure Element rather than accessible via the Keychain.
Posted on 10-08-2024 10:24 AM
I think you meant "/usr/bin/app-sso platform -s". However, the output of this command does not include any data that correlates with the device registration in Entra. The only unique identifiers that we have in Entra are "Device ID" and "Object ID", and neither of these show up when running that command. Perhaps there is a different way to correlate a PSSO Joined Mac with Entra that I am overlooking?
a month ago
Correct, I typed "profile" but meant "platform". Don't answer questions without enough coffee in your system.
I've asked around, and it appears that there is no identifier on device that would correlate the UUID in Entra. I've been told that Jamf Pro does contain the information, but it's accessible only via the API and with the "conditional-access" endpoint. The app-sso platform -s simply tells you the device IS registered, but only Jamf Pro knows the device identifier.
That being said, what is the functionality you're trying to get on the client device itself that would need that UUID?
a month ago
This works! Thanks for pointing it out. I will edit my EA to use the API if the device has our SSO profile. Cheers!
a month ago - last edited a month ago
@rabbitt
Thanks so much for all this. We are testing Microsoft Platform SSO with Entra successfully. In a passwordless environment, we can see some huge benefits and a better overall Mac experience with Smart Cards.
Thanks again for all your help at JNUC with the braindate meet! Your presentation was awesome as well. Appreciate the tips and cheat codes.
3 weeks ago
I have an issue where, after authenticating with the company portal, I see the "MS-Organization-Access" certificate in the user's keychain, but it is not trusted. Is it necessary to trust this certificate, and will it cause any issues if it remains untrusted? How can I trust that certificate, and is there a root CA required for it to be trusted?
3 weeks ago
If you're using PSSO with Microsoft in Secure Enclave key authentication mode, there should be no MS-Organization-Access certificate in the user keychain at all, so I'm confused by the question.
3 weeks ago
@rabbitt - I'm going to go ahead and get this out of the way - We still AD Bind. (hangs head in shame).
But, I've been looking to convince management to get away from this for a while. After JNUC and hearing your session (awesome session BTW), management decided to get some Jamf Connect licenses and start looking at PSSOe. The problem I'm running into is that we seem dead set on not allowing just anyone the capability to register in Entra. We have it restricted to a small group of employees. That means I'll have to touch every single machine.
Do you have any advice on how I can accomplish this easily or how to convince management to open it up? Their concern is that we've had a bunch of personal devices register in our tenant and this was presented as the way to stop that.
Thanks!
3 weeks ago
I think you less have an issue with registering devices in Entra as much as registering personal devices into Jamf Pro. The PSSO payload needs to come down from an MDM here to work, so we know the device would be enrolled in Pro. Perhaps limit registration of devices to only those coming through Apple Business Manager? Perhaps add in the (in private beta preview, so talk to your Jamf AE) Network Relay with an ACME certificate new to Jamf Connect ZTNA. That would give you a machine authenticity attestation from Apple with the ACME cert to prevent serial number spoofing.
2 weeks ago
I'm not sure I exactly follow. We have zero Jamf Cloud BYOD, so that's not an issue. Everything is ASM and PreStage. However, we have so many personal devices showing up in Entra that management is pulling everything back to try to stop devices from registering with our tenant.
2 weeks ago
Running into the same limitation as you-- there doesn't seem to be a way to automate registering these devices using Jamf, so to register them, the user has to have permission to join devices to Entra-- which includes personal windows devices, which don't need anything pushed from an MDM to join. If you find a solution to this I'll be curious to know as our org is in the same boat right now.
a week ago
@rabbitt , thanks for posting this very helpful information.
We are facing some similar inconsistencies with our test deployment of PSSOe with password sync on Jamf Pro Cloud 11.10.1-t1728656858, using Company Portal Version: 5.2409.1 (53.2409926.002) and a signed config profile created in iMazing. We were experiencing some issues with the profile created in the Jamf UI, the session duration key value was being manipulated so, we went to a signed profile and didn't set that value, taking the default. We've still been experiencing what I would call a "drift" where, initially, things seem to work fine. After logging in, SSO works and the tokens are read, website and apps seamlessly connect as expected. Then after a few days or so, it may start with Teams displaying a banner that you need to sign in. Other sites that were previously, silently passing the SSO token, were prompting for login credentials and MFA. Our testing with SecureEnclave was must smoother but, due to our environment and culture at the time we have to start with password sync. I've tried to capture some logs using unified logging and some predicates but, I'm not sure what's "normal noise" or what's actually an error. Additionally, a line in the output of the app-sso platform -s command has been getting my attention but, I'm not sure if it's actually an error or if it's just describing what would be output in the event of that type of error. Under the "Login Configuration" section there is a key-value pair with the following:
"invalidCredentialPredicate" : "error = 'invalid_grant' AND suberror != 'device_authentication_failed'",
1. Any thoughts on the "drift" for Microsoft applications and sites that were previously taking SSO tokens prompting for credentials? (I saw your response to "wlumley" and we'll be checking with our Identity & Access folks regarding a conditional access policy if it exists or not.
2. Do you know of any good log predicates that may be of value to stream or look up when troubleshooting PSSOe w/ password sync?
3. Have you heard of or had any experiences with the Jamf UI when creating config profiles changing some values of the keys?
I think this particular one should have the wording changed and that might fix the issue since the key takes seconds but, the interface uses
resulted in:
So, the value entered in the UI was multiplied by 3600. The UI should say to enter the number of hours but, we got an error when entering "1". After this we didn't populate that key but, it still did not affect the issues we've been experiencing.
a week ago
Forgot to post:
Here's what our current config looks like on the device:
a week ago
Also observed the banner for Teams asking to sign in again. Saw earlier this week, but not today. Maybe an update or something came out for Teams.
a week ago
¯\_(ツ)_/¯ I had been trying to find a log from Teams that even displayed the banner's text with a timestamp, to attempt to correlate it with some other events but, I was unsuccessful.
a week ago
Also, replace "session duration key" with "login frequency" woops.
Tuesday
We've decided to switch to SecureEnclave. During my journey down the rabbit hole of Platform SSO logs I came up with a few variations on a predicate that gave some insight into the problem.
Silent token refresh attempt results
log show --style compact --predicate '(subsystem contains [c] "AppSSO Extensi" or subsystem contains [c] "com.microsoft.ssoextension" or subsystem = "com.apple.AppSSO") and (eventMessage contains "_finishAuthorization:withCompletion:" or eventMessage contains "authorization:didCompleteWithError:")' --debug --info
You can play with variations on this predicate to see some interesting things. The subsystems listed were the ones I found mostly related to SSO. I also looked at keychain and device unlock logs with variations on this predicate. I was able to compare my experience on an Intune managed device running password sync vs our Jamf managed devices. The Jamf implementation at this time seems to have some bugs around the silent refresh. Not surprisingly, the Intune implementation for both password sync and SecureEnclave were both smooth.
The above predicate only showed successful results on my Intune managed device.