For Windows Professionals, it's critical to understand the latter, which is always either:
Locally in the Security Accounts Manager (SAM), which is part of the local registry
or ...
Centrally in the same, network-wide SAM on the Domain Controller(s) of the current Domain
In fact, the network-wide SAM in a Domain actually comes from the local SAM of the local registry of the first promoted Domain Controller (DC).
SIDE NOTE: By "Domain," this can be both older NT3-4 Domains, and newer NT5+ (2000+) ActiveDirectory (AD) Domains. SIDs remain unchanged in either, although AD Domains have some beneficial approaches, such as differentiating between [Security] Groups (containing users and external domain groups) and Domain Local Groups (containing only groups from the local domain). More on this in a bit.If your file system has any SIDs that aren't one of those two that the NT system can reference, then the OS will prevent you from accessing the files -- at least in NT6+ (Vista and later). It was much more "dangerous" in NT5 (2000/XP/2003) and completely dangerous in NT3-4.
This is especially problematic in an Enterprise environment, especially when more than one (1) domain is in use.
E.g.,back in those early days, we had to use separate "Resource" Domains -- where file shares were at -- from "Security" Domains -- where users/groups were defined. We'd put users in groups of a "Security" Domain, and then add those groups from a "Security" Domain into a group of a "Resource" Domain. A share or file would then have only "Resource" Domains applied.
This was so the NTFS file system of that server with a file in a file share would only have SIDs of its local domain, preventing corruption.
In NT5+ (2000+), Active Directory now has both [Security] Groups and Domain Local Groups (DLGs). Users go in Security Groups, and Security Groups are assigned to Domain Local Groups (DLGs). DLGs are then put on files in shares so they always have SIDs that are local. Multiple Domains can assign their Security groups to another Domain's DLGs, but only that local Domain's DLGs go on the files in shares of those servers.
This is all due to how NTFS was designed in the early '90s, and it continues today. At least NT6+ (Vista and later) are "smart enough" to just cut off access if an SID on a file is unknown, instead of corrupting a NT file system (NTFS). CarioFS (NT4, never made it), WinFS (NT6, never made it), etc... was supposed to address this, but it never happened.
Even when migrating/restoring, NT lacks a 'read-only' mount/access (unlike POSIX systems -- like UNIX and Lnux). So a NT system must "take ownership" of files, before it can even use them. Otherwise, again, it can corrupt the NTFS file system without those references. That's why it's best to use a "Domain," even at home.
SIDE NOTE: Although it can be much safer to migrate data using Linux than Windows from NTFS, as Linux has a read-only NTFS mount. Linux can also use its 3G NTFS driver to migrate files with SIDs references intact, unlike the NT kernel in Windows (long, even deeper story of the internals). This is one of there reasons Microsoft -- especially the Azure team -- now uses Linux for a lot of Infrastructure operations.