Dan Griffin's Blog

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

I was doing some troubleshooting Friday of a System Center Configuration Manager 2007 SP1 deployment on Windows Server 2008. The SCCM (or ConfigMgr - whichever abbreviation you prefer) client is installed on a Vista machine in the lab for testing.

The first problem I observed was that a software package distribution was failing. I confirmed that the SCCM site server is configured as a Distribution Point, and that the package in question is deployed to that DP. But still no luck.

Analyzing the status messages on the ConfigMgr server, I saw most notably the following:


System: (my Vista machine)
Source: SMS Client
Component: Software Distribution
Type: Milestone
Severity: Error
Message ID: 10051
Description: The content for ... could not be located. This SMS client will no longer attempt to locate this content. Possible cause: The content source might not be available ...

But at this point, based on the success messages posted by the DP, I was pretty certain that the DP component itself, as well as the package in question, was configured correctly, at least on the server side.

Another couple of troublesome messages came from the client in %systemroot%\system32\ccm\logs\cas.log. First this one, dating back to the initial install of the ConfigMgr client: “Software Distribution Site Settings for the client are missing from WMI …”

And this one in execmgr.log in the same client directory: “Raising event … SoftDistErrorNoContent …”

An equally important observation about cas.log, which I suspected at the time but couldn’t confirm until now: the NetBIOS name of the DP server didn’t occur in the log until after the issue was fixed. That’s a telltale sign that the client knew the package existed, but couldn’t figure out how to download it.

It took me a while to get there, though. Some web searching led me to initially believe that the correct version of MSXML was missing from the Vista client, and I tried installing on older version, but, for future reference, I don’t think that was part of the problem.

Then another post reminded me that the ConfigMgr client had been unable to automatically detect its local site code (see %systemroot%\system32\ccm\smscfgrc.cpl | Advanced | Configure Settings). I thought, at the time, that was only because I’d forgotten to create the System Management node in Active Directory. But re-running the client auto-discover at this point revealed that was still broken! It hadn’t occurred to me until that point that these issues might be connected.

The answer came when I ran across posts, in various contexts, about setting site boundaries. Seems that can affect a lot of ConfigMgr functionality - to a confusing extent, actually, because even though the client may be hardcoded to a certain site, package distribution will stlil fail unless an explicit boundary mapping exists for the client in question.

Lab testing confirmed this. Check out Site Database | Site Management | (Site Name) | Site Settings | Boundaries in the Configuration Manager Console snap-in. I set a single boundary to include the virtual 10.0.0.x network in use by the test machines. Much to my delight, auto-discovery and the package download were fixed immediately.

Permalink | Comments (0)

I referred to this in my TechEd post here. Various links to the interview are here.

Permalink | Comments (0)

Are you one of those people who, like me, thought that couldn’t be done? Well, read on, because it can!

What am I talking about? I wanted to create an IPsec policy that requiring a health certificate. That is, require that the IPsec peer presents a valid certificate which includes the System Health Authentication OID (used by NAP). Since that capability isn’t supported by the old IP Security Policies snap-in, I needed one of the new Connection Security Rules (that is, the new rule type included in the Vista and Server 2008 firewall).

But I also wanted that rule to be port-specific. While that capability is supported by the legacy IP Security snap-in, it’s not exposed by the Connection Security Rules GUI. Lame.

However, the underlying rules engine supports that combination, and the capabilities are exposed by the netsh.exe command-line. Cutting to the chase, here’s an example:


netsh.exe advfirewall consec add rule name=HRweb-Secure endpoint1=10.0.0.3 endpoint2=10.0.0.2 action=requireinrequireout port1=any port2=8000 protocol=tcp auth1=computercert auth1ca="DC=LOCAL, DC=NORTHWIND, CN=NORTHWIND-NORTHWINDDC-CA" auth1healthcert=yes

In summary, that command creates a new connection security rule with the following characteristics:

  1. The rule applies to traffic exchanged between two IPs, 10.0.0.3 and 10.0.0.2.
  2. Authentication is required on inbound and outbound traffic.
  3. The rule applies to traffic originating from any port, but only when destined for port 8000.
  4. Finally, both parties must present valid certificates issued by the specified CA, and the certs must contain the health OID.

As an aside, regarding the operating environment, the x.2 machine is a demo web server and x.3 is the client. But keep in mind that IPsec views them as peers.

Important caveat: that rule only gives you integrity, not privacy. That is, the resulting traffic is authenticated and has a cryptographic checksum, but it’s not encrypted. As I said, this is for a web server, and TLS is being used for encryption. Why bother with IPsec? The health OID! By requiring that, I’m ensured that any machine hitting the demo web site has been deemed compliant, based on the current network health policies.

Permalink | Comments (0)

In my previous post on this subject, I neglected to mention the following configuration change required in order to support a Health Request Agent (for Network Access Protection on Windows Server 2008) with an Enterprise Certificate Authority:

On the health certificate template, you must allow the enrollment client to specify the subject name. Normally, the subject name is obtained by the CA implicitly from the security context of the caller (e.g. the name of a remote machine). But in this case, the caller is the HRA service, enrolling on behalf of some other machine.

What happens if you don’t allow the subject name to be supplied in the request? All of your health certificates will be issued to the machine name hosting the HRA. That doesn’t do the actual client machine much good (assuming the cert is being used in the context of an application that does name checking).

How to allow the subject name to be supplied in the request? Open the certificate manager snap-in for the Enterprise CA, right-click on Certificate Templates, and select Manage. Find the health cert template, right-click, and select Properties. Click on the Subject Name tab and select “Supply in the request”.

You’ll may get a warning at that point, and for good reason. Allowing a free-form subject name means that anyone with enrollment rights for that template can obtain a cert in anyone’s (or anything’s) name. The CEO’s computer, for example. Thus, you need to ensure that those rights are granted to as limited a group as possible.

Permalink | Comments (0)

This NY Times article (link at the bottom), regarding a judge’s recent order that Google turn over YouTube usage information to Viacom in response to a copyright-infringement lawsuit, does a good job of hinting at the hypocracy on both sides of the case.

The crux of the suit is this. Viacom asserts that the success of YouTube is partly due to the site making available free viewing of copyrighted work, such as television shows. Owners of those works have never been paid by Google or YouTube.

Included in the data demanded by Viacom is the IP address of each user who interacted with the site since its founding in 2005.

Both firms have claimed that an IP address alone is not enough information to identify a specific person with certainty. And Viacom claims that they won’t go after users who uploaded copyrighted videos; they simply want to correlate YouTube’s explosive growth with the availability of unlicensed media.

Viacom may actually be telling the truth right now. But once they have that information, their tune may change.

Because, for one thing, the claim about IP addresses is misleading. There are databases readily available that accurately map IPs to specific countries. In the US, that mapping can even be done to down to the city level, due to major ISPs operating in areas with high population density.

Once you know what city a user is in, perhaps his or her login or domain name betrays enough information to get a phone number, real name, or address. Or maybe one of those data can be correlated with other lists available on the net. Or maybe a single reverse DNS query is all that’s needed.

True, that process may be difficult to 100% automate. But they’ll start with the addresses that show up the most in the YouTube traffic. And those are likely to be the easiest targets to triangulate, due to their heavy web usage.

It’s not Viacom’s position in all of this that bothers me, though. If I owned copyrights on a bunch of television shows, I too would want to identify the worst violators of those rights and remind them to stop.

It’s Google’s “Don’t be Evil” mantra that sticks out like a sore thumb here.

Google objects to handing over the YouTube usage data, partly on the grounds that identities could be betrayed. As already stated, I readily agree. But that contradicts the position, shared by both companies, that IP address alone isn’t a risk.

Furthermore, as observed by the Times writer, YouTube’s enormous popularity is such that the data store in question is immense. We’re talking hundreds of millions of users.

How different is that from a single company owning data correlating every video tape anyone has ever rented? Or every library book people have ever borrowed?

My point is this: if Google really wanted to not be evil, they would have scrubbed the data as it accumulated (or at least when YouTube was acquired). Large stores of personal data are always going to be a target for hackers and lawsuits. The best way to take care of your users is to avoid storing the data in the first place.

The Don’t be Evil thing is just like greenwashing: that is, companies - a great example is British Petroleum - that put on a environmentally friendly veneer, but don’t change the true nature of their business.

The world needs oil companies. The world needs internet search companies. But at the end of the day, that’s what they are: companies, and they exist to profit. Consumers musn’t forget to look deeper than the greenwashed, and don’t-be-evil-washed, surface.

http://www.nytimes.com/2008/07/04/technology/04youtube.html?_r=1&scp=1&sq=google%20viacom&st=cse&oref=slogin

Permalink | Comments (0)

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 sslcert
SSL Certificate bindings:
-------------------------

IP:port : 0.0.0.0:443
Certificate Hash : 33cf8c2cec185727f7de9100b2a3bab9dfe87483
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

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:443
SSL Certificate successfully deleted

netsh http>add sslcert ipport=0.0.0.0:443 certhash=72da46ab86476f5f6291755e0d24ce61a5f96c31 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=MY

SSL Certificate successfully added

netsh http>show sslcert

SSL Certificate bindings:
-------------------------

IP:port : 0.0.0.0:443
Certificate Hash : 72da46ab86476f5f6291755e0d24ce61a5f96c31
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

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)

New Value:
EditFlags REG_DWORD = 11016e (1114478)
EDITF_REQUESTEXTENSIONLIST -- 2
EDITF_DISABLEEXTENSIONLIST -- 4
EDITF_ADDOLDKEYUSAGE -- 8
EDITF_ATTRIBUTEENDDATE -- 20 (32)
EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
EDITF_ENABLEAKIKEYID -- 100 (256)
EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

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. 0x80094012
Request Disposition Message
Denied by Policy Module

Requester Name
NORTHWIND\NORTHWINDDC$

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!

Permalink | Comments (0)

A current project, along with the recent RTM, has inspired me to try out Microsoft’s Hyper-V virtualization technology. However, getting it installed on my Dell PowerEdge 1900 required some digging. For the benefit of posterity, here roughly what you have to do:

First, get the latest Dell OpenManage (OM) software. That’s at least version 5.4, which includes the version of their Systems Build and Update Utility (SBUU) that supports Windows Server 2008 (WS08; required to run Hyper-V). Warning, the whole OM image is 3.5 GB, and you’ll obviously need a DVD burner. But trying to get SCSI, SAS, RAID, etc drivers installed without this is not worth your time, and previous separate versions of SBUU (such as 5.3) don’t support WS08. On the plus side, you end up with a single disk that has all of the OM tools (and it’s bootable for SBUU).

Next burn the WS08 x64 boot image (another DVD). Don’t forget, Hyper-V requires 64-bit Windows!

Now boot the OM disk, select the installation/SBUU options, and then select the WS08 x64 option. There are some additional choices here, such as using a utility partition and configuring RAIDs, that you have to decide for yourself.

As an Interesting side note – the latest OM uses the Vista-era WinPE. I hadn’t seen that before, so I thought something had gone wrong when the blue Vista “curtain” background suddenly appeared after OM-initiated reboot. Not to fear: you’re prompted for the WS08 media at that point, and the installation completed without issues.

Once the server is up, perform the usual initial configuration steps. Just be prepared to do lots of reboots. Then, to get Hyper-V going:

  1. Ensure that your processor’s virtualization extensions are enabled in the BIOS.
  2. Add the Hyper-V role from Server Manager. It’ll warn you that the feature is pre-release. That’s okay, just don’t forget the next step.
  3. Download and install the Hyper-V RTM update.

Initial reactions about Hyper-V? Well, it’s way better than Virtual Server 2005. Cleaner and faster. And, so far, building new VMs (Windows on Windows) is done via a more consistent and intuitive interface than VMware Server 5.x. Stay tuned.

Permalink | Comments (3)

There’s a seven part series from the BBC on YouTube, filmed for Gates’ last full-time week at Microsoft (having ended two days ago). They captured some classic Bill-isms while filming two executive reviews, one from this year and one from 10 years ago.

http://www.youtube.com/watch?v=2gOrWBPt1bA&feature=related
“You guys never understood. You never understood the first thing about this.”
 
http://www.youtube.com/watch?v=d_LHBfHrWIo&feature=related
“It’s a Turing machine and this is the syntax, right?” [As in, give me the bottom line …]

Gotta love it!

Permalink | Comments (0)

The Hyper-V virtualization technology for Windows Server 2008 released today - see the press release.

And, as with any Microsoft technology, don’t forget to check out the Solution Accelerators available for virtualization - link here.

Permalink | Comments (0)

I’m happy to announce that JW Secure is now a Microsoft Certified Partner. We’ve also completed the ISV/Software Solutions competency.

What does that mean? Well, mainly that JW Secure has completed a long list of successful software development projects with a variety of customers using Windows-compatible security technologies. And that those qualifications have been registered with the Microsoft partner program.

Click on the image to see our official blurb on the Microsoft partner page.

Permalink | Comments (0)
« Older PostsNewer Posts »