Enable Remote Access to a Non-Domain Windows Computer

Setting up a fresh Windows workstation or recovering an isolated standalone server often leaves you in a difficult spot: you have zero physical or console access to the computer. You cannot plug in a keyboard, there is no crash cart monitor attached, and no remote KVM/iLO/iDRAC console is available. All you have is the machine’s static IP address on the network and the local administrator account credentials.

Yet when you attempt standard troubleshooting, Test-Connection fails with packet timeouts, Remote Desktop reports error code 0x204, and Enter-PSSession throws a WinRM connection refused error.

An unpingable non-domain Windows machine can still accept administrative commands over SMB (TCP 445) using Sysinternals PsExec.

Because the machine is not joined to an Active Directory domain, there is no Kerberos ticket granting service, no domain group policy pushing firewall exemptions, and no centralized DNS registration. Windows defaults to a locked-down profile where ICMP echo requests (ping) are discarded, WinRM listeners do not exist, and remote desktop services are disabled. Under the strict constraint of having no console or physical access, your only path is network-level bootstrapping: if TCP port 445 is reachable across the wire, you can use Sysinternals PsExec with your local administrator credentials to spawn a remote execution shell and configure Remote Desktop, WinRM, and OpenSSH in place.

Quick answer

When you have zero physical console access to an unpingable non-domain Windows computer, test whether SMB is reachable using Test-NetConnection -ComputerName <IP> -Port 445. If TCP 445 succeeds, use your local administrator credentials to launch an elevated remote execution shell over Sysinternals PsExec: .\PsExec.exe \\<IP> -u .\<AdminUser> -p <Password> -h -s powershell.exe. Once connected through this network bridgehead, enable RDP via Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0, configure WinRM using Enable-PSRemoting -Force -SkipNetworkProfileCheck, and install OpenSSH via Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0; Start-Service sshd; Set-Service -Name sshd -StartupType Automatic. Finally, open Windows Firewall for ports 3389, 5985, and 22.

The Non-Domain Admin Problem: Silent IP and No Access

In enterprise environments, Active Directory coordinates trust, mutual authentication, and firewall profiles automatically. When a computer is in a workgroup or deployed as an isolated node in a DMZ, Windows treats inbound connections with suspicion:

1. Firewall Drop Rules: The Public or Private network profile defaults to blocking incoming ICMPv4 and ICMPv6 echo requests. A silent ping response does not mean the system is offline; it simply means the Windows Defender Firewall rule File and Printer Sharing (Echo Request - ICMPv4-In) is disabled.
2. Missing Inbound Listeners: Neither Remote Desktop (TermService) nor Windows Remote Management (WinRM) listen on their respective TCP ports (3389 and 5985) by default on clean Windows client installations (Windows 10 and Windows 11).
3. Local Account Token Filter Restrictions: Windows Vista introduced User Account Control (UAC) token stripping for local administrative accounts over the network. When connecting across network boundaries with a non-domain local account, Windows strips the administrative token and assigns standard user privileges, denying access to administrative shares (ADMIN$, C$) and WMI unless a specific registry flag is set or the built-in local Administrator account is used.

Operational Constraints and Access Boundaries

This guide assumes strict operational reality:

• Zero Console / Physical Access: No keyboard, mouse, monitor, VM hypervisor console access, or hardware out-of-band management (IPMI, iLO, iDRAC) is available. All remediation must occur strictly across the network adapter.
• Known IP Address: The target machine is running at a known, reachable IPv4 address (e.g., 192.168.1.150).
• Known Local Administrator Credentials: You possess the username and password for an account in the target’s local Administrators group.
• Non-Domain Host (Workgroup): The machine is not joined to Active Directory; Kerberos cannot be used, and group policies cannot push administrative scripts.
• PsExec as the Bridgehead: Because SMB (TCP 445) is commonly accessible for remote service management even when ICMP and high-level remoting ports are blocked, Sysinternals PsExec serves as the bootstrap tool to gain the initial shell.

If your network routing permits traffic to the host subnet and SMB has not been blocked by an intermediate hardware firewall, the Windows Service Control Manager (SCM) on TCP 445 provides our backdoor to bootstrap everything else.

Why Ping Fails While Administration Is Still Possible

Network engineers often treat ping as an authoritative test for system health. On modern Windows installations, ICMP is decoupled from TCP socket listeners. Windows Defender Firewall maintains three distinct network profiles: Domain, Private, and Public.

When a computer is not domain-joined, its network interface typically defaults to Public unless an administrator explicitly marks the network as Private. On the Public profile:

• All unsolicited inbound ICMP echo packets are discarded without sending a rejection notice (stealth mode).
• Port 445 (SMB) may be allowed on local subnets if File and Printer Sharing was prompted, or it may remain open to local administrative endpoints depending on OEM imaging.
• Inbound connection attempts to TCP ports 3389 (RDP) and 5985 (WinRM) are blocked at the kernel network stack before any application socket can respond.

Before assuming a hardware fault or bad cabling, test the transport layer directly with PowerShell.

Prerequisites and Local Account Token Filter Policy

To follow this walkthrough, ensure you meet the following baseline requirements:

• Target Operating System: Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025.
• Credentials: A known local administrator account and password. Using the built-in account named Administrator bypasses Remote UAC restrictions. If using a secondary local admin account (e.g., localadmin), the remote host may require LocalAccountTokenFilterPolicy set to 1.
• Administrative Machine: Windows PowerShell 5.1 or PowerShell 7+ running as Administrator on your workstation.
• Sysinternals Suite: Download Sysinternals PsExec from Microsoft and extract PsExec.exe to a local folder (such as C:\Tools\Sysinternals).

If the target has an active local admin account other than the primary built-in Administrator, Windows drops administrative privileges during network authentication. You can pre-emptively disable this remote token filtering over PsExec by passing the -s flag, which forces execution under the target’s local NT AUTHORITY\SYSTEM context.

Stage 1: Verify SMB Port 445 Connectivity

Do not rely on ping.exe. Open an elevated PowerShell terminal on your management PC and run Test-NetConnection:

$targetIP = "192.168.1.150"

# Check raw ICMP response
Test-Connection -TargetName $targetIP -Count 2

# Check TCP port 445 (SMB transport)
Test-NetConnection -ComputerName $targetIP -Port 445

If the output displays:

TcpTestSucceeded : True

The target kernel is running, network routing is functioning, and Windows is actively listening on SMB. You have everything required to bootstrap remote management.

If TcpTestSucceeded returns False, verify that your management machine and the target are on the same VLAN or that intermediate routers and software firewalls are not actively filtering TCP 445.

Stage 2: Bootstrap Access with Sysinternals PsExec

Sysinternals PsExec operates by communicating with the target machine’s Service Control Manager over the IPC$ and ADMIN$ SMB shares. It temporarily deploys a lightweight Windows service called PSEXESVC.exe, starts it, executes your requested command under the specified security token, and redirects standard input/output back over named pipes to your console.

Open an elevated PowerShell prompt in your Sysinternals directory and invoke PsExec.exe:

$targetIP = "192.168.1.150"
$localAdmin = "adminuser"
$password   = "P@ssw0rd2026!"

# Connect and spawn an interactive remote PowerShell prompt
.\PsExec.exe \\$targetIP -u .\$localAdmin -p $password -h -s powershell.exe

Parameter Breakdown

• \\$targetIP: Specifies the remote IPv4 address.
• -u .\$localAdmin: The .\ prefix forces Windows to evaluate the credential against the target machine’s local Security Accounts Manager (SAM) database rather than attempting domain authentication.
• -p $password: Supplies the local administrator password.
• -h: Launches the remote process with the elevated administrative token if UAC is enabled.
• -s: Runs the command in the target machine’s NT AUTHORITY\SYSTEM context, completely circumventing Remote UAC token stripping.
• powershell.exe: The interactive process to execute on the remote host.

When successful, your console prompt changes to PS C:\Windows\system32>. You are now running PowerShell inside the target machine. Confirm your environment:

hostname
whoami
Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress

Keep this PsExec terminal open. You will execute Stages 3, 4, and 5 directly within this remote shell.

Stage 3: Enable Remote Desktop (RDP)

With remote command execution established, configure Remote Desktop Protocol (RDP) to enable full graphical access.

1. Enable RDP in the Registry

RDP is controlled by the fDenyTSConnections DWORD under the Terminal Server registry key. Setting it to 0 enables the service:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0

2. Configure Network Level Authentication (NLA)

Network Level Authentication requires connecting clients to authenticate before a full session is negotiated. On non-domain computers, NLA can occasionally cause credential handshake mismatches. For maximum initial accessibility, set UserAuthentication to 0 (or 1 if your corporate security policy strictly mandates NLA):

# 0 = NLA Optional/Disabled (easiest for initial non-domain recovery); 1 = NLA Required
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 0

3. Open Firewall Rules for Port 3389

Ensure Windows Defender Firewall allows incoming connections on port 3389 across all active network profiles:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Set-NetFirewallRule -Name "RemoteDesktop-UserMode-In-TCP" -Enabled True -Profile Any

4. Ensure the Terminal Service Is Running

Start the Remote Desktop service (TermService) and configure it to run automatically on system boot:

Set-Service -Name "TermService" -StartupType Automatic
Start-Service -Name "TermService"

Stage 4: Configure WinRM and PowerShell Remoting

Windows Remote Management (WinRM) enables programmatic command execution via Enter-PSSession, Invoke-Command, and modern management modules without the overhead of an interactive GUI desktop.

Run the following commands inside your remote PsExec console:

1. Configure WinRM Service and Firewall

The Enable-PSRemoting cmdlet automates the creation of HTTP listeners on port 5985, creates the necessary local firewall rules, and starts the service:

Enable-PSRemoting -Force -SkipNetworkProfileCheck

[!NOTE] The -SkipNetworkProfileCheck flag is mandatory on non-domain computers. Without it, Enable-PSRemoting fails if any network interface is categorized under the Public profile.

2. Enable Basic and Negotiate Authentication

Because Kerberos is unavailable without an Active Directory Domain Controller, the WinRM service on the target machine must accept local authentication over NTLM/Negotiate:

Set-Item -Path WSMan:\localhost\Service\Auth\Negotiate -Value $true
Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $true
Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $true

3. Verify the Listener

Confirm the listener is active on TCP port 5985:

Get-ChildItem WSMan:\localhost\Listener

You should see a listener with Transport = HTTP bound to port 5985 listening on IP: *.

Stage 5: Install and Start OpenSSH Server

Modern Windows 10, 11, and Windows Server distributions ship with a native Microsoft port of OpenSSH. Enabling SSH provides cross-platform terminal access, robust public key authentication, and resistance to standard Windows NTLM authentication quirks.

Execute the following in your remote shell:

1. Install OpenSSH Server Feature

Query and install the OpenSSH Server capability using DISM/PowerShell:

# Check if capability is present
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'

# Install the OpenSSH Server capability
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

2. Configure Service Startup and Start the Daemon

The OpenSSH server binary is registered as sshd:

Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

3. Open Inbound Port 22 in Firewall

Windows automatically registers an inbound rule during capability installation, but you should verify it explicitly:

if (-not (Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -DisplayName "OpenSSH SSH Server (sshd)" `
        -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 -Profile Any
} else {
    Set-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -Enabled True -Profile Any
}

4. Enable ICMP Echo Requests (Optional Ping Repair)

If you also want the machine to answer standard network ping diagnostics in the future, unblock ICMP echo requests:

netsh advfirewall firewall add rule name="Allow ICMPv4-In" protocol=icmpv4:8,any dir=in action=allow

At this point, all three remote management protocols are installed, listening, and allowed through the host firewall. You can now exit the PsExec session by typing exit.

Stage 6: Client Configuration for Workgroup Authentication

Before your management PC can connect to the target over WinRM, you must configure your local client. In a workgroup environment, Windows will not authenticate to an IP address over WinRM because it cannot mutually authenticate the host with Kerberos.

Run the following commands on your local management workstation in an elevated PowerShell session:

1. Add the Target IP to TrustedHosts

The TrustedHosts list informs your local WinRM client that it is safe to transmit credentials to the specified IP address without Kerberos verification:

$targetIP = "192.168.1.150"

# View current TrustedHosts
Get-Item WSMan:\localhost\Client\TrustedHosts

# Append the target IP (or use * in isolated lab environments)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $targetIP -Concatenate -Force

2. Allow Unencrypted Client Connections for Local Subnets

If you have not provisioned an HTTPS certificate on port 5986, permit unencrypted HTTP transport on your client:

Set-Item WSMan:\localhost\Client\AllowUnencrypted -Value $true

Stage 7: Verification and Troubleshooting

With both target and client configured, verify all three administrative protocols from your local management workstation.

Validating active listeners, firewall allowances, and interactive remoting across SSH, WinRM, and RDP.

1. Test Network Ports from Client

$targetIP = "192.168.1.150"

$ports = @(22, 3389, 5985)
foreach ($p in $ports) {
    [PSCustomObject]@{
        Port    = $p
        Open    = (Test-NetConnection -ComputerName $targetIP -Port $p -WarningAction SilentlyContinue).TcpTestSucceeded
    }
}

All three ports should report Open: True.

2. Connect via WinRM (PowerShell Remoting)

$cred = Get-Credential  # Enter username formatted as .\adminuser and password
Enter-PSSession -ComputerName "192.168.1.150" -Credential $cred

Once inside, test running remote background commands across sessions:

Invoke-Command -ComputerName "192.168.1.150" -Credential $cred -ScriptBlock {
    Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, TotalPhysicalMemory
}

3. Connect via OpenSSH

Open a terminal or PowerShell prompt:

ssh [email protected].150

Accept the host key fingerprint and supply your local administrator password. You will receive an authentic Windows command shell.

4. Connect via Remote Desktop (RDP)

Launch the standard Windows Remote Desktop Connection utility:

mstsc.exe /v:192.168.1.150

When prompted for credentials, click More choices -> Use a different account, and supply:

• Username: .\adminuser or 192.168.1.150\adminuser
• Password: your local administrator password

Troubleshooting Common Edge Cases

Summary

Recovering management access to an unconfigured, non-domain Windows computer does not require local keyboard access if SMB port 445 is reachable. By leveraging Sysinternals PsExec to establish an initial bridgehead under the local SYSTEM account, you can quickly configure Remote Desktop for graphical troubleshooting, WinRM for PowerShell scripting and automation, and OpenSSH for cross-platform remote administration.

Once these services are secured and verified, you can perform full system maintenance, automate patch deployments, or complete a domain join workflow entirely across the network.

For related guides on remoting architecture and port validation, see PowerShell Remoting with WinRM and SSH and Test if a Network Port is Open.