RDP access with dACL

[pdigiacomo]

I have a customer who wants to allow their users to RDP to their workstations over VPN.  If the user is logged in to the office workstation and fully authenticatied to ISE there isn't a problem.  However if they need to reboot the workstation they can no longer connect to it remotely, until a user logs in to it, which is difficult remotely.

We have an Authorization rule/profile in place that says if the computer is a domain member apply a dACL to it.

Here is the dACL we are using and I can verify in the switch that it has been applied.

permit tcp any any eq 3389

permit ip any host 172.19.48.86

permit ip any host 172.19.48.87

permit ip any host 172.19.48.88

permit ip any host 192.168.106.8

permit ip any host 192.168.106.9

permit ip any host 192.168.106.11

permit udp any eq bootpc any eq bootps

permit udp any any eq domain

permit icmp any any

permit tcp any any eq 88

permit udp any any eq 88

permit udp any any eq 123

permit tcp any any eq 135

permit udp any any eq 137

permit tcp any any eq 139

permit tcp any any eq 389

permit udp any any eq 389

permit tcp any any eq 445

permit tcp any any eq 636

permit udp any any eq 636

permit tcp any any eq 1025

permit tcp any any eq 1026

If we change this to a "permit all traffic" then it works fine.  It seems to me that we need to allow RDP inbound to the workstatation, but this is the only access-list in play right now.

I can provide any other information that may be needed.

Thanks,

-Paul

[Tarik Admani]

Paul,

Are you allowing machine authentication from the supplicant? When performing remote desktop the supplicant only sends the machine credentials and not the user credentials which I think is your issue. Let me know if that fixes your issue because one of my previous customer is able to reboot their machines through vpn without any issues.

Tarik Admani
*Please rate helpful posts*

[pdigiacomo]

I agree that is the issue, but what do i need to change?

We are sending the Machine credentials first when the computer boots up prior to a user loggin on.  we have an Authorization rule that says if you are a member of domain computers then give you the dACL posted previously.  Then after the user logs in they are hitting a rule that says if you are a member of domain users then permit all access.  As you can tell this is a PoC for ISE so things are pretty basic.

The problem we are seeing is that the users can reboot the remote workstations but RDP is blocked after the reboot.  the user has not logged in to give the session the permit all access permission.  so we need to make sure that they can get to the machine which they cannot.

I am not sure how to send the user credentials prior to somone actually logging in.  we are using AnyConnect and it is configured to pass both user and machine credentials.

[Tarik Admani]

It seems as if that is your issue, the destination for the device on the port (in our case the source port of the vpn traffic) is set to 3389. Please try adding the acl that allows the traffic iniitated from the vpn clients.

permit tcp any eq 3389 any

Tarik Admani
*Please rate helpful posts*

[Alex Martin]

Tarik, I know that this post is over 2 years old, however while implementing Cisco ISE NAC in our environment recently I too was puzzled at the ACL required to get this to work.  Specifically I was using Dameware (TCP 6129) but the same principle applied to me as RDP.  Thank you very much for the information, just wish I would have been able to figure it out on my own.

[bberry]

I am running ISE 1.3 and seem to be having the same issue. One cannot RDP into a system that has been authenticated on ISE. Machine authentication validating against domain computer is used when the system first starts and then user authentication kicks in. If I try to RDP into system RDP shuts down and even takes any other open RDP session with it. RDP then does not eve try to connect or receive messages about resource not in the domain.

I have not yet tried to RDP into a system that does not have a user logged in. I will also be trying Dameware to see if that third party remote access program acts the same since our IT group uses both to access remote systems.