Hello,
Our organization is configuring AnyConnect to use the SBL feature to ensure that domain laptops are always connected to the domain via the VPN, and NAM to ensure that only our laptops can connect. I realize that the ‘intended use’ of AnyConnect is to facilitate BYOD, but this is something that we have to AVOID at all cost. Only company owned laptops that are properly joined to the domain, have the correct certs pushed via GPO, and are in the correct domain OU should be allowed to come anywhere near completing a connection. I think Security would also like to create other ‘requirements’ but they may be making this whole thing much more difficult than it has to be.
For our current VPN solution we have RSA tokens which provide dual factor authentication for remote users, and I’ve been told Security would like to continue the use of these for the ASA. I believe the model our Security team would like to see implemented is something like, this machine can't even be booted (well, ok, can't log onto it) unless you're connected to our internal network by either a wire in the office (yes, we do NOT have wireless, long story) or a VPN connection established prior to the end user logging into their laptop. I have fairly good experience with other aspects of ASAs, but have only configured one AnyConnect using webvpn for a client several years ago and the AnyConnect has grown up quite a bit since then, plus I'm not the one actually configuring this particular device. As I proofed my question list below, it seemed to me that much of it would probably be cleared up by a good configuration example but I didn’t see one that pertained to our particular situation and all of its moving parts. Perhaps what we need is the overall understanding of how RSA auth for AnyConnect, SBL and NAM play together.
We've got multiple "not quite sure how to configure this" types of questions (and general understanding of order of operations) about this including (but not limited to):
- It seems from reading the AnyConnect Admin Guide 3.0 that we will need both a VPN profile (to establish IPSEC) and a NAM profile (to create checklist of 'you can only transmit traffic IF...') Can someone confirm?
- The AnyConnect Admin Guide gives details about each component (RSA auth,SBL and NAM), but not much about when you're using them together. I haven't yet found a Configuration Example for this particular combination, anyone know if one exists (link please)?
- Are there any specific gotchyas for using the three together (RSA auth, SBL and NAM)?
- Here's our current understanding of how the 2 features interact, if someone can confirm or correct our misunderstanding that'd be great:
- User boots machine
- User enters hard drive encryption password
- Network connection established as part of boot-up process. Most users will be either: Wired, Wireless (but no laptops have internal wireless NICs, all wireless NICs in the organization are USB and may only be used outside the office), or some might also connect with an Air Card.
- We realize that if the user is in hotel with a web based authentication page required before a wireless Internet connection can be established, that there's a gotchya. We will have users who need to travel and connect to the VPN from such hotels, so this may be an issue. Does that rule out using SBL, or is there a way to work around this? Any advice on how (if it's possible) to configure SBL so users in hotels with web auth required can connect? The Admin guide is pretty murky at this point. Is this perhaps allowed by set Captive Portal Remediation to Always on and configuring TRUSTED NETWORK DETECTION to have the Untrusted Network Policy set to “Connect”? If so, is anything else required?
- SBL steps in and says "no windows logon till you phone home" and establishes the AnyConnect tunnel.
- NAM client checks with ASA to determine if the whole process may continue. We would prefer NAM to check the cert on the client machine before the user is presented with a logon prompt. Or does the NAM check cert after u/p is entered?
- SBL presents user with his normal windows logon which is authenticated via the newly created VPN tunnel.
- User enters his Domain/U/P
- Somewhere we’ll probably have to check the RSA credentials – how/when is this done? And how is it configured?
- Finally,
- If machine/user pass all the tests, network access is granted.
- If not, user packs up and comes back to the office.
- Anything else we should be aware of in the process that will affect what configuration we need to end up with?
And general "we're just checking our understanding" types of questions:
- Since our AnyConnect will not be accessible via a webvpn, the actual connection specifics (connection ip address, VPN group profile name and other tunnel specifics) should be hidden from the end user, right? or will that depend on whether or not that end user has local admin rights on his laptop?
- We don't want AnyConnect to be downloadable for our connection (no 'non-domain' machines allowed) so we'll need to push out the AnyConnect client to the laptops. I understand there's a specific order to this, first AnyConnect and its client side configuration, THEN the NAM client. Any specific gotchyas with the client push/config that we’ve missed and should be aware of?
- NAM will be checking for a Domain machine cert. That will need to be pushed, set to "prevent export" again to prevent users from putting the domain cert on their home machines. Any other gotchyas here?
- As stated, Security would like to have the 2 factor RSA tokens used in conjunction with SBL and NAM. I have a feeling that they’re overloading us with requirements that may make the whole solution untenable, but don’t quite have a grasp of how it might possibly work to confirm that. Any general thoughts on that?
And finally last but not least:
Is there a 'best practices' for using RSA auth, SBL and NAM together with the non webvpn AnyConnect? I've yet to find one.
I realize this is a lot, so thanks in advance for wading thru it. It’s also likely that answers will generate more questions. Such is the way of life! Thanks.
