TEMP Profiles vs Username.domain Profiles
Posted by William Diaz on February 7, 2013
There is often confusion between the two. But knowing what each profile type means is an important step in understanding what is going wrong with the profile.
TEMP profiles
These are often created when the local profile and the roaming profile are not the same. For example, a user logs on to their normal workstation and as the local profile is compared against the roaming profile, some file is missing, or some folder or file security rights in either of the profiles have been modified that do not allow it to be read or written so that both the profiles cannot be merged. An example of mismatching profile can be found here.
Another cause of TEMP profiles is when a local profile file is opened (or gets “hooked”) by some system or application process before logon or during logon, preventing, for example, ntuser.dat from opening. An example of this can be found here; and you can also recreate this by remotely opening a handle to the ntuser.dat of any user profile by using the remote Registry > Load Hive in regedit and then trying to log on as that person on the workstation which you loaded their hive. I was both victim and the offender in this example here. In both these cases TEMP profiles protect the integrity of the local profile.
And finally, TEMP profiles are also created when the local user profile folder is renamed or removed but the registry profile remains intact. A registry profile on the affected system means the user has at some point logged on to that workstation but Windows cannot locate the folder profile defined in the ProfileImagePath string of the registry profile (more on that below).
You might also see the registry profile get renamed to .bak:
If this is the case, you can recover the original registry profile by renaming it to remove the .bak or by modifying the ProfileImagePath string of the new registry profile to the original profile folder path.
Username.domain profiles
Username.domain profiles (or username.local for non-domain, workgroup PCs) literally include the domain name they belong to, i.e. smithj@microsoft.com. These are created when the user logging on to the system has a local username profile folder on that system but does not have a registry profile. Windows does not want to overwrite local user profile folders that already exist so it sees the existence of the folder and decides to create a new profile with the username + the domain name in both the registry and the local file system.
Registry profiles can be found under HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ProfileList. Each profile takes on a unique security identifier (SID). Each SID key defines the path to the local user profile folder:
Delete the registry profile and if a local profile folder already exist for that user on that system, the new registry profile will define a new ProfileImagePath and use that going forward:
Again, this is done to protect the original local profile folder as it may contain files that should not be deleted. If the registry profile happens to get compromised again and username.domain profile folder still exists, then a new profile will created as username.domain.000, 001, 002, etc.
If you are seeing cases of username.domain profiles, you need to investigate what is compromising the registry profiles. Hint, Process Monitor and set a registry filter on the ProfileList registry key.
Leave a Reply