We are in the process of testing an "Always On" VPN solution for our remote users using the Anyconnect 3.x client and the SBL module. We've opted for machine based authentication that uses certificates from our PKI. The VPN head end is a pair of ASA 5520s in Active/Standby mode. Once the machine authenticates, the user will be required to authenticate to the laptop using cached domain credentials. Laptops will be running Windows 7 professional.
So far, we have a couple of concerns:
1. We would like to streamline the process of booting the laptop to the VPN connection by bypassing the "Switch User" button and going directly to the "network logon" options. Or, when the laptop is powered on - it goes directly to the SBL process and automatically creates the VPN with no user interaction (using the machine certificate).
2. We are exploring the idea of using a smart card or RSA type token for authenticating the user to the machine/domain rather than using AD credentials.
3. Many of our remote users will be at Hotels that require authentication via a captive portal, how does this work with the SBL?
The main purpose of this thread is to gather opinions and caveats from other engineers that have deployed an Always On solution. We are hoping to deploy this in the next couple of months and avoid as many 'gotchas' as possible. We would also like to hear what has worked best or not worked best for other organizations.
Wow! This sounds exactly how I have mine deployed!
I'll answer you questions in order....
1. We're using the SBL option with network logon and it works great... WITH A WIRED CONNECTION!!! Due to Windows order of operations, wireless cards are like the last thing to come up. Not a problem as Always On/TND takes care of this. The downside is password expiration notifications. We have to run .vbs scripts (via the ASA) after authentication to check password age and then send the pop-up to them notifing them of the days to expire. This is happens with all of our wireless connections... and wired connections behind a captive portal. (see answer 3)
When using SBL on a wired connection, they aren't going to be using cached credentials. They'll be logging directly into the Domain. If you're pushing a bunch of GPO's, it could take a little while for login... 20 sec or so.
Another note... I've found that the installation of SBL adds another 30-45 seconds of boot time. I don't mind it but a lot of other people might. This just falls under the user training category.
2. We just stuck with AD auth. RSA tokens would be a great add.... BUT.... for me it was to get rid of them. I know... don't ask. They wanted a "single sign on" solution and machine certs we're the only way I could do that.
3. It doesn't! SBL will fail, the user will have to manually close the SBL box, and then authenticate once logged in with cached credentials.
Caveats I've found....
1. TND Configuration - Don't try to use DNS servers for TND configuration. What ever list of DNS servers you have configured, the client must match it EXACTLY. If you configured 188.8.131.52 and 184.108.40.206 as your DNS server list and your client only has 220.127.116.11 assigned via DHCP, it's not trusted. It must be an exact match!!
Go with the DNS suffix route. If you go that route and you have multiple DHCP servers all make sure that your DNS suffics is an exact match! If you have Acme.com configured in your TND config and your DHCP server is serving up acme.com (lower case), it's not trusted.
2. Client installations - AARRRRGGGGGG!!! What a pain!! Most of our users only have Domain User rights and guess what? You need to be an Administrator to read the Machine Certificate Store!! My AD guys here have been able to work some magic with our deployment and have been able to get our SCCM to deploy it perfectly now. Something with the Administrator account running the Cisco AnyConnect service. We still have a pain with manual installations though.
Other than that... I'm loving it! Anyone else care to chime in?
Hi Robert - thanks for your reply! Do your users find the "Switch User" process tedious? Or was it just a matter of training? We are looking for a way to bypass this and have the computer boot to the Network Logon screen... but so far, we haven't found a way to do it. We haven't tested expiring passwords, captive portals, or even booting to a wireless connection as of yet - but I'll get on that and see how it goes. TND does work great so far with the wired connection, very impressive.
We've been using machine certificates for our Cisco wireless solution for about 2 years now, and it's worked great. I haven't noticed where users without admin rights to the local machine have had any problem. When we tested the Always on VPN using the same machine certificate, we didn't notice any issues with this since the certificate store is accessed before the user ever logs on to the laptop. I'm curious why you guys have run into that issue...
We have struggled with how we are going to deploy this. Since our current VPN solution authenticates with domain credentials against a Cisco ACS 5.2 server (RADIUS), we won't be able to deploy the AO VPN remotely by having them just connect to the new tunnel. We've toyed with pushing the configuration file out remotely , but haven't tested it.
We're just starting to rollout Win7 so a majority (98% still) of our machines are still XP. We don't run into the switch user process there and for the Win7 people, I haven't heard a peep about it.
As for your deployment, I'd try with the remote push of the config from the ASA. It should be pretty seamless as long as it's still the same ASA endpoint and your groups are defined correctly.
I guess I'm confused on how to push the initial config with the ASA. The VPN authentication will be switching from user/password via RADIUS to a certificate trust relationship between the client and the ASA. In order for them to get the config, they will need to authenticate to the tunnel at least once -- they won't be able to do that with a username and password.
Taking up an old thread.
Im trying to do a Always-On with machin certificate on Windows 7
Anyone know how to get users to access the machin certificate store?
Setting AnyConnect service to admin right's dont seems to work for me.
You shouldn't have to do that. The user does not have to have any special access for the machine certificate to be used. Are you using the profile editor in the ASDM or are you using the standalone editor? In either case, using the profile editor for the AnyConnect package make sure you have the following checked:
Certificate Store should be set to "Machine"
Certificate Store Override
Auto Connect On Start
Automatic VPN Policy (Trusted Network=Disconnect, Untrusted Network=Connect) Always On
Make sure you leave "Disable Automatic Certificate Selection" unchecked
In the Connection Profile, make sure you have your Authentication Method set to certificate
In Group Policy, under AnycConnect Client, make sure you have "Always On VPN" set to Use AnyConnect Profile Setting.
Try those things and see if that fixes it, if it doesn't we can look a little deeper. Also (this may seem juvenile) make sure that the client actually has the machine certificate and that you aren't looking at a user based certificate.
I tried both Machine and Any for certificate store, and I used certificate store Override.
Always-On and TRN worked with local admin rights, but when logging in as domain user I get
a certificate error. When our AD guy changed permissions to read/'all users' on one certificate in he folder .../crypto/RSA/
MachineKeys everything works nicely. But this solution feels a bit wrong, to change rights on 'system' files.
It might be that some thing hangs in configuration on the Windows machine, alot of changes have been done and tested(?). So we did make a clean install with all domain 'stuff' and I'll try again tomorrow.
I'll have to check and see what the permissions on the actual certificate that we issue are - I can't remember if we had to do the same. I know that the users are NOT admins on the local machine though. To be honest, if you have an AD environment that requires user authentication I don't see an issue with having the machine certificate set with these permissions. If they still have to authenticate to the domain (cached) to login to the laptop, then only legit users should be able to use the laptop regardless of the fact that the laptop is what is authenticated to the VPN.
This does raise a concern though about the CRL and how often the ASA checks it - if you have an internal PKI, make sure you understand how to force a CRL refresh from the ASA and that it is set up correctly. Should a laptop or outside resource go missing, it would be important to be able to immediately revoke the certificate then refresh the CRL on the firewall/VPN headend . We tested this numerous times and it worked like a charm once we had it set up right.
If you have a password change policy in your AD environment, this is another potential 'gotcha'. Be sure to test that users are getting their notification. We've had issues with that.
No issues. Solid solution. It just works if you set it up correctly. Easy to maintain and rollout AnyConnect updates and changes to the VPN.
If this posts answers your question or is helpful, please consider rating it and/or marking as answered.
Have there been any updates regarding TND. Is it still a good idea to only use dns-suffix and not DNS servers?
Are you permitting some sort of local lan access for printers etc?
If not how did your users react to not be able to use there home resurces?
I'm a bit concernd with the security of anyconnect. Some of our customers have a lot of users with admin rights on there PCs. It's simple to use google to find out how to disable the anyconnect service and therefor bypass security.
All good questions.
1. I do remember reading that there have been updates to TND from Cisco and how it works, but I couldn't tell you what they were. We use DNS-suffix and it works well for our purposes.
2. We allow split tunneling as well as local access, mostly because we don't have a good solution to proxy Internet traffic through the corporate offices.
3. If you are wanting to lock them down to a truely "Always On" VPN users haveing admin access is going to be a challenge. Our main goal was laptop visibility and updates. We had laptops in the field that hadn't actually touched the domain for over a year. Using the AO VPN, if they don't connect to the VPN they don't get Internet access. Obviously this is easier to maintain when they aren't Admins.
If this posts answers your question or is helpful, please consider rating it and/or marking as answered.
AFAIK DNS suffix is still the way to go. I don't know if it has been updated, but please see my previous pose on using DNS servers. In the past, if you push one DNS server, and the client has two DNS server statements, those don't match and it wouldn't be a trusted network. I don't think it has changed but same yourself the headache and use DNS suffix.
Like Christopher, we allow split tunneling as well. Our security model isn't requiring us to bring non-production traffic back over the tunnel for inspection. Doing so is also a strain on your bandwidth resources.
Our users are only users. They don't have rights to shutdown services so shutting down the AnyConnect service isn't an option for them. It's all or nothing. As an admin rights, all one has to do is shutoff the service and then it's off. That will definately provide a challenge for you.
If this is for customer access, I'd go with a SmartTunnel though the VPN portal. This works well for us. We have our vendors AD auth to our portal and then they have access to fireup a smart tunnel. Once started, they have access to our network. We then use Dynamic ACL's based on AD group membership (LDAP integration from the ASA) to limit their access. That may be a viable solution for you as well. Not the best, but it works.