How do I convert a SID between binary and string forms?

Of course, if you want to do this programmatically, you would use ConvertSidToStringSid and ConvertStringSidtoSid, but often you're studying a memory dump or otherwise need to do the conversion manually.

If you have a SID like S-a-b-c-d-e-f-g-...

Then the bytes are

a (revision)
N (number of dashes minus two)
bbbbbb (six bytes of "b" treated as a 48-bit number in big-endian format)
cccc (four bytes of "c" treated as a 32-bit number in little-endian format)
dddd (four bytes of "d" treated as a 32-bit number in little-endian format)
eeee (four bytes of "e" treated as a 32-bit number in little-endian format)
ffff (four bytes of "f" treated as a 32-bit number in little-endian format)

So for example, if your SID is S-1-5-21-2127521184-1604012920-1887927527-72713, then your raw hex SID is


This breaks down as follows:

01 S-1
05 (seven dashes, seven minus two = 5)
000000000005 (5 = 0x000000000005, big-endian)
15000000 (21 = 0x00000015, little-endian)
A065CF7E (2127521184 = 0x7ECF65A0, little-endian)
784B9B5F (1604012920 = 0x5F9B4B78, little-endian)
E77C8770 (1887927527 = 0X70877CE7, little-endian)
091C0100 (72713 = 0x00011c09, little-endian)

Yeah, that's great, Raymond, but what do all those numbers mean?

S-1- version number (SID_REVISION)
-...-...-...- these identify the machine that issued the SID
72713 unique user id on the machine

Each machine generates a unique ID that it uses to stamp all the SIDs it creates (-...-...-...-). The last number is a "relative id (RID)" that represents a user created by that machine. There are a bunch of predefined RIDs; you can see them in the header file ntseapi.h, which is also where I got these names from. The system reserves RIDs up to 999, so the first non-builtin account gets assigned ID number 1000. The number 72713 means that this particular SID is the 71714th SID created by the issuer. (The machine that issued this SID is clearly a domain controller, responsible for creating the accounts of tens of thousands of users.)

(Actually, I lied above when I said that this is the 71714th SID created by the issuer. Large servers can delegate SID creation to helpers, in which case SID issuance is no longer strictly consecutive.)

Security isn't my area of expertise, so it's entirely possibly (perhaps even likely) that I got something wrong up above. But it's mostly correct, I think.

Comments (9)
  1. So what are the security issues with giving out ones SID?

  2. Larry Osterman says:

    As far as I know, there aren’t any issues with giving out the SID – except for one minor issue.

    The -…-…-…- actually identify the domain that issued the SID, and that means that it’s possible to corrolate the domain on which a user account is created.

    That means that if you know one account on a domain that has a weak security policy, you can know if other accounts are also created on the same domain.

    It’s a small bit of information disclosure, but in the scheme of things…

    If you think about it, the SID of all the users in an ACL are included in the security descriptor for objects, and the security descriptor contents are semi-public information (you need READ_CONTROL access rights to the object).

    But I’m also not a security guy (although I’ve done a LOT of security work).

  3. Adrian Oney says:

    Same boat as Raymond – not a security guy, but I’ve done a good amount of security work.

    I personally found the information on SIDs in the SDK and even Howard & LeBlanc’s excellent "Writing Secure Code" book somewhat lacking in organization. When I had to put things together for the DDK, I organized the list of SIDs this way (from wdmsec.h):

    Each SID is listed in the form EnglishName ("SDDL Abbreviation", FullSID, Authority:SubAuthorities)

    The following SIDs represent *accounts* on the local machine:



    The OS itself (including its user mode components.)


    A predefined account for services that presents user credentials for local

    resources and annonymous credentials for network access.

    Available on XP and later.


    A predefined account for services that presents user credentials for local

    resources and the machine ID for network access.

    Available on XP and later.

    (A local *account* for a guest and a default administrator also exist, but

    the corresponding SDDL abbreviations are not supported by this library.

    Use the corresponding group SIDs instead.)

    The following SIDs represent *groups* on the local machine:



    The builtin administrators group on the machine. This is not the same

    as the builtin Administrator *account*.


    Group covering all local user accounts, and users on the domain.


    Group covering users logging in using the local or domain guest account.

    This is not the same as the builtin Guest *account*.

    The below SIDs describe the authenticity of the user’s identity:



    Any user recognized by the local machine or by a domain. Note that

    users logged in using the Builtin Guest account are not authenticated.

    However, members of the Guests group with individual accounts on the

    machine or domain are authenticated.


    Any user logged on without an identity, for instance via an anonymous

    network session. Note that users logged in using the Builtin Guest

    account are neither authenticated nor anonymous. Available on XP and



    Prior to Windows XP, this SID covers every session: authenticated,

    anonymous, and the Builtin Guest account.

    For Windows XP and later, this SID does not cover anonymous logon

    sessions – only authenticated and the Builtin Guest account.

    Note that untrusted or "restricted" code is also not covered by the

    World SID. See the Restricted Code SID description for more


    The below SIDs describe how the user logged into the machine:



    Users who initally logged onto the machine "interactively", such as

    local logons and Remote Desktops logons.


    Users accessing the machine remotely, without interactive desktop

    access (ie, file sharing or RPC calls).


    Interactive Users who *initially* logged onto the machine specifically

    via Terminal Services or Remote Desktop.

    (NOTE: There is currently no SDDL token for this SID. Furthermore, the

    presence of the SID doesn’t take into account fast user switching


    The below SID deserves special mention:



    This SID is used to control access by untrusted code.

    ACL validation against tokens with RC go through *two* checks, one

    against the token’s normal list of SIDs (containing WD for instance),

    and one against a second list (typically containing RC and a subset of

    the original token SIDs). Only if both tests pass is access granted.

    As such, RC actually works in *combination* with other SIDs.

    When RC is paired with WD in an ACL, a *superset* of Everyone

    _including_ untrusted code is described. RC is thus rarely seen in

    ACL’s without the WD token.

  4. Pavel Lebedinsky says:

    If you’re looking at a memory dump then you can also use !sid debugger extension:

    c:debuggers> cdb notepad

    0:000> dc RPCRT4!AnonymousSid

    78073fc8 00000101 05000000 00000007

    0:000> !sid RPCRT4!AnonymousSid 1

    SID is: S-1-5-7 (Well Known Group: NT AUTHORITYANONYMOUS LOGON)

  5. Florian W. says:

    My greatest highlight inside the security-API-documentation on MSDN is the article: "Windows NT Security in Theory and Practice". This article has a nice line: ‘First, you should definitely read Robert Reichel’s two-part article "Inside Windows NT Security," which appeared in the April 1993 and May 1993 issues of the Windows/DOS Developer’s Journal’.

    Unfortunatly, that article is *not* part of MSDN:-(

  6. Norman Diamond says:

    I found one article by Robert Reichel on windows security. He’s a real estate agent, and he recommended that windows on and near the ground floor should be locked.

    As for that other Robert Reichel, it seems his articles would likely be included in a CD that was made by the original publisher, but the CD is sold out. CMP has more recent archives posted on their web site. Anyone know if they could be persuaded to do the same with older ones?

Comments are closed.