Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Debugging a NAP HRA on an Enterprise CA

July 4, 2008

I’ve been doing some demo preparation involving Network Access Protection (NAP). The machine I’m building is Windows Server 2008 with a bunch of roles configured: Active Directory (AD), IIS, NAP, Health Registration Authority (HRA), and an Enterprise Certification Authority (CA).

The NAP lab guide for IPsec, which is roughly what I’m following, assumes that the HRA and Enterprise CA are on two different machines. Technically, there’s no need for that, and I’m trying to consolidate the footprint of my demo as much as possible.

Thus, I encountered three problems which can be a challenge to debug if you don’t know what to look for, or if, like me, you jump right in rather than reading the directions first.

The symptom for all three problems was the same: I had a Vista client (NORTHWINDC1) joined to this test domain (NORTHWIND), and while it had full network connectivity and evidence of NAP activity (for example, running “netsh.exe nap client show status” on the command line confirmed that the IPsec enformence agent was enabled and that the Windows SHA was running), it wasn’t obtaining a health certificate.

The first issue I discovered was that SSL connectivity to the server (NORTHWINDDC) was broken. How? Well, http://northwinddc worked and https://northwinddc didn’t. Why is that a problem? Because the default HRA certificate request URLs use SSL. Plus, in this configuration, with an Enterprise CA available in the domain, SSL should just work on member web servers due to auto-enrollment. So I new there was something really broken.

Turns out that the IIS 7.0 management console will show you a list of available server certs, but not let you pick which one to use. Apparently it defaults to the first one it finds, even if, for example, the subject name of that certiifcate doesn’t match the DNS name of the host. That’s pretty bogus, especially if there are other certs present that do match (and meet the usual expiration and usage constraints).

The following command saved my bacon:


>netsh.exe http show sslcertSSL Certificate bindings:
-------------------------

Followed by this command to figure out which cert has that hash:


>certutil -store MY 33cf8c2cec185727f7de9100b2a3bab9dfe87483
MY
================ Certificate 3 ================
Serial Number: 348bd263ce56fcba48953e605cca4ea3
Issuer: CN=NORTHWIND-NORTHWINDDC-CA, DC=NORTHWIND, DC=LOCAL
NotBefore: 7/1/2008 3:16 PM
NotAfter: 7/1/2013 3:26 PM
Subject: CN=NORTHWIND-NORTHWINDDC-CA, DC=NORTHWIND, DC=LOCAL
CA Version: V0.0
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): 33 cf 8c 2c ec 18 57 27 f7 de 91 00 b2 a3 ba b9 df e8 74 83
Key Container = NORTHWIND-NORTHWINDDC-CA
Unique container name: e5ccea44e1de4a2ce8735b52c42734db_592a541a-4bff-495f-bee8-ee08f9ca41d5
Provider = Microsoft Software Key Storage Provider
Signature test passed
CertUtil: -store command completed successfully.


As I mentioned above, that’s never going to work: IIS (or http.sys) defaulted to the local CA cert, which has little resemblance to the server DNS name. Here’s the cert I really want:


>certutil -store MY 72da46ab86476f5f6291755e0d24ce61a5f96c31
MY
================ Certificate 1 ================
Serial Number: 13914f7e000000000006
Issuer: CN=NORTHWIND-NORTHWINDDC-CA, DC=NORTHWIND, DC=LOCAL
NotBefore: 7/4/2008 9:07 AM
NotAfter: 7/4/2009 9:07 AM
Subject: CN=NORTHWINDDC.NORTHWIND.LOCAL
Certificate Template Name (Certificate Type): DomainController
Non-root Certificate
Template: DomainController, Domain Controller
Cert Hash(sha1): 72 da 46 ab 86 47 6f 5f 62 91 75 5e 0d 24 ce 61 a5 f9 6c 31
Key Container = 5311de249661b6a047e69d4b8ed168d9_592a541a-4bff-495f-bee8-ee08f9ca41d5
Simple container name: le-DomainController-cc2e44d1-1d33-4a84-b8e1-6758599b6638
Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.


And here’s how to get IIS to use it by defualt:


netsh http>delete sslcert ipport=0.0.0.0:443SSL Certificate successfully deleted

Now SSL was working (including https://northwinddc.northwind.local, which is what the client actually uses). But still no health certs.

The second issue I encountered was that I’d missed a setting change required when using the NAP HRA with an Enterprise CA (rather than with a stand-alone Subordinate CA, which is what the lab instructions show). Namely, you have to run the following on your CA, followed by a stop/restart of the CA service.


>Certutil.exe -setreg policy\EditFlags +EDITF_ATTRIBUTEENDDATE
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\NORTHWIND-NORTHWINDDC-CA
\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:Old Value:
EditFlags REG_DWORD = 11014e (1114446)
EDITF_REQUESTEXTENSIONLIST -- 2
EDITF_DISABLEEXTENSIONLIST -- 4
EDITF_ADDOLDKEYUSAGE -- 8
EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
EDITF_ENABLEAKIKEYID -- 100 (256)
EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

But still no health certs.

The third issue: permissions on the health certificate template. It was actually the NAP eventlog on the client which started leading me in the right direction. Windows Debugging 101: always check eventvwr.exe!


Log Name: Microsoft-Windows-NetworkAccessProtection/Operational
Source: Microsoft-Windows-NetworkAccessProtection
Date: 7/4/2008 10:27:02 AM
Event ID: 21
Task Category: None
Level: Error
Keywords:
User: NETWORK SERVICE
Computer: NORTHWINDC1.NORTHWIND.LOCAL
Description:
The Network Access Protection Agent failed to acquire a certificate for the request with the correlation-id {8F938128-F3E0-4A04-8653-9CD62ABFBF2E} - 2008-07-04 17:27:01.503Z from https://northwinddc.northwind.local/domainhra/hcsrvext.dll.
The request failed with the error code (500). This server will not be tried again for 10 minutes.
See the HRA administrator for more information.Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-NetworkAccessProtection" Guid="{4ef850d8-bf30-4e64-a917-ee21b9be1f0a}" />
<EventID>21</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2008-07-04T17:27:02.003Z" />
<EventRecordID>518</EventRecordID>
<Correlation />
<Execution ProcessID="1348" ThreadID="2248" />
<Channel>Microsoft-Windows-NetworkAccessProtection/Operational</Channel>
<Computer>NORTHWINDC1.NORTHWIND.LOCAL</Computer>
<Security UserID="S-1-5-20" />
</System>
<UserData>
<NapEvent xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="myNs">
<URL>https://northwinddc.northwind.local/domainhra/hcsrvext.dll</URL>
<CorrelationId>{8F938128-F3E0-4A04-8653-9CD62ABFBF2E} - 2008-07-04 17:27:01.503Z</CorrelationId>
<HResult>500</HResult>
<Blackout>10</Blackout>
</NapEvent>
</UserData>
</Event>

That, in turn, got me thinking about the CA log, which turned out to have some interesting information. Namely, in the CA snap-in under Certification Authority | NORTHWIND-NORTHWINDDC-CA | Failed Requests:


Request Status Code
The permissions on the certificate template do not allow the current user to enroll for this type of certificate. 0x80094012Request Disposition Message
Denied by Policy Module

Then it hit me: the local HRA is running under the NETWORK SERVICE account, which I hadn’t explicitly added to the System Health Authentication template that I’d created following the lab. Ten minutes later, I received my first health certificate on the client. So proud!

Search:

Archives

Recent Posts

• Cloud developers
• Microsoft Security Intelligence Report v8
• Windows LNK bug and SCADA vuln
• Mobile devices + Cloud
• Concurrency, Security, and Windows

RSS Feed

Blogroll

Security Focus: