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

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

sd — Mon, 15 Mar 2004 15:08:00 GMT

huh?

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

Andreas Magnusson — Mon, 15 Mar 2004 15:58:00 GMT

So what are the security issues with giving out ones SID?

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

Larry Osterman — Mon, 15 Mar 2004 16:03:00 GMT

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).

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

Adrian Oney — Mon, 15 Mar 2004 17:44:00 GMT

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:
-------------------------------------------------------------

System ("SY", S-1-5-18, SECURITY_NT_AUTHORITY:SECURITY_LOCAL_SYSTEM_RID)
The OS itself (including its user mode components.)

Local Service ("LS", S-1-5-19, SECURITY_NT_AUTHORITY:SECURITY_LOCAL_SERVICE_RID)
A predefined account for services that presents user credentials for local
resources and annonymous credentials for network access.
Available on XP and later.

Network Service ("NS", S-1-5-20, SECURITY_NT_AUTHORITY:SECURITY_NETWORK_SERVICE_RID)
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:
-----------------------------------------------------------

Administrators ("BA", S-1-5-32-544, SECURITY_NT_AUTHORITY:SECURITY_BUILTIN_DOMAIN_RID:DOMAIN_ALIAS_RID_ADMINS)
The builtin administrators group on the machine. This is not the same
as the builtin Administrator *account*.

Builtin users group ("BU", S-1-5-32-545, SECURITY_NT_AUTHORITY:SECURITY_BUILTIN_DOMAIN_RID:DOMAIN_ALIAS_RID_USERS)
Group covering all local user accounts, and users on the domain.

Builtin guests group ("BG", S-1-5-32-546, SECURITY_NT_AUTHORITY:SECURITY_BUILTIN_DOMAIN_RID:DOMAIN_ALIAS_RID_GUESTS)
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:
----------------------------------------------------------------

Authenticated Users ("AU", S-1-5-11, SECURITY_NT_AUTHORITY:SECURITY_AUTHENTICATED_USER_RID)
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.

Anonymous Logged-on User ("AN", S-1-5-7, SECURITY_NT_AUTHORITY:SECURITY_ANONYMOUS_LOGON_RID)
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
later.

World ("WD", S-1-1-0, SECURITY_WORLD_SID_AUTHORITY:SECURITY_WORLD_RID)
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
information.

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

Interactive Users ("IU", S-1-5-4, SECURITY_NT_AUTHORITY:SECURITY_INTERACTIVE_RID)
Users who initally logged onto the machine "interactively", such as
local logons and Remote Desktops logons.

Network Logon User ("NU", S-1-5-2, SECURITY_NT_AUTHORITY:SECURITY_NETWORK_RID)
Users accessing the machine remotely, without interactive desktop
access (ie, file sharing or RPC calls).

Terminal Server Users (---, S-1-5-14, SECURITY_NT_AUTHORITY:SECURITY_TERMINAL_SERVER_RID)
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
either.)

The below SID deserves special mention:
---------------------------------------

Restricted Code ("RC", S-1-5-12, SECURITY_NT_AUTHORITY:SECURITY_RESTRICTED_CODE_RID)
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.

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

Pavel Lebedinsky — Tue, 16 Mar 2004 06:20:00 GMT

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 AUTHORITY\ANONYMOUS LOGON)

Reference to nowhere

Florian W. — Tue, 16 Mar 2004 07:37:00 GMT

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:-(

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

Norman Diamond — Thu, 18 Mar 2004 05:17:00 GMT

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?

Commenting on this entry has been closed.

Raymond Chen — Mon, 02 Aug 2004 21:20:00 GMT

Commenting closes after two weeks.

http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx

Hex SID to Decimal SID Translation « Scripting. Stuff. (By Froosh)

Hex SID to Decimal SID Translation « Scripting. Stuff. (By Froosh) — Tue, 04 Sep 2007 05:32:09 GMT

PingBack from http://froosh.wordpress.com/2005/10/21/hex-sid-to-decimal-sid-translation/