Fun with TMG Beta 3 and NAP

I was playing today with TMG Beta 3(domain member) and NAP(I’ve installed the NPS role on the DC). First I seemed to run into an issue I’ve observed in another lab of mine a while ago(using Windows Server 2008 R2 RC as the VPN server without TMG), that is, sometimes when I connect(using PEAP-EAP-MSCHAPv2 for user authentication) I get the bellow error on my Windows 7 RC VPN client although previously I was able to connect just fine(actually, as can be seen from bellow, the same thing happened with XP SP3 or Vista SP2 VPN clients) –the Windows 7 RC machine was a domain member, but the XP SP3 and Vista SP2 weren’t-:

error_conn
error_conn2
error_conn3

 

Decided to take a closer look, and apparently I was trying to login to an un-existing domain(a sort of a combination between my user name and a part of my domain name, interesting stuff):

log_error_1
log_error_2

 

I did not specify a domain on the VPN connection:

vpn_connection_without

 

As soon as I added a domain on my VPN connection, I did not encounter that issue:

vpn_connection_with

 

Next, I decided to spin a little bit the case when having non-NAP capable machines too along with NAP capable ones. I wanted to have these machines retained in the Quarantined VPN Clients on TMG(see the bellow Network Policy from the NPS, if you use the wizard from NPS for VPN clients and NAP, it will also create a policy like so, you may like to read this).

nps_pol1
nps_pol2

 

But apparently, right now it just doesn’t work like that with TMG Beta 3, as if I let it like so, NAP non-compliant clients may be able to avoid the health checks pretending as being non-NAP capable, as can be seen from bellow the “non-NAP capable” client was “released” into the VPN Clients network and not remained as desired in the Quarantined VPN Clients network(well, as I have configured the Network Policies, non-compliant clients will not be able to avoid the health checks like so due to the Active Directory user groups restriction and this will combine with TMG’s group-based access rules, but that’s just another story, search bellow):

non_nap_capable_conn
non_nap_capable_mon
usr_clr_quant

 

The current available documentation, mentions something about the RQS based quarantine control and non-NAP capable clients, but that sounds more likely for creating custom CMAK profiles using RQC on the client. Would be a little bit silly to install RQS on TMG just to enable a couple of non-NAP capable clients to be retained into the Quarantined VPN Clients.

 

For the moment(until I will figure this part), I’ve made my own “quarantine network” for non-NAP capable clients.
We already saw the Network Policy for non-NAP capable clients.

I’ve created within Active Directory two groups of users, one for NAP capable VPN users and another for non-NAP capable users. Well, not the users are non-NAP capable, rather the clients they use, but likely the users are supposed to VPN-in from certain machines(say corporate laptops), -TMG does not provide VPN clientless access(if we exclude OWA and such forms of VPN clientless access)- and there might be a group of users(maybe remote contractors or a business partner) using “foreign machines” non-NAP capable, thus there is a chance to have separate users.
So when an user that is supposed to use a NAP capable client attempts to use a non-NAP capable client(or disable the Network Access Protection (NAP) agent) to avoid health checks(as we saw above such a client will be “released” into the VPN Clients network with TMG Beta 3, well at least this happens in my lab), its request will not match any Network Policies on the NPS, thus its VPN connection will fail.
A downside of this behavior is that if an user from the non-NAP capable users group attempts to use a NAP capable client, its request will fail as it will not match any Network Policies on the NPS.

nap_users
non_nap_users

nps_pol3
nps_pol4

nps_pol5
nps_pol6

 

Due to TMG’s fundamental ability to support group-based access rules(TMG must be domain member if you want to use the user mapping feature and the NPS is registered within Active Directory), we can have granular access rules, so even if the non-NAP capable clients are “released” into to the VPN Clients network, they will only be able to access the needed services, so in the end they will still be “trapped” –note that the bellow TMG access rules are just for testing and do not have a specific meaning-:

usr_map_tmg

tmg_acc_rul_vpn

tmgb3_mon_vpn

 

All in one, once configured, NAP with TMG Beta 3 and VPN clients seems to work pretty good, and the checks are pretty fast.
For example I’ve liked the part when playing with the Windows Firewall, turn it off, start the VPN connection, the health check requires a firewall, so it will automatically enable the Windows Firewall(due to the auto-remediation setting), and I will get unrestricted access, then a little bit later I will disable the firewall again, and it will immediately detect this change and automatically re-enable the firewall.
Pretty cool. –:)

compliant_win7_mes
compliant_xp_mes

non_compliant_vista_mes

Comments (1) -

  • Jason Jones

    7/9/2009 12:44:42 AM |

    Interesting as ever Adrian!

Comments are closed