Our thinking


Remove additional Platform Single Sign-On credentials saved in macOS when using PSSO with Microsoft 365 / Entra and Company Portal

I’m working on a Mac that’s configured with Platform Single Sign-On via Intune. I’m wanting to test it pretty thoroughly myself before widespread deployment with my clients.

It generally works pretty well for me so far, however there is one annoying thing that has been happening.

If you’re signing in to Microsoft 365 from an app that is PSSO aware, it will then save that identity on your Mac, and present it in any other PSSO aware app when you go to sign in.

This is generally not what I want – I use Microsoft Edge, with a whole bunch of separate profiles, to sign in to each of my clients’ Microsoft 365 tenancies as their Global Admin. I only ever want these identities to be used from within the individual profile for that client, I never want them presented when I am, for example, signing in to Outlook or using an app that has SSO via Microsoft.

There is no offical way to remove these identities once they’re there. You can delete the profile in Edge, but they remain. You can clear all browsing history, but they still remain. You can sign in using a completely different app, e.g. Safari, and there they are!

If you go into the Company Portal app and sign out in there, these identities are all removed – along with your primary identity, but you then bring on a world of hurt trying to get your Mac registered with Intune and PSSO again after you’ve done this. Yeah, it works, but it’s pretty drastic and the steps to fix it are not straightforward.

One thing I’ve found that seems to work is to tail the SSO Extension Log Files when logging in:

tail -F ~/Library/Containers/com.microsoft.CompanyPortalMac.ssoextension/Data/Library/Caches/Logs/Microsoft/SSOExtension/*

And then undertake an activity that brings up the Microsoft sign-in page.

Once you’ve done this, stop the tail with ^C and look in the logs for lines containing “Adding SSO-cookie header with PRT”

Here’s a couple of one-liners that will do that for you

  1. Using Grep and Sed (this should all be on one line in Terminal)
grep 'Adding SSO-cookie header with PRT' ~/Library/Containers/com.microsoft.CompanyPortalMac.ssoextension/Data/Library/Caches/Logs/Microsoft/SSOExtension/*.log | sed 's/.*\(Adding SSO-cookie header with PRT.*\)/\1/'
  1. Using Awk (again, all on one line)
awk 'match($0, /Adding SSO-cookie header with PRT.*/) { print substr($0, RSTART) }' ~/Library/Containers/com.microsoft.CompanyPortalMac.ssoextension/Data/Library/Caches/Logs/Microsoft/SSOExtension/*.log

For each logon event, there will be a bunch of tokens that are added. the first one is most likely the one you want to keep. The entry in the log will look something like this:

Adding SSO-cookie header with PRT (environment=login.microsoftonline.com realm=[uuid] clientId=[uuid] credentialType=PrimaryRefreshToken homeAccountId=11111111-aaaa-2222-bbbb-333333333333.cccccccc-4444-dddd-5555-eeeeeeeeeeee speInfo=(null))(refresh token=a1b2c3d4, family ID=(null))(id token=(null), legacy user ID=auth.placeholder-1a2b3c4d__automatica.com.au)(primary refresh token=11aa22bb, key location type 2)

The other lines following it will be slightly different, e.g.:

Adding SSO-cookie header with PRT (environment=login.windows.net realm=(null) clientId=00000000-1111-2222-3333-444444444444 credentialType=PrimaryRefreshToken homeAccountId=12345678-1234-1234-1234-123456789abc.00000000-1111-2222-3333-444444444444 speInfo=(null))(refresh token=12341234, family ID=(null))(id token=(null), legacy user ID=Masked(null))(primary refresh token=12121212, key location type 0)

Look at the homeAccountId for each token and take note of the uuids. One of the tokens will be your main account – in my case it’s the one that doesn’t have the legacy user ID masked, instead it has values like legacy user ID=auth.placeholder-1a2b3c4d__automatica.com.au) and the homeAccountId for this token is 11111111-aaaa-2222-bbbb-333333333333.cccccccc-4444-dddd-5555-eeeeeeeeeeee

Make note of the uuids for the other Primary Refresh Tokens (PRTs) in the logs.

Then look in Keychain Access (not the Passwords app) and search for primaryrefreshtoken. Examine the uuids for each of the PRTs and delete the ones that don’t match your main account.

After doing this, reboot.

Doing this seems to have worked for me, it survived a reboot. It survived me going into my user account in System Settings and clicking on Registration > Repair and it also survived me going into System Settings > Users & Groups > Network Account Server > Edit and clicking on Repair in there too.

Now, please be aware that this is a dodgy hack, and could lead to all sorts of things breaking in exciting and unusual ways. I’m not responsible for anything that happens from you taking this advice – you might end up not being able to log in to your Mac again, you may not be able to log into Microsoft 365, cats and dogs might end up living together, or other even weirder issues might occur. This might not even remove the accounts from the account picker for you – I really don’t know enough about what’s going on behind the scenes to be sure if this really works.

I do know however that neither Apple nor Microsoft provide us with any tools whatsoever to manipulate, or even see any of these other identities – you can see your primary identity via Terminal by typing in app-sso platform -s but this doesn’t give you any ability to edit anything, nor even see any of the other identities that are saved.

Oh, and if you look at the various PRTs in the log file and then look at the output from app-sso platform -s you’ll notice some of the uuids matching up for one of the PRTs. This is the PRT you want to keep in the keychain.

If you go searching in the keychain for the uuids for the other PRTs, you’ll probably see a bunch of things for each of the other uuids. I don’t know what they are, I don’t know if they need to be deleted too (probably) or what happens if you do delete them, or if you do leave them behind. I have left them as-is and just deleted the minimum number of items in the keychain that seemed to then work.


Leave a Reply