Where do registry settings in user profiles come from – part 1?

Trying to figure out where a particular registry setting that a user ends up with in their session can be tricky since there are a myriad of places that registry settings can come from. These can include:

·         The default user profile

·         A mandatory profile

·         An existing local profile

·         An existing roaming profile

·         Group policy

·         Logon scripts (of which there are many types and ways to launch)

·         Terminal Server “shadow” key

·         Applications (including application virtualisation products)

The first hurdle to cross when a user is not getting the correct setting can be to see what the setting really is in order to confirm that it is indeed the registry which is “at fault”. The rest of this article will explain the various methods that can be employed to see what particular registry setting a user has since this isn’t always as straightforward as it sounds.

If the user has logged off then using regedit.exe to load their ntuser.dat, which is what becomes their HKEY_CURRENT_USER hive when they logon, can be the simplest method. Their ntuser.dat file should be in the location specified for the roaming profile in their Active Directory account properties although on Terminal Services there are a number of group policy settings that can override this to set a computer wide roaming profile path or to force a mandatory profile. If a roaming profile is not configured then try the locally cached profile on the computer they were using via its C$ share. Group Policy Objects (GPOs) may be in place to delete locally cached profiles after logoff although this is usually only used in conjunction with roaming profiles since otherwise a user’s settings would be discarded (which can sometimes be desirable). I always take a copy of the ntuser.dat file and work on this in order not to disturb timestamps and to prevent issues if the user logs on again whilst you are performing investigations. To load the hive in regedit.exe, put the focus on to “HKEY_USERS” key and select the “Load Hive” option from the File menu. When prompted for a key name, enter any arbitrary, but vaguely meaningful, name. Remember also, when your investigations are complete, to unload the hive from the File menu.

If the user is still logged on, it may just be a case of running regedit.exe remotely and connecting to the user’s machine. Obviously when doing this HKEY_CURRENT_USER is not directly accessible so you will have to go via the remote HKEY_USERS and select the correct key name based on the user’s SID. Rather than having to ascertain the user’s SID, simply look in the “Volatile Environment” sub key of each SID key for clues as to which user it relates to, such as the “USERPROFILE” or “APPDATA” values. If remote access is not possible, regedit could be run locally although this may well be prevented via group policy and you probably want to run regedit yourself rather than letting a user loose with it so a remote control session or physical visit will be required. If regedit is denied via group policy, there are a couple of temporary ways around this short of changing GPO’s for this user. The first, which must obviously be done as an administrator, e.g. via runas, since users do not have write rights to their own group policy keys in HKEY_CURRENT_USER, is to temporarily change the registry value which stops regedit from working. This is the “DisableRegistryTools” in “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System” which should be (temporarily) set to a zero. No logoff and logon is required, which would probably refresh the value anyway, since this registry value is read dynamically at run time by regedit.exe itself. The second method is to find another tool that will expose the registry for examination – note that reg.exe is also subject to the above GPO applied registry setting. It is actually possible to make binary modifications to a copy of the regedit.exe executable so that it looks for another, non-existent, value but the method will not be detailed here. If you do this, you should guard this executable carefully and ideally use another security product which prevents execution of unauthorised code since this can wreak havoc on your carefully crafted computers.

Next time we will cover in more detail the multitude of places where these registry settings can come from.