Compartilhar via


Example impact of Microsoft Accounts on Windows APIs in Windows 8/8.1

Windows 8 introduced the ability for a user to logon to their desktop with their Microsoft Account.  This is an email address and password that you can use to sign on to any Microsoft site and services such as Outlook.com, OneDrive and Office 365.  More information on this is in the following BLOG post:

https://blogs.msdn.com/b/b8/archive/2011/09/26/signing-in-to-windows-8-with-a-windows-live-id.aspx

When you logon with your Microsoft Account, you'll noticed that you are actually logged on with a local account created by Windows.  If you dump the token of the Microsoft Account.  You'll notice the following new Security Identifiers (SIDs):

  • S-1-11-96-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ
  • S-1-5-64-32

A SID is made up of a revision level, an authority and a bunch of relative identifiers (RIDs) or subauthority values.  The standard notation for a SID is the following:

S-R-I-S

You can also reference SID components at the following link:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa379597(v=vs.85).aspx

Typically the values are defined in Winnt.h

Going back to the SIDs in the token, we can break them down and identify them.

The first SID (S-1-11-96-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ-ZZZ) represents your Microsoft Account.  This is a user SID (the type of SID).  If you convert the SID to a readable name.  It will convert to:

MicrosoftAccount\yourid@domain.com

The Authority ID, 11 isn't defined in Winnt.h and neither is the first rid which is 96 but we have a good idea what represents the SID.

The second SID (S-1-5-64-32) is a group SID and represents the following Group:

NT AUTHORITY\Microsoft Account Authentication

The authority ID (5) is fairly common in Windows:

#define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5}

The first RID is 64 which is:

#define SECURITY_PACKAGE_BASE_RID       (0x00000040L)

The 2nd RID is 32 which is:

#define SECURITY_BUILTIN_DOMAIN_RID     (0x00000020L)

I will have future posts on Microsoft Accounts as I encounter more interesting things with applications running as the Microsoft Account user.

Now, let me discuss the impact of Microsoft Accounts on a specific Microsoft Technology.  In this case, it was with a Network Provider DLL.  Basically, you can create a DLL in Windows that enables it to interact with other kinds of network.  Take a look a the following link for more info:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa378776(v=vs.85).aspx

For example, you can create a Network Provider DLL which will be invoked when a user logs on.  During this time, you can deal with this event like synchronizing the user's password.  Well, in the case of a Network Provider DLL, it will not be invoked during a logon because the logon isn't a Domain Logon.  Windows internally checks to see if the logon was a Kerberos Interactive Logon.

This is just an example of how new functionality introduced in Windows can impact existing APIs and technologies.  In this case, if you have written a Network Provider DLL and a Microsoft Account user logs on, your DLL will not be invoked.

 

Follow us on Twitter, www.twitter.com/WindowsSDK