ISA 2004: Why RADIUS Authentication is Cool

One of the coolest new features available with ISA 2004 is RADIUS authentication for Web Publishing rules. So, why is this a big deal? Why is this even necessary?

Here's the list off the top of my head:

• ISA no longer needs to be a domain member to authenticate clients in authenticated Web Publishing scenarios
  • If you're in a multi-tier firewalled environment, this is really useful - you open two ports specifically for RADIUS, rather than either straddling the internal firewall with a dual-NIC scenario (making ISA a domain member) or swiss-cheesing the firewall and creating trust relationships.
    • I personally think you could probably replace any given "regular" firewall with an ISA 2004 domain member, but I'll put that aside for now.
  • You could authenticate clients against different domains with no trust relationships between them! (assumption, untested),
• RADIUS is an open authentication mechanism - any RADIUS compliant authentication provider can be used - it's like outsourcing your authentication
  • Windows provides the Internet Authentication Service (or IAS, the Windows Server RADIUS server) that can be used to authenticate Windows users, and even (I noticed the other day) forward authentication requests to another RADIUS server in a chain (so you can directly authenticate those 'nix folk with their own directory server, as long as they can do RADIUS too)

Web Browsers don't understand RADIUS as an authentication type, so ISA challenges the client for Basic authentication credentials, then creates a RADIUS Access Request packet that it sends to its chosen RADIUS server. If the RADIUS server responds with an Access-Accept, then the user is allowed through; an Access-Reject predictably causes authentication to fail. Assuming the user is successfully authenticated, Basic Delegation can then be enabled to allow the previously submitted credentials to be forwarded directly to the published Web Server, allowing a single-sign-on- like experience.

So - the short version: decoupling authentication from the underlying Windows infrastructure has some real benefits for some scenarios.

Possible drawbacks as I see them:

• Probable need for encryption of RADIUS traffic (don't trust your back-end). PAP over RADIUS isn't as insecure as Basic over the Internet, but I'm sure it doesn't take too long to brute-force; might be better to protect it and not risk that in the first place. (See the ISA 2004 help on RADIUS authentication; IPSec is recommended)
• Every time a rule is "hit" by a client, RADIUS reauthenticates the client (same as regular authentication, just noting that you'll see a lot of RADIUS traffic on busy sites instead of a lot of regular Domain authentications)
• ISA doesn't include a lot of information in the Access-Request packet (NAS IP, NAS Port, Username, Password), so differentiation between ISA and other services might have to take place based on the extra information included by those services, if they're all run on the same machine. For example, RRAS acting as a VPN server (from memory) provides more information in the Access-Request than ISA, so if you needed different VPN and OWA authentication policies on the same ISA Server, you might need to dig into the differences between the two request types.

So, my take is that it's a really useful feature. Adds a nice big tick to the "plays well with others" column.