How to remote control a computer connected through a VPN client connection

I've run into numerous cases where a user is successfully connected via a Cisco VPN client and is having application problems. The helpdesk would like to get into the user's computer to diagnose the problem. Since they have a valid VPN tunnel, you'd think they'd just be able to remote desktop into the user's computer and take a look. Unfortunately, as soon as you remote desktop into their computer, you get a screen saying you'll have to kick them off. When you kick them off, you're also killing the VPN connection.

In order to get around that limitation, I know of two options. The first option is to have the user install VNC Server. This would allow the helpdesk to use a VNC client to remote into their computer. This option requires that the user has admin right on the computer in order to install VNC Server.

The second option is preferable because it does not require admin rights and is already built into Microsoft WinXP. The method involves using "Remote Assistance". The process is to

1. Have a user create a file
2. Email the file to the helpdesk
3. Have the help desk download the file from the email
   
4. Have the help desk double click on the file to open a connection to the users computer.

The remote assistance program is located at Start->All Programs->Remote Assistance, as seen below


This brings up the Remote Assistance wizard. The user should click on "Invite someone to help you"

In the next screen click Continue

The next screen gives the option of defining a password that the helpdesk has to input before being allowed remote access

Next the user saves the file

Finally, the user emails the file to the helpdesk. The helpdesk downloads the email attachment and double clicks on the file to launch it. After the file is launched, it opens a remote desktop session to the user's computer.

Adding static routes for Cisco NAC Manager and Profiler

The NAC Manager and Profiler don't have a documented way of adding a static route, in addition to the default gateway. In most cases this is fine because all traffic follows the default gateway. When doing a pilot or setting up a lab environment there's a greater possibility of needing a static route to direct some traffic another direction than the default gateway.

Since the NAC products are built on Fedora Core, you can use the standard way of adding default routes within Fedora. Modifying the routing table requires root access, so make sure you are logged in as root or type "su -" to elevate to root privileges. Assuming eth0 is used for the traffic, you would create a file called "route-eth0" in the "/etc/sysconfig/network-scripts" directory. Here's an example of the contents of the file assuming you want to route the 192.168.0.0/16 subnet to 10.1.1.110

GATEWAY0=10.1.1.110
NETMASK0=255.255.0.0
ADDRESS0=192.168.0.0

As you probably figured out, you can add additional entries for GATEWAY1, NETMASK1, and ADDRESS1 to add additional static routes.

Once you've created this file, you can apply it in one of two ways. The safest way is to reboot the device with "shutdown -r now". The second way is to just restart the routing process with "service network restart"

Ports required for AD SSO

When configuring NAC for AD SSO, the last place you'd think to look would be the documentation, right? We'll, this would be one time that it makes a lot of sense to RTFM. On page 9-7 of the PDF version of the 4.1.3 Clean Access Server Installation and Configuration Guide they have all the ports required for AD SSO.

Here are the TCP ports required, in the unauthenticated role, for AD SSO to work: 88, 135, 389, 445, 1025, and 1026.

The one thing that isn't listed in the documentation is that ICMP is also required. Part of the login process includes trying to ping the AD server. If this fails, then AD login doesn't work

CSA Basic Building Blocks

CSA is a very powerful tool to enforce the security policy for a company. It has a very structured approach to create a security policy that is enforced through the CSA Agents. In order to optimize its use, it is important to understand the fundamental building blocks involved with turning the written security policy into an actionable enforcement tool.

I view the building blocks in two separate parts. The first part is creating the actions that will be used to enforce the security policy. The second part is defining the different types of computers, such as desktops and servers, that have the same type of characteristics. Once these two parts are created, they are linked together so that the correct actions are linked to the appropriate types of computers.

The first part involves creating three objects that build upon each other: rules, rule modules, and policies. The first object is called a rule. This is the basic if/then action that determines enforcement. An example would be, "if an application tries to open a cmd.exe shell, deny and log the access". In addition to denying access, there are a number of different actions that can be taken. The diagram below shows the different actions available. The diagram is important, because, in many places within CSA, the icons associated with the actions are shown without the actual names.




The second object is called a rule module. A rule module combines multiple rules together that all pertain to the same operating system and provide the same type of functionality. Rule modules are then combined into a policy. The policy should contain all aspects that cover the security policy for a particular group of computers (ie desktops or servers). Unlike the rule modules, the policies are not restricted to pertaining to a single operating system. That completes the first part.

The second part is defining the types of computers. CSA calls these groups. These groups break up the computers based on operating system and other logical criteria such as function and business group. Additionally, CSA parameters, such as polling interval, alerts, and events, can be defined for the group instead of for individual hosts.

The last step is to tie the policies created to the groups. This creates an enforceable security policy for the different types of computers in the network.