Heading over to http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/ you can see that there are a few things that aren’t perfect with how Apple implemented settings provisioning. The reason I’m mentioning it here is that not only did I find the article quite interesting, but I also took my time commenting the article, and thought I’d maybe elaborate some points further here.

Apple has not implemented provisioning and SCEP in a proper way – we can probably agree upon that right off the bat. I have not tested all the variations of signed/unsigned/verified/unverified/etc. When I tested provisioning a signed profile, from an unverified source (I signed with a certificate from my own CA, which is not in the trusted store), the profile did not install without also doing a SCEP enrollment to the CA. (So if you had malicious intent you’d also have to setup a CA.) The behavior might be slightly different with a trusted signer. But the attack itself with signing up for trial Verisign certificates has the classic elements of social engineering as the working element nonetheless. If your users blindly accept provisioning profiles you have a problem regardless of how/when Apple fixes their implementation.

While part of me wants to add this to the list “Why iPhones should not be used in the enterprise” that still does not satisfy all the customers/end-users/businesses screaming that they want to use the iPhone. I’m afraid it’s not a big enough showstopper to bring that to a halt. My recommendation would be to still evaluate using iPhones like the flaw didn’t exist. (Yes, you still have to consider the flaw, but it doesn’t detract from the functionality side of things.) You might still reject the iPhones based on other considerations, but that’s another discussion entirely.

The trust issue exists on other platforms too though. If I wanted to compromise a Windows Mobile I could send out an OMA CP message bootstrapping an OMA DM server, and if I put the name of the mobile operator in the “From” field I’m pretty sure I could fool a user or two into messing up their devices that way. Actually this would apply to other OMA DM devices too for that matter, not only Windows Mobile devices.

Symbian had an issue last year, (or was it the year before – I forget), where a malware publisher managed to get their application signed with a trusted root certificate. While I didn’t read a follow-up story detailing a major outbreak of the malware it certainly had potential to wreak havoc.

I don’t remember if it was on Windows XP, or Windows Vista, but in one of the yearly root CA updates Microsoft removed a bunch of CAs as it was way more than what would qualify as a handpicked list of especially trusted certificate authorities. So managing trust isn’t just a challenge in mobility.

I guess what I’m saying is that it’s “just yet another security flaw”. We see these every week on the desktop. We have procedures for handling them. The mobile devices are no different

And as much as I disapprove of some of Apple’s choices regarding functionality, vendor lock-in, etc they are doing the right thing by implementing provisioning for upping enterprise adoption rate. Let’s hope it’s a work in progress and that it does not stop here.

The quick recap first; SCEP is a protocol defined by Cisco for enrolling machine certificates. SCEP is implemented in Windows Server as Network Device Enrollment Service (NDES). iPhone uses SCEP for secure bootstrapping/provisioning, and maybe it could be relevant for other devices too.

As far as installation of the NDES role I would recommend the following white paper by MSFT:
http://www.microsoft.com/downloads/details.aspx?familyid=E11780DE-819F-40D7-8B8E-10845BC8D446&displaylang=en

Let’s get down to actually using it. SCEP is implemented as a dll file called mscep.dll which you can interact with through HTTP GET commands. There are a couple of different operations you can specify as the desired action. The first one is called “GetCACaps” which is used to retrieve what operations and behavior the server supports, but this operation is optional and as far as I can tell it is not implemented by Microsoft.

The next, which is supported, and not optional, is “GetCACert”. An example URL of this would be:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(You’ll notice I’ve attached a message parameter as well, but the message part of the URL can be any random text at this point.)

If doing this in a browser you’ll see a response in the form of a file called “mscep”. Save this as a p7b file, and you will have the entire certificate chain of the CA relating to NDES. If you have a single Root CA, and do a “next-next” install of the NDES role you will have three certificates in the chain; one for the Root CA, and two for the certificate request agents.

Before moving on to the next step, let’s take a quick de-tour looking at how this setup works on a high level:
You have three URLs that work in your browser
http://CA/certsrv/mscep & http://CA/certsrv/mscep/mscep.dll which will both give you the same html output:

http://CA/certsrv/mscep_admin which gives some info for the admin who enrolls the device:

And following this these are the steps involved in an enrollment:
- Device generates a key pair (public and private).
- Admin logs on to the admin page in his browser, and retrieves the password.
- Device generates a certificate signing request (CSR), and sends off to the SCEP/NDES server.
- NDES sends the request to the CA. (This can be on the same server.)
- A response is received by the device containing the actual certificate.

It does sound easy doesn’t it. You generate a request, and if you have it in the form of a file it will be a long Base64-string like this (I left out most lines of the string to make the screenshot smaller):

And you submit it to the NDES service through the browser:
http://CA/certsrv/mscep/mscep.dll?operation=PKIMessage&Message=MIID9Q=
I’ve left out most of the string here too, but it’s really just copy & paste everything from the CSR file except the first and last lines. You’ll once again get a file called “mscep” back, but it’s not going to work saving it as pfx, cer, etc.

Checking out the Event Viewer on the CA we see something similar to this:

Ah, but thing is, when I said generate a CSR above I left out a couple of the finer details. You see, you’re not able to just go through the certificate request process in IIS or the Certificates MMC. As the error indicates you aren’t getting all the details embedded that you need for a SCEP request. I found a neat tool called “ASN.1 Editor” (ASN is the format for CSR files), and thought I would be able to handcraft the request with this utility. Then it occurred to me that generating a valid key pair in my head, using it for signing, and inputting it in the request probably is well above my mental capabilities Nonetheless it is a useful utility if you’re generating CSRs and want to “debug” these. (If you have a certificate you already have on file, you can look at that too.)
Hit the link for download: http://lipingshare.com/Asn1Editor

This leaves us to the programmatic approach, and I’d love to have given you all some finished C# code as the next step. I ran into a couple of challenges while testing this though – the first being that support for crypto stuff is so-so in C#, barely present in Compact Framework, and dependent on the OS on the desktop side. Realistically you need to run it on Windows Server 2008/Vista or Windows 7. While I certainly have access to those platforms, and it is workable with some dll imports, it gave me a couple of pointers to where this had to be taken for building a proper solution, but not the solution itself. I initially thought that a client on Windows Mobile was feasible, but maybe it’s more work than it’s worth. You’d also have to go through all the same obstacles implementing it for the Android if that became a feature request, and you’d still have to adapt in some way if using it on the iPhone. (The iPhone already has native support courtesy of Apple Inc. mind you – I’ll get back to that.)

I’ll also admit that learning the crypto APIs required for this was more than I could chew through in an hour. I’ve managed to create a CSR programmatically and getting the same error as above, and I’ve managed to put together a request that crashes the program entirely when running. Basically I have to learn it proper if I want to get it working, and that’s probably an exercise better left for later on when I see a greater need for it. At the moment it’s more of a nice-to-have than need-to-have for what I do. (Man, I felt stupid trying to guess my way to something that would work.)

If you want the “algorithm” it works roughly like this:
Create a PKCS#10 request, wrap it in a PKCS#7 request with a couple of extra attributes (senderNonce, TransactionID, MessageType). Sign this with the public key from the certificate of the RA and submit.

If you want the gory details there’s no way to avoid reading the RFC:
http://tools.ietf.org/html/draft-nourse-scep-20
And this paper is also of great help:
http://www.gamingstandards.com/…/appendix_d_scep_operations.htm

So, let’s say for the sake of discussion that we have solved the coding issues – what would we do next? I’d probably start by removing one more obstacle on the server side. The default install of the NDES role on the CA will require you to use one-time passwords (remember the admin web page?). While this is a good secure by default implementation I find it slightly impractical  for our purposes, so let’s disable it. Navigate to regedit on your CA, and flip the following registry key to 0 (if it doesn’t exist create a DWORD value):
HKLM\Software\Microsoft\Cryptography\MSCEP\EnforcePassword\EnforcePassword

So, the iPhone works you say…How did I solve that since I didn’t see the coding through to the bitter end? Well, I resorted to “cheating” actually I installed the latest Feature Pack for an Afaria Server I’ve got running, since this adds iPhone support. The funny thing is that the technical approach I was evaluating was/is very similar to what Sybase have done. I’m not going into the details of the Sybase implementation as some elements are only relevant for the iPhone, and not SCEP enrollment in general, but it basically starts with an SMS sent to the device to trigger the enrollment process. The device generates a request, sends this to a provisioning server, and the server signs this request before passing it onto the CA. The iPhone picks up the generated certificate by talking to the CA directly though, and doesn’t do everything through the provisioning server. (I’m not entirely sure as to when the communication end-points are switched.)

What I’m thinking is that it should be possible to channel everything through a proxy web service so you don’t have to expose the CA directly to the Internet. (Yes, I am aware of a reverse proxy like ISA Server, but not published at all is even better.) This web service could also handle requests from both clients able to generate the actual request themselves, and clients who has to make do with a “light” request and have the server do the rest.

Eventually you should end up with a certificate on your device, and your CA will have it on record if you get it right:

Notice how the common name does not easily identify the device.

So, great, another certificate on the device. What to do with it? The iPhone uses it for signing of the provisioning profiles you send to it. You can lock down the iPhone with security policies – like enforcing Power-on-Password, removing YouTube/Camera/AppStore, and the user will not be able to remove it.

While I haven’t investigated it further I believe it should be possible to enforce restrictions like only allowing devices with the proper device certificate to access ActiveSync – while still allowing ActiveSync without the need for VPN tunnels and the like. Like so many other things – the technology is there and it’s up to you to find a use for it

I haven’t actually upgraded the forest and domain level to 2008 yet, as most services will run with 2003 levels. I haven’t gone the whole nine yards transitioning to IPv6 either for that matter. What I have been taking a closer look at is Certificate Services. It’s been one of those components that have just been working for a long time out of the box, but the feature list said there were a couple of new bits to take note of. I’d like to provide a minor update based on a few things I have learned so far about them

Network Device Enrollment Service
The first “new” feature is NDES. (I say “new” because it was available previously as an add-on, but now it’s a native component of the OS.) NDES stands for Network Device Enrollment Service, also known as MSCEP, which is the Microsoft implementation of Cisco’s Simple Certificate Enrollment Protocol. The purpose of SCEP is to be able to enroll certificates to Cisco equipment like routers and switches, but it is open for others to implement too. A common feature of network equipment is that you cannot always enroll certificates the same way you do with a desktop or server – often the component cannot access the CA directly through a graphical user interface, and since you don’t like moving private keys around you don’t want to be copying pfx files around either you need a different enrollment mechanism. So basically, you “assist” the device by creating a sort of pre-enrollment request, and let the rest work itself out automagically. (Of course this is over-simplifying, but hopefully you understand what I’m getting at.)

How nice, but why are you telling us this? Do we care about Cisco in this context? No, possibly not, but we do care about the iPhone. And while it’s still a love/hate thing for many IT people the iPhone is unavoidable in more and more enterprises. As much Steve Jobs possibly classifies as a megalomaniac, the man understands that to progress further with this device in the enterprise, Apple needs to add enterprise features. The 3GS sports encryption, and the latest incarnation of the OS also supports client certificate based ActiveSync and all sorts of things. And even better, they’re taking steps towards manageability providing options for bootstrapping devices through the iPhone Configuration Utility. For a single-user scenario this tool works nicely, but you don’t want to use this en masse for deploying a large number of devices. And you don’t have too – you can create xml that can be send over-the-air much like OMA DM on Nokia devices. Based on this Good Technology has support for the iPhone in their product, and Afaria from Sybase hopefully has support coming during December if there isn’t an unexpected showstopper.

The profile can be pushed as mandatory, so the user cannot uninstall it. To accomplish this the profile is signed/encrypted with a certificate, and – you guessed it. This certificate is enrolled via SCEP. Unfortunately I do not have any slick screenshots at the moment showing how this works, but do have a look at the docs from Apple to learn more:
http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

SCEP is implemented as an ISAPI plug-in in IIS, and you interface with it through HTTP POST/GET. If you want to test that it’s all working enter the following URL in your browser:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(The message part of the URL can be any random text at this point.)
You’ll be rewarded with a file called “mscep” that contains the certificate of the CA in a binary form.

To actually enroll for a certificate you need to prepare a request device side, and depending on the configuration you might need to acquire a one-time-password as well. I’m testing out how this works in a Windows Mobile context, (I don’t develop for the iPhone), so I haven’t worked out all the low level bits yet. Hoping to present something at a later time.

Certificate Enrollment Web Services
The other new feature in 2008 R2, that actually is new and not re-cycled, is Certificate Enrollment Web Services. While there’s been a web interface for enrolling certificates it has required ActiveX, needed the site to be trusted, notoriously difficult using programmatically, not really supporting mobile devices…well… a few shortcomings. But everybody loves Web Services, and it has been created to simplify enrollment from non domain-joined computers and other platforms than Windows/Internet Explorer.

While my own DojoCert utility does what it’s supposed to do there are things I’d like to see better implemented. Problem is I’ve been limited as to what I can do in C# and the .Net Compact Framework. The native C++ APIs could probably produce something, but these are also intended for enrolling via LAN/WLAN. I’m not going into all the technical details here and now, as my early experiments shows you need to perform some tweaking to use it on mobile devices. (Not there quite yet, unfortunately.)

How does it work then?
Do yourself a favor if you are interested in this topic – read the following white paper from Microsoft. Should help you out in installing it on your CA.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=28b910f8-6374-48dd-a897-11fff62ab795

The short version is – the client will ask the Enrollment Policy Web Service what templates are available, and what requirements these templates have. Based on this the client generates a certificate request, sends it off to the Enrollment Web Service, and a response is returned. Sounds ever so simple, I know, and provided I can get it working I believe it adds value as opposed to the simpler NDES scenario. (How simple it really is I do not know the extent of yet.)

NDES/SCEP are primarily intended for machine certificates, so in a scenario where you issue certificates to both devices and users you might decide to go for both, or just the web services.

I’m hard at work looking at both these two alternatives, and I hope to get something to work. Although you never know what kind of snags you run into. Will be posting more, if I find something worthwhile

Now, I am aware of a product called Office Communications Server, and vendors like Cisco with their software. That’s besides the point for now though Just like food, it tastes better when it’s home made. (Or rather you learn more making your own pizza than having it delivered.)

While browsing the Compact Framework API for something completely different I stumbled across easily accessible methods that will allow me to make calls programmatically. It’s really no effort as you can see from the few lines of code below.

In this case I’ve created a small console application (no graphical interface) that dials the number “1234”, but I could use a number supplied as an argument too for that matter.

Hey, this is nice for spying purposes! Well, no. It’s not placed as a “secret” call in the background. The user will notice that the device makes a call, or notice after the call has been made if it was in his pocket at the time.

It’s not a feature complete program at the moment. We’re missing a delivery system – I mean, we can’t have a program on the device without there being some desktop/server side mechanism of triggering the client. If you have an MDM solution that let you do push of management commands it could work. Or you could send an sms from the server, intercept the message, and trigger it. You could expand the client to listen to some server, and do something a bit like ActiveSync.

But isn’t this a light overkill when you could just pick up the phone and use the keypad directly? Well, the best thing after sliced bread it certainly is not, but it could make things more user friendly in some scenarios. Take for instance a phone list on the intranet – look up the number, hit “dial” and you’re off. Or if you’re sitting in front of the desktop most of the time, wearing a headset, and making calls while the device is somewhere else on the desk. (No function to hang up here though, so maybe you should still keep the device nearby.)

Anyways, some times I just come up with crazy ideas, and leave it for others to decide if it’s worth pursuing further I haven’t attached a download of the program above, but if someone is interested I could probably do a proper compile and upload.

Ah, but how to test the program, passing parameters without a command line? (I cheated and ran it through Visual Studio.) I’m sure some of you are already familiar with Rapi Tools – the rest of you download them, and add them to your toolbox:
http://www.xs4all.nl/~itsme/projects/xda/tools.html

Very convenient. Use prun.exe with the app executable and parameters on your desktop, and the device executes. (You need to cradle with ActiveSync so it really only serves a practical purpose in testing scenarios.)
 

So I’ll talk to you later then (Ah, the hilarious puns one come up with late at night…)

Ever since Microsoft got started with the Windows product line they’ve worked hard to have an OS variant ready for every need. Well, obviously they didn’t have that back when they released Windows 1.0, but they’ve continually worked towards it as a goal in my opinion. Up until Windows NT the desktop computer was the main concern, but with NT Server they branched into servers as well. (Digressing for a short history lesson – did you know that Mr. Bill G himself recommended OS/2 for workstation use and not Windows for Workgroups? Microsoft and IBM were in cahoots at the time and collaborated on both OS/2 and Windows NT 3.1. You could install a Windows app in OS/2 and it would simply work, and in many cases work better than it’s native environment. Wouldn’t work the other way though. Eventually things soured between the two business partners, and OS/2 Warp flopped even though it was a great piece of an operating system.) Not feeling everything was covered by these two editions work started on a stripped down version of Windows known as Windows Embedded/Windows Compact Edition. This was also to form the platform for the Windows Mobile line later on. (Trivia bits: Windows CE 4/5/6 releases all got their codenames from whisky.) Now I know there’s a lot of differences between Windows Mobile and Windows Embedded even though some of the core bytes are the same, but nonetheless I found it interesting to get to know Embedded a little closer.

A benefit of Windows Embedded is that it’s designed to be run on computers with low specs, so I thought maybe I can recycle some old hardware. My initial purpose was to build a media center, but the media center bits aren’t included in this release so I had to nix that idea. The next thought I had was to build a Kannel server just for the fun of it. I usually promote running services on a server OS not a client OS, but beta is beta, and it’s not like I would recommend this for a 24/7 production environment.

Windows Embedded is highly modular, and you can nail down exactly which elements of Windows you want to install. Never going to use a feature? Don’t install it in the first place. This does mean that you need to know what you are doing. Don’t expect .Net applications to work if you didn’t include the necessary module for that.

You have two main options for deploying Windows Embedded – create a custom image with answer files, or just boot off the iso you download from Connect. I inserted the iso in a Hyper-V guest, and fired it up. (A virtual appliance might seem pointless to you, but it’s so much easier to test and do screenshots before going with real hardware.) This is what it looks like:

  
“Build an Image”.

You can go for a pre-defined template, or roll your own custom image. I chose “Minimum Configuration”.

You can modify both included drivers, and features to get it just the way you like it. Really cool is that you can change to a bootable USB stack which means you can run Windows off a USB stick – and not just install from a stick like Windows 7.

Overkill deluxe, but it’s the default size for dynamically expanding disks in Hyper-V, and it doesn’t actually consume that amount of gigabytes either.

Shouldn’t take too long.

Windows Update doesn’t really work as of know with my minimal installation.

 
The stripped down template doesn’t even include the regular Explorer Shell. Just the cmdline. (Obviously you might want to include the shell for some scenarios – like actually testing and playing around a little with your new OS.) As you can see in the bottom right corner it is based on Windows 7 so it has UI elements matching the regular Windows experience.

Mounted the Kannel files as an iso, but would work equally well copying from a USB stick.

2 cmd shells is all I need for the basics.

Seems to be running like they should. Oh, yeah, you might want to test your Kannel.conf before loading it into your “appliance” since you don’t have Notepad

The http daemon is running too. Needless to say this was tested from a different computer.

Now this isn’t rocket science or anything, but goes to show how you can have a little fun sidetracking a few hours from your most used operating systems. Oh, right, specs. It’s running totally smooth with 512MB of RAM, (it will refuse to install with less), and the entire vhd file takes up 624MB of space after compacting the drive. Not too shabby if you ask me.

This is just a quick Maintenance Release of DojoCert, with one minor feature change. While it was assumed that SSL would be used for enrolling I have added a checkbox that will allow you to enroll without using SSL. (By default it will be enabled.)

Mind you, I would still recommend using SSL, but for testing it can be convenient to test without SSL. By default a Microsoft CA will not let you enroll via the web interface without SSL, so while I haven’t checked if this holds true for programmatic enrollment it may very well be the same condition that applies.

If you don’t need to control the SSL parameter you can continue using the previous release.

Link: http://mobilitydojo.net/files/DojoCert_101.cab

Self-signed root  certificate
While the recommended approach with Exchange 2007 and onwards is to use SSL certificates from a commercial CA on your internet facing services it’s perfectly ok to use certificates signed by your own CA. Windows Mobile devices are enforcing SSL trust, and will not allow the device to sync if the certificate fails validation. In other words – if you use a self-signed SSL certificate, and you don’t distribute this to the users, they will not be able to sync their devices. Seemingly a good approach, but there’s a few drawbacks.
- Since you distribute the root certificate to the users who are allowed to sync it is possible that one of these users are able to extract the certificate and re-distribute it.
- Other devices than Windows Mobile may be perfectly happy to sync with untrusted certificates. Symbian devices prompt the user to accept the untrusted cert. and will proceed if accepted by the user. iPhones will just do the sync (user-firendly remember).
Most likely the self signed approach will not help you in the long run.

Bonus tip: A very useful tool for extracting the certificate when you know the address of the server is SSLChainSaver: 
http://blogs.msdn.com/windowsmobile/archive/2008/05/18/sslchainsaver-v2-released.aspx

“Faking” the Common Name and/or hostname
A variation of the trick above is to issue the certificate to a non-resolvable address; like eas.contoso.local or possibly not even add a host record to the public facing DNS server so you can only access EAS by knowing the IP address. To make it work on a Windows Mobile device you’d add a static host name entry to the registry so the certificate will be validated even with the .local suffix. This solution will also block the basic users, but you can count on one clever user locating the loophole and telling the others all about it.

Blocking by default, only allowing specific devices
Ok, we’re not really that much closer to a real solution to the problem are we? How about looking further at Exchange itself? Exchange 2007 introduced a cmdlet that will let you “disable” EAS for new devices. This means that while EAS is available as a service. only devices you specifically allow will be able to use it. Basically a whitelisting feature. The drawback? Well, you have to manually enter the specific device ids that are allowed through another cmdlet (ok, the same cmdlet, but different parameters). So it introduces a certain administrative overhead, but if you have enough people manning your helpdesk it’s doable. Well, if you know how to extract the device id you need to enter that is. (More on this later.)

To disable EAS run the following cmdlet:
Set-CASMailbox –ActiveSyncEnabled $false –Identity user@domain.com
(You can pipe the output of a Security Group to this command to disable it for multiple users.)
To enable a specific device, for a specific user:
Set-CASMailbox –ActiveSyncAllowedDeviceIDs xyz –Identity user@domain.com

While this approach is effective I believe it’s a hassle on the admin side of things.

Installing middleware
A totally efficient approach, and one that should perhaps have been mentioned earlier is disabling ActiveSync altogether. No EAS enabled on your Exchange server – no user able to sync without permission. Or with permission for that matter Jokes aside, it is an alternative that could be worthwhile for some enterprises. If you disable EAS, and install a BlackBerry Enterprise Server for instance, only BlackBerry devices will be able to sync. Of course introducing another server into your infrastructure introduces other aspects as well – someone needs to manage it, does it support all the devices you need (?), are there more or less features than native EAS, etc. I don’t think I would implement a PIM solution purely with the intent of blocking certain devices, but it might make sense if you choose a PIM solution that will let you do more than just shuffle PIM data, and include this as part of a larger mobility strategy.

Blocking User Agent in ISA/ForeFront
If you are more gung ho than the average Exchange admin/architect maybe you have exposed your ActiveSync virtual directory directly to the dangers of the Internet. Odds are, if you’re slightly more sane that you’ve got some box wedged in between. Something like a firewall, reverse proxy or similar to put an extra hop between your domain and your WAN. While there are a number of products out there, for some reason ISA Server / ForeFront Threat Management Gateway comes highly recommended from Redmond Since ISA / TMG is able to inspect every last octet of bits that flows through it’s network interfaces you have some options available for filtering.

EAS uses HTTP as the transport protocol, and one of the details in this protocol is that the client side is supposed to report a “user agent” where it reports what kind of client it is. (This is most commonly an identifier of the browser, but in cases like custom apps, or OS components some other agent is reported.)

So how does it look? Well, it’s a silly example, but here’s how to block Internet Explorer (because that’s quick and easy to test). Normally when opening EAS in IE you’ll get an error code of 501/505. So I’ve run through the wizard in ForeFront for publishing EAS. I then edit the rule created (you have to create the rule first, it cannot be done in the wizard).
Click “Configure HTTP”.
 
Go to the “Signatures” tab and click “Add”.

I’ve specified MSIE as that is how Internet Explorer identifies itself, but you can add “iPhone”, “Android” or whatever have you here. When I try to browse the site now I get the following error:

Nice indeed. But are we happy with this? No, unfortunately not. While you have the ability to blacklist specific user agents you do not have the ability to whitelist. And you don’t really want to be updating this on a weekly basis as an admin task. Another weakness of the mechanism is that on some platforms the user might be able to modify the user agent, and then you run into a classic cat and mouse game. Now if you want to use this method it should also be combined with parsing the EAS-logs on your CAS server to know the actual user agents being used, and also try to catch the usernames of those who try to circumvent the system.

Have a look in c:\inetpub\logs\LogFiles\W3SVC1 (if running IIS in the default location). And/or parse the log files more thoroughly:
http://msexchangeteam.com/archive/2006/02/14/419562.aspx

ForeFront UAG
ForeFront is not a single product – there’s a whole family of products. A new member of the family is ForeFront Universal Access Gateway, which is currently in the RC0 stage. I believe it’s the successor to the Intelligent Application Gateway which was only available as OEM appliances (correct me if I’m wrong). I’m not exactly sure how this will position itself versus ForeFront TMG when they both hit RTM. (TMG will RTM before UAG as per my understanding.) If you want to use the DirectAccess feature in Windows 7/Windows Server 2008 R2 UAG is apparently the way to go, and it is intended as a gateway to your infrastructure as alluded to in the product name. To complicate matters further ForeFront TMG is actually a component that is used for firewall services in UAG. Still hanging on? Not me…

So why do I bring it up? Wouldn’t it be the same as the last bullet point? Yeah, well, sort of. You can publish Exchange ActiveSync through UAG as well. You’ve got more options than you can shake a stick at too, as far as I can tell. I did not however see a clever whitelist feature though, so thus far I haven’t found a compelling reason to use it. I could of course be wrong, since I am not as familiar with this product yet.

Network Level Restrictions
While EAS makes the most sense when you can access it externally, you don’t have to publish it to the whole Internet. Many mobile operators will set up a private APN for you if you ask nicely (read: ordering extra services). This means that while you are using the same GSM network as other subscribers you’ll basically have your own VLAN. There’s different implementations out there involving authenticating against a RADIUS server, connecting a dedicated router in your infrastructure that is hooked up to your operator, etc. The device is then allowed access based on a username/password combo, authenticating the IMSI number of the SIM card, or a combination.

While some mobile operators are pushing this as a good solution, and often incorrectly labeling it as mobile VPN, it also has a few drawbacks.
- It will usually cost you extra money.
- You need to standardize on one operator. (This isn’t really a drawback per se, but it’s more difficult to change operator when you’re unhappy with their service if you’re dependent on services like these.)
- It may not work properly when roaming.
- Depending on the authentication scheme it might be possible for a clever user to copy the configuration settings to a non-compliant device along with the SIM card. (Remember; this is not an authentication of the device.)
- Deployment can be tricky – you cannot expect users to handle this themselves.
- If you need to maintain an extra RADIUS server that’s more work for you.
- You may see reduced throughput, and if you’re really lucky you’ll see sporadic time-out related errors.

If you build a RADIUS filter that will let you check both IMEI and IMSI, and only allow devices you pre-approve it should work though. There are some benefits to bringing the mobile devices closer to your infrastructure on a VLAN level too, so it might be beneficial as a component in your overall strategy. As you can probably tell by now I like the concept of a grand strategy:)

In the same vein – I have heard people suggesting putting IP filters/restrictions in place. Only allow a certain range of IPs to sync, etc. Stop right there. It’s not a good idea. Don’t pursue it further – it is:
- A hassle to maintain
- Usually a large range of IPs you need to allow. If there are potentially a million other people who can have an IP in that range you’re not really restricting things.
- NAT anyone?
- Also works on the SIM level – a non-provisionable device is still non-provisionable.

Putting EAS behind VPN
Closely related to looking at the network side of things is putting EAS behind a VPN. If you’re deploying SCMDM this is an interesting scenario. Since WM 6.1 is the only OS supported by SCMDM so far it’s very effective at restricting access. A minor drawback is that you will not be able to allow other devices to sync even if you want to. SCMDM isn’t the only VPN solution out there so you can achieve similar goals with other VPN clients too. Just make sure you have a wide range of client support, and preferably a client configuration the users aren’t able to copy from one device to the other.

I really like VPNs, but unfortunately it can be troublesome to get working. IPSec is locked down on many default APNs, and SSL-based VPN for mobile device isn’t really there yet. I’d really love to see DirectAccess for mobile devices, but that’s probably still in the future. (And I don’t even know if it’s there.)

ISAPI-filter / IIS Module
We’ve been through a couple of different options by know, and they’ve all had their imperfections. Wouldn’t it be nice with a silver bullet now? Well, ok, still not there, but I did defer the most promising alternative until now. That is, it might require a little help from your friendly neighborhood programmer. If that is not a problem, it might be right up your alley.

As I said EAS traffic flows through the HTTP protocol between the client side and the server side. This means that you can filter on things like user agent, source IP address, etc. But triggering the sync itself is performed by submitting an HTTP POST request. Provided your ActiveSync is located at eas.contoso.com the POST will look similar to this:
https://eas.contoso.com/Microsoft-Server-ActiveSync/?DeviceID=1234&DeviceType=iPhone&User=andreas&Cmd=Sync
The interesting parameters are DeviceID and DeviceType, as these are the ones identifying the device itself. Now if we could filter by these properties…

Enter ISAPI. By now you’ve probably figured out if you weren’t already in the know, that ActiveSync on the server side is running on Internet Information Services (IIS) – hosted either on Windows Server 2003 or Windows Server 2008 as a web application. IIS has a concept where you can add your own plug-ins to the execution stack. In IIS 6 these are implemented as so called ISAPI filters consisting of a .dll written in C++. In IIS 7/IIS 7.5 these can be the same dlls, or a managed module written in C#. (I’m not sure of the exact distinction between an ISAPI filter, and an IIS module, but MSFT seems to be recommending the latter.) This means that before the traffic is passed on to the actual web application you can do a lookup on the DeviceID and DeviceType in a database, do a regular expression, or what best suits your given scenario. Not in the list of approved DeviceTypes? No sync for you!

Yes, it is similar to the building of access rules in Exchange 2010 that I showed in my last article, but I believe it’s more flexible “outsourcing” this to a database. And you also have the option of combining DeviceIDs and DeviceTypes to build both blacklists and whitelists. I know, most Exchange admins aren’t very open to the idea of installing extra software on their servers, but configured properly it will only affect ActiveSync, and if you don’t build too complex rules it shouldn’t be much of a performance hit either.

So, what does the DeviceIDs and Type look like? Ah, here’s where the detective work comes into play. What I have found so far:
Windows Mobile –> DeviceID = long hex value (called ExchangeID), DeviceType = PPC/SmartPhone/variation of this
iPhone –> DeviceID = IMEI, DeviceType = iPhone
Symbian E-series –> DeviceID = IMEI, DeviceType = IMEI

You can catch more through monitoring the ISA Server logs, or run Network Monitor on your Client Access Server.

You’d also need to figure out things like where to store the database (preferable on a “witness server” if you have redundant CAS servers), administration of the filter (web interface to the db?), and make some planning to make sure that you understand the implications. But I believe done right it would be smooth. Trying to add two plus two you might wonder if this is possible to implement on your reverse proxy. Yes, I believe you can. ISA/TMG has an SDK allowing you to write plug-ins, and other proxies might have SDKs too. While I’m not going to dismiss this idea entirely I believe this can be considered business logic, and more suited to perform on the application server. An ISA/TMG server should pre-authenticate users as part of the security mechanisms, but other than that it should be optimized for throughput and inspecting traffic for signs of malicious activity. Filtering authenticated users seems to me like it is better to implement at the next stage in the sync pipeline. I’m open to different takes on this however

Ok, this turned out to be a longer post than I initially thought. I believe I have given you some ideas, hopefully some methods you hadn’t already come across. (I know there’s a lot of smart people out there.) Maybe there’s more options that haven’t crossed my mind yet. Well, you know where the comments sections is if you have any input, and if I come up with any more tricks you know I’ll be telling you all about it

Sure, the source being available helps in a lot of scenarios, but it doesn’t always give you what you want. Now for instance if I am dabbling with a new Windows Mobile device, and there is some setting I want to be able to control (other than the button in the GUI), I might go looking in the file system or the registry for clues. Some times I end up looking at a file, (say for instance a .dll), that I have a pretty good clue is responsible for what I’m looking for, but I don’t find a way to control the feature outside of this file. And in cases like this it would be nice to be able to have the source of the file, and being able to learn how to do it by reading some code. True, if the application is written in C# it’s pretty easy to do a “reflection”, and re-build most of the source that way. If it’s written in C++ it’s more hassle, but you can still reverse engineer it some way. But whether you like it or not that’s just the way a lot of software is provided to you, and you usually have to rely on solid documentation to be able to do all the things you desire. (Or rather “all the things you are supposed to be doing” according to the application provider.)

Now, I don’t intend to start a new religious war, bringing up the old Linux versus Microsoft debate all over. Let’s just say open-source and closed-source are different approaches to delivering software.

I mentioned previously that I have been playing with an Android device, and quite liked parts of it. And the Android is Linux-based, and open-source based. So is the Android platform open for managing too? I’ll try to provide a very brief overview.

Google has based themselves on the Linux kernel, and together with some partners (like for instance HTC) have created their own distro. In addition to having devices with Android pre-compiled (would be sort of useless having to compile it yourself after walking out of the store I guess), you can download an SDK, the source itself, modify it, and re-compile to your liking. And at least theoretically you are able to build your own mobile device. (Needless to say there are some more minor challenges to making your own mobile than just an OS.) Most people will be more than happy to just buy ready-made devices, and adapt these to their needs though.

But it’s important to understand that when you buy a device, like the HTC Hero that I tested, it’s not “pure” Android. It’s the HTC flavour of Android. You want to sync with Exchange? Additional software provided by HTC. You want to connect to a desktop computer and transfer files? Additional software provided by HTC. If you ran the Google version it simply would not be there. (Yes, there might of course be an element of political motivation on Google’s side too for not providing these features, but that doesn’t help you as an end-user.)

In traditional Linux terms I guess it’s a sort of “fork”. I do not know if the HTC-compiled version is different enough from the bits provided by Google to qualify as a proper fork – probably not since Google and HTC are working closely together. If you are not familiar with the term fork it basically means a different branch of Linux. For instance while Debian and Red Hat both are Linux-based operating systems, and have common traits they have chosen different directions, and software compiled for one might not work out-of-the-box for the other.

With the backdrop set, how do you go about managing an Android device?

Android uses the concept of application signing, much like the other major mobile operating systems. It does not require all applications to be signed by Google however. You can use self-signed certificates if you so like. (The certificate chain is not validated, it’s used to authenticate the application itself.)

Each application will be allocated it’s own memory space, and will not be able to mess around freely with any other application’s memory. If you as a developer have more than one application, and make sure to sign them with the same certificate, Android will be able to figure out that your applications might want to share some info between them and allow cross-application access. So obviously this would be the first obstacle you’re facing regarding device management.

Well, we can appreciate applications not disturbing each other. But configurations and settings aren’t necessarily allocated in memory so maybe there’s a way around this issue. On Windows Mobile we mainly use the registry for storing configuration data. Or .ini/xml-files. Not so here. Well, ok, you can create your own xml files if you sit down to code an app I guess, but the standard/recommended method is small databases containing the metadata. So you need to figure out how to parse the db, sort out the tables and columns, etc if you want to know what metadata the application uses. You’ll probably figure this out if you hook up an emulator and grant yourself root access. Unfortunately initial tests indicate that even root will not give you write access to the databases if you didn’t sign them. (What’s the point of root if you can’t “own” everything…)

So I guess that means hands off other apps in general.

How about basic stuff like power-on-password, encryption, etc. Well… There are no built-in facilities for this. It is possible though to create your own PoP. (It would basically be just another app, which just happened to be a power-on-password program.) Other system settings like GPRS? Prime candidate for OMA CP/DM. Which isn’t currently supported either so you’re out of luck there too.

How do you actually manage Android devices then? I must admit I wonder too. Third-party apps have become available, and some provide what they call device management. But, we’re still lacking some serious options. I know several MDM vendors are working on it, but it seems they are running into challenges as well. (If it was a breeze we surely would have seen some fancy stuff by now.) Oh, well, I have plenty of source code just sitting here, and a lot of spare hardware. I’d surely be out of luck if the source had been proprietary

I don’t remember if I have mentioned the irony of the market space for mobile operating systems before – but Microsoft is still the most “open” alternative when it comes to being able to modify the stuff that comes out of the box. It must feel bad for the most ardent Linux fans out there, but your platform of choice is the restrictive one. (/Ironic observations: I still believe there are some really nice features in the OS design of the Android, but even though version 2 of Android is right around the corner the platform has not reached the same level of maturity as Windows Mobile has.)

Now, I majored in software engineering, so someone majoring in economics/marketing could probably explain this in a better way than me. But this is basically what we call commoditization. Choosing Hotmail or Gmail for basic mail does not matter. The SMTP traffic looks pretty much the same in both instances, and if one of them started charging money for the basic service you’d switch to the other. Once a technology has moved past the early adopters, and are approaching the late majority, it will eventually become a commodity. When a product is a commodity the basic product is not bound to a specific provider, and you basically (pun intended) need to distinguish yourself from “the pack” and offer a premium product to have any profit margins to speak of.

Ok, fair enough. How does this relate to mobility? Well, PIM has pretty much gone that way. Even your most primitive mobile device will support email/contacts/calendar in some way. Possibly only through cradling to a desktop. Possibly only POP3/IMAP support. But on so-called smartphone devices you’ve come to expect being able to sync to Exchange. With both Lotus/IBM and Novell adding ActiveSync to their groupware products you except it to “just work” and not require all sorts of third-party apps that cost money. It’s basically a commodity by now. (If your primary business is selling PIM-related apps and middleware you have to offer something extra than basic PIM to survive.)

MDM has so far not been commoditized. While Mobile Device Management certainly is getting easier and more accessible you still have to pay up money if you want to be able to do anything proper, and you’re not in the position where you can expect everything to work on all platforms and devices. I do believe however that we are getting closer a few steps by the time (Pop quiz: is this a good or a bad thing?)

And I believe Microsoft is thinking along those lines too. How so, you say? Well, I obviously do not have access to the entire mobility strategy of Microsoft, or their roadmap, but I noticed a curious thing after the Windows Mobile 6.5 launch two days back. They also released an upgrade to, and RTMed, the MyPhone service. On my main device, (a Touch Diamond 2 for the time being), I’ve been running it since I loaded up a 6.5 ROM on it a few weeks ago. Since I use Exchange ActiveSync it’s mainly for backing up SMS, and syncing the few pictures I snap. Works like a charm.

MyPhone has new features in this release. It’s got a remote kill function. And if you have forgotten where you misplaced your device you can have Microsofts servers “pinging” it and it will ring for 60 seconds regardless of whether the device is in silent mode or not. Surely a step in the direction of enabling MDM light for your average user. (Although pitched primarily as a sync solution so far, the MyPhone name is generic enough for further expansion later.) If you allow it, it will even track the location of your device, presumably through GPS or A-GPS logs.

But what really made me notice that something was going on was a bug that has been bothering me. The Power-on-Password screen in WM 6.5 displays the time and next calendar appointment without unlocking. But due to my ROM not being RTM there’s been an annoying bug displaying the time as “00:00” all the time – so I have to authenticate to use the device as a watch. MyPhone forced a soft reset of the device after upgrading itself, and in addition to changing something with the font the time was now displaying properly! Bug fixed! But the shell protection is part of the OS isn’t it?

If you will indulge me for a few more minutes. (Already ranting, but there’s ample time for a digression I guess. You are free to move along if you like.) The module in Windows Mobile that is responsible for making things like Power-on-Password work is called the LASS (Local Authentication Subsystem). The LASS itself does not handle the actual authentication – this is handled by a LAP (Local Authentication Plugin). If you want the low-level details MSDN is waiting for you: http://msdn.microsoft.com/en-us/library/aa923670.aspx

The high-level brief is that Windows Mobile by default includes a LAP that will let you authenticate with a password/PIN. (SIM card authentication is handled by the radio stack as far as I know.) But Microsoft has provided the opportunity for people to write their own custom authentication modules. For instance when I run Afaria (a Sybase product) on a device I often include the Data Security Manager module that replaces the built-in LAP.

You can have a look a which LAPs you have on your device, and which is the currently active LAP by taking a look at the registry.
HKLM\Comm\Security\LASSD\LAP will have subkeys for each LAP, and the key “ActiveLap” will tell you which one is active.
The default LAP is called lap_pw, and after installing MyPhone you have a new one called lap_sky. It didn’t change the active LAP on my device, but apparently it’s updating some other files too in the process. By changing the ActiveLap key manually in the registry I can switch the interfaces though. (Still works with the same password as before.)

Lap_pw:

Lap_sky:

The plot thickens. Without trying to sound conspiratorial I must say “sky” sounds an awful lot like “cloud”. And if it wasn’t enough calling the LAP “sky”, MyPhone also installs a file called SkyCommandListener.dll Yes, I understand that since the remote wipe feature is included, and you can control this from the MyPhone interface in your browser it doesn’t qualify as discovering any secrets – there obviously had to be something device-side executing these remote instructions. Looking at it from an end-user perspective I can only say this is nice though. It indicates Microsoft are able to implement more MDM features at a later time if they want to. Initially these features are free, but some of them will be “premium” features later on.

They will probably try to tie it in with the Windows Mobile MarketPlace offering at a later time too. While you can only install apps on the device for know, there is a planned upgrade that will let you buy apps in your desktop browser. And I don’t see why a remote install wouldn’t be possible in the same go.

How it will tie in with enterprise offerings, whether from Microsoft or third-parties, remain to be seen.

Oh, and the pop quiz? It does kind of depend on where you are standing I guess. (Who would have expected that answer, eh?) But only dead fish follow the stream

It’s ironic, but previously your main concern regarding the availability of ActiveSync was that it was a Windows Mobile exclusive feature. Then Microsoft started licensing it to other companies. DataViz released RoadSync for a number of devices which was a clean and nice implementation of the client bits. Nokia released Mail4Exchange. Even Apple who aren’t big fans of the company from Redmond knew they had better support it for the iPhone.

And the really impressive part is now other companies are implementing it server side as well. IBM announced a few months that Lotus Domino would use ActiveSync for doing push mail meaning that any device implementing ActiveSync could sync with Domino without third-party software. And the last thing I heard is that Novell is running a beta program currently implementing it for GroupWise.

I think you won this one Microsoft. I’ll give you that.

But with this backdrop set – this leads to a new problem. Whereas you had a limited device pool to choose from before now you have devices all over being able to sync. But they are not necessarily able to implement all security features, and not necessarily manageable. So, this creates a new challenge. You only want to allow a subset of devices, and only the subset you can have some level of control over.

With Exchange 2007 came the ability to define a security policy, and enforce that non-provisionable devices would not be able to sync. This feature has a couple of problems though:
- They apply on the user-level, not device-level. (You apply the policy to user accounts.) So if a user has two devices you have to either block both, or allow both.
- You have to be really good to keep track of which devices support which policies. (The quick answer is that only Windows Mobile 6.1 and 6.5 supports all policies at the time of writing this.)
- And you know what? It’s a matter of trust from the server perspective. The previous firmware on iPhone was able to report “yes, I support device encryption” even though only the iPhone 3GS actually does.

Apparently it’s not only me complaining about this. I’m getting more and more requests asking how can we block all these non-approved devices? And Microsoft seem to have been listening to someone. Exchange 2010 has features that allow you to have more control. Possibly not unsurprising I’m having a look at these settings today

I do not know if these features can be controlled to the Exchange Management Console – I couldn’t find them, but maybe it’s just me. I had to dig into the Exchange Shell to configure them.

First off – you can define the default action when a new device tries to establish a sync partnership (regardless of whether the device supports any policies). You can either allow, block, or quarantine devices. A quarantine means an admin will have to approve it before it can perform a sync.

You have the following two cmdlets to control this:
Get-ActiveSyncOrganizationSettings
Set-ActiveSyncOrganizationSettings

Get- is just a read-out of the current setttings. To set a policy execute something like the following:
Set-ActiveSyncOrganizationSettings –DefaultAccessLevel Quarantine –AdminMailRecipients admin@contoso.com

You’ll get a mail like this in your inbox:
Subject: “Your mobile phone is temporarily blocked from synchronizing with the server while permission to access is being verified.”

Body:

The admin you specified will receive the following mail:
Subject: “The mobile phone that belongs to contoso\andreas has been quarantined. Synchronization with the server via Exchange ActiveSync is blocked until you take action.”

Body:

So to allow the device the admin must fire up their Exchange Shell and execute something along the lines of this:
Set-CASMailbox –Identity andreas@contoso.com –ActiveSyncAllowedDeviceIDs 123456789ABCDEF

I believe this has scaling issues. Who on earth wants to be typing in horribly long device GUIDs every time a user fires up a new device. But it’s a start.

Taking it to the next step we have four more cmdlets for you:
New-ActiveSyncDeviceAccessRule
Get-ActiveSyncDeviceAccessRule
Set-ActiveSyncDeviceAccessRule
Remove-ActiveSyncDeviceAccessRule

Ok, they all work in conjunction to control the same feature. But this one is more interesting. You can create access rules, and limit access based on the following characteristics:
- Device Model
- Device Type
- Device OS
- Device User Agent

As an example the Windows Mobile 6.5 Professional emulator would result in the following values:
Device Type: PocketPC
Device Model: Microsoft DeviceEmulator
Device OS: Windows CE 5.2.21234
User Agent: MSFT-PPC/5.2.5001

Filtering based on the OS down to specific build numbers probably wouldn’t be your first choice, but filtering on model and type might make sense. The complete cmdlet would look like this if you wanted to block all PocketPC devices:
New-ActiveSyncDeviceAccessRule –QueryString PocketPC –Characteristic DeviceModel –AccessLevel Block

When I try to to do the initial synchronization on my emulator I’m told that I am not allowed to do this:

And an email in case you missed it:
Subject: Your mobile phone has been denied access to the server via Exchange ActiveSync because of server policies.

Body:

I believe this is definitely taking steps in the right direction as far as putting some restrictions in place. It’s not too admin-friendly at the moment being limited to the shell, but it’s probably not too unrealistic to expect something in SP1 whenever that comes around.

You also have some work with how you want to approach this – create access rules to allow specific known good devices, and block the rest? Or allow all by default and specifically blocking other devices? And you can still define and enforce security policies through the console.

I mentioned a few paragraphs back that there were other methods for restricting access, and even with these new features in Exchange I believe there’s still reasons to consider these alternatives. I still haven’t gotten around to finishing that original post I have been working on, but it’s never too late is it? I’ll see if I can put it some effort, and see what I can come up with