Obtain an authorized RDP interactive session

Needs: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Check the installed binary name

# Check the installed binary name
command -v xfreerdp3 || command -v xfreerdp

# Password
xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /p:'PASSWORD' /cert:ignore /dynamic-resolution +clipboard

# NT hash
xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /pth:NT_HASH /cert:ignore /dynamic-resolution

Native client

FreeRDP's /pth uses Restricted Admin mode. The target must support/permit that mode and the identity must be an administrator; ordinary Remote Desktop Users membership is not sufficient for Restricted Admin. Password-based RDP instead needs the Remote Desktop service, NLA compatibility and the effective “Allow log on through Remote Desktop Services” right without a deny override.

REM Native client
mstsc.exe /v:TARGET_HOST
mstsc.exe /restrictedAdmin /v:TARGET_HOST

Ordinary RDP can place reusable user credentials in the destination's LSASS. Restricted Admin avoids sending those reusable credentials but prevents ordinary onward access as that user; treat the resulting session's network identity separately.

Purpose: use a validated identity with Remote Desktop logon rights to establish a Windows desktop and verify the resulting source position.

Prompt for the password

# Baseline: prompt for the password
xfreerdp3 /v:TARGET /u:USER /dynamic-resolution /cert:ignore

# Variant — domain identity
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

# Variant — authentication only
xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

# Variant — explicit password
xfreerdp3 /v:TARGET /u:USER '/p:PASSWORD' /dynamic-resolution /cert:ignore

Decisive output: a usable desktop establishes a remote session. Open PowerShell or Command Prompt and verify whoami, hostname and ipconfig before treating commands as target-origin execution.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Failure cues: a certificate warning is not a credential result. NLA/security negotiation, account context, authentication, Remote Desktop logon rights and an already occupied/restricted session can fail separately. /cert:ignore is appropriate only for the controlled lab context because it removes certificate identity validation.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Verify → Verify destination, user/token and permitted desktop actions; keep credentials out of reusable screenshots/notes.

If it fails → A valid password can still lack logon rights. NLA, TLS, domain qualification and Restricted Admin policy are separate conditions. More detail ↓

If → then

A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context
Needs: A functioning command channel and the actual effective token/process context
Readable application configuration, unattended setup, PowerShell trails or Credential Manager entries → Recover Windows application, history and stored-credential artifacts
Needs: Artifact read permission and exact protecting identity/context for saved or DPAPI material
A password, actual NT hash, AES/NT long-term key or ticket is available → Select password, NT hash, key-to-ticket or ticket authentication
Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Obtain an authorized RDP interactive session

USE WHEN: RDP is reachable and the identity may have remote-interactive logon rights
STARTING ACCESS: Identified authentication material, destination service reachability and a candidate authorized identity
RESULT: A verified remote-interactive desktop/logon context

Recognize the clue

Check the destination RDP endpoint and use actual group/logon-policy evidence for the candidate identity; determine whether password or Restricted Admin is intended.

Test-NetConnection TARGET -Port 3389

SYNTHETIC EXAMPLE OUTPUT

3389: reachable
Candidate identity: DOMAIN\USER
Remote-interactive logon right: not yet confirmed

Means: RDP transport does not grant desktop access; Restricted Admin/hash use has additional requirements.

Confirm: Check NLA/TLS, identity qualification, logon authorization and the chosen authentication mode.

After validation: The authorized interactive logon opens under the verified token: choose RDP.
Ruled out in this context: The account lacks the required logon right or the hash route lacks Restricted Admin support: reject that variant.
Still inconclusive: A generic connection error requires separating client/protocol/policy before judging the credential.

Troubleshooting: A valid password can still lack logon rights. NLA, TLS, domain qualification and Restricted Admin policy are separate conditions.

Check the installed binary name:

Password:

Older packages may expose the same syntax through xfreerdp.

NT hash:

FreeRDP's /pth uses Restricted Admin mode. The target must support/permit that mode and the identity must be an administrator; ordinary Remote Desktop Users membership is not sufficient for Restricted Admin. Password-based RDP instead needs the Remote Desktop service, NLA compatibility and the effective “Allow log on through Remote Desktop Services” right without a deny override.

Native client:

Ordinary RDP can place reusable user credentials in the destination's LSASS. Restricted Admin avoids sending those reusable credentials but prevents ordinary onward access as that user; treat the resulting session's network identity separately.

Purpose: use a validated identity with Remote Desktop logon rights to establish a Windows desktop and verify the resulting source position.

Baseline: prompt for the password

Some Kali releases expose xfreerdp instead of xfreerdp3; check command -v xfreerdp3 xfreerdp and the selected binary's /help output.

Decisive output: a usable desktop establishes a remote session. Open PowerShell or Command Prompt and verify whoami, hostname and ipconfig before treating commands as target-origin execution.

Variant — domain identity

Local and domain accounts with the same username are different identities. Make the intended context explicit when results differ.

Variant — authentication only

This tests authentication without opening the UI. Success does not guarantee that all session policies or desktop initialization will permit a full session.

Variant — explicit password

Prefer prompting because command-line passwords can enter shell history and process listings.

Failure cues: a certificate warning is not a credential result. NLA/security negotiation, account context, authentication, Remote Desktop logon rights and an already occupied/restricted session can fail separately. /cert:ignore is appropriate only for the controlled lab context because it removes certificate identity validation.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Why it works

RDP is an access method, not automatic local elevation. Restricted Admin/hash use and ordinary password logon have different requirements and network credential behavior.

Worked example · hypothetical

Observation: a domain user is in the destination's RDP access group. Test: perform a correctly qualified login. Illustrative output: a desktop opens under a non-admin token. Interpretation: establish host/token state and inspect the new access context.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗