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.
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 "firstname.lastname@example.org". 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.
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 email@example.com and firstname.lastname@example.org.