Is there a way to specify which computers can be allowed a full authentication process to a corporation that deploys/deployed a vpn 3000 concentrator?
7 laptops. Each one of the seven is given to a different employee. They each have their own login/password, and utilize the PCF file that none of them really know about, but nothing will stop them from finding it if they are curious.
To prevent the transference of PCF file, and a login/password from one employee to someone on the outside, from being utilized on their own desktop/laptop, can the 3000 concentrator employ any type of mac-filter based queries so unauthorized computers can't fully authenticate on to the network.
I posted the same question yesterday and haven't found an answer yet. One way to do it is to implement Cisco NAC (Network Admission Control) which I'm looking into. I haven't found any other way to control access based on either computer name or Mac address. Let me know if you find anything.
Well, implementing NAC takes alot of modifications to various devices to get the nac frame-work in place. I was looking for any type of out of the box configuration changes that could allow target boxes yes or no connection.
Im starting to think , seperate device or device(s) would be necessary. A low cost solution to addressing this concern.
My issue here is that is there any way for the VPN3000 to see the machine's name when it connects, or is there an easy way of doing this through Active Directory?
Mac filtering works on a different layer in OSI then the layer the concentrator works at.
I did a little further investigations, and had some help from others that mentioned this type of functionality we desire, all though it is a good security concious thoguht/need/desire, not even the asa's do this.
Can anyone from cisco address the original question? The cheapest method to implement. So rogue pc's can't utilize an imported pcf, and a users creds, because corporate maintains a list of acceptable macs.
We're trying to find the same answer: Basically is there any way to keep a rogue PC (ie: home PC) from connecting via VPN if someone has downloaded the VPN client software from the Internet and installed it?
This has to be a major issue for a lot of companies correct?
I'll try to get in contact with a few people.
Some have said, if we have this fear about an employee, then simply revoke their access. Well the approach/thought that was given to me, was to make it happen. Technologically, it is possible, but how?
Im rather curious as to why cisco doesn't have this as a feature on asa's, or concentrator's, or pix's when it comes to software client vpn connections that authenticate with a username and password.
Can not one representative at cisco help out here? My next avenue to find out, will be to email a regional account rep that maybe could point me in the right direction, but I don't want to hassle him at the present.
First off let me say that a user cannot just download a VPN client from Cisco. You must have a valid Cisco account. Next the user must have the proper credentials applied to the VPN client , i.e. Group authentication including username and password, and then if they somehow compromise this information they must be authenticated via Radius, AD, or however your concentrator is configured. We have 8 of these boxes, (4) 3005's and (4) 3015's and I find them very user friendly to configure and administrate.
I hope this helps ......
the jist of our issue is, we want to limit the hosts to corporate laptops only.
So if a malicious employee gives their PCF file(if they know about it, and where it resides), and their concentrator username/password, it will be null, because any other computer except for the corporate laptop will not be allowed onto the network. If mac adresses can be integrated into the authentication process through whatever method cisco could implement this, this would make security "that much better".
Well sorry to tell you, but the "regular" users cannot, but the more tech savvy ones have been able to find the VPN client software out on the Internet. So this is a valid problem and we're trying to find a way to fix it. Cisco's answer to this is NAC, but there has to be an easier and cheaper solution to this.