howto://connect clients to exchange-part two

by Ed Fisher on 2010-07-28

in Infrastructure

Welcome back. In the first half of this series, howto://connect clients to exchange-part one, we covered how to securely enable POP3 and IMAP for clients, and how to make those services accessible over the Internet using our TMG server. In this post, we are going to cover ActiveSync and Outlook Anywhere, and then of course, how to publish them through our TMG.

Exchange ActiveSync is Microsoft’s solution for connecting Windows Mobile devices to Exchange. It also happens to work for iPhones/iPod Touch/iPads, and Droid devices (though Verizon will charge you extra for that privilege. Bzzz!) ActiveSync uses a secure connection over HTTPS, and can be published easily through our TMG, making it the most attractive option for those devices that can use it. For Outlook clients who work remotely, and for whatever reason don’t want to first connect by VPN, Outlook Anywhere lets you make MAPI connections by tunneling RPC over HTTPS, supporting the full Outlook experience. Again, we’ll use our TMG to publish this. We’ll find out everything there is to know about remote connections to Exchange: their dreams, their desires, their most intimates of intimates, and from what I’m looking at, "intimate" is the stud muffin’s middle name. If you would like to set this up on your Exchange server, read on.

Exchange ActiveSync is installed by default on servers when you install the Client Access Server role, so there is not much else to do with that. If you have a CAS, you have ActiveSync. All users will have ActiveSync enabled by default, and you should be good to go. Of course, if it was really that easy, I wouldn’t be blogging about it, would I?

It’s called SEKURITAH

I’m confused. In NT4 days, we all just logged on as Administrator and got the job done. Then in Windows 2000, we started paying attention to security and best practices, and had two accounts…a regular user account, and a privileged user account. We quickly learned what a pain in the arse that was, so in 2003, we started to really use RUNAS.

But then, folks realised that the above was all crap, and we just always made our AD account a member of domain admins. Yeah, we call it human nature. So the good folks as Microsoft introduced User Account Control, and the lovely ConsentUI. That sounded pretty good to me, and I am an advocate of UAC, however…what they did NOT get rid of is a little gem called sdAdminHolder. Why is this a problem? Because it is evil, absolutely evil. This little gem flags all accounts made members of privileged groups to try to better secure them. In addition to restricting who can make changes to these accounts, it also blocks inheritance on the DACLs. This will bork ActiveSync for you the first time you try to set up your account, so listen up.

When you go to set up your device, it will error that a connection failed. Before you spend too much time looking at firewall ports or funky DNS issues, check the system logs on the Exchange server for Event ID 1053 from MSExchange ActiveSync. If this is your problem, it will look like this.

What was that honey? It was BAD! It had no fire, no energy, no nothing!

Exchange ActiveSync doesn't have sufficient permissions to create the "CN=Ed Fisher,CN=Users,DC=olympus,DC=home" container under Active Directory user "Active Directory operation failed on zeus.olympus.home. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
".
Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type "msExchangeActiveSyncDevices" and doesn't have any deny permissions that block such operations.

You see, in order to actually use ActiveSync, configuration information has to be written to Active Directory in your user account object, and if you are a privileged user, sdAdminHolder will spank you with this error. We can fix it, but realise that a process called SDPROP checks for things that mess with accounts flagged with sdAdminHolder every hour, and will just set things back, so move quickly.

If you want to see whether or not an account is flagged, check the attributes. All privileged accounts will have adminCount set to 1, like so.
Sir, are you classified as human? Negative, I am a meat popsicle.

How to get around sdAdminHolder issues

If you want to get around this, have the client device in hand and ready to set up. Don’t start this process until you have the device ready to configure, as that SDPROP is going to undo what we are about to do. Quiver ladies, quiver.

  1. On your CAS server, launch the Exchange Management Console.
  2. Browse down to Server Configuration and then double-click your CAS server from the server list.
  3. Go to the System Settings tab, and determine with domain controller is being used.
    image
  4. Launch ADUC on that domain controller and find the account.
  5. Right-click the account, and select Properties.
  6. Then go the security tab, and click Advanced.
    image
  7. Check the box to include inheritable permissions blah blah blah…
    image
  8. Hit OK, then hit OK, and then try to connect with ActiveSync again.

If all goes well, you should slip in under the wire before SDPROP can put things back. SDPROP won’t remove the ActiveSync data, so you will be fine unless you need to make changes or add another device. If that happens, you can just do this again. Since Windows Mobile phones are pretty straight forward to configure (read that as I don’t have one to play with) you are on your own for setting these up. For those of you who belong to the cult of Apple, see this post (coming soon.)

Securing ActiveSync

You may want (or the Security team may tell you) to tighten up the settings on ActiveSync. Here is what we can do with that. I prefer to leave things more open so I can support more devices, and let policy and user training mitigate any risks of exposing confidential information. Again, YMMV. Most of these settings will only work on Windows Mobile devices.

  1. Log on to the Exchange Management Console, browse down to Organization Configuration, Client Access, and then click the Exchange ActiveSync Mailbox Policies
  2. Double-click the Default Policy to bring up the Properties. Notice the default is to allow non-provisionable devices. This is a good thing for iPod/iPhone/iPad devices.
    image
  3. You can require that mobile devices require a password for use, and whether or not to encrypt data stored on the device. Just remember how much fun it is to type complex passwords on those little keyboards!
    image
  4. You can set limits on synching and file sizes
    image
  5. You can restrict what functions the device can use
    image
  6. And you can also configure permitted or denied applications on the last two tabs.
  7. To deal with a lost or stolen device, first browse down to Recipient Configuration, Mailbox.
    image
  8. Highlight the user, then on the Actions Pane, click Manage Mobile Phone.
    image
  9. From this screen, you can either remove a device from a mailbox (leaves the data that is already on the device intact) or lay the smackdown upon it with a remote wipe.
    image
    Just remember, no device is guaranteed to be completely clean, and unrecoverable, after any kind of data wipe. Don’t send state secrets, launch codes, or Swiss bank account numbers through email. <♫> The more you know </♫>

Configuring Outlook Anywhere

Next up is Outlook Anywhere. The idea with this is, we want to permit our clients with laptops and the full Outlook client to connect to Exchange without first requiring a VPN. Kind of like using a multipass. Since the connection is securely encrypted within an HTTPS connection and authenticated against AD, this does not present a problem to me. For others, the idea of letting ANYTHING on the inside be accessible without a VPN is anathema, so your mileage may vary on getting this approved. But seriously, what is the real difference between an encrypted VPN tunnel and an encrypted HTTPS connection, other than licensing costs? Not much. And this one is really quite easy to do.

  1. Launch the Exchange Management Console.
  2. Browse down to Server Configuration and double-click your CAS server.
  3. Click on the Outlook Anywhere tab.
  4. Configure your external DNS name, and what level of authentication you want. Trust me, you want NTLM. If you have SSL accelerator hardware you can allow offloading.
    image

That is it…Outlook Anywhere is now supported on the CAS. Next up, our TMG configuration so we can actually use this across teh tubes!

Publishing ActiveSync and Outlook Anywhere with TMG 2010

To publish these services through TMG requires two rules. We are going to use our generic https listener that we set up on TMG during this post on publishing Outlook Web Access. If you have multiple public ip.addrs and want to set up a dedicated listener, please do so.

  1. Log onto your TMG server and launch the TMG Management Console.
  2. Browse down to Firewall Policy. Right-click, New, Exchange Web Client Access Publishing Rule…
    image
  3. We’re going to setup ActiveSync first, so give this rule an appropriate name, and then click Next.
  4. Click the drop down list to select Exchange Server 2010, then check the box for Exchange ActiveSync. Don’t ask me why these are check boxes and not radio buttons…I don’t know.
    Last time I looked, checkboxes were for when you could select more than one at a time. Dude, WTH?
  5. Leave the default for a single Web site and click Next.
  6. Leave the default to connect using SSL, and click Next.
  7. Enter only the internal FQDN of your CAS server, and then click Next.
  8. Enter the external FQDN for your ActiveSync clients, and the click Next.
  9. Select your generic https listener, and click Next.
  10. Make sure you select that client may authenticate directly, then click Next.
    image
  11. Leave the User Set for All Users, and click Next.
  12. Click Test Rule. You will see that ActiveSync uses the special URL https://fqdn:443/Microsoft-Server-ActiveSync/. If the test shows green, you are good to go. Green? Super green!
    Unbelievable!!!
  13. Now go back and do it all again, this time naming the rule and choosing the option for Outlook Anywhere.
    image 

That’s it. Get on an external network, and test things out. You should now be able to ActiveSync or Outlook Anywhere across teh tubes. Yay! Now dance all night long. All night long…all night. That, or book a weekend at Fhlostan Paradise. You’ve earned it. Just in case you missed some of the references I scattered through this post, they’re from The Fifth Element. Here’s a sampling of the best character from that flick…DJ Ruby Rhod!

Direct link for RSS and email subscribers…http://www.youtube.com/watch?v=m60GdwvUjQw 

If you found this post useful, please consider following us on twitter. You’ll be the first to learn about new posts, and, rarely, we’ll share a comedic or witty tweet. Of course, you can also leave a comment below (anonymous allowed) to let us know we hooked you up.

You might also enjoy:

  1. howto://connect clients to exchange-part one
  2. howto://connect your iphone to exchange with activesync
  3. howto://install Exchange 2010 on a single box-part two
  4. howto://install Exchange 2010 on a single box-part one

{ 7 comments… read them below or add one }

Ben 2011-09-15 at 12:40

I like your style of writing good stuff thank you very much!!!

Reply

Ed Fisher 2011-09-15 at 21:51

Thank you Ben!

Reply

Johney Emmanuel 2011-10-04 at 23:54

Excellent post, keep ‘em coming!!!!

Reply

mike 2012-02-03 at 14:47

thanks so much… i had the biggest problem for weeks getting an iphone to connect to our exchange… your a life saver!

Reply

Ed Fisher 2012-02-03 at 15:03

Excellent, glad it hooked you up. Thanks for letting me know.

Reply

CID 2012-02-13 at 03:16

that’s exactly the answer I was looking for. Thank you very much for your expertise.

Reply

Ed Fisher 2012-02-13 at 14:12

De rien!

Reply

Leave a Comment

Previous post:

Next post: