fix access denied problem on win11 25H2

Kumar, Manoj 0 Reputation points

"I am attempting to remotely access my Windows 11 (25H2) PC using an administrator account. However, despite having administrator privileges, I receive an 'Access Denied' error. Remote Desktop (RDP) only works if I first log on to the system locally — without an active local session, the remote connection is denied."

0 comments No comments

Sign in to comment

2 answers

  1. Jason Nguyen Tran 20,115 Reputation points Independent Advisor

    Hi Kumar, Manoj,

    I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

    0 comments No comments

    Sign in to comment
  2. Jason Nguyen Tran 20,115 Reputation points Independent Advisor

    Hi Kumar, Manoj,

    The behavior you’re describing usually occurs when the administrator account being used is not explicitly granted the “Allow log on through Remote Desktop Services” right in local security policy. Even though the account has administrator privileges, Windows enforces RDP permissions separately. To fix this, open Local Security Policy (secpol.msc), navigate to Local Policies > User Rights Assignment, and confirm that your account is listed under “Allow log on through Remote Desktop Services.”

    Another common cause is that the Remote Desktop Users group does not include the intended account. Adding your administrator account to this group ensures consistent access. Also, check that the system is not enforcing restrictions through Group Policy that require an active local session before RDP connections are allowed.

    It’s also worth verifying that Network Level Authentication (NLA) is configured correctly. If NLA is enabled but the account cannot be validated remotely, the connection may fail with “Access Denied.” Disabling NLA temporarily can help isolate whether this is the root cause.

    Finally, confirm that the firewall rules for Remote Desktop are enabled and that no third-party security software is blocking inbound RDP requests.

    I hope this explanation helps you resolve the issue and restore reliable remote access. If this answer is helpful, please don’t forget to hit “Accept Answer”.

    Jason.

    1. Kumar, Manoj 0 Reputation points

      Thanks Jason, but No, i tried all these already, even in Task manager actual users logged are showing with DWM-1, DWM-2,DWM-3 accounts not actual users which i have created , this system are in workgroup. In event logs as well no denied logs , even no user account name except NT services as shown in screenshot

      👁 User's image

    2. Jason Nguyen Tran 20,115 Reputation points Independent Advisor

      The important point here is that those DWM accounts are normal system processes (Desktop Window Manager) and not interactive user sessions. They don’t represent your real logons, so they aren’t the source of the access issue. Since your system is in a workgroup, Remote Desktop permissions are enforced locally, and administrator rights alone don’t automatically grant RDP access.

      To resolve this, make sure your admin account is explicitly added to the Remote Desktop Users group. You should also check Local Security Policy (secpol.msc) under User Rights Assignment to confirm that your account is listed under “Allow log on through Remote Desktop Services.” Without this explicit entry, RDP connections can be denied even for administrators.

      It’s also worth reviewing Network Level Authentication (NLA) settings. If NLA is enabled but the account cannot be validated remotely, you may see “Access Denied.” Disabling NLA temporarily can help confirm if this is the cause. Additionally, ensure that firewall rules for Remote Desktop are enabled for the correct network profile (Private or Public, since you’re in a workgroup).

      In short, the DWM accounts you’re seeing are expected system behavior, and the real fix is to grant your admin account explicit RDP rights and verify NLA/firewall settings. That should stabilize remote access without requiring a local session first.


      I hope this clears up the confusion and helps you move forward. If this answer is helpful, please don’t forget to hit “Accept Answer”.


    Sign in to comment
Sign in to answer

Your answer