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


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. Please do not rely on this post as documentation for how to configure this.

 

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:

  1. 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.
  2. 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
  3. 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.
  4. 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 

 

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.

 

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.

 

Comments (9)

  1. jason.jones@silversands.co.uk says:

    Hi Andy,

    I have been looking at how to secure IBCM with ISA Server for quite some time now and quite a lot of lab work, have come to a similar setup as yours. I was never really comfortable with using server publishing in ISA for obvious reasons. Server pubs is a pretty easy config to get up and running, just need to ensure the certificate SAN names are correct for dual intranet/internet MPs.

    I have used a similar solution in terms of ISA config, but have used an alternate solution to certificate mapping.

    The way I have achieved this is to create the client certificates for IBCM clients with a subject name of computername$@addomain.com and then created computer accounts in AD to represent these external clients. This way you don’t need to have the actual .cer files, and you can manage clients on an individual basis – e.g. you could disable just one  client and ISA would then fail the authentication request as AD would respond accrodingly. The other benefit is that you can group the machine acocutns into a "IBCM Internet Machines" group whcih can then be assinged to the ISA publishing rule to make the configuration nice and specific.

    Using computer accounts seems more logical with SCCM to me as we are talking about client machines rather than users. This approach also negates the need to configure certificate mapping within IIS. The only down side is that you will need to create a "fake" computer account for every external client, which isn’t that scalable I guess. But importing individual .cer files is also pretty painful 🙂

    I had not thought of using user based mapping, so may give this a go in our lab to see if it has benefits over my current approach – thoughts?? Have I missed something obvious here you know about?

    Thanks for your post, as I have been really struggling to find anyone who has this working in practice as most people seem to "fallback" to server publishing as bridging seemed just too hard. Personally, I like to get ISA working a little harder than that! 🙂

    Cheers

    JJ

  2. jason.jones@silversands.co.uk says:

    Sorry, for the "Andy" reference Adam, it has been a long week! 🙂

  3. Adam Meltzer says:

    The computer account approach you’ve mentioned is actually really interesting — it’s not one that I thought of.

    I actually think the computer approach you’re taking may be easier to automate and deal with rather than the user approach. However, you’ll probably want those clients use a certificate selection criteria to make sure that other certificates don’t end up orphaning the client. I think this approach may be a lot easier to manage because it requires fewer steps.

    I’m not a security expert, so I am not sure if there would be any downside or increased security risk to this approach. However, if you’re really extremely paranoid about security, you’d probably be using CTLs anyway. As far as scalability, it certainly doesn’t sound any /less/ scalable. 🙂

    Thanks for posting this suggestion, it sounds like a great alternate approach and one I’ll experiment with in my labs!

  4. jason.jones@silversands.co.uk says:

    Hi Adam,

    Must admit, I can’t take full crediti for the UPN idea as that was suggested by Jim Harrison who has been helping me with the ISA config. Be interested to see how you get on with my approach, please feedback…

    Yeah, I plan to configure ISA to be specific about the CA that is allows, also you could include some form of custom OID (or other attribute) and then get ISA to check this too…as you probs know, there are quite a few "rules" you can define for SSL client cert auth in ISA.

    The thing I like if being able to disable individual machine accounts in AD as opposed to using the blocking feature in SCCM. I know you can revoke the cert, but disabling the account is instant and no CRL latency.

    Cheers

    JJ

  5. Adam Meltzer says:

    I’m just curious why you prefer the AD blocking as opposed to blocking the client through the ConfigMgr console? Blocking through the ConfigMgr console is also basically instantaneous (in native mode, at least) and you have a bit more auditing.

    I’ll update with more info once I get a chance to try that method.

  6. jason.jones@silversands.co.uk says:

    Blocking in AD just seems more natural to me in the same way you would disable a user account, no better reason that that…I’m also not an SCCM guy, so not really sure how blocking works 😉 Not really fussed either way…

  7. In case you are doing Internet Based Client Management (IBCM), Adam has a great article on configuring

  8. Gabe Brown says:

    If 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.

  9. After my original post on configuring ISA bridging with ConfigMgr 2007, I’ve had several conversations

Skip to main content