Windows – How to do if I forgot the Windows password

The SYSTEM and NETWORK SERVICE accounts are not real account and do not exist in the SAM – in other words, they cannot have a password set, and you cannot login into them. They only exist as "well-known SIDs" (security identifiers) – Windows simply gives special treatment to such SIDs as S-1-5-18 or S-1-5-20, similar to how uid 0 is special in Unix, and privileged programs can use this account by creating tokens themselves (similar to calling setuid()+capset() in Unix).

An easy way of running programs with SYSTEM privileges is via PsExec from Sysinternals:

psexec -dsi cmd

However, unlike Unix root, not even SYSTEM is allowed to bypass object ACLs – that's why all registry entries, system files and other things explicitly show SYSTEM in their ACLs. Instead, if an administrator needs for some reason to override an object's ACL, they can take ownership of that object using SeTakeOwnershipPrivilege¹ (granted by default to all Administrators). This works because an object's owner is always allowed to change its ACLs, even if they explicitly deny it; this is the only² exception Windows makes.

Sometimes access is being denied due to other reasons – many antivirus programs come with "self defense" kernel drivers, which patch various functions in the Windows kernel itself and make them reject modifications to specific keys or files based solely on their name; the block is before the original ACL checks take place, and no permission or privilege can override it. The only way to bypass such protection is to undo the kernel modifications; any kernel debugger can be used for this. Such tools as Kernel Detective can list all entries in the SSDT, which kernel driver has modified which function, and even have commands to reset the default values.

¹ If curious, you can use Process Explorer to view all SIDs and privilege bits assigned to a particular process. You'll see that not even the system processes have any sort of generic "override security" privilege; instead, only specific privileges such as SeImpersonate, SeTakeOwnership or SeCreateToken exist.

² For files, someone holding SeBackupPrivilege can read a file in "backup mode" – an archive containing the data, metadata, ACLs, ownership... – then optionally modify it, and restore it to the filesystem again. That is, assuming someone has reverse-engineered the structure of these backup archives. This is not available for other kinds of objects.

I think the problem you're having with @Daniel Beck's answer is that the password isn't stored in the user record's Password attribute, but as a shadow hash file in /var/db/shadow/hash/USERGUID, and the AuthenticationAuthority attribute still points to that. This seems to work for me:

sudo dscl . -delete /Users/buildbot AuthenticationAuthority
buildbotGUID=$(dscl . -read /Users/buildbot GeneratedUID | awk '{print $2}')
sudo rm "/var/db/shadow/hash/$buildbotGUID" "/var/db/shadow/hash/$buildbotGUID.state"

Ideally, you should also remove the account's Kerberos principal (OS X clients run their own "local" Kerberos realm, and it occasionally gets underfoot). But that's a bit more complicated, and I think depends a fair bit on which version of OS X you're using.

BTW, if the above doesn't completely do the trick, try this:

sudo dscl . -create /Users/buildbot AuthenticationAuthority ";DisabledUser;"