SAM registry hive files have not been found on the all drives

Many people think the built-in Administrator account is the most powerful account in Windows, which is not true. If you wanted to find something in Windows like root is for Linux, it would be the SYSTEM user account. This account can see and do things an admin can't. This makes it essential for all troubleshooting, like when you want to access the SAM and SECURITY hives in the Registry.

Why is it like this? Well it wasn't always this important, and up to Windows 2000, things were a little different as Microsoft was still building different operating systems for consumers other than enterprises.

When consumers had Windows 95, enterprises had Windows NT; when consumers had Windows ME, enterprises had Windows 2000. With the introduction of Windows XP, Microsoft merged these lines and started offering the same products to both of them. Enterprise users didn't have to have admin rights as they could call the service desk, but consumers needed to have admin rights as they didn't have a service desk to call.

This meant consumers running as full admins were at high risk of accidentally destroying their computers by, for example, right-clicking Program Files and hitting Delete. This is when Microsoft started moving more and more rights to the SYSTEM account and away from the Administrator account.

The SYSTEM user:

• Has more privileges than the admin
• Can see things the admin can't
• Can stop processes the admin can't
• Has a higher integrity level than the admin
• Can bypass most policies

Let's look at an example where you would like to verify whether the computer account password actually changes when you are troubleshooting issues with a computer that has lost the trust relationship with the domain. The Active Directory computer account has a password attribute, but locally it is stored in the Registry. Let's open regedit.exe and see we can't access it:

Regedit.exe running as Administrator is not able to see the SECURITY hive's content

Let's try the same thing with the SYSTEM account. We'll use PsExec.exe from Sysinternals for this.

First, start a command prompt via Run As Administrator and run:

-psexec -sid cmd.exe

Starting a command prompt with the SYSTEM account

From the new command prompt, you can verify you are running as SYSTEM via WhoAmi.exe.

Now start regedit.exe (you need to close other instances of RegEdit or use the -m parameter).

Running regedit.exe as SYSTEM

As you can see, you can now access many places admins can't, like SECURITY, SAM, or the hives for AppLocker.

Another great example is trying to figure out how Group Policy background sync triggers. In Windows 7, the GPClient service was running all the time and would sync Group Policy Objects (GPOs) every 90–120 minutes. In Windows 8, Microsoft changed this as GPClient was just consuming CPU power when it wasn't needed for anything.

Try to open the Task Scheduler with an admin account to see the Group Policy tasks. Nothing is there.

Scheduled tasks shown as an admin

Now open taskschd.msc running as SYSTEM from the prompt and look again.

Subscribe to 4sysops newsletter!

Scheduled tasks shown as SYSTEM

So as you can see, you can see many things as the SYSTEM account and not as Administrator.

Where is the SAM registry file found?

What is the SAM registry hive?

What can you find in the SAM registry file?

In which hive key the SAM info will get stored?