The topic of 802.1x and Windows RDP/RDS came up in a discussion I was having with someone about the pros and cons of the Cisco AnyConnect with the Network Access Manager (NAM) module. We were bouncing ideas back and forth when I remembered something I ran into a few years ago.
Way, way back (6 years ago), I was deploying Cisco ISE at my previous network admin job. I was testing out various scenarios in order to verify authentications and dACLs worked correctly. One of the test involved RDP. After configuring the dACL to allow RDP responses (permit tcp any eq 3389 any) for authorized computers or users, I found that I could successfully RDP into a machine no matter if someone was logged in or if it was sitting at the login prompt. I also noticed that the RDP user authentication was not showing up in the ISE RADIUS Live Logs.
I thought this was strange because I had network access as expected. Further testing revealed that I also had more network access that I should when logging in as a user that should have been restricted. When I checked the authentication session on the port, it was showing the computer (or the currently logged in user) was authenticated and had the dACL assigned for that connection. I thought for sure it was just something wrong in my config.
It turns out that this is by design. Or lack of design. Windows will not trigger an 802.1x authentication for an RDP session even though the authentication mode (wired or wireless) is configured for “User or computer authentication”. It’s even documented for Windows 7:
802.1x user authentication fails when a RDS connection comes in
“When 802.1x authentication mode is configured to user authentication, the supplicant fails to query the user token in the remote desktop session.”
So you have some choices to make.
- Disable RDP/RDS on the Windows workstations.
- Configure computer authorization with a restricted dACL/VLAN/SGT (limited to AD, AV server, WSUS, etc.).
- Deploy Cisco AnyConnect with the NAM module.
The NAM module takes over network configuration (including authentications) from Windows. This includes RDP session authentications. I tested this out and found that every single RDP login was picked up and authenticated/authorized properly. Yes, there are some caveats to using AC and NAM versus the Windows supplicant (ie Admin can’t force user logoff) but securing the network sometimes requires a little sacrifice. See the section ‘Single Sign On “Single User” Enforcement’ in the following link for more information:
I would not suggest the registry hack to allow multiple user logins unless absolutely required. Allowing multiple logins will only authenticate/authorize the first user. If a second user logs in, they will receive the same access as the first user because the first user’s credentials are used for the authentication in the background.
Where I worked, management didn’t want to deploy AC and NAM to all of the workstations due to budget restraints. So we ended up going with a restricted dACL for machine authentications. This dACL was still more restrictive than even the most restricted user account so the RDP wasn’t a concern. Network admins that required RDP had jump boxes they could utilize in the data center.