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 access flags;
- to generate audit. The ACL is used for this purpose too;
- to identify user of computer or domain;
- to identify computer in domain;
 - 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.

String form
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.

Named SIDs
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.

Explicit SID data
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 (S-1-5-21-1166345773-2347170053-14123502-500 in our example), the 501 will designate a Guest (S-1-5-21-1166345773-2347170053-14123502-501 in 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.