Using RADIUS to Support Multiple Untrusted Domains For Web Publishing

While deciding how I was going to deal with switching over to a new Exchange setup in our office, I was wondering how I would deal with the fact that I always prefer to keep the Exchange organization separated from the the production domain. I like to keep the Exchange forest separate from our production forest because the users in the Exchange forest aren’t all employees of our business, so I figure it’s safer to put the Exchange Server is in a separate forest and then create a one-way trust between the Exchange forest and our production forest.

The problem is that our inbound ISA Firewall is part of the production domain, so as to allow us to leverage the security advantages of domain membership. Since the ISA Firewall doesn’t belong to the Exchange forest, and the production forest doesn’t trust the Exchange forest, there’s no way that the ISA Firewall can authenticate the Exchange users using it’s own domain membership.

What’s the solution? RADIUS authentication. For the Web Publishing Rules used to support connections to OWA, ActiveSync, and RPC/HTTP to the Exchange 2007 servers, I can use RADIUS authentication. I configure my ISA firewall to connect to an NPS server in the Exchange 2007 organization and authenticate the Exchange users that way. It works a treat!

The primary limitation of using RADIUS authentication over Windows authentication is that you can’t use domain security groups when configuring the ISA firewall’s inbound access in the Web Publishing Rules. That’s not too big of a problem though, since I can control service access on the Exchange Server for who has permission to use a particular Exchange 2007 feature.

Speaking of Exchange, I’ve changed my opinion regarding documentation and management of Exchange 2007. My initial impressions of Exchange 2007 was that it was an installation and configuration nightmare, with poor documentation and fearful drops into the hole known as PowerShell. However, with Exchange 2007 SP1, much of that has changed. The documentation is much better, there’s little need to fall into PowerShell, and when you do, it’s only to do a couple of things and the new documentation makes it easier to deal with PowerShell.

The only complaint I have is that certificate management is still of a problem and more complex than it needs to be. You still need to use PowerShell to request a certificate, and the rationale for why so many SANs entries are required is still missing. There has to be a better way, and there is. Check out the certificate request wizard included with OCS 2007, and you’ll see that there is a very nice wizard that allows you to configure a certificate request that includes the subject name and the SANs. It certainly makes life more pleasant.

Oh, I do miss being able to see mailbox statistics in the console. That’s something that needs to be fixed. Maybe in SP2? Or Exchange 2009? 🙂



Thomas W Shinder, M.D.

Email: [email protected]
MVP — Microsoft Firewalls (ISA)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top