While troubleshooting a Windows 10 machine joined to an Active Directory domain, I encountered a peculiar permission issue where a Domain Admin account receives "access denied" errors when trying to access language settings through the SystemSettingsAdminFlows.exe, while the local admin account works perfectly fine.

Running icacls on the executable reveals:

c:\windows\System32\SystemSettingsAdminFlows.exe NT SERVICE\TrustedInstaller:(F)
                                              BUILTIN\Administrators:(RX)
                                              NT AUTHORITY\SYSTEM:(RX)
                                              BUILTIN\Users:(RX)
                                              APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)

The key observation here is that while Domain Admins are members of the local Administrators group (S-1-5-32-544), they're still being denied access to certain system functions.

This behavior stems from Windows 10's User Account Control (UAC) implementation. When a Domain Admin logs in:

• They receive a filtered admin token by default
• Certain protected system processes (like SystemSettingsAdminFlows.exe) require elevation even for admins
• Local admin accounts may bypass some of these checks due to different token handling

Option 1: Disable UAC Filtering for Admins

# Registry modification to disable UAC filtering
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "FilterAdministratorToken" -Value 0 -Type DWord

Note: This reduces security and requires reboot.

Option 2: Explicitly Run as Elevated Admin

# PowerShell script to launch settings with full privileges
Start-Process "SystemSettingsAdminFlows.exe" -Verb RunAs -ArgumentList "Control.exe /name Microsoft.Language"

Option 3: Modify File Permissions (Not Recommended)

# Temporary permission grant (security risk)
icacls C:\Windows\System32\SystemSettingsAdminFlows.exe /grant "DOMAIN\Domain Admins":F

For domain-wide solutions, these GPO settings can help:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options:
- User Account Control: Run all administrators in Admin Approval Mode → Disabled
- User Account Control: Behavior of elevation prompt for administrators → Elevate without prompting

The local admin account bypasses some UAC checks because:

• It's treated as a "true" administrator account by the local machine
• It doesn't undergo the same token filtering as domain accounts
• Certain protected processes have different ACL evaluations for local vs domain principals

---

Recently, I encountered a peculiar issue while working on a Windows 10 machine joined to our Active Directory domain. When logged in with our primary domain admin account, attempting to access language settings would trigger multiple error messages:

c:\windows\system32\SystemSettingsAdminFlows.exe
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

Interestingly, the changes would still save despite these errors, but having to dismiss 5-6 popups each time was frustrating. The problem didn't occur when using the local admin account on the same machine.

First, I verified that the domain admin account was indeed part of the local Administrators group. The account had no trouble performing other administrative tasks, which made this specific issue particularly puzzling.

Running icacls on the problematic executable revealed the following permissions:

c:\windows\System32\SystemSettingsAdminFlows.exe NT SERVICE\TrustedInstaller:(F)
                                             BUILTIN\Administrators:(RX)
                                             NT AUTHORITY\SYSTEM:(RX)
                                             BUILTIN\Users:(RX)
                                             APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)

The whoami /groups output showed that the domain admin account had all expected group memberships, including Domain Admins, Enterprise Admins, and local Administrators. Here's the relevant portion:

OFFICE\Domain Admins                                 Group          S-1-5-21-1731680816-2417063338-1172291106-512 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators                         Alias           S-1-5-32-544                                  Mandatory group, Enabled by default, Enabled group, Group owner

After some research, I realized this might be related to User Account Control (UAC) behavior with domain accounts. Windows treats domain accounts differently from local accounts when it comes to UAC elevation, even when they're in the Administrators group.

Here's a PowerShell script I used to verify UAC settings:

# Check UAC registry settings
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" | 
Select-Object EnableLUA, ConsentPromptBehaviorAdmin, FilterAdministratorToken

After testing several approaches, here's what worked:

1. Create a scheduled task to run SystemSettingsAdminFlows.exe with highest privileges
2. Modify the registry to adjust UAC behavior for domain admins

Here's the PowerShell code I used to create the scheduled task workaround:

$action = New-ScheduledTaskAction -Execute "C:\Windows\System32\SystemSettingsAdminFlows.exe"
$trigger = New-ScheduledTaskTrigger -AtLogOn
$settings = New-ScheduledTaskSettingsSet -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
Register-ScheduledTask -TaskName "RunSettingsAsAdmin" -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest

For a more permanent solution, I modified these registry keys:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v FilterAdministratorToken /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

This issue appears to stem from Windows 10's security model treating domain admin accounts differently than local admin accounts when it comes to certain system operations. The solutions provided maintain security while eliminating the annoying permission prompts.

Remember to test these changes in your environment before deploying widely, as they do modify security-related settings.