Adam Meltzer's Configuration Manager Blog : native mode

Firewalls and Internet Based Client Management: Part 2: ISA Bridging with ConfigMgr 2007 (Take Two)

ameltzer — Wed, 14 May 2008 18:46:00 GMT

IMPORTANT: This post is being kept for archival purposes, but please reference http://technet.microsoft.com/en-us/library/cc707697(TechNet.10).aspx for official documentation on how to get this configured.

After my original post on configuring ISA bridging with ConfigMgr 2007, I've had several conversations with both the ISA team and customers and have been able to work out a different way to configure bridging with ConfigMgr 2007. This is still a complicated solution with some overhead, but I think that folks will find this much more palatable than the original solution.

Pre-Requisites

Here's what you'll need in advance to any further ISA configuration:

A Microsoft Enterprise CA. I have not been able to get this to work with a Standalone CA and don't know if this is possible. I'd love to be proven wrong, though.
A web server certificate on the ISA server. If you're using a single Internet MP, the subject name or subject alternate name(s) in this certificate has to match what you're using in the ConfigMgr console for the external FQDN. For the purposes of this post, I performed this configuration with a single MP/DP combination. If you're using multiple MPs and DPs for IBCM, you'll have to have multiple subject alternate names in the certificate adding additional complexity to the rules. ISA 2006 supports multiple subject alternate names (with caveats), ISA 2004 doesn't support this at all.
A client certificate on the ISA server, this certificate needs to be in the Personal store for the Microsoft Firewall service account (fwsrv). This certificate is used by ISA to authenticate itself with the management point when bridging the SSL connections
Your ISA server needs to be domain joined because it needs a means to authenticate ConfigMgr client certificates. It can be joined to a private domain in the DMZ, it does not have to be a corporate domain.

CA Configuration Specifics

I cloned the Authenticated Session template and created a new one. For the purposes of this example, I called it "IBCM Client Authentication". In the Request Handling tab for the template, I have "Allow private key to be exported" checked, and "Enroll subject without requiring any user input checked." I don't know if these are required or not. In the Subject Name tab, I have "Supply in the request" selected as we will need to specify custom certificate names. For "Extensions" make sure that "Application Policies" has "Client Authentication" as the only policy.

Client Configuration Specifics

Clients will need to have client authentication certificates using the "IBCM Client Authentication" template. The subject name format has to be "machinename$@addomainfqdn". The AD domain FQDN has to be the same AD domain as the ISA server. The machine name has to be a Computer in the AD site that ISA is joined to. For my proof of concept, I put these machines into a special group that wasn't Domain Computers. The client computer itself does not have to be joined to the domain, and in fact, I did my proof of concept with workgroup clients. There just has to be a computer account in AD that maches machinename in the certificate.

Sample configuration: AD domain is "contoso.com", client machine name is "myclient". Certificate subject has to be "myclient$@contoso.com". MYCLIENT has to be a Computer account in AD. You absolutely have to provision this certificate from the template that extends Authenticated Session or else this won't work, and this is why I couldn't get this to work with a Standalone CA.

ISA Configuration Specifics

When configuring the web listener for the server publishing rule on the ISA server, you'll need to use a certificate for that listener to connect back to the management point. This is the certificate I mentioned in #1 above. For the listener, you'll need to choose "SSL Client Certificate Authentication" and have it point to Active Directory. Unfortunately, this will end up adding complexity to the configuration, but this is absolutely necessary for security! I'll talk more about why later. For authentication delegation, you'll want to use "No delegation, but client may authenticate directly" (I believe this is only needed in ISA 2006, not 2004).

If you want to restrict the paths that the rule will respond to, you'll need at minimum /sms_mp/*, /ccm_incoming/*, /ccm_outgoing/*, and /ccm_system/*. Other features (software update points, for example) may require additional paths. It's important to note that fallback status points (FSPs) do not use SSL, so you'll need to have the rule accept non-SSL requests, or set up a separate server publishing rule for your FSP. If you're using a FSP, you'll need to also allow /sms_fsp/*.

For the properties of the actual bridging rule, you'll want to go to the "Bridging" tab, and select "Use a certificate to authenticate to the SSL Web server." For this certificate, you'll want to use the client certificate mentioned in #2 above. The server publishing wizard doesn't do this for you, so this will require an additional manual step after running the wizard.

Summary

While this isn't a "simple" solution, it has considerably less overhead and complexity than the original certificate mapping-based solution. Instead of having to gather the certificates, and bind them to an AD user account using certificate mapping. All you need to do is create a specifically formatted certificate, and make sure it maps to a computer account in AD. I've done a couple of successful lab deployments with this so far and have been happy with the results. Please let me know if you have any questions or other comments and I'll be happy to try to address them.

If after reading this and you still have questions, you can request documentation from the ISA Server team. Please send an e-mail jointly to isadocs@microsoft.com and smsdocs@microsoft.com.

Common native mode client -> MP error messages and what to do about them

ameltzer — Mon, 14 Apr 2008 20:20:00 GMT

Often times, basic communication issues can happen between the client and MP and they can be hard to decipher from logging alone. The error class I'll concentrate on here are the "WINHTTP_STATUS_CALLBACK" errors that may appear in the ccmexec.log on the client. These errors are bubbled up from WinHTTP and the MSDN documentation can be found here. However, only a few of these are relevant to ConfigMgr, and I'll cover a few of these here.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED

This error happens when CRL checking is enabled on the client, but the CRL cannot be accessed. The CRL (certificate revocation list) is what the client downloads in order to verify that the certificate for the MP, DP, or other SSL-capable site role hasn't been revoked by the administrator. When this isn't accessible, the client is blocked from communicating until it can download this list (a better safe than sorry approach). The ways to fix this are: make CRLs available to the client (could be challenging for Internet clients); publish additional CRLs that the client can access (this will require publishing new certificates to SSL site roles since CRLs are stamped in the certificates themselves; turn off CRL checking on clients. This is an infrastructure error.

WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA

This error means that the root or intermediate certificate for the CA that issued the certificate for the MP, DP, or other SSL-capable site role isn't in the client's Local Computer Trusted x Certification Authorities store. The way to fix this is to import the root or intermediate certificate into the appropriate store for the local computer (not the user). This is a deployment error.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID

This means that the hostname the client is connecting to doesn't match the certificate's subject or subject alternate name. I.e., the client is connecting to https://myhost.contoso.com, but the certificate has https://myotherhost.contoso.com. The way to fix this is to change the FQDN the client uses in the ConfigMgr console or to create a new certificate with the correct subject name. This is a certificate error.

These are by far the most common errors you'll see with SSL communication on a native mode client. I hope this has provided some insight into what those errors mean and how to fix them!

Update: A "friendly" way to validate the certificate on the MP is to do what I call the browser test. That's to point your browser to https://yourmp and see if any certificate errors are returned. If your browser returns errors, the client most certainly will as well, but the browser provides a somewhat friendlier (and quicker) way to troubleshoot those issues.

Firewalls and Internet Based Client Management: Part 2: ISA Bridging with ConfigMgr 2007

ameltzer — Thu, 14 Feb 2008 23:21:00 GMT

Update #1: Please see the comments below this post. Jason Jones suggested a method that may work better than the one I described. I haven't tested it out yet, but I'll update this post when I do.

Update #2: GabeB has noted in the comments below, "[i]f you have read the blog entries and still have questions on setup, you can request documentation from the ISA Server team for how to configure ISA with Internet-based site systems in Configuration Manager 2007, send an email jointly to isadocs@microsoft.com and smsdocs@microsoft.com." I also will have some more posts coming up about this hot topic.

I was going to save this for last, but there's been a lot of questions lately about this that I've been fielding, including a pointed interest from attendees at TechReady 6 about ISA bridging. This is not a meant to be a step-by-step guide, and will require a bit of familiarity with ISA, but the information provided here should be adequate to help you get ISA bridging working with ConfigMgr. This was written with ISA 2006 in mind, but most of this applies to 2004 as well. The UI is a little different, but the same principles apply.

Pre-Requisites

Here's what you'll need in advance to any further ISA configuration:

A web server certificate on the ISA server. If you're using a single Internet MP, the subject name or subject alternate name(s) in this certificate has to match what you're using in the ConfigMgr console for the external FQDN. For the purposes of this post, I performed this configuration with a single MP/DP combination. If you're using multiple MPs and DPs for IBCM, you'll have to have multiple subject alternate names in the certificate adding additional complexity to the rules. ISA 2006 supports multiple subject alternate names (with caveats), ISA 2004 doesn't support this at all.
A client certificate on the ISA server, this certificate needs to be in the Personal store for the Microsoft Firewall service account (fwsrv). This certificate is used by ISA to authenticate itself with the management point when bridging the SSL connections
Your ISA server needs to be domain joined because it needs a means to authenticate ConfigMgr client certificates. It can be joined to a private domain in the DMZ, it does not have to be a corporate domain. You'll also need access to make changes to user accounts on this domain. I'll talk more about why this is needed later.
You'll need some way to access the client's certificates' public key (private key is not necessary). This is related to step 3, and one I'll go more into depth later.

ISA Configuration Specifics

These steps should be all you need to configure ISA for bridging. But, it's not enough to have your clients communicating using native mode. Because of the SSL Client Certificate Authentication, you'll have additional maintenance overhead. The overhead is that you'll have to bind these certificates to an account in Active Directory. For my proof of concept, I created a unique user account called "IBCM Users" and mapped the public key of the client certificates used for my site to that account. To do this, in the Active Directory Users and Computers console on your domain controller, go to the View menu and enable "Advanced Features". Now you can add certificates to this account by either right clicking on the account and choosing "Name Mappings", or going to the properties and going to the "Published Certificates" tab to add the certificates. One way you can get the client certificates themselves is to export them from the CA server itself. I'm not aware of end-to-end ways to automate this at the moment, so if anybody knows of a good way to do this, I'd be interested in hearing it.

After doing this step, clients will be able to mutually authenticate with the ISA server, which in turn will be able to mutually authenticate with the management point giving you a secured end to end communication with traffic inspection and all of the benefits that come with ISA bridging.

Why is this so complicated?

I mentioned earlier that you have to use SSL Client Certificate Authentication when configuring the web listener. If you don't do this, clients will appear to function properly, but you're missing out on one of the key benefits of native mode, and that's your connection is mutually authenticated. By skipping these steps, clients won't know the difference since they don't care if they are authenticated or not, they just care if they can talk to the MP. However, by skipping this step, you're encrypting your communications over SSL and not authenticating any of those connections. This means that along with clients, anybody else can talk to your ConfigMgr IBCM infrastructure from the Internet. That's obviously a Bad Thing.

The other area of complexity is that the ConfigMgr client uses machine certificates for authentication, not user certificates. One reason for this is because we think of clients as machine entities and need to be able to manage clients regardless of if a user is logged in or not. Unfortunately at this time there's no way to glue the user and machine pieces together, so that's why there's this necessary out of band process for having to publish those machine certificates into an account in Active Directory rather than just using a user certificate.

So what do I do?

Most of the certificate process could probably be automated. There's ways to export the certificates' public keys from the CA, and there's ways to bind those certificates to accounts in AD using LDAP for example. I haven't cobbled together an end to end solution, but I'm sure it's possible. Another option is to use SSL tunneling. You won't get traffic inspection, but you'll get a much simpler configuration. It's a trade off of highest security or lowest complexity.

Hopefully this has brought to light some of the complexities around using ISA bridging with ConfigMgr, and some ways to get things working. Please post in the comments if you have any questions or additional points to add.

TechReady 6 Configuration Manager 2007 PKI labs

ameltzer — Mon, 11 Feb 2008 02:31:00 GMT

I'll be proctoring the "Configuring Configuration Manager 2007 Security including PKI" labs this coming Wednesday. I'll be at both the 1:15PM and 3:00PM sessions. I'll do a write-up here afterward going over some of the common problems that were brought up during the labs and will try to provide some solutions. Chances are if someone's hitting them in the lab, there will be people running into them in the "real world." If you're attending either of those sessions, feel free to come and say hi to me. :)