Tuesday, September 23, 2008

Accessing production resources from your test environment

Comes up a lot. "I'm standing up MDM in the lab but really want to be able to get at (insert LoB here. Usually Exchange, but it can be anything)".

Makes perfect sense and adds a lot of validity to your testing. Plus, it means that if you're getting at your production email then you're more likely to actually use it, rather than have to carry a 2nd device solely for the purposes of kicking the tires.

My experience has been that the novelty wears off very quickly for customers if they don't have a genuine motivator to encourage usage, and putting their production email on the test device is a very good way of achieving this.

It's actually extremely easy to do (so long as you have buy-in from your Security and Firewalls team since they're the ones who have to approve this and make it possible to work).

The simple fact is that once an MDM device has connected to the MDM Gateway it has access from that point onwards to anything you choose - it comes down to whether (a) the host can resolve (usually through DNS) and (b) if there's a route from the vpn pool of addresses through the internal firewall to the target host.

The above image shows how it works giving Exchange (2K3-SP2, E2K7-RTM or E2K7-SP1) as the example of the target LoB host(s) in your Production environment.

On the left hand side you have your QA environment where you've stood up the MDM components (and requisites, like SQL, WSUS & CA). Completely separate from this is your Production environment where the Exchange mailboxes reside.

The device, once enrolled, will be managed from your QA environment. That's the left arc, showing the DM pushing down policies and .cab files. The users mailbox and corresponding AD User object, however, are located in the other domain.

All that the device has to do in order to access Exchange is, as detailed above, resolve the mailbox server and be able to route to it, following the right-hand arc/flow.

Client authentication takes over from this point, either with the user credentials being passed through the IPsec connection within an SSL tunnel, or the certificate being passed through via the same route. Very easy. Beyond MDM providing the transit route between the device and the GW, everything else is handled by the internal resolution/routing/authentication mechanisms.

That's why I refer to MDM as an enabler - it enables things like this very, very easily indeed. The Admin intervention is negligible, beyond getting the approval and active participation of your Security and Firewalls/Routing team.

Secondly, this highlights also just how low impact MDM is once it's in[1]. Nothing needed to be added since the MDM infrastructure is in place and the device can securely connect; all that was required was to ensure the device could get at the target host. Easy, eh? :-)

[1] OK, so I'll admit that getting it installed and working is a biotch, but once it's there everything else really is extremely easy indeed.

No comments: