Technical Analysis and Configuration Guide for Using IP Address as Target in PowerShell Remoting

Overview of PowerShell Remoting Authentication Mechanisms

PowerShell Remoting (PSRemoting) is implemented based on the Windows Remote Management (WinRM) service, with Kerberos as the default authentication mechanism. Kerberos authentication requires fully qualified domain names (FQDN) as target identifiers, which is the fundamental reason why IP addresses cannot be used directly for connections. When specifying an IP address as the -Computername parameter, the system automatically falls back to NTLM authentication, but specific configuration conditions must be met.

Error Analysis and Core Problem Identification

Based on the user's reported error message: "The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided.", the core issues can be clearly identified in authentication mechanisms and transport security requirements. Specifically:

• When using IP addresses, default Kerberos authentication is unavailable, requiring NTLM authentication
• NTLM authentication requires either HTTPS transport configuration or adding the target IP to the TrustedHosts list
• Explicit credentials must be provided, even when using the current user identity

Detailed Configuration Steps for Solutions

Method 1: Configuring TrustedHosts List

Add target IP addresses or wildcards to the local computer's TrustedHosts configuration using PowerShell commands:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.123.123" -Force

Or use wildcards to allow all hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force

After configuration, restart the WinRM service to apply changes:

Restart-Service WinRM

Method 2: Enabling HTTPS Transport

Configure SSL certificates and enable HTTPS listeners for more secure transport channels:

# Create self-signed certificate (test environment)
$cert = New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My

# Create HTTPS listener
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint -Force

Use the -UseSSL parameter when connecting:

Enter-PSSession -ComputerName 192.168.123.123 -Credential $cred -UseSSL

Method 3: Providing Explicit Credentials

Regardless of the transport method used, explicit credentials must be provided when connecting via IP address:

$cred = Get-Credential
Enter-PSSession -ComputerName 192.168.123.123 -Credential $cred

Special Considerations for Cross-Network and VPN Environments

In VPN connection environments where DNS resolution may be unavailable, using IP addresses becomes necessary. The recommended approach is a combination of HTTPS and TrustedHosts:

1. Configure TrustedHosts on the client to include the server IP
2. Enable HTTPS listener on the server side
3. Use -UseSSL parameter and explicit credentials when connecting

This configuration resolves authentication issues while ensuring transport security, particularly suitable for cross-domain and untrusted network environments.

Security Best Practices

While setting TrustedHosts to "*" can quickly resolve the problem, from a security perspective, it is recommended to:

• Use specific IP addresses or IP ranges instead of wildcards when possible
• Prioritize HTTPS transport configuration in production environments
• Regularly review and update the TrustedHosts list
• Combine with network firewall rules to restrict remote management access

Troubleshooting and Verification

After configuration, connection status can be verified using:

Test-WSMan -ComputerName 192.168.123.123

Check current TrustedHosts configuration:

Get-Item WSMan:\localhost\Client\TrustedHosts

Examine listener status:

Get-ChildItem WSMan:\localhost\Listener

Through systematic configuration and verification, IP-based PowerShell Remoting can be ensured to operate stably and reliably across various network environments.