The .Default user is not the default user


If you ever gone spelunking in the HKEY_USERS registry key, you've no doubt found the user named HKEY_USERS\.Default. Who is this guy?

Despite its name, the profile for the .Default user is not the default user profile. It's actually the profile for the Local System account and is an alias for HKEY_USERS\S-1-5-18. (S-1-5-18 is the security identifier for the Local System account.) Consequently, settings in HKEY_USERS\.Default are used by programs and services that run as Local System. The most visible examples of programs that run as Local System are winlogon and logonui, the programs that display the interface for logging onto the system. Whatever color scheme and screen saver you choose for the Local System profile get used at the logon screen.

Unfortunately, the name .Default has led people to believe that this user's settings are the basis for new user profiles. In retrospect, calling it .Default was probably a bad decision. It just gave people the wrong idea. Here's one customer that was faked out:

I'm setting the values in HKEY_USERS\.Default\International but when I create a new user, that user doesn't pick up those settings. I'm stumped.

The registry settings for new users do not come from the .Default user. Rather, they come from what I've started calling the "template user", which is kept† in the file C:\Documents and Settings\Default User\ntuser.dat. This hive is not loaded most of the time (since there's no reason to waste memory on something that is needed only rarely), so if you want to make a change to the template user, you'll have to load the hive manually.

Mind you, messing with the template user hive directly is most likely not supported. The supported way of modifying the template user hive on Windows XP is to use the system preparation tool "SysPrep". Boot into factory mode, make your customizations to the current user, then reseal. The resealing process propagates the current user's settings to the template user (or, more specifically, the ones that can safely be propagated to the template user—you don't want to propagate things like encryption keys) before "resealing" the system for deployment.

(No, I don't know what the mechanism is for Windows Vista.)

Nitpicker's corner

†s/which is kept/which is typically kept on US-English systems/

Comments (30)
  1. Joel Python says:

    Only on Windows would you be able to set desktop wallpaper for a system account!

  2. David Crowell says:

    @Joel

    What’s the problem with that?  You will need admin rights to do it.

  3. Joel Python says:

    The point is – why would a system account need desktop wallpaper? It’s not like the system has eyes that it can use to look at it!

  4. Rick C says:

    So, Joel, you are advocating special-casing the system to make sure that unnecessary settings don’t get used by one particular user?

  5. Andy C says:

    Setting the wallpaper for the system account is useful because that’s what is displayed when nobody is logged on.

  6. I think the process for Vista involves some hackery with Windows PE but I’m still working out the exact steps myself.

    Is having a .DEFAULT profile something of a security risk? could something be loaded into .DEFAULT that runs whenever an application runs as local system?

  7. J says:

    "Is having a .DEFAULT profile something of a security risk? could something be loaded into .DEFAULT that runs whenever an application runs as local system?"

    Don’t you need admin rights to change HKEY_USERS?  If that’s the case, you can probably do something a little more malicious than changing a registry setting in .DEFAULT.

  8. Joel Python says:

    James, were your remarks directed at me?

  9. Slightly off topic… but why is it called a "hive"?

  10. Richard Smith says:

    Eric: First hit on a google search for "why is it called a hive":

    http://blogs.msdn.com/oldnewthing/archive/2003/08/08/54618.aspx

  11. Ian Watkins says:

    [url=http://www.pandora-security.com/forum/viewtopic.php?t=2093]Used to be possible[/url], but I think it has since been locked down by a hotfix last time I tried it.

  12. Nick says:

    [The resealing process propagates the current user’s settings to the template user (or, more specifically, the ones that can safely be propagated to the template user—you don’t want to propagate things like encryption keys) before “resealing” the system for deployment.]

    I’m curious about this now. Normally to customize the default user when I’m creating an image for one of our labs, I follow the steps found here: http://support.microsoft.com/kb/319974

    Does that take care of safe propagation as well? I always thought it just copied all the profile files into the specified directory. In fact, I used to know somebody who just did that manually, saying I wasted my time using the Copy To dialog.

    [I was not aware that “Copy Profile” cleans the profile a la reseal. Maybe it does, maybe it doesn’t. I do know that people who do raw profile copying run into problems like “Why does Bob’s documents show up as ‘Carol’s Documents’?” -Raymond]
  13. Nick says:

    [I do know that people who do raw profile copying run into problems like "Why does Bob’s documents show up as ‘Carol’s Documents’?"]

    Ah, that has bitten me once or twice.  I now make sure and check for the Desktop.ini file that changes the folder name from "My Music" to "Administrator’s Music".  That section is supposed to be deleted when the file is copied, but it doesn’t happen with the Copy To dialog. (http://support.microsoft.com/kb/321281)

    Getting off-topic, but I assume the [DeleteOnCopy] section of the ini file is removed by the shell when the file is copied, but if you use something like CopyFile(), the section is not removed? That sounds like it may be the cause behind KB321281.

  14. James Schend says:

    The .Default account’s wallpaper (and screensaver) is used behind the login screen if nobody has logged in to the computer. Most companies use this, as they can set it to their corporate logo (and an appropriate screensaver) for computers that are just idling for whatever reason. It looks really slick in a computer lab of 30 computers all waiting for users to log in to have a wallpaper for your school instead of the default XP wallpaper.

    I’m sure Linux has the same feature, it’s just about 20,000 times more complicated than going into TweakUI, clicking Logon, then Settings.

    Next time try actually *using* Windows before criticizing it.

  15. A says:

    > which is kept in the file %ALLUSERSPROFILE%ntuser.dat.

    *braces for nitpicking accusation*

    That should say "Default Userntuser.dat". There is no %ALLUSERSPROFILE%ntuser.dat file.

  16. Starfish says:

    > I’m sure Linux has the same feature, it’s just about 20,000 times more complicated than going into TweakUI, clicking Logon, then Settings.

    >

    > Next time try actually *using* Windows before criticizing it.

    Pot…kettle…anyone? (Ironic since you need to *install* TweakUI on Windows – KDE and Gnome come with options to do it already!)

    Random thought: wouldn’t it be odd if Local System was like any other user and could be logged in as? Or maybe it is possible, useless as it is…

  17. andy says:

    "(Ironic since you need to *install* TweakUI on Windows – KDE and Gnome come with options to do it already!)"

    IIRC TweakUI is a Powertoy and unsupported anyways. Reread the article where the supported way of dealing with this is described. Probably sucks only for companies changing logos all the time :)

  18. Stephen Jones says:

    —-"than going into TweakUI, clicking Logon, then Settings."—-

    In my version of Tweak UI there is no settings button on the logon tab. Presumably you need to check you have the correct version of Tweak installed first. Gets more complicated by the minute!

  19. Les Bowman says:

    I just make my own custom registry modifications for the Default User template. I’ll set the power settings, kill the welcome screen, check "Empty Internet Explorer Temp Files on close" and all sorts of other stuff. Export those keys to a .reg file, edit the .reg file and change the path in the registry key to something like HKUDefUser save the .reg and then load the hive of the default user using the name I specified in the modified registry file, import the reg file and then unload the hive. You pretty much have to do this for images, other wise people will complain that the NumLock key isn’t on or worse I can’t delete old profiles remotely because the TempInet folders have path&file names too long to delete.

    <a href="http://www.computerpowersaver.com/PM_Win2k_Whitepaper.pdf">This link</a> has a good overview of the process and is a good place to start. From there you’ve just got to find the registry keys for you edit. Keep in mind some things like the XP Tour/Firewall have to be turned off in the local group policy and with Win2K you have to load/unload hives in RegEdt32.

  20. Norman Diamond says:

    Friday, March 02, 2007 11:03 AM by J

    [Gary Williams:]

    > Is having a .DEFAULT profile something of a

    > security risk? could something be loaded

    > into .DEFAULT that runs whenever an

    > application runs as local system?"

    >

    Don’t you need admin rights to change

    HKEY_USERS?  If that’s the case, you can

    probably do something a little more malicious

    than changing a registry setting in .DEFAULT.

    All true, but there are reasons why writers of some kinds of malware prefer to do things like loading their app in the local system account.  If they install something like a spam server, they want it to be camouflaged so it will continue operating for a long time before being discovered.

    Meanwhile, how many apps would break if the local system account’s name were changed from .Default to .LocalSystem?

  21. Melvin says:

    The .Default account’s wallpaper (and >screensaver) is used behind the login screen if >nobody has logged in to the computer. Most >companies use this, as they can set it to their >corporate logo (and an appropriate screensaver) >for computers that are just idling for whatever >reason.

    And more helpfully when you’ve got a 16 port hot key KVM you can tell which server it’s set to before initiating the logon process by incorporating the server name into the default wallpaper.

  22. 1 says:

    windows = single user os.

  23. Igor says:

    This is the way I use to customize user account during Windows install:

    in $OEM$ folder make a file CMDLINES.TXT with the following:

    —snip—

    [COMMANDS]

    "REGEDIT /S TWEAKUSR.REG"

    "USERACCT.CMD"

    —snip—

    Obviously TWEAKUSR.REG should contain all user customizations.

    USERACCT.CMD should also be in $OEM$ and contain the following:

    —snip—

    NET USER <your_username> <your_password> /ADD

    NET LOCALGROUP Administrators <your_username> /ADD

    —snip—

    While you are at it, why not enable auto logon if you are doing it for the home computer? Create a file AUTOLOG.REG in $OEM$ folder with the following content:

    —snip—

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon]

    "DefaultUserName"="<your_username>"

    "DefaultPassword"="<your_password>"

    "AutoAdminLogon"="1"

    —snip—

    Then just add "REGEDIT /S AUTOLOG.REG" to CMDLINES.TXT.

  24. KJK::Hyperion says:

    .Default is named like that because it’s the fallback key advapi32.dll uses for HKEY_CURRENT_USER when it cannot open the HKEY_USERS<user’s SID> key

  25. gripper says:

    Actually,

    Sysprep has its limits updating the Default user template.

    Working with a huge OEM customer, I ran bug-a-boo issue where sysprep doesn’t migrate all the owner settings to the default user template after reseal. Actually it was such a huge issue, my X-mas vacation was cut short and I flew out to Austin to investigate first hand.

    This specifically effected a few Registry keyed Windows Installer components – the behavior was noted that after reseal and after OOBE, the MSI keyed registry components didn’t exist, and an MSI repair was triggered.

    This was fixed by creating an install action that directly updated the Default User template NTUSERS.DAT file.

    So even sysprep seems to have its limits…

  26. VSTO Add-Ins aka Managed Office Add-Ins have a major deficiency on the deployment side. Putting it simple,

Comments are closed.