The idea of SidCenter component is simple enough. It has a set of properties that corresponds to different SID forms. For example you have SID in FormA and you need to obtain it in FormB. Then you simply assign SidCenter.FormA property and then read SidCenter.FormB property. SidCenter will do all work for you. Let's illustrate it.

Create new form and place TsvSidCenter component on it. Look on its properties

The most simple property is Server. It is a name of computer on which SID manipulation should occur. An empty string means current computer. Other significant properties are Domain/UserName, SidString, WellKnown, Source, SID and SID explicit data (Revision, IdentifierAuthority, SubAuthorityCount). Not all of these properties are available in design time. Let's start with those that are available.

Domain/UserName
Use these properties to obtain SID from the name of user, computer or domain. For example set Domain value to the name of your domain and the UserName property to your logon name. You will see that all other properties changes. You can do the same in run time and as you see you will not need to do anything more - just get required representation of SID.

To get the SID of domain or computer simply left the UserName property empty. Note that the last number in SID string is DWORD(-1).

Now note that Source property has ssName value. This property changes automatically to reflect what source of SID is primary now and what is derived. Only primary SID source will be stored into form's .dfm file (Check it - right click the form and select 'View as Text' menu item). It means that if Source is ssName then only Domain and UserName properties will be stored into form resource. Running on another machine SidCenter will use these properties to obtain SID, not SidString or other properties.

Well, now try to change the last number in the SidString property say to 500. You will see three things. At first, Source property will change. Now it equals to ssString. In addition you will see that UserName property will change to Administrator (or localized equivalent on non-English NT workstations). And the third the WellKnown property will be changed to wkAdmin. SidCenter automatically detects well-known SIDs and changes WellKnown property if necessary.

Try to change the last number in SidString to another values: 501 (Guest), 512 (Admin's group), 513 (User's group) and so on. You can try to set SID string to values from registry (HKEY_USERS or HKEY_LOCAL_MACHINE\...\Profiles subkeys names) or from Recycler subdirs to obtain user names. Some other SID string are available from documentation ('S-1-5-4' for example). You can do the same at run time if you have SID string and need to obtain SID in other form.

Another important property is WellKnown. This property allows to obtain predefined SIDs. It is especially useful when the name of well-known SID is localized and you wish to avoid localization problems. Several well-known SIDs can't be obtained via its names. The Authenticated Users group is exactly this case (at least on NTWS4.0Rus SP4 and NTSV4.0Eng SP3) . Try to change the WellKnown property and watch the changes. Note that some well-known SIDs are short while other include a lot of digits. It is so because one SIDs do not depend on domain or computer while some others do.

To illustrate other SidCenter properties we shall need to add a code to our example. We shall do it on the next step.