Samba Active Directory: Troubleshooting Windows GPOs, RDP and Logon Rights

A practical Samba AD homelab case study covering Windows Group Policy, Remote Desktop, firewall rules, local administrator permissions, secedit, SIDs and gpresult.

Real-world homelab case study · October 2026

Introduction

My Synology NAS Seido runs Samba AD for the order.realm homelab. Recently I was reorganising workstation GPOs, enabling RDP on Windows Pro computers, and diagnosing why remote access or sign-in could still fail after a policy appeared to be enabled. This is a record of the findings and tests, rather than a generic checklist.

GPO quick-reference table

All paths below start inside the Group Policy Management Editor. The Computer / User column helps avoid changing the right setting in the wrong policy scope.

Goal Scope Location (after scope) Setting / action
Enable RDP Computer Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections Allow users to connect remotely: Enabled
Require NLA Computer Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security Require user authentication using NLA: Enabled
RDP firewall Computer Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → Inbound Rules Allow trusted source IPs to RDP TCP port
Remote logon rights Computer Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment Allow / Deny log on through RDS
Logon script User Policies → Windows Settings → Scripts (Logon/Logoff) Logon
Startup script Computer Policies → Windows Settings → Scripts (Startup/Shutdown) Startup
Loopback Computer Policies → Administrative Templates → System → Group Policy Configure user Group Policy loopback processing mode

The environment

The domain includes older Shuttle PCs, a dedicated Arcade computer, a music PC and general-purpose Windows machines. One computer OU is OU=OlderPCs,OU=Computers,OU=NetherRealm,DC=order,DC=realm. I wanted baseline policies shared across machines but dedicated restrictions kept to their intended OUs.

1. Check where the machine lives

A GPO existing in the console does not prove that it applied. Check hostname, domain membership, computer OU and resultant policy before editing anything.

hostname
whoami /groups
Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain
gpresult /scope computer /r
gpresult /scope user /r
gpresult /h "$env:TEMP\gpo-report.html" /f

2. Enabling RDP centrally

Rather than hunting around ADUC, edit the linked GPO in Group Policy Management (GPMC). These are Computer Configuration settings, so link the policy where the intended computers live.

GPO: Enable Remote Desktop

  1. Open: Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections
  2. Setting: Allow users to connect remotely by using Remote Desktop Services
  3. Value: Enabled

GPO: Require Network Level Authentication (NLA)

  1. Open: Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security
  2. Setting: Require user authentication for remote connections by using Network Level Authentication
  3. Value: Enabled

GPO: Permit RDP through Windows Firewall

  1. Open: Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → Windows Defender Firewall with Advanced Security → Inbound Rules
  2. Action: Create a predefined Remote Desktop inbound rule (TCP), or a narrowly scoped equivalent
  3. Scope: Restrict applicable profiles and remote IP ranges to your trusted network/VPN; confirm it applies to the domain profile

What caught us out: RDP can be enabled in policy while the effective firewall rules still block TCP 3389. Do not open 3389 to the public internet.

3. Rule out connectivity before permissions

DNS resolution is not the same as TCP reachability. ICMP ping can fail when firewalls block it, so check TCP port 3389. Because VLANs and routing were also being adjusted in the homelab, separate a routing problem from a Windows logon problem.

Resolve-DnsName YOUR-PC.order.realm
Test-Connection YOUR-PC.order.realm -Count 2
Test-NetConnection YOUR-PC.order.realm -Port 3389
Get-Service TermService
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select DisplayName,Enabled,Profile,Action

4. Separate administrator and RDP rights

Local Administrators and Remote Desktop Users are different roles. For routine remote access, grant a dedicated domain group membership in Remote Desktop Users on the target machines instead of making everyone a local administrator. Verify the effective local membership and the security token of the account actually being tested.

Get-LocalGroupMember -Group 'Administrators'
Get-LocalGroupMember -Group 'Remote Desktop Users'
whoami /groups

5. The secedit discovery

We exported rights.inf and inspected SeInteractiveLogonRight. That setting is Allow log on locally (console), not Allow log on through Remote Desktop Services. An RDP investigation must also review SeRemoteInteractiveLogonRight, SeDenyRemoteInteractiveLogonRight and the relevant local logon deny right. Deny rights take precedence over allow rights.

secedit /export /cfg "$env:TEMP\rights.inf"
Select-String "$env:TEMP\rights.inf" -Pattern "SeInteractiveLogonRight|SeDenyInteractiveLogonRight|SeRemoteInteractiveLogonRight|SeDenyRemoteInteractiveLogonRight"

6. Understand SID entries

The security policy export contained built-in SIDs S-1-5-32-544 (Administrators) and S-1-5-32-545 (Users), plus domain-specific SIDs. Translate domain SIDs rather than guessing which named account each represents. One account working does not prove another has the same groups or rights.

$sid = 'S-1-5-21-REPLACE-WITH-YOUR-SID'
([System.Security.Principal.SecurityIdentifier]$sid).Translate([System.Security.Principal.NTAccount]).Value

7. Find the policy that actually wins

In Group Policy Management, select the GPO and check its Scope and Settings tabs. The link location, security filtering and inheritance determine which objects get it. On the client, gpresult shows the result.

GPO: Allow or deny Windows sign-in rights

  1. Open: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment
  2. For RDP: Check Allow log on through Remote Desktop Services and Deny log on through Remote Desktop Services
  3. For console: Check Allow log on locally and Deny log on locally
  4. Important: Deny takes precedence; identify any policy granting a deny right before changing group membership

Fix the originating GPO rather than making a temporary local change that a later policy refresh overwrites. Review Microsoft-Windows-GroupPolicy/Operational and the relevant Security events if processing or authentication fails.

gpupdate /force
gpresult /h "$env:TEMP\gpo-after.html" /f
secedit /export /cfg "$env:TEMP\rights-after.inf"

8. Other GPO cleanup lessons

During the same tidy-up I reviewed desktop settings, unwanted application configuration, a WireGuard policy and a SYSVOL user logon script for software deployment.

GPO: User logon script

  1. Open: User Configuration → Policies → Windows Settings → Scripts (Logon/Logoff) → Logon
  2. Target: Users in scope, not every computer in a computer OU
  3. Location example: \\YOUR_DOMAIN\SYSVOL\YOUR_DOMAIN\Policies\{YOUR-GPO-GUID}\User\Scripts\Logon

If you need an installer to execute for the device regardless of who signs in, evaluate Computer Configuration → Policies → Windows Settings → Scripts (Startup/Shutdown) → Startup instead; startup scripts run in a different security context, so confirm access to the installer share.

GPO: Scope specialist-machine restrictions

Keep an arcade or kiosk-specific restriction in an appropriate computer OU and check whether loopback processing is enabled if the user settings need to depend on the workstation. Path: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode. Only enable Merge or Replace when it is actually needed.

Important: Removing a script-based software deployment does not uninstall an existing application. A managed software installation may have a separate removal setting; do not assume it applies to an installer run from a script.

9. Verification checklist

Test in order: identify target and account; confirm OU and applied GPOs; confirm DNS and TCP route; confirm RDP listener, NLA and firewall; check local groups; export allow/deny user rights; resolve unknown SIDs; correct the originating GPO; refresh; and retest separately with each intended account.

Lessons learned

The useful distinction is between reachability, service state and authorisation. We identified a missing effective firewall allowance and clarified a misleading console-logon permission check. Those findings were established, but a later account-specific RDP test was still being investigated, so it would be inaccurate to declare every login case resolved.

Privacy note: Replace example machine names, SIDs, credentials and IP addresses with your own. No secrets are included in this post.

Related: Home Network Design.