Deployment of Certificates to Workstations for Wireless Authentication

There are three things to do…

1. Setup Group Policy to auto enroll workstations and servers with certificates
2. Install Enterprise Certificate Authority
3. Setup NPS to allows devices that have certificates issued by the CA to be allowed to connect.

I like to start with group policy first because when you install the CA, it starts handing out certs immediately.
Go to the Default Domain policy or I guess you could create one for this specifically (but I think that’s silly), and expand
Computer Configuration – Policies – Security Settings – Public Key Policies
Go to the properties of “Certificate Services Client – Auto-Enrollment” and change configuration model to “Enable”, then enable the two check boxes in the image below. The first check box allows certs to be auto renewed, since they are issued with a one year life span. The second check box allows certs to be updated if you should choose to modify the template (rare case).

Next, expand Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Automatic Certificate Request Settings
From there, right click and create a new Policy, and choose the Computer template. Without this template, I find that certs will get issued automatically to member servers and domain controllers, but not workstations.

Regarding the type of template to use, Computer Template or Domain Controller Template, there is a nice chart listed on technet documentation here  and a mention of templates on technet forums here.
It should look like the image below:

The next process is to install the Certificate Authority. Here is my advice, by default the name of the certificate authority is the first part of your active directory dns domain name followed by your server name. For example, if your domain is, and the server is dc1, then the name of the root certificate and the certificate authority will be contoso-dc1. Because it’s possible to move this to another server later on, I don’t like to tie in the server name with the CA name, so I rename it during the installation process of the CA and call it, following my example, Contoso-EnterpriseRoot-CA. That will be the online name and also the name of the root certificate.

Start server manager, and install the Certificate Authority role. During the installation wizard you will want at a minimum “Certificate Authority” and “Certificate Authority Web Enrollment” services checked.  If you plan on giving non-domain member devices (iPads) certificates, then install the “Network Device Enrollment Service” also. This last role service requires you to setup a “proxy” user account to request certificates on behalf of non domain member devices. I like to create a user called NetDeviceEnrollService or something similar to that and put more info into the description area.

During the installation, you will have an opportunity to rename your CA to what you want.

Once it’s installed, you don’t have to reboot the server or anything. In fact, if you open the local certificate store and look at the Trusted Certificate Authorities section, you should see the certificate listed there.

You should start seeing this on all servers and workstations…. why? Because the default setting in windows is to trust any root CA that is “registered in Active directory”. What you see below is a report from gpresult.exe utility on a member server.

That completes the certificate portion installation.
The next part is configuring the Network Policy Server (NPS) to issue certs.
Configure a wireless policy that uses MS-CHAPv2 in combination with certificates issued by the CA.


2008 R2 Domain Controllers unable to communicate to root DNS servers

I upgraded a domain with two local domain controllers from 2003 to 2008 R2.
I installed two new dcs, then moved the fsmo roles over and flipped ip addresses.
That way i did not have to deal with issues of dns resolution for workstations (modify dhcp scope for DNS) or member servers.
When I did that, the new dcs had the old dcs ip address, and the old dcs had some other previously unused ip addresses.
At that point, the new dcs were being queried for names of external websites. The dcs were unable to resolve anything external.
For a quick fix, I configured one of the dcs to enable forwarding (rather than root hints servers) and all requests were forwarded to the ISP’s DNS servers.
That worked, but why could 2003 perform root hints communication, but 2008 could not I thought?
The answer turned out to be this technet article. It affects 2003 R2, 2008, and 2008R2

Basically type this from an elevated cmd prompt
 dnscmd /config /enableednsprobes 0

No need to restart services or reboot anything.

Two issues: difference in implementation of dns server between windows version and some cisco firewall setting.
The cisco engineer enabled large packet size or something like that, but that still did not fix the issue.
So i ran the commands described in the above article, and all is good. I was able to turn off forwarders and use root hints as necessary.

Some strange setting on the cisco firewall that did not like the way 2008 operated dns.

“Some firewalls contain features to check certain parameters of the DNS packet. These firewall features may make sure that the DNS response is smaller than 512 bytes.”
Click on the image below to see it larger.
Note: You have to run the cmd prompt elevated (Runas Administrator)

Network Load Balancing Windows 2008 R2

For this verison of windows, it requires both NICs to have a Gateway.
This is because Windows 2008 R2 uses something called a Strong Host Model.
Someone else says:
Now I tested web site access from an external IP and it worked perfectly. My conclusion? You have to configure the default gateway on an NLB NIC if using Network Load Balancing on Windows Server 2008 R2. Otherwise it will not route correctly to other networks; it should pick up the default gateway from the management NIC but it does not.

and from here:

Windows 2008 introduces a “strong host model” that doesn’t allow the
different NICs to talk to each other. For example, if a request comes in on
the 2nd NIC and there’s no default gateway setup, then the NIC will not use
the 1st NIC to reply to the requests. (even though there’s a default gateway
setup on that 1st NIC).

In order to change that behaviour and go back to a 2003 model, you go to the
command prompt and then you type:

netsh interface ipv4 set interface NLB weakhostreceive=enable
netsh interface ipv4 set interface NLB weakhostsend=enable

(where NLB is the name of the network interface… default is Local Area

As an alternative, you can set a default gateway on the 2nd NIC but that can
introduce more problems where the system doesn’t know which way to send
traffic. MS said that I could set the metric to 2 on the 2nd NIC and that
way it will only be used if the 1st NIC is unavailable.