Using NAP health certificates to provide IPSec server/domain isolation

Hi

I was recently involved with a proof of concept/functional discovery for a large, shared infrastructure hosting company who provide services to financial organisations.

The requirement we were testing (which we confirmed works – hence this blog) was to find a way to isolate servers and workstations in the same forest from each other on the same network using NAP with IPSec enforcement and Windows group memberships alone. The clients would undergo NAP health checks. If they pass the health check, they will be issued with a certificate. This certificate will be used as their authentication method in IPSec communications with servers. Only certain workstations and servers can communicate with other servers.

And everything is Windows Server 2003 and Windows XP. How can this be achieved?

There are 3 “tricks” to get this to work:

1. On the template used to issue certificates to NAP clients, on the “Subject name” tab you set this to be “Supplied in the request”.
2. In the 2003/XP IPSec policies, when setting the authentication method to “Use a certificate from this certification authority (CA)” you check the box “Enable certificate to account mapping”.
3. You assign the User Right  for “Access this computer from the network” on the server to be protected to be only a domain group. This domain group contains only the computer accounts (and users) you want to be able to access the server.

In this way we can use domain groups to decide which healthy clients (and additionally which NAP exempt servers) can access certain servers using only Group Policies and Windows Groups (i.e. using AD alone).

Here are the screens where these changes are made…

1. “Supplied in the request”:

2. “Enable certificate to account mapping”:

3. “Access this computer from the network”:

 

So, what are we doing with all this?

Templates

A template is created on the Enterprise Edition CA based on the existing template “Workstation Authentication”. We set this to: 1) issue certificates based on the template without requiring CA manager approval 2) allow the HRA to choose the name of the client which will ultimately receive the certificate created from this template 3) secured so that ONLY the HRA computer account can enrol/autoenrol certificates based on this template 4) use the EKU for “System Heath Authentication”.

We’ll create a a second template to be used by the CA to issue certificates via autoenrolment to all of our servers (NAP exempt computers). This template will create the subject of the certificate based on the requestors name and will have an ACL allowing only the computer accounts of the servers to autoenrol.

Certificate Mapping

Next, by mapping the certificate name to a computer account in AD, we are able to use the groups that the computer account is a member of to decide if the IPSec authentication will succeed or fail. For the mapping to work, the certificate name needs to match the computer name. For the computer name of the NAP client to appear in the certificate requested by the HRA, the HRA needs to be able to submit the name of the client in the certificate request. The name of the “Issued To:” field in these certificates will be in the form of <“COMPUTER_NAME$@UPN.suffix>”. Using the UPN allows certificates to be mapped to computer accounts anywhere in the forest, or even to computer accounts in forests joined by forest-trusts.

User Rights

Lastly, the computer account we matched via the certificate needs to be used to protect some high-value servers from unhealthy clients (or even servers who have been “lost” to application developers who need to be members of their particular dev server in the domain). On the User Right (under the GPO settings for Local Policy) we change the defaults for “Access this computer from the network”. This is a tricky setting and sometimes doesn’t work the way you first expect. In our case we want to protect our servers from unhealthy COMPUTERS. We have no concept of an unhealthy USER (yes, yes, sick leave, flu etc – haha). So we want to allow only certain computers, but all USERS. When testing this, remember that running PING against a computer is sending packets from one computer to another, even though the user account opened the command prompt. But opening explorer to display the shares of a computer is a conversation between the USER and the target server.

We will have these 3 entries assigned to the User Right “Access this computer from the network” on servers we wish to protect from some computers:

1. The built-in group “Users” – so all user accounts who have logged on (includes local accounts, domain accounts, domain accounts from other domains in the forest)
2. SYSTEM (representing the computer itself)
3. Some domain group containing the computer accounts of the computers we permit to allow contact to this server

Common servers are grouped together in OUs, so applying this user right is done simply through GPO.

It Works!

To get all of this working, we needed 1 computer running Windows Server 2008:- the HRA/NPS server. No schema changes are required, the CA can be Windows Server 2003 (the EKU can be setup using it’s OID).

Gotchas:

We wanted every component to be redundant. This means at least 2 HRAs, 2 NPS servers and 2 CAs. The first 2 are simple to supply with redundancy. the last is not. Here’s the scenario:

Every time a client changes its health status (and before its old certificate expires, and when it reboots) it will need a new certificate. The default lifetime for certificates is 4hrs. The Authentication Methods for  on 2003/XP work in a very particular way. If 2 computers wish to talk, they first negotiate the authentication methods they have been configured to use. As soon as they find a METHOD they agree on, they will use it. If the authentication based on that method FAILS, then the authentication has failed and no other methods are tried. When you specify the CA to use to detriment which certificate to use as credentials, you must choose an ISSUING CA, not a CA root. So the 2 communicating computers need to have a certificate issued by the SAME CA. If I have 2 CAs on my network for my HRAs to choose from, and I have 2 authentication methods in IPSec specifying these CAs, the second authentication method will never be used as the computer I am talking to has the first CA authentication method listed first (as do I) and we agree to use this method forever. In the case where CA1 fails and the HRAs start using CA2 to issue certificates to healthy clients, the clients will no longer have a certificate issued by CA1, but they WILL have CA1 listed as the first Authentication Method for IPSec authentication. This method, based on CA1, will always fail until I change the GPO for the clients to instruct the clients to use the Authentication Method using CA2 as the FIRST priority.

Now, my servers will attempt to use the Authentication Method which is set to use CA1 first. This will fail to negotiate as my clients are NO LONGER configured to use that method. The servers will offer the Authentication Method using certificates issued by CA2. Communication can now work as all servers will need to have NAP exception certificates issued from both CA1 and CA2.

But how can we push out GPO client changes to all clients when all the certificates will be expired after 4 hours? Or worse yet, imagine a client who changed his health status moments after the failure on CA1. He will be immediately unable to talk to protected servers.

We can do a number of things to mitigate this:

1. We can increase the frequency of background GPO refreshes on clients.
2. We could increase the health certificate lifetime on clients from 4 hours to a few days.
3. We can take the HRAs offline while the CA1 is offline and GPO refreshes are ongoing.
4. We can use a script/3rd party tool to force a GPO refresh on clients.

None of these methods is particularly nice (compared to the redundancy built into HRAs, NPSs, DCs etc). It would be better to be able to specify a Root CA in the certificate authentication method for IPSec. I’m still looking into this and will get back if there are any updates.