First of all, copying a loaded user profile isn’t possible without the BACKUP privilege. You can’t open already opened files a second time (share deny). The solution is: Either you can use a backup application that runs with the special privilege or you can just use another administrative user (which I did).

There are some keys which have absolute path variables that must be changed, too. But that is a minor problem. The big problem was that Windows could not load the profile of the Administrator. Windows tried to start up the users desktop but then failed with the dialog:  “Windows failed to load user profile.”

It got more confusing because every other user in the system didn’t suffer from this problem. And to top it,  sometimes I could successfully login to the Administrator account.

Solution

In such cases the event manager is a good way to find the error source. In my case, it told me that “NTUSER.DAT” (this is where Windows stores the current user keys called a registry hive) was already opened by another process. I really can’t say why this was the case because it shouldn’t be the case shortly after a fresh boot up. (Of course, the file was correct, it had no write protection, and security was set accordingly)

In such a case you usually have some ways to fix the problem:

1. Reinstall Windows
Good choice. But too much work — and who will promise me that it won’t happen again?

2. Leave Administrator where it was
Also good choice. And I tried it. However my Windows could not handle two profile places somehow and the very same error occured with the old profile location.

3. Live with the situation
Some people do it. I thought about it, too, I have to admit. That’s because there is a user called root in the system now.

4. Find the bug and ignore how much time it will cost.
Ouch. I don’t have time, so not a good option.

5.Create a workaround.
YES! That’s what I did.

So I came up with a practical and fast solution. As I’ve already written, the user’s registry hive could not be loaded.
Why? I don’t know much about it but the registry file was blocked.
Well, I’ve found out that if the Administrator registry hive was already loaded (HKEY_USERS\S-1-5-21-xxx-500 is visible) the Windows could successfully logon the Administrator. I simulated this situation by manually loading the user’s profile using the LoadUserProfile function from Windows API. Well, it always worked!

The next step was to do it automatically before an Administrator could logon. Of course, I could have created a service which loads the user profile at startup but I wanted to be fast so there is another option called Task Scheduler.
Every Windows startup I let run the code above as a simple task with Administrator credentials (needs password).

I don’t know whether the Task Scheduler loads the profile (I would guess so). However the problem is that the profile could be unloaded after the process has ended. So the hive would be removed and logon would no more be possible.

Thus the code above just loads the profile but does not unload it. Since profiles are not watched by Windows (at least in XP) the registry hive  stays loaded and a logon attempt will work (T.Free won’t unload it!).

JEDI Windows Security Code Library used features

• TJwSecurityToken (class)
  
• TJwSecurityToken.LoadUserProfile (method)

A principal is not recognized by its name, but by its unique SID which is a dynamic structure in the C world. It is made of three parts:

• A revision level that defines the sid version and currently is set to one (1).
• A 48 bit number which defines the authority that created the SID. (e.g. Windows NT defines 5)
• An array of numbers which uniquely identify the principal within the authority. The last number is sometimes called a relative identifier (RID).

A template string of a SID may look like this. (Brackets [ ] define optional parameters):

S – R – I [- S1 [- ... - Sn - [RID]]]

• S declares the string as a SID.
• R defines the revision number.
• S1-…-Sn defines the sub-authority. It is an array of n numbers that identifies a domain or machine.
• RID is the relative principal identifier. It is an unique, sequential and increasing number for a principal assigned by the authority. In Windows, known RIDs start with 500 which defines the Administrator account. RIDs of 1000 and above are used for the usual users and groups. The RID is not an independant part of a SID. In fact it is really the last part of the sub-authority array. Thus the Windows API and JWSCL do not have functions to read or alter it directly. To do so you must access the sub-authority array.

Windows defines some well known SIDs and some well known RIDs. Well knowns SIDs look the same on every computer because they have no domain or machine identifier. On the other hand there are well known RIDs which are system or domain relative. I write system as in operating system, because even on a multi boot computer the SIDs vary between different operating systems if they are not cloned. Several identical SIDs on different machines may lead to security problems. In this case there is a little helper called NewSID that helps changing the SID.

You can find a list of well known SIDs and RIDs in MSDN. Some important well known SIDs are shown here:

• S-1-1-0 : The Everyone group
• S-1-5-4 : The Interactive identifier which allows interactive logon.
• S-1-5-5-#-# : The Session Logon SID (more about it here ) “#” is a placeholder for the high and low value of the logon session ID called LUID. It can be retrieved from the principal’s token.

Here are some important well known RIDs. The ellipsis <…> represent the system or domain.

• S-1-5-<…>-500 : The Administrator account
• S-1-5-<…>-501 : The Guest account
• S-1-5-32 : The Builtin Local groups which identifies a member of a Builtin database

Some well known RIDs are appended to the Builtin SID to define them as special accounts and that they are hard-coded into the system.

• S-1-5-32-544 : The Administrators group
• S-1-5-32-545 : The Users group
• S-1-5-32-546 : The Guest group

1. Create a copy of an existing TJwSecurityID instance
2. Create a copy of an existing SID structure
3. Create a copy from a nested SID structure within a SidAndAttributes structure
4. Create a SID from an authority and an identifier
5. Create a well known SID from known constants
6. Create a SID from a string that represents the SID
7. Create a SID from the combination of a system and user name

These ways are accomplished by the TJwSecurity constructors:

1. constructor <strong>Create</strong>(const SecurityID: TJwSecurityId);
2. constructor <strong>Create</strong>(const SID: PSID);
3. constructor <strong>Create</strong>(const SID: PSidAndAttributes);

4. constructor <strong>Create</strong>(const Authorities: TJwSubAuthorityArray; Identifier: TSidIdentifierAuthority);
   

   constructor <strong>Create</strong>(const Authorities: array of Cardinal; Identifier: TSidIdentifierAuthority);
5. constructor <strong>CreateWellKnownSid</strong>(WellKnownSidType: TWellKnownSidType; DomainSid: TJwSecurityId = nil);
6. constructor <strong>Create</strong>(const SIDString: TJwString);
7. constructor <strong>Create</strong>(const SystemName, AccountName: TJwString);

1.

<u><strong>Create</strong>(const SecurityID: TJwSecurityId)</u>

2./3. <strong>Create</strong>(const SID: PSID)/<strong>Create</strong>(const SID: PSidAndAttributes);
It is quite uncommon to create an instance by using a SID structure. However if you ever encounter such a task you must be aware that the assigned SID is copied (not refered to it) into the instance. The const key-word in front of the parameter name denotes that parameter SID will not be altered internally. Thus there is no other way than to copy it. Also be aware that the SID memory is checked for a correct SID structure; otherwise EJwsclInvalidSIDException will be raised.

4. <strong>Create</strong>(const Authorities: TJwSubAuthorityArray; Identifier: TSidIdentifierAuthority);
It is easily possible to create a SID from scratch by using the internal parts of a SID. In the following example we create the well known group SID “Everybody”.

The constant five bytes long array identifier SECURITY_WORLD_SID_AUTHORITY from JwaWindows is declared as follow:

We add a subauthority of zero and get the shown output. The emtpy brackets usually contains the SID’s attributes which we did not use.

Everybody (S-1-1-0) []

The second constructors receives an declared array which describes the sub-authoroties. With the help of it we can alter an existing instance. The example shown below demonstrates how to alter the Everybody group by changing the sub authority array.

5. <strong>CreateWellKnownSid</strong>(WellKnownSidType: TWellKnownSidType;...);
The way to create a well known SID as shown in part #4 is very inconvenient. Thus the class TJwSecurityID contains a constructor that directly allows us to use one of the well known SID constants declared in JwaWindows or JwaVista (only if you need the new Vista definitions). The enumeration type WELL_KNOWN_SID_TYPE holds all known SIDs.

The CreateWellKnownSid constructor uses the definition from JwaVista. So if you do not use JwaVista in your use clause you have to add it now because the constructor uses the new version. In this case you should add JwaVista in front of JwaWindows since Delphi uses by default an identifier that is declared in the latest included unit.
The code below uses declarations introduced by JwaWindows but not JwaVista.

Of course it is possible to explicitly refer to JwaVista. This task is done by adding the unit name in front of the identifier seperated by a point operator.

Creating a well known SID in this way needs getting used to:

If you start programming and want to use Vista stuff from the beginning, you should add JwaVista after JwaWindows. In this case you can easily create a well known SID.

6. <strong>Create</strong>(const SIDString: TJwString);

A very convenient way to create a SID instance is to use the SID string format that was described at the very first part of this discussion.

Be warned that the constructor may raise an exception if you do not comply with the SID string format.

7. <strong>Create</strong>(const SystemName, AccountName: TJwString);

There is sometimes the necessity to get the SID of a user on a specific system. E.g. the user enters his name and the domain or machine name, in this case you can create a SID by a principal’s name. The following example creates a SID instance from the given user on the local system.

Call this method if you need display information of the SID instance. It shows information about the domain and user name, the SID string and attributes if any. Set the parameter ignoreExceptions to false if you want to get an exception if a SID could not be translated into an name. Set it to true if you just want an empty string to be displayed instead. If you don’t want to use too many exception handling mechanisms, you should set the parameter value to true.

Everybody (S-1-1-0) []

I already used this method to show you the output earlier in this article.

GetText uses the system or domain name once assigned to the constructor. However sometimes it is necessary to change it. The property CachedSystemName gets or sets this system or domain name.

This readonly property contains the SID’s string representation as shown in GetText.

Use the WellKnownSidType property if you need to know of what well known type the SID consists of. Be aware that you should not rely on it if the return value is WinNullSid, because in this case the SID could also be any other SID. The property returns this value for a NULL SID and also for a unknown SID. Use the boolean property IsWellKnownSID to check for a well known SID.

The attributes assigned to a SID can be used in different ways. Some WinAPI functions need them for example. However you can use two versions that are nearly equal. Either you set a bitmask using the property Attributes or you use a enumeration set with AttributesType.

Next time I’ll talk about more JWSCL classes that represent well known SIDs and are defined in the unit JwsclKnownSID.

Tell me how you liked this blog entry by adding a comment.