SCCM v.Next hits Beta 1

And goes public too at the same time. (It showed up for downloads on 24. May, but I didn’t notice it the same day.)
Downloadable from https://connect.microsoft.com/ConfigurationManagervnext

I think it was about six months back that Microsoft disclosed that the roadmap for the SCMDM product would be a merge with SCCM in what has been codenamed v.Next. This would bring about the grand unified management console enabling you to manage both client computers, servers, and mobile devices from the same place. I’m having mixed feelings about this, not because I enjoy having to relate to different interfaces for managing different devices, but because managing computers and mobile devices aren’t necessarily the same thing. That’s not to say there aren’t benefits to it though, and if it’s pulled off the right way it could make sense. This is a topic I could rant on about for hours though, so we’ll leave that discussion aside. Microsoft has made a strategic choice, and I will of course try to evaluate what is available in this build.

I don’t have hands-on experience with SMS/SCCM from before since I mainly deal with MDM solutions. Even given this the installation experience went pretty smoothly. Sure, there are some beta issues, but nothing you can’t solve easily (at least when it comes to installing it). I’m not going to cover the installation process, as I’m trying to focus on what you can do with v.Next, and the install process is sure to change before RTM.

Microsoft and Nokia have both stated that Symbian devices will be supported by System Center, but it is not known whether this will apply to the current Series 60 generation, or only to new (and unannounced) devices. iPhone and Android are unsurprisingly not supported at the time of writing, and from what I can tell it seems like only Windows Mobile 6.1 and 6.5 are supported for now. This probably isn’t a problem as far as having an introductory look.

In this post I’m only going through the interface, and commenting on a few of the features I can see. I have not done a deep dive in the available technical documentation, and this means I might get something wrong/incorrect/missing too :) I intend to do some actual testing of devices in the (hopefully) near future.

Enrollment
It seems the enrollment concept we saw in SCMDM is still present here. You need to fill in details like which OU to place device, which CA to use (you can easily choose), etc. The certificates you enroll are used by the device for authentication purposes, but not for establishing a VPN tunnel. The Mobile VPN feature is gone in v.Next, and last thing I heard it’s not clear if it will be re-introduced, and if so in what form.
image

After creating the enrollment policy you can create devices – either single devices or importing from a csv file:
image

App Distribution
The ability to distribute applications is naturally present. Most likely still based on the robust WSUS distribution engine underneath.
image

Configuration Items
Normally I refer to settings like Power-on-Password, device encryption, etc as security policies. In v.Next this is called “Configuration Items”. You’ll recognize most of these categories from Exchange (2007 & 2010), and SCMDM. Or other MDM solutions for Windows Mobile for that matter.
image

After checking the relevant categories you’ll be prompted for the specific settings. I’m thinking this might be more intuitive for new admins, but such things have a touch of personal preference so you might disagree. It’s nicely wizard-driven at least.
image

With policies implemented through Exchange there are some loopholes, and one can try to get around the policies. With SCCM we can have the devices report compliancy which would uncover such attempts.
image

You may check the operating systems you want to apply the settings to.
image

If the wizard configuration items aren’t enough you can also create custom settings; I’d say this is a nice and user-friendly way of setting registry keys (especially compared to having to build custom adm files in SCMDM):
image

You can also specify “Windows Mobile OMA URI”, but I’ll admit I’m not sure of how this URI should be formatted:
image

After you have created a couple of different policies, and perhaps an app or two, you can group it together as a baseline to apply to devices.
image

There’s obviously an inventory view as well, but since I haven’t enrolled any devices there wasn’t all that much info present in it :)

For a beta I’m very happy with the responsiveness in the UI, and I’m not seeing many hiccups in the UI either. I don’t see any fantastic new features at the moment compared to what SCMDM has to offer, but it’s a slightly different mindset required for administration (if you’re used to SCCM already I’m guessing it’s familiar stuff already). Of course, it’s not impossible for new features to surface as we progress through the beta builds.

This was a sort of “quick and dirty” article, but I wanted to get some initial impressions out there as quickly as possible. More testing and evaluation will be performed once I’ve verified the base deployment is working, and I’ve had time to read through some white papers.

Securing Exchange ActiveSync with Client Certificates – WAN Access

Hopefully you managed to get yourself started with client certificates in the last post, or maybe this was something you had already sorted out in your own lab without any assistance of mine. The thing is, an ActiveSync configuration that only works over the LAN isn’t all that worthwhile is it? You’ll want to make it work across them Intertubes as well don’t you?

Now granted, this does not have to be complicated as such. If you have gotten it working directly on your Exchange and you’re piping the traffic through a regular firewall which just happens to do a port forward on the incoming traffic it doesn’t require much effort (just forward the port and let Exchange handle the rest). I don’t know about you though, but I prefer some kind of reverse proxy in between that inspects the traffic and authenticates the connection before passing it through to the back-end server. Perhaps not entirely unsurprising I have chosen Microsoft ForeFront Threat Management Gateway 2010 (the artist formerly known as ISA Server) for this purpose in my infrastructure. Let’s try to build on what we have already done, and create some firewall rules that will make this work.

The three-headed dog
When you authenticate yourself to ForeFront with username and password the firewall is able to read your actual credentials, and after checking these to be good with Active Directory they are passed along to the Exchange Server. So as far as Exchange is concerned it’s just like you authenticated directly to Exchange. But client certificates do not work this way. TMG is not able to pass along the certificate and present it directly to Exchange. This is a desired design that improves the security of the credentials. So how does TMG pass along your identity? This is where Kerberos enters the stage. You can read all the details in the TechNet Library if you want to understand the protocol (multiple readings might be necessary) – take a look here:
http://technet.microsoft.com/en-us/library/cc995228.aspx

The short take of it is that we need to configure Kerberos Constrained Delegation (KCD) for this to work, and there are some additional things you need to do before creating the firewall rules. Keep in mind that this requires your TMG Server to be joined to the same domain as the Exchange Server. (And from what I can tell based on my testing they need to be in the same AD site/subnet as well.)

Configuring Active Directory
First order of the day is to open up “Active Directory Users and Computers” on your Domain Controller (or your workstation if you have remote tools installed). Locate the object for your ForeFront TMG Server. (Do not touch the Exchange Server account.) Go to the “Delegation” tab of the properties. Configure it as shown below (look up the “Service Type” and “Computer” account by clicking the “Add” button):
image
In case you’re wondering I have intentionally blanked out the “User or Computer” column in my screenshot :) The computer account you need to add is the Exchange Server hosting the CAS role.

The service type is supposed to be http even though we are using https – it is not a bug or typo. (SSL is something you layer on top of http, it’s not an entirely different protocol.)

Configuring Exchange
If you followed my previous article you might have “Basic Authentication” enabled under the Authentication options for the Microsoft-Server-ActiveSync virtual directory. (Client certificates is enabled in a different config view shown in the next paragraph.) But this will not get you very far with Kerberos. The concept with Kerberos is that Active Directory grants the “tickets” to TMG, which are passed along to the Exchange Server, and thus you will need to enable “Windows Authentication” as well. (Actually you can disable Basic if you like, but maybe you like to keep it for other purposes.)

IIS Manager
image

Basic and Windows are enabled.
image

To accept or require…let me see…
In my previous post I briefly mentioned that you could have the SSL settings set to either Accept or Require certificates. The client certificate from the ActiveSync device will be passed along as a Kerberos ticket, and will work even if you set it to “Ignore” on the Exchange Server. The effect of setting it to require here is that the TMG Server will have to present a client certificate in addition to the Kerberos ticket. You can mull it over what you prefer – I’ll get back to the TMG settings affected later on down this page.

Locate “SSL Settings” in IIS Manager
image

Set to Ignore/Accept/Require.
image

Creating a Web Listener
You have now laid the foundations in your infrastructure for creating the necessary firewall rules so you may now switch to your ForeFront TMG console.

Now, you can run through the Web Publishing Wizard and create the Web Listener as part of this process, but I think it’s more clean to create the listener before creating the publishing rule. The important screenshots are shown below (I’ve created a listener called “HTTP / HTTPS” through the Wizard already):
Connections
HTTP should not be checked/enabled.
image

Authentication
Select “SSL Client Certificate Authentication”, and if you like you can check “Use a fallback authentication method” if you have some devices that do not support certificates.
image

Authentication->Advanced
image

You would think that you need to check “Require SSL client certificate”, but this only applies when using Forms-Based Authentication (which is not supported by ActiveSync).
You would also need to configure the correct server certificate on the “Certificates” tab. In the “Advanced” dialog you would most likely (after testing things working) change the “Client Certificate Trust List” to only trust certificates issued by your CA.

Creating a publishing rule
After you’ve got the listener configured we move on to creating the actual publishing rule. You can use the Web Publishing Wizard, but choosing “Publish Exchange Web Client Access” will make it slightly easier for you.

image

Pick any name that suits your rule naming scheme.
image

Choose your Exchange Server version (I’ve only tested with Exchange 2010), and select only “Exchange ActiveSync”.
image


image

Remember that you must use SSL for this specific scenario.
image

Type the internal host name, and while it’s optional to specify an IP address I recommend it. (Ensures you’re not getting irritating SSL errors when bridging the traffic if there some mismatch in DNS names and certificate names.)
image

image

Select the Web Listener we just created. Should not be necessary to edit the properties.
image

Select “Kerberos constrained delegation”. The SPN should already be filled in (based on the internal name you specified earlier in the wizard). It’s important that this matches up with the SPN you specified in Active Directory. Depending on how your AD and DNS is configured you might have to use the full FQDN instead of just the short name. (Short name worked for me, but keep it in mind if you’re having problems getting it working.)
image

image

image

Using Client Certificates for the Bridging
If you specified “Required” on your ActiveSync virtual directory you have to edit the rule you just created to accommodate this. If you set it to “Ignore” or “Accept” you can skip this step.

For this to work you need a certificate installed on your TMG Server. But it should not be in the Computer store that other rules require. You need to import it into the Firewall Service certificate store. You just need a plain Computer certificate with the FQDN as subject name.

Import into this store:
image

Next you should go to the “Bridging” tab of your publishing rule. Check “Use a certificate to authenticate to the SSL Web server”, and select the certificate you imported in the previous step.
image

Hit “Apply” in your TMG console, and fire up either a device, or my EAS MD utility to test. Hopefully things work at this point, but if you’re unlucky you might run into some error. When I tested I experienced 401/403 which means authentication failed – if so double check all the settings. I also saw a 408 timeout error, and this usually implies something is failing in the Kerberos delegation.

When googling Kerberos errors you might run into tips suggesting you should use the SetSPN tool. While this is a perfectly ok tool it is not required for this scenario, and if you do use it remember to clean up the mess it leaves. While using the ADUC interface for editing will automatically update the relevant info in AD there is no automagic involved with SetSPN. The odds are that you will mess around, try a couple of different settings, and forget to remove the incorrect ones. Using the AD GUI is much better.

Depending on how you view things you might consider us to be finished now, or almost there. When authenticating directly to the Exchange Server we saw that by enabling and disabling basic authentication we could control whether the device needed to supply both a client certificate and a username/password, or just the certificate. How to achieve this in our current setup? Well, the thing is that a publishing rule will only let you specify one authentication type. (Fallback mechanism is only invoked when the primary mechanism fails.) And to set up multiple authentication methods on TMG you need to create multiple web listeners, which in turn requires multiple external IP addresses. When you’re not using certificates it is possible through some “hackish” approaches to have multiple authentications. With certificates you still have the problem of passing along the certificate. I have only looked briefly at this, and not had any success getting it working. (It could be something obvious for all I know.)

So, do we call “bad design” on this one? Well, it’s not a straight answer to this question. If you are enjoying the benefit of not having to enter passwords on the device you’ve achieved that goal. If you insist that things are more secure using both means…Well… The thing to consider as well is how easy it is for users to enroll certificates. Do they need to perform any special means for enrolling or can they just enroll on the desktop, export as a pfx file and transfer to any device? And what about the device handling the certificates? With Windows Mobile you need to import the certificate into the private store where it is tamper-proof and non-exportable. Think through the entire scenario, not just the TMG rules, and evaluate what’s right for you.

I learned a lot jumping through all the necessary hoops to get this working, and I hope you found it to be of some value. Let me know if something is missing from this quick two-part guide.

Securing Exchange ActiveSync with Client Certificates – LAN Access

Certificates is not only a recurring theme on this site, it’s also a recurring pain point from what I hear. Getting it working is just down right confusing sometimes. With this in mind I thought I’d walk us through a scenario where you want to secure your Exchange ActiveSync deployment with the use of client certificates.

Ok, I said “a scenario”, but it might be more correct to say “a couple of scenarios” because there are a couple of design choices you can make. But let’s set the stage before we proceed – why are we even discussing certificates in the first place? What are they good for?

Let’s be honest – you will save yourself a lot of work and hassle if you go for the good old username & password combo. But through using certificates you can achieve other goals which might not be met the same way without taking the route of yet more complex configurations:
- Security
- User friendliness

Yes, these are normally two conflicting goals – I know :) Security can be beefed up with certificates as a means of adding an extra factor to the authentication process, as something you need in addition to a password. User friendliness can be improved upon by removing the need for users typing in complex passwords every couple of weeks on their mobile device.

With that in mind let’s see what we can do to get this train rolling. Oh, yes, one more word of advice; since we are dealing with mobile devices do not hit the implement switch before you have checked out if there are any devices that are not able to handle it. Windows Mobile devices are ok, iPhones are ok, possibly Symbian too. Don’t know about Android (it would be specific to the ActiveSync client used since it’s not provided by the OS). “Feature phones”, also known colloquially as “dumbphones” are probably out of the loop.

I assume that you have already installed an Exchange Server with the Client Access Server role functioning before following along here. I am using Exchange Server 2010 RTM on Windows Server 2008 R2, and ForeFront TMG 2010 as a firewall/reverse proxy. Exchange 2007 might be slightly different on some points, but pretty similar. Which OS you’re running matters because part of the functionality is provided by the OS, so if you’re running on Windows Server 2003 things will also differ from what I do on my servers.

We’ll start out enabling client certificate authentication directly on the Exchange server assuming for the sake of the test that all mobile devices connect via the LAN :) In the Exchange Management Console go to
Server Configuration->Client Access->Exchange ActiveSync.
Your properties might look like this:
image

You’ll want to switch this to “Require client certificates” like so:
 image

Note that we have unchecked “Basic authentication” as well.
As it says in the dialog box you need to configure SSL itself through the IIS manager. Often when I test and debug in my lab I disable SSL and run it through plain HTTP. This will not work if you want to use client certificates, and you should require SSL. (If you haven’t messed around with this setting the defaults after installing Exchange 2010 are already configured to require SSL.)

Actually you could change the client certificate requirement in IIS too:
image

And as long as we have the IIS console open. How about we configure the certificate mapping at the same time? Mapping what you say? While having a certificate is a nice thing in itself how does Exchange verify if your certificate is good? If someone presented you with a hand-written post-it note with a doodled self portrait and “driver’s license” written along the top would you trust it? Wouldn’t you rather have the laminated, (or credit card version), with some official looking logos and stamps? We need to define where Exchange should perform the lookup for verifying that your certificate is good, and this we call mapping the certificate. Rather than explain the process in detail I’ll refer you to this link for the necessary steps:
http://www.iis.net/ConfigReference/…/…/…/clientCertificateMappingAuthentication

Short version – install the “Client Certificate Mapping Authentication” role service, and enable it to have Exchange use Active Directory as the source for certificate verification.

Since we haven’t gotten to the part of enrolling certificates on devices yet you can use my ActiveSync “emulator” if you’d like to test at this point – http://mobilitydojo.net/downloads
image

If all is good you should be able to run a “Basic Connectivity Test” even without specifying a password. (You need to provide the username as that’s used for other purposes behind the scenes.) The .cer file I’m using is a certificate I have enrolled through AD directly to the “Personal” store on my development box, and exported to a file without a private key.

Now, back to that “Basic authentication” bit again. I said there might be different scenarios to choose from, and technically you don’t have to uncheck the box like I did. You have three possible combinations of client certificates and basic authentication;
- Basic authentication enabled, ignore/accept client certificates. This is the default. Will let you synchronize as long as you provide a valid username and password.
- Basic authentication disabled, require client certificate. Will let you synchronize as long as you provide a valid certificate.
- Basic authentication enabled, require client certificate. Will let you synchronize provided you supply both a valid certificate, and a username & password combo.

You can test out all combos with a device, and/or my utility, but I’m getting differing results testing in a browser. (Which is not the recommended way to test EAS anyways.) Pick your poison as to whether you’d like to use a real device or my utility but at this point it’s easier to ignore real devices and get back to those later. What this means is that whether you enable or disable basic authentication, (in addition to requiring certificates of course), dictates whether you require one or two factors for authenticating the users. You’ll see the 401 and 403 error codes when testing if you don’t get the authentication right.

I guess we’re doing fine so far aren’t we? But so far we have concerned ourselves with the easy part of the equation. Play around with the settings and see if you can make it work, and in the next installment I’ll have a crack at making it all work from outside your LAN :)

RSS for Posts RSS for Comments