# Enable winrm on windows server ### Fix: Enable WinRM on the Windows Server You need to run these commands **on the Windows Server itself** (`192.168.10.5`), in **PowerShell as Administrator**: #### Quick path — enable HTTP listener on 5985
powershell
```powershell # One-shot: starts the WinRM service, sets it to auto-start, # creates the HTTP listener on 5985, and adds the firewall rule. Enable-PSRemoting -Force ``` If the server is on a "Public" network profile (common on standalone test VMs), that command will refuse. Use this instead:
powershell
```powershell Enable-PSRemoting -Force -SkipNetworkProfileCheck ``` #### Verify it's listening After running the command, confirm:
powershell
```powershell # Should show a Transport = HTTP listener on port 5985 winrm enumerate winrm/config/Listener # Confirm the service is running Get-Service WinRM # Confirm the port is bound netstat -ano | findstr :5985 ``` The `netstat` line should show something like:
``` TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 1234 ``` #### Verify the firewall rule
powershell
```powershell Get-NetFirewallRule -DisplayName "*WinRM*" | Select-Object DisplayName, Enabled, Profile, Direction, Action | Format-Table -AutoSize ``` You want `Enabled = True` for the "Windows Remote Management (HTTP-In)" rule, and the `Profile` should cover the network you're connecting from (Domain, Private, or Public). ### Then test from your Linux box Once the server is configured, just retry:
bash
```bash python winrm_ad_enum_http.py --host 192.168.10.5 --user 'DOMAIN\admin' ``` ### Why "refused" specifically (vs. "timed out") The difference matters for diagnosis:
- **"Connection refused"** (what you got) → The TCP stack on the server responded with a RST packet. The host is reachable on the network, but nothing is listening on that port. Almost always means the service isn't running or isn't bound. - **"Connection timed out"** → No response at all. Usually means a firewall is silently dropping packets, or the host is unreachable.
So good news: your network path to `192.168.10.5` is fine. You only need to turn WinRM on. ### Optional: HTTPS at the same time While you're on the server, you may as well enable HTTPS (5986) too so the `winrm_ad_enum.py` script also works. Here's the minimal sequence — self-signed cert is fine for a lab:
powershell
```powershell # Get the server's FQDN (or just use the IP / hostname clients will use) $fqdn = [System.Net.Dns]::GetHostByName($env:COMPUTERNAME).HostName # Self-signed cert $cert = New-SelfSignedCertificate -DnsName $fqdn ` -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(5) # HTTPS listener New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * ` -CertificateThumbPrint $cert.Thumbprint -HostName $fqdn -Force # Firewall rule for 5986 New-NetFirewallRule -DisplayName "WinRM HTTPS-In (TCP 5986)" ` -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Allow ``` Run the verification again — `winrm enumerate winrm/config/Listener` should now show **both** an HTTP and an HTTPS listener. Once that's done, give me a shout if the next run still has issues — but my bet is this fixes it cleanly.
## You said: why the winrm only works with AllowUnencrypted to True for some winrm calls why the winrm only works with AllowUnencrypted to True for some winrm calls
4:53 PM
## Claude responded: Good observation — this catches a lot of people out. Good observation — this catches a lot of people out. The short version: **WinRM doesn't decide encryption per-call based on what you're doing, it decides based on which auth transport you negotiated**. Some transports provide their own encryption layer, others don't. `AllowUnencrypted` is what the server checks when a transport can't encrypt. ### The actual rule When a WinRM request arrives over HTTP (port 5985), the server asks one question: **"Is this SOAP body wrapped in an encryption layer?"**
- **Yes** → process the request, regardless of `AllowUnencrypted`. - **No** → check `AllowUnencrypted`. If `false`, reject with HTTP 411 / "The WinRM client cannot process the request. Unencrypted traffic is currently disabled". If `true`, process it.
The transport you authenticate with determines the answer to that question. ### Transport-by-transport breakdown
TransportProvides encryption?Needs `AllowUnencrypted=true`?
**NTLM**Yes — NTLMv2 with session security (sealing)No
**Kerberos**Yes — GSS-API confidentialityNo
**CredSSP**Yes — wraps in TLS even over HTTPNo
**Negotiate**Yes (negotiates to NTLM or Kerberos)No
**Basic****No** — credentials base64, body cleartext**Yes**
**Certificate**No on its own over HTTP**Yes**
So if some of your calls work and others don't, the most likely cause is that the failing calls are using a transport that can't encrypt — Basic or certificate auth — while the working ones are using NTLM/Kerberos. ### Why this design exists WinRM is essentially SOAP-over-HTTP. Microsoft's security model says: **the payload must be confidential, but it doesn't care how you achieve that**. There are three valid ways:
1. **Transport-level encryption** — use HTTPS (port 5986). The TLS tunnel encrypts everything, including the credentials. Any auth method is fine. 2. **Message-level encryption** — use HTTP (port 5985), but with NTLM/Kerberos/CredSSP, which encrypt the SOAP body inside the HTTP request. The HTTP envelope is plain but the contents aren't. 3. **No encryption** — only allowed if the admin explicitly opts in via `AllowUnencrypted=true`. This is for Basic auth, certificate auth, or scenarios where the admin has decided the network itself is trusted (IPsec, isolated VLAN, loopback only, etc.).
The setting exists as a **safety net** so that misconfiguring the client doesn't silently leak credentials in cleartext. If you forget to enable NTLM and accidentally fall back to Basic, the server refuses rather than sending your password in plaintext. ### Common scenarios where you'd see "some work, some don't" **Scenario A: Mixed clients**
- Your Python script using `pywinrm` with default `transport=ntlm` → works. - A `curl` test or some legacy script using Basic auth → fails until `AllowUnencrypted=true`. - Diagnosis: check which transport each tool uses.
**Scenario B: Same client, different auth**
- `python winrm_ad_enum_http.py --transport ntlm` → works. - `python winrm_ad_enum_http.py --transport basic` → fails with HTTP 411. - Diagnosis: Basic has no encryption, so it falls afoul of the default `AllowUnencrypted=false`.
**Scenario C: Kerberos vs NTLM**
- NTLM works fine. - Kerberos works *if* SPNs are correct and the client has a ticket, but the failure mode (no encryption layer because the auth handshake itself failed) can look like an encryption problem rather than an auth problem.
**Scenario D: PowerShell client without `-Authentication`**
- `Invoke-Command -ComputerName ...` defaults to Kerberos → encrypted → works. - `Invoke-Command -Authentication Basic -Credential ...` → not encrypted → blocked unless `AllowUnencrypted=true`.
### How to check what's actually happening **On the server**, see what the current policy is:
powershell
```powershell Get-Item WSMan:\localhost\Service\AllowUnencrypted Get-ChildItem WSMan:\localhost\Service\Auth ``` The `Auth` listing shows which auth methods are enabled — Basic, Kerberos, Negotiate, Certificate, CredSSP. If Basic is enabled but `AllowUnencrypted=false`, you can authenticate with Basic only over HTTPS. **On the wire**, sniff a working vs failing request with Wireshark on port 5985:
- A working NTLM request: you'll see the SOAP envelope as binary garbage after the `Authorization: Negotiate ...` header — that's the encrypted payload. - A failing Basic request: you'll see the SOAP envelope as readable XML, which is exactly why the server refuses it when `AllowUnencrypted=false`.
### The right fix Don't reach for `AllowUnencrypted=true` just to make things work. Instead, figure out *why* the failing call isn't using an encrypting transport, and fix that:
- If the client is using Basic, switch to NTLM (`--transport ntlm` in the script). - If you can't switch (some scripts, some appliances genuinely require Basic) → enable the HTTPS listener on 5986 and point those clients at HTTPS instead. They can keep using Basic; TLS handles the encryption. - `AllowUnencrypted=true` should be a last resort, for closed labs or networks you fully trust.
### TL;DR `AllowUnencrypted` isn't really about what command you're running — it's about whether the **auth transport** carrying that command provides encryption. NTLM/Kerberos/CredSSP do, so they bypass the check. Basic and certificate auth don't, so they trip it. "Some calls work, others don't" is almost always "some calls use NTLM, others use Basic."