Mohamed Saber
GitHubFacebookLinkedin
Active Directory Domain Controller
Active Directory Domain Controller
  • πŸ”—Windows System Internals 101
    • πŸ†”Windows SID
      • πŸšͺWindows Logon Process
      • πŸ₯·Security principals
      • πŸ‘¨β€πŸ«security group
      • πŸ”‘Windows Security Context
      • 🎯Logon Base concepts
      • β›³Windows Security Access Token(SAT)
      • πŸ“ŒWindows Securable Objects
      • πŸ“œWindows Objects
      • πŸ“‘What is Security Descriptors in Windows
      • 🏒SID's Authority
      • πŸ”Local Security Authority (LSA)
      • πŸ”‘Windows Logon Session
Powered by GitBook
On this page
  • Base concepts for in detailed Knowledge
  • What is Local Machine or Local Computer ?
  • Key Components of a Local Machine ?
  • What is the Windows LSA Key?
  • What is Windows NT SYSTEM Access ?
  • What Are SYSTEM-Level Secrets?
  • DPAPI (Data Protection API) in Windows Internals
  • Window User Profiles
  1. Windows System Internals 101
  2. Windows SID

Logon Base concepts

What is Common Windows Logon Scenarios ?

Base concepts for in detailed Knowledge

What is Local Machine or Local Computer ?

  • A local machine refers to a standalone computer running Windows that manages its own security, user accounts, and resources independently, without being part of a centralized domain (like Active Directory).

Key Components of a Local Machine ?

  • What is Windows NT ? 1. The term "NT" in Windows NT stands for "New Technology" 7. This name was chosen because Windows NT represented a significant advancement in operating system design compared to previous versions of Windows. It introduced a completely new architecture that was more reliable, secure, and scalable 2. Windows NT was built from the ground up with a new kernel, independent of the MS-DOS-based systems used by earlier versions like Windows 3.x. This made it more robust and capable of handling advanced tasks

  • πŸ” What Are Cached Credentials? 1. Cached credentials are secure, local copies of a user's login information (specifically, a hash of the password, not the actual password). Windows stores these after the first successful domain logon on Domain-Machine, so the user can still log in even if the domain controller or cloud provider isn’t available , because the system stores a hashed version of their credentials locally.β€”like when they’re working offline or remotely. 2. Cached credentials enable users to authenticate locally on a Windows machine without contacting a domain controller. This is particularly useful for remote or mobile users who may not always have network access. 3. Cached Credentials Exist Only on Domain (or Azure AD) Joined Machines,Not on Local-Only Machines( Mean by That cached credentials are not used on a computer that is not connected to any domain (also called a local-only machine or standalone machine) ) But Local (standalone) machines do not use cached credentials in this context.

    Situation
    Does It Use Cached Credentials?
    Why?

    A PC at home with a local account

    ❌ No

    The password is already stored locally in SAM data base.

    A company laptop joined to a domain

    βœ… Yes

    Needs cached credentials for offline access.

    4. Cashed Credentials Security Considerations : 4.1. Storage Location: Cached credentials are stored in the registry under HKEY_LOCAL_MACHINE\Security\Cache\NL$n 4.2. Security Risks: If a device is compromised, attackers with administrative privileges could potentially extract cached credentials using tools like Mimikatz. 4.3. Configuration: Administrators can limit or disable credential caching by modifying the CachedLogonsCount registry value. Setting it to 0 disables caching entirely? 4.3.1. Disabling the cached credentials feature : to disabling the cached credentials feature is that if the machine loses its network connection and can no longer reach the domain controller, any local login requests to that domain will fail. The number of cached logins can be forced to zero by using a Domain Security Policy. Set β€œNumber of previous logins to cache (in case domain controller is not available),” which can be found under Computer Configuration β†’ Security Settings β†’ Local Policies β†’ Security Options, to zero. This change affects the CachedLogonsCount registry key on each member machine in the domain. This registry value can be found inside the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon ,

    Inside this key, you'll find entries named like:

    NL$1, NL$2, NL$3, ..., NL$10 ----------> This Where is Stored in Windows NT system ?

    4.4. The registry path where cached credentials are stored in Windows is:

    HKEY_LOCAL_MACHINE\Security\Cache 4.5. HKEY_LOCAL_MACHINE\Security\Cache\NL$n: Purpose and Technical Details ? 4.5.1. What is NL$n :

    • Location: HKLM\SECURITY\Cache\NL$1, NL$2, etc. (where n = numeric index)

    • Purpose: Stores secondary logon information (The term "secondary logon information" in the context of HKLM\SECURITY\Cache\NL$n refers to backup authentication data that Windows stores locally to allow users to log in when primary domain authentication is unavailable.) when:

      • A domain-joined machine loses network connectivity.

      • A user logs in with a previously used domain account.

    • Data Format: Encrypted NTLM hashes (not plaintext passwords).

    4.5.2. How Cached Credentials Work :

    A. When Does Windows Cache Credentials?

    1. Windows stores a hashed copy of the password in NL$n.

    2. If the machine goes offline, the user can still log in using the cached hash.

    3. User logs into a domain-joined machine while connected to the network.

    4.5.3. Technical Breakdown of NL$n Hint < ' _ ' > reading NL$n directly from the registry is far harder than extracting credentials from LSASS memory.

    Component

    Description

    Encryption

    Uses LSA secrets (protected by SYSTEM account).

    Hash Type

    NTLM (v1 or v2, depending on OS version).

    Registry Permissions

    Only SYSTEM and Administrators can read.

    4.5.4. What is the LSA Key?

    • Definition: A secure storage mechanism within the LSASS (Local Security Authority Subsystem Service) that holds sensitive system data Which called also as "LSA Secrets", including:

      • Cached domain credentials (NL$n).

      • Auto-logon passwords.

      • Service account credentials.

      ⚠️ LSA Secrets are stored in two primary locations, both designed to protect their confidentiality and integrity:

      1. Registry: HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets

        • Description: This registry key contains encrypted LSA Secrets. Each secret is stored as a subkey under Secrets, with names like NL$n (for cached domain credentials, where n is a number from 1 to the maximum cached logons, typically 10 by default) or specific names for other secrets (e.g., DefaultPassword for auto-logon).

        • Encryption: The data is encrypted using the LSA encryption key, which is derived from system-specific information and protected by the LSASS process. Only processes with appropriate privileges (e.g., SYSTEM) can access this key.

        • Access Control: The SECURITY hive is locked down to prevent unauthorized access. By default, only the SYSTEM account has read/write access, and even administrators cannot view it directly without elevating privileges.

        • Purpose: Storing secrets in the registry ensures persistence across reboots, allowing LSASS to retrieve them when needed for authentication or service operations.

      2. Memory: LSASS Process Space

        • Description: LSA Secrets are loaded into the memory of the LSASS process (lsass.exe) during system operation. This includes decrypted or partially decrypted forms of the secrets for real-time use in authentication tasks.

        • Protection: Secrets in memory are protected by the Windows kernel and LSASS’s isolation mechanisms. However, they are vulnerable to memory-dumping attacks if an attacker gains sufficient privileges (e.g., SYSTEM or debug privileges).

        • Access: Only privileged processes or threads running within LSASS can access these secrets. Tools like Mimikatz exploit vulnerabilities to extract secrets from LSASS memory, as discussed in various cybersecurity resources.

        • Purpose: Storing secrets in memory allows LSASS to quickly access them during authentication, such as verifying cached credentials for offline logon or authenticating service accounts.

    πŸ” Think of it as the β€œmaster password” that Windows uses to guard other secrets.

    2. The LSA Key is used to encrypt and decrypt several critical secrets in the system, including:

    πŸ›‘οΈ Protected Item
    Description

    LSA Secrets

    Includes cached credentials, service account passwords, RDP info, auto-logon credentials, etc.

    NL$KM

    The NTLM credential encryption key used by the system to store cached domain credentials.

    DPAPI Master Keys

    The root keys used to encrypt/decrypt files, browser passwords, Windows credentials, etc.

    Auto-logon Passwords

    Stored under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon in plaintext, but encrypted using the LSA key if protected.

⚠️What LSASS Stores in Memory

The LSASS process manages Windows security functions and retains various types of credentials in memory for operational purposes:

Credential Type

Description

Example

NTLM Hashes

Hashed versions of passwords (used for local/domain auth).

8846F7EAEE8FB117AD06BDD830B7586C

Kerberos Tickets

Encrypted TGTs (Ticket-Granting Tickets) for domain authentication.

krbtgt service tickets.

Plaintext Passwords

Occasionally, passwords may exist in clear text due to certain auth protocols or misconfigurations.

Pa$$w0rd123

Cached Domain Logons

Offline logon hashes (from NL$n registry entries).

Cached NTLM hashes for domain users.

DPAPI Master Keys

Keys used to decrypt stored credentials (e.g., saved browser logins).

User123_DPAPI_KEY

⚠️Why Plaintext Passwords Sometimes Appear in LSASS

A. Common Scenarios

  1. WDigest Authentication (Legacy)

    • Older Windows versions (pre-2014) stored plaintext passwords if WDigest was enabled.

    • Patch KB2871997 disabled this by default, but admins can re-enable it (insecure).

  2. SSPI (Security Support Provider Interface) Calls

    • Some applications (e.g., IIS, SQL Server) may pass plaintext creds to LSASS for authentication.

  3. Credential Delegation

    • Used in scenarios like Remote Desktop with "Allow Delegation" enabled.

  4. Third-Party Software

    • Poorly designed apps might inject plaintext passwords into LSASS for authentication.

B. Example: WDigest Exploitation

  • Before 2014: Windows stored plaintext passwords in LSASS if WDigest was active.

  • After 2014: Microsoft patched this, but attackers can re-enable it via:

    powershellCopy

    reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

    After a reboot, plaintext passwords reappear in LSASS.

What is the Windows LSA Key?

  • ➀ Definition:

    The LSA Key is a symmetric key used by the Local Security Authority Subsystem Service (LSASS) to encrypt and decrypt sensitive secrets stored in the Windows registry.

    It is stored in the SYSTEM hive and used to encrypt secrets found in the SECURITY hive of the registry.

  • The LSA key is created once, during:

    • Initial Windows setup (e.g., when you install Windows for the first time)

    • Or the first system boot after installation, before any user logs in

  • Where is the LSA Key Stored?

    It’s stored obfuscated and encrypted inside the Windows registry:

    πŸ“ Location:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    More specifically, the actual key is hidden and extracted from a value under:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data

These 4 values are XOR-obfuscated and encoded. When combined, they form the LSA encryption key.

  • Flow of LSA Key Creation ?

    Flow Diagram

    flowchart 
        A[Windows boots] --> B[LSASS starts]
        B --> C[LSASS reads SYSTEM hive]
        C --> D[Combines JD + Skew1 + GBG + Data]
        D --> E[Derives LSA Key]
        E --> F[Decrypts secrets from SECURITY hive]
        F --> G[LSASS uses the secrets (e.g., credentials, DPAPI)]
  • We have a point , the LSA Key is initialized From LSASS.e Process to decrypt the LSA secrets That LSASS retain or load in LSASS process during runtime

  • Step-by-Step: LSA Key Creation Flow

    1. Windows OS Initialization

    • During Windows installation or first boot:

      • The SYSTEM account is in full control.

      • LSASS (Local Security Authority Subsystem Service) is initialized.

    2. LSASS Needs a Secret Storage Key

    • Windows needs a persistent key to:

      • Encrypt/decrypt secrets like service account passwords, cached logons, and DPAPI master keys.

    • This is where the LSA Key is generated.

    3. Key Material Is Created by SYSTEM

    • Windows (under SYSTEM) generates a random 128-bit or 256-bit symmetric key.

      • Typically using the Cryptographic API (CryptoAPI) or CNG (Cryptography Next Gen) system libraries.

      • The key is strong and unique per machine.

    4. The Key Is Stored in Obfuscated Form

    • SYSTEM writes the encrypted key into the registry under:

    HKLM\SYSTEM\CurrentControlSet\Control\Lsa

    It is split across 4 values:

    • JD

    • Skew1

    • GBG

    • Data

    These values are:

    • Binary blobs stored in the SYSTEM hive.

    • Combined and XORed together to reconstruct the LSA key.

    This obfuscation helps hide the key from naive attackers or tools.

Then after we create LSA key , how we can use it ?

At Boot: LSASS Reconstructs the LSA Key

  • When Windows starts:

    • LSASS reads the 4 obfuscated registry values

    • Combines and decodes them using XOR logic

    • Loads the real symmetric LSA key into memory

  • This key:

    • Never leaves the LSASS process memory in plaintext(Inside LSASS is plaintext==Binary Format but out side is encrypted)

    • Is used throughout the session to:

      • Decrypt cached secrets

      • Decrypt DPAPI master keys

      • Decrypt stored service account credentials

  • Registry-Level View (Behind the Scenes)

    Registry Hive
    Path
    Description

    SYSTEM

    Control\Lsa\JD, Skew1, GBG, Data

    Contains the encrypted and split LSA Key

    SECURITY

    Policy\Secrets

    Contains encrypted secrets, decrypted using the LSA Key

What is Windows NT SYSTEM Access ?

  • What is "NT AUTHORITY\SYSTEM"?

    1. Common Name:

    • Full name: NT AUTHORITY\SYSTEM

    • Also known as: LocalSystem, SYSTEM, or NT SYSTEM

    2. Privilege Level:

    • Highest privilege on a Windows machine

    • Has full access to the entire local system

    • More powerful than any Administrator account

    3. Where Does SYSTEM Come From?

    • It’s a built-in Windows account.

    • Created and managed by the Operating System, not visible in standard user account management.

    • Used by Windows services, drivers, and core OS components to perform actions that users or admins normally cannot.

    4. Common Uses of SYSTEM

    Component
    Uses SYSTEM Privilege

    lsass.exe

    Handles authentication and security policies

    services.exe

    Manages system services

    winlogon.exe

    Handles user logon/logoff

    Device Drivers

    Run in kernel mode with SYSTEM privileges

    Scheduled Tasks

    If configured as SYSTEM, runs with full system power

    5. Why Is SYSTEM So Critical?

    1. Direct Kernel Access

    • SYSTEM can call native APIs, access memory, the registry, and any file.

    • It can also impersonate other users, including administrators.

    2. Can Modify Security Descriptors

    • It can bypass Access Control Lists (ACLs), even on files and registry keys administrators can't touch.

    3. Used by Windows Services

    • Services running as SYSTEM can persist, escalate privileges, and survive reboots.

    6. Why Attackers Want SYSTEM Access:

    Once an attacker has SYSTEM, they can:

    • Dump LSASS memory to extract credentials.

    • Create persistence mechanisms (like services or registry keys).

    • Disable antivirus and EDR.

    • Access SAM and SECURITY hives in the registry.

    • Install rootkits and run arbitrary code without restriction.

    7. Common Tools/Techniques to Gain SYSTEM:

    Tool/Technique
    Purpose

    PsExec.exe -s

    Run a command as SYSTEM

    Mimikatz

    Dump SYSTEM-level secrets

    Exploits (e.g., Token Privilege Escalation)

    Elevate to SYSTEM

    Scheduled Tasks

    Create a SYSTEM task

    Service DLL Hijacking

    Replace a DLL loaded by a SYSTEM service

    UAC Bypass

    Some methods escalate to SYSTEM silently

    8. In Windows, "SYSTEM" (also called LocalSystem) is the highest privilege account on a Windows machine. It’s even more powerful than an Administrator.

Privilege Level
Description

🧍 Standard User

Limited rights, can't install software or make system changes.

πŸ‘‘ Administrator

Can install programs, manage users, and control most of the system.

πŸ›‘οΈ SYSTEM (NT AUTHORITY\SYSTEM)

Full access to everything on the local machine, including other users' data, LSASS memory, protected registry keys, et.....

What Are SYSTEM-Level Secrets?

  • ➀ Definition:

    SYSTEM-level secrets are security-critical pieces of information that are accessible only to processes running under the SYSTEM context or with kernel-level access.

  • These include:

    Type
    Examples

    Credential secrets

    NTLM hashes, clear-text passwords, Kerberos tickets

    Service secrets

    DPAPI master keys, LSA secrets, machine account passwords

    Token secrets

    Access tokens, security identifiers (SIDs), privilege info

    Crypto secrets

    Private keys, BitLocker keys, certificate keys

    Registry-based secrets

    SAM database, SECURITY hive, LSA secrets

DPAPI (Data Protection API) in Windows Internals

  • ➀ What is DPAPI?

    DPAPI (Data Protection API) is a Windows built-in encryption framework used to securely store and retrieve sensitive data, such as:

    • Saved credentials

    • Wi-Fi passwords

    • Browser secrets (Chrome, Edge, IE)

    • RDP credentials

    • Certificates and private keys

    It’s available since Windows 2000 and is used transparently by applications through simple APIs.

Window User Profiles

  • A Windows user profile appears to be a way for the operating system to manage individual user settings and data.

  • Windows User Profile ?

A Windows User Profile is a structured, user-specific container that holds personal data, application settings, user-specific registry settings, and security artifacts like "DPAPI keys" and credentials also representing the user's characteristics and preferences within the operating system. It is loaded when a user logs on and unloaded upon logoff.

  • It is created the first time a user interactively logs onto a computer, not when accessing shared network folders, ensuring a personalized experience. The primary purpose is to save and load configuration information, such as desktop arrangements, network connections, and application settings, each time the user logs on, providing consistency and privacy.

  • User profiles provide the following advantages:

    • When the user logs on to a computer, the system uses the same settings that were in use when the user last logged off.

    • When sharing a computer with other users, each user receives their customized desktop after logging on.

    • Settings in the user profile are unique to each user. The settings cannot be accessed by other users. Changes made to one user's profile do not affect other users or other users' profiles.

  • Each profile is:

    • Linked to a unique SID (Security Identifier)

    • Stored on disk (usually under C:\Users)

    • Mapped to the registry hive HKEY_CURRENT_USER

    • Used to isolate user settings and secrets

  • Profile Structure on Disk/Location

    C:\Users\<Username>\
  • Key Folders/Components

    • AppData (hidden): plays a crucial role in how applications store user-specific data.

      • Local (AppData\Local): Machine-specific data (e.g., cached files, temp files).

      • Roaming (AppData\Roaming): Syncs across devices (Like ... Outlook signatures, SSH keys).

      • LocalLow (AppData\LocalLow): Low-integrity data (Like ... browser sandboxed data).

    • Documents, Desktop, Downloads: User-created files.

    • NTUSER.DAT: Registry hive for the user (loaded as HKEY_CURRENT_USER).

    • UsrClass.dat: COM class registrations (loaded as HKEY_CLASSES_ROOT).

  • Windows Profiles Internals

    Profile Creation Process

    1. First Logon:

      • Copies the Default User Profile (C:\Users\Default) to create a new profile.

      • Assigns NTFS permissions to the user’s SID. 1. NTFS permissions to the user’s SID refers to the access control settings applied to a user’s profile folder (As ..... C:\Users\<Username>) using the NT File System (NTFS) security model, tied to the user’s Security Identifier (SID). 2. Key Components

        • NTFS Permissions : These are rules defining who can access files or folders on an NTFS-formatted drive and what actions they can perform (e.g., read, write, modify, or full control).

        • User Profile Folder: The folder storing a user’s personal data and settings (e.g., Documents, Desktop), typically located at C:\Users\<Username>.

        • SID (Security Identifier): A unique alphanumeric string assigned to each user account in Windows ( S-1-5-21-...). It identifies the user or group in the system, independent of the username, ensuring consistent access even if the username changes.

        3. What It Means When a Windows user profile is created (e.g., upon first login), the system assigns NTFS permissions to the user’s profile folder, linking those permissions to the user’s SID. This ensures:

        • Exclusive Access: By default, only the user (identified by their SID) has full control over their profile folder. Other users, including administrators, are typically restricted to prevent unauthorized access to personal files.

        • Security and Privacy: The SID-based permissions protect sensitive data (e.g., Documents, AppData) by ensuring only the account associated with that SID can access or modify the folder’s contents.

        • Consistency Across Systems: For roaming profiles (used in network environments), the SID ensures the correct user retains access to their profile, even on different computers, as the SID remains constant.

      4. How It Works

      • When a user logs in for the first time, Windows creates their profile folder and sets NTFS permissions. The user’s SID is added to the folder’s Access Control List (ACL) with permissions like "Full Control."

      • The ACL might also include permissions for:

        • SYSTEM: For system processes to manage the profile.

        • Administrators: Often with limited or no access to user data, unless explicitly granted.

      • Other users’ SIDs are typically denied access to prevent unauthorized viewing or editing.

      • You can view these permissions by right-clicking the profile folder (C:\Users\<Username>), selecting Properties > Security tab, where the SID or resolved username appears with associated permissions.

    2. Registry Initialization:

      • NTUSER.DAT is initialized from Default User\NTUSER.DAT , Windows NT inherit all properties of the default user for the first logon User.

      • Loaded into HKEY_USERS\<SID> and linked to HKEY_CURRENT_USER.

        1. What is HKEY_USERS\<SID>

        a. When a user logs into Windows, the system loads their registry settings from NTUSER.DAT (stored in their profile folder) into the HKEY_USERS\<SID> hive and then creates a symbolic link to HKEY_CURRENT_USER (HKCU). This process ensures that user-specific settings are available to applications in a standardized way. b. Step 1 ( User Authentication )

        • When a user logs in, winlogon.exe triggers the Local Security Authority Subsystem Service (LSASS) to authenticate the user.

        • Upon successful login, the User Profile Service (ProfSvc) retrieves the user’s Security Identifier (SID) and checks:

          • Local Profile: C:\Users\<Username>\NTUSER.DAT

          • Roaming Profile (if domain-joined): \\Server\Profiles\<Username>\NTUSER.DAT

        c. Step 2 Loading NTUSER.DAT into HKEY_USERS\<SID> d. Step 3 Linking HKEY_CURRENT_USER

        • After loading into HKEY_USERS\<SID>, Windows creates a symbolic link:

          • HKEY_CURRENT_USER β†’ HKEY_USERS\<SID>

        • This allows applications to access user settings via a consistent HKCU path, regardless of the actual SID.

        Why are other user SIDs there too ?

        Even though User One is logged in, you might still see other users’ SIDs listed. Here’s why:

        1. Another user is still logged in

        • Windows lets users switch without logging out (Fast User Switching).

        • If User Two is still logged in, their settings are still loaded too.

        2. Background processes

        • Some programs or services might run as another user, which temporarily loads their registry settings.

        3. Domain or shared computers

        • On work or school computers, profiles are sometimes cached.

        • If other people logged into the machine before, their settings might still be there.

        4. Admins loaded them manually

        • IT people can open another user’s settings by loading their NTUSER.DAT file into the registry

        e. Step 4 Profile Loading (Logon Sequence)

        Profile Loading (Logon Sequence)

        1. Authentication: LSASS (Local Security Authority Subsystem Service) validates credentials.

        2. Profile Selection:

          • For domain users: Checks for roaming profiles.

          • For local users: Uses the local profile.

        3. Hive Mounting:

          • The User Profile Service (ProfSvc) loads NTUSER.DAT into the registry.

          • Applies Group Policies and logon scripts.

        d. Profile Unloading (Logoff Sequence)

        • Sync Changes: For roaming profiles, uploads updates to the network share.

        • Hive Unload: Unmaps HKEY_CURRENT_USER and closes handles to NTUSER.DAT.

      Types of User Profiles

      Types of User Profiles in Windows

      1. Local User Profile

      • What it is: A profile created and stored on the local machine when a user logs in for the first time.

      • Where it's stored: C:\Users\<Username>

      • Used by: Users who log into local accounts or domain accounts on one computer.

      • Example: If you log in as John on one computer, your settings and files are saved only on that computer.

      2. Roaming User Profile

      • What it is: A profile stored on a network server, not just the local machine.

      • Where it's stored: Profile gets downloaded to the PC from a server at login and saved back to the server at logoff.

      • Used by: Users in organizations using Active Directory/domains who move between PCs.

      • Benefit: User gets the same desktop, settings, and files no matter which company computer they log into. 3. Default User Profile

        • What it is: A template profile that Windows uses to create a new local user’s profile.

        • Stored in: C:\Users\Default

        • Used for: Copying basic files and settings when a new profile is being created.

        • Admins can modify it to set default settings for new users.

        Summary Table

        Profile Type
        Stored Where
        Can Save Changes?
        Used For

        Local

        C:\Users\Username

        βœ…Yes

        Regular PC users

        Roaming

        Network share

        βœ… Yes

        Domain users on multiple PCs

        Mandatory

        Network share

        ❌ No

        Locked-down environments (labs, kiosks)

        Temporary

        Temporary folder

        ❌ No

        Error fallback, profile load failed

        Default

        C:\Users\Default

        N/A

        Template for creating new profil

PreviousWindows Security ContextNextWindows Security Access Token(SAT)

Last updated 1 month ago

πŸ”—
πŸ†”
🎯
Inside & Outside LSASS process
Registry Hive we talk about