Adam Meltzer's Configuration Manager Blog : ibcm

FAQ: How do I configure a certificate to use multiple subject names?

ameltzer — Wed, 27 Feb 2008 00:57:00 GMT

Update: I've attached a sample .INF file to this posting.

It's a pretty commonly asked question. People want to use different subject names on the Internet and intranet for their MPs. This isn't hard to do, and it requires something called a Subject Alternative Name, often abbreviated as SAN. The SAN can contain multiple alternate names. The SAN will take precedent over the common name (CN), or the regular subject name for a certificate. This is important because it means that if you have "hostnameA" in the CN, and "hostnameB" in the SAN, "hostnameA" will cause a CN mismatch. You will have to have a SAN for "hostnameA" and "hostnameB" for both to work.

To request certificates with SANs, you have to first configure your CA to support them. On Microsoft CAs, SAN support is not enabled for general requests by default. To enable this, run the following command on your CA server: certutil.exe -setreg policy\editflags +EDITF_ATTRIBUTESUBJECTALTNAME2

You MUST restart Certificate Services after doing this.

Now that the CA is configured to support SANs, you need to specially craft your request to use them. If going through web enrollment, you can add a custom attribute in the last section. To specify a SAN of "hostnameA" and "hostnameB", you would use the following syntax: SAN:dns=hostnameA&dns=hostnameB

Each SAN argument is ampersand separated. This should issue a certificate that will have a "Subject Alternative Name" section under Details. You can verify this by using the browser test by going to each https URL and ensuring that you don't get any certificate errors.

If you're using an .INF file to request certificates from a CA, the syntax is slightly different. You'll need to add a [RequestAttributes] section, and then use the syntax of: SAN="dns=hostnameA&hostnameB"

Hopefully this will be enough to help provide some basic knowledge on how to configure SAN support on the CA and in certificates.

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

ameltzer — Thu, 14 Feb 2008 23:21: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.

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

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.

Lessons Learned from TechReady 6

ameltzer — Thu, 14 Feb 2008 19:55:00 GMT

I proctored two labs yesterday around migrating sites from mixed mode to native mode. I talked to a lot of people and tried to answer a lot of questions. There were a few common threads, which I will elaborate here because I found them interesting.

Native mode is hard

Native mode setup is something I pretty much take for granted. I've been setting up native mode sites since June of 2006, so it's all pretty much second nature to me. The certificate authority setup and requirements, provisioning certificates, and so on. But, seeing people struggling through the labs brought me back to reality. Native mode has a lot of dependencies and complicated configuration steps required outside of the product for it to work. Unfortunately, there's not a lot we as a product team can do around that. One of the decisions we made was to be agnostic to PKI environments. We just use the certificates that we are given (provided they are in our basic set of parameters). One of the reasons this was done was because in the "real world", most companies would have completely separate people as their "SMS guy" and "PKI guy", so the "SMS guy" would give his or her requirements to the "PKI guy", who in turn would provide the requisite certificates.

People are really interested in Internet Based Client Management

I'd say 80% of the questions that were asked of me were about Internet Based Client Management. Things such as basic requirements, different modes, how it works in big hierarchies, and most of all, ISA configuration. I think a lot more people are interested in IBCM than we may have originally estimated, and there's a lot of questions about it. I pretty much figured this was the case given how the forums have been lighting up with questions around it, but hearing it from people out in the field further validates that.

ISA setup with ConfigMgr was a very hot topic. I'm going to prioritize my postings here to make my next post specifically on ISA bridging as that was definitely up in there as a "most asked" class of questions.

Overall, it was a great experience going to TechReady and talking with people out in the field. It's always great working with customers, and those who work with customers, and I hope in my future postings here, I can answer some of the common questions people have had about native mode and IBCM.

Firewalls and Internet Based Client Management: Part 1

ameltzer — Fri, 01 Feb 2008 20:12:00 GMT

Let's jump right in to one of the most complicated, and frankly, confusing aspects about Internet Based Client Management (IBCM), and that's how to use it with firewalls. I'm going to focus on its use with ISA server, because that's what I have the most experience using. Because IBCM requires native mode, and this requires SSL, it presents some interesting challenges and configurations required for firewalls.

When creating the necessary server rules for IBCM using ISA, there's two options: SSL bridging (sometimes called SSL termination or server publishing), or SSL tunneling. Both have their own strengths and weaknesses.

SSL Tunneling: tunneling is the most simple means of getting traffic through a firewall to your management point and distribution point from the Internet. In essence, it's simply brokering traffic from point A to point B. It is very fast as it's just passing bits around. However, you cannot perform any traffic inspection or use any advanced firewall features because all it's doing is shifting encrypted blobs around. It doesn't know or care about what's in the data, it just wants to move data.

SSL Bridging: bridging is the most complicated, but also the most secure means of getting traffic through a firewall to your management point and distribution point from the Internet. It requires a certificate on its end, and the client actually uses the SSL bridge as its "management point". The SSL bridge decrypts the traffic, performs any inspection on it, and then re-encrypts it with its own certificate, and passes it to the actual management point. This obviously can have a very large performance penalty as you're doubling the encryption and decryption required. This is also very complicated to set up since you have to double your certificates.

For comparison, here's a couple pictures I made a while back for a presentation that showed the comparitive differences between the two:

SSL tunneling:

SSL bridging:

Those images put into perspective what the different modes are doing and what they mean to IBCM.

In Part 2, I will discuss the finer points of actually configuring ISA for use with Configuration Manager with some sample configurations.