Please note: this short review
is my own point of view on SID and its usage. The aim of this review is to
present basic information that you will probably need if you are going to
manipulate Windows NT Security. Please refer to the Microsoft's documentation
for the complete information about it.
Well, let's begin.
The SID is a variable length structure
that is widely used in Windows NT Security Model. The main role of SID is to
identify security subjects. This subject can be represented by user or a group
of users, by computer or a domain. On one hand it makes SID universal and
powerful tool because it results to the uniform way of security subjects
identification. On the other hand it makes SID usage complicated enough. The
SIDs are used:
- to identify owner of securable object;
- to identify
owners' group of securable object;
- to specify access rights to securable
object. The Access Control List (ACL) is used for this purpose. This list
consists of Access Control Entries (ACE) and each entry consists of SID and
- to generate audit. The ACL is used for this purpose
- to identify user of computer or domain;
- to identify computer
- to identify domains.
Several predefined SIDs are used as
aliases. For example the SID exist that corresponds to any user logged on via
modem. If this SID is used to disable access to some securable resource then
any user will not have access to this object via modem in spite of they could
have access to the same object via network for example.
The SID has a lot of representations
and it does not simplify the SID usage.
Often SID is stored as string ('S-1-5-32-547' for example). This
representation is used in documentation, in registry (see HKEY_USERS subkeys),
in folder names (see RECYCLER subdirectories) and probably in other situations.
Almost all SIDs have readable names and Windows API includes
functions that convert name to SID and vice versa. It is not too convenient
(memory allocation and so on) but you can use it to obtain SIDs for users,
computers and domains. Unfortunately sometimes it does not work. The first case
is names of well-known SIDs. Microsoft specifies for example that 'EVERYONE'
group exists always and LookupAccountName should return well known SID for this
name ('S-1-1-0'). It is not so. The Russian equivalent ('???') should be used for this purpose on
Russian version of NT and I guess that other localized versions have the same
problem. Another big surprise was that sometimes LookupAccountSID correctly
returns the name for given SID but LookupAccountName fails to convert this name
back to SID.
There are several special cases in which the SID data should be
changed explicitly. I mean predefined SIDs that depend on computer or domain.
For example the Administrator's SID will differ for any two computers in spite
it has the same name. To build such SID you should take the SID of computer
(S-1-5-21-1166345773-2347170053-14123502-4294967295 for example) and change the
last number (4294967295 = DWORD(-1)) to desired value. For example 500 will
correspond to Administrator built-in account
our example), the 501 will designate a Guest
our example) and so on.
Now you see that SID manipulation is
complicated and can essentially change in different situations. The variable
SID length creates additional difficulties. Do not forget that dealing NT
security you will have to convert SIDs from one form to another. It complicates
SIDs using completely. So... use TsvSidCenter component. It does all this stuff
so you will not need to code and even study it. Let's continue.