In Windows Server domains, the BUILTIN\\Users group is a fundamental security principal with specific inheritance rules. Its membership isn't always intuitive due to nested group relationships.

The BUILTIN\\Users group typically includes:

* Authenticated Users (S-1-5-11)
* Domain Users (when on a domain controller)
* INTERACTIVE (S-1-5-4)
* LOCAL_SERVICE (S-1-5-19)
* NETWORK_SERVICE (S-1-5-20)

To programmatically check membership:

# PowerShell example
$group = [ADSI]"WinNT://./Users"
$group.Invoke("Members") | ForEach-Object {
    $_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)
}

# C# alternative
using System.DirectoryServices;
DirectoryEntry localMachine = new DirectoryEntry("WinNT://" + Environment.MachineName);
DirectoryEntry usersGroup = localMachine.Children.Find("Users", "group");
object members = usersGroup.Invoke("Members");
foreach (object member in (IEnumerable)members) {
    DirectoryEntry memberEntry = new DirectoryEntry(member);
    Console.WriteLine(memberEntry.Name);
}

On domain-joined machines:

• Domain Users are automatically added to local BUILTIN\\Users
• Local user accounts become members upon creation
• Service accounts inherit permissions through nested groups

Default permissions granted to BUILTIN\\Users include:

Read/Execute on most system folders
Basic registry read access
Limited service control permissions

For security hardening, consider reviewing these default permissions using:

# Audit Users group permissions
icacls C:\ /t /find "BUILTIN\\Users"

The BUILTIN\\Users group is a local security principal present on all Windows machines (both domain-joined and standalone). In domain environments, its membership dynamically includes:

- Authenticated users from the domain (DOMAIN\\Domain Users)
- Local machine accounts
- Interactive users (when logging on locally)
- Built-in security principals like INTERACTIVE and Authenticated Users

This default inheritance means domain users automatically get basic access rights on all domain-joined machines. Consider this PowerShell snippet to check effective permissions:

# Check BUILTIN\\Users group members
Get-LocalGroupMember -Name "Users" | Format-Table

# Verify effective permissions for a folder
(Get-Acl "C:\\SharedData").Access | 
Where-Object {$_.IdentityReference -like "*Users*"} | 
Select IdentityReference, FileSystemRights

The group's broad default permissions (read/execute on most system locations) make it a frequent target for privilege escalation attacks. Best practice recommends:

• Restricting write/modify permissions for BUILTIN\\Users
• Using domain groups instead for granular control
• Auditing with tools like AccessChk:

accesschk.exe "BUILTIN\\Users" -accepteula -q -v

To modify default behavior, you might implement these ADMX policies or registry changes:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System]
"LocalAccountTokenFilterPolicy"=dword:00000000

Or through Group Policy (GPO):

Computer Configuration -> Windows Settings -> 
Security Settings -> Restricted Groups