When setting up PowerShell remoting between domains in a parent-child relationship (mycompany.com → dev.mycompany.com), authentication failures often occur due to Windows security policies. The key symptoms manifest when:

• Attempting FQDN-based connections (my-vm.dev.mycompany.com)
• Using local admin accounts across trust boundaries
• Facing WinRM's strict default security configurations

We'll address this in three phases:

The essential registry modification to bypass UAC token filtering:

# Disable UAC token filtering for local accounts
New-ItemProperty 
-Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 
-Name LocalAccountTokenFilterPolicy 
-Value 1 
-PropertyType DWord

Security Note: This reduces security for local accounts. Consider alternatives for production environments.

When working across domains, credential formatting becomes critical. These methods properly format credentials:

# Method 1: Explicit credential object
$cred = New-Object System.Management.Automation.PSCredential(
    "dev\username",
    (ConvertTo-SecureString "password" -AsPlainText -Force)
)

# Method 2: Using Get-Credential with domain specification
$cred = Get-Credential -UserName "dev\username" -Message "Enter password"

# Method 3: Alternative FQDN format
$cred = Get-Credential -UserName "username@dev.mycompany.com"

Effective session creation commands for different scenarios:

# Basic local session
New-PSSession -ComputerName localhost

# FQDN with explicit credentials (best practice)
New-PSSession -ComputerName my-vm.dev.mycompany.com -Credential $cred

# Using URI format for WinRM
New-PSSession -ConnectionUri "http://my-vm.dev.mycompany.com:5985/wsman" 
              -Credential $cred

For complex environments, consider these additional settings:

# Configure TrustedHosts for certificate-less environments
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*.dev.mycompany.com" -Force

# Adjust authentication mechanisms
Set-Item WSMan:\localhost\Client\Auth\Negotiate -Value $true
Set-Item WSMan:\localhost\Client\Auth\Kerberos -Value $true

While convenient for development environments, these configurations should be adjusted for production:

• Implement certificate-based authentication
• Configure constrained endpoints
• Use Just Enough Administration (JEA)
• Consider Group Policy Managed Service Accounts

When working with PowerShell remoting across domain boundaries (in this case between mycompany.com and dev.mycompany.com), several authentication hurdles emerge. Let me walk through the specific scenario and solutions:

# Initial failed attempt with FQDN
New-PSSession -ComputerName my-vm.dev.mycompany.com
# Result: Access denied due to cross-domain restrictions

By default, Windows imposes strict security policies for remote connections across domain boundaries. Even when your account has administrative privileges on the target machine (my-vm in our case), domain trust relationships come into play.

The key aspects affecting our scenario:

• LocalAccountTokenFilterPolicy setting (required for local admin access)
• WinRM configuration for cross-domain communication
• Credential delegation requirements

Here's the complete working solution that addresses both authentication and trust issues:

# Step 1: Set LocalAccountTokenFilterPolicy (one-time configuration)
Set-ItemProperty 
-Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 
-Name LocalAccountTokenFilterPolicy 
-Value 1

# Step 2: Configure WinRM for cross-domain access
winrm set winrm/config/client '@{TrustedHosts="my-vm.dev.mycompany.com"}'

# Step 3: Establish the session with proper credential formatting
$cred = Get-Credential -UserName "dev\msorens" -Message "Enter DEV domain credentials"
$session = New-PSSession -ComputerName my-vm.dev.mycompany.com -Credential $cred

For more complex environments, consider these additional settings:

# For certificate-based authentication (recommended for production)
Enable-PSRemoting -Force -SkipNetworkProfileCheck
Set-WSManQuickConfig -Force -UseSSL

# Configure SPN for proper Kerberos authentication
setspn -S HTTP/my-vm.dev.mycompany.com dev\my-vm$

When things go wrong, these diagnostic commands help:

# Check WinRM listener configuration
winrm enumerate winrm/config/listener

# Test basic connectivity
Test-WSMan -ComputerName my-vm.dev.mycompany.com

# Enable detailed logging
wevtutil set-log "Microsoft-Windows-WinRM/Operational" /enabled:true

• Always use FQDNs rather than hostnames
• Configure proper DNS resolution between domains
• Consider implementing constrained delegation for service accounts
• For production environments, use certificate-based authentication

# Example of constrained delegation configuration
$principals = @("HTTP/my-vm.dev.mycompany.com", "WSMAN/my-vm.dev.mycompany.com")
Set-ADComputer -Identity "my-vm" -ServicePrincipalNames $principals