Logout local machine from O365 / Office account RRS feed

  • Question

  • I've attemped asking the general MS forums over here:

    But they directed my question to MSDN.

    Post #1

    I'm trying to programatically logout all users from the local machine. (long story short, very security concious company with people leaving themselves logged into semi-public equipment)

    Please no answers from an admin / azure / ad / etc, perspective. Focusing just on the local machine for today :) 

    After some digging / Googling and playing around with ProcMon. I've gotten thus far:

    • Apparently the tokens for authentication are stored in the Credential Manager:
      • This may have been true, I certainly have some old entries in there. But wiping out Credential Manager (manually or programatically [via cmdkey]) doesn't seem to affect anything
    • I've found the following registry keys that stores the Identity information of logged in users:
      • Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Roaming\Identities
      • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\Privacy\SystemCache
        • Deleting these effectively does nothing, they are retrieved from *somewhere else* and restored upon booting up any Office application again. Both seem to be used as a cache from somewhere else.
    • I found the identity in a bunch of other places in the registry hive, but they are pretty innocuous (although there is a lot of targeted tracking info attached to it.... but that's a story for another day)
    • netlogon service does show up a lot, but disabling that doesn't affect any of the above either :( 
    • %LOCALAPPDATA%\Microsoft\Vault doesn't seem to contain any relevent entries (read: recent)

    Does anyone have more familiarly with the authentication process that Office365 uses and can point me in the right direction?

    Just need to log people out, should be pretty easy on paper...

    Post #2

    A user can sign themselves out of Office, therefore, there's sufficient information to sign someone out without needing admin on Azure. (We just want users to be automatically signed out locally)

    You can even signout while offline... The task is to disassociate the token locally from the remote token, if the remote token is still alive for a short while, that is perfectly fine!

    I also spent some time debugging the HTTP sessions as that was an angle I didn't really think of. My findings so far:

    #1 Request

    PROCESS: backgroundTaskHost.exe

    POST https: login_microsoftonline_com/common/oauth2/token?user=<OS username>

    BODY: Has a bunch of small details, but does contain a client_id as the only important detail. The client_id is in guid format. 

    RESPONSE: Nonce base64 string

    #2 Request

    PROCESS: backgroundTaskHost.exe

    POST https: login_microsoftonline_com/common/oauth2/token?user=<OS username>

    BODY: This is the really interesting one, this body contains a JWT token, when Base64 Decoding, it has the following body:


      "win_ver": "10_0_17763_529",

      "tbidv2": "<base64 encoded binary>",

      "scope": "openid aza",

      "resource": "",

      "request_nonce": "<base64 encoded binary | same nonce as given as a response to the first request>",

      "refresh_token": "<base64 encoded binary>",

      "redirect_uri": "ms-appx-web://Microsoft.AAD.BrokerPlugin/<guid>",

      "iss": "aad:brokerplugin",

      "grant_type": "refresh_token",

      "client_id": "<same client_id as before>",

      "aud": ""


    RESPONSE: Base64 encoded.... something. The first few charecters are clearly the start of a JSON string, but then it degenerates into jibberish, may be some sort of encryption involved. 

    {"alg":"dir","enc":"A256GCM","ctx":"<base64 encoded binary>"}<jibberish>

    They seem to be the main two requests involved in the logout process. The thread of similiarity is the client_id. Where is that stored?

    EDIT: I found it in the registry, it's the OAuth application client ID. And it's in the Service Catalog as FP_LINKEDIN_2WAY / FP_LINKEDIN_ORGID. So that's probably not an ideal lead :/ 

    I'm going to go hunt down the refresh_token then instead and try and find where that is stored. But due to the copy I have being base64 encoded, the original may be stored as binary which will make it tough to find :/ 

    • Edited by Matthew Gladman Tuesday, September 24, 2019 1:55 AM Fixed formatting and adding back URLs
    Tuesday, September 24, 2019 1:53 AM