ISA Server and RADIUS: Two Domains And No Trust


A question from Ashok:



I've been trying to find out if one can use RADIUS to authenticate web proxy clients on another domain that is not a member of ISA domain. So I have an ISA 2004 Std with SP1 on domain A, say, and then have another internal network which connects to domain B. The question is: can I use RADIUS authentication to authenticate clients in domain B, as ISA is not part of this domain?


Short version: Yes! ISA Server 2004 Standard and Enterprise Editions both do RADIUS authentication, so it's possible.


Long version: I've covered this type of setup before to some extent, but doing it again with a real-world example might be useful.


I'd consider using the RADIUS authentication method as the authentication scheme for the Web Listener that the clients are connecting to.


The RADIUS server(s) you specify will be used to authenticate users that hit that listener. (Microsoft's RADIUS server implementation is called Internet Authentication Service, or IAS).


Horrific And Strained ISA Server Metaphors #287: ISA Server Authentication. As A Monk.


If you use any of the non-RADIUS authentication methods, ISA will try to "look within itself" to authenticate a Web Proxy client, which means that when RADIUS/IAS is not being used:



  • when standalone (not domain joined), the local account database, or
  • when a domain member, the local account database and domain accounts from its domain (and any trusted domains), or
  • when a DC, the local machine database is the domain, plus any trusted domain accounts

ISA Server will look within itself and seek answers within its Order (nudge nudge, domain hierarchy), but will not consider outside opinions. If there is no trust between the domain of the client and the Order of the ISA Server, ISA Server cannot trust that client.


So: the RADIUS authentication method gives ISA a "forget the introspection and just ask someone else" option when authenticating a client, and instead of looking within itself, ISA asks the RADIUS server to tell it whether the client is legit or not. It doesn't look within itself (or its Order) at all, it essentially becomes a slave to the RADIUS infrastructure while it makes its request.


For the actual mechanics involved (which have popped my brain every time I've tried to read them today), see this KB article.


Okay, Let's Forget That Metaphor


A helpful* picture - all clients are configured to use the ISA Server. There is no trust between these domains (which would mean that you could use Integrated auth, not be prompted for credentials every time) but they share an Internet link.



On the prompting: ISA doesn't tell the client that it's using RADIUS as such, it asks for the client credentials using Basic authentication, then takes those credentials and makes a RADIUS message with them, and fires them off at its currently preferred RADIUS server. As soon as RADIUS is in the picture on the client listener, it doesn't matter that the machine is a domain member - RADIUS will be used.


Because it's Basic authentication from the client's perspective, IE will always stop and ask the user to confirm they want to actually send their credentials to the proxy server. For this reason, a domain with trusts is a better setup from a user experience perspective for forward proxy (web browsing) users.


For web publishing, it's much more acceptable to ask for a username and password.


ISA needs all RADIUS servers it's configured to use to have the same "world view" - the same question asked of all the servers in its list must produce the same response. This makes it a little like the DNS server list on one adapter.


If your server is standalone (eg, not a domain member at all), then you'll need to configure the local IAS Server's Connection Request Policies (aka RADIUS proxying) to forward authentication requests to another IAS server in the target domain.


My God, It's Full Of RADIUS Messages


RADIUS authentication happens per request. That's chatty. One HTTP verb through the proxy equals one authentication check hitting the RADIUS infrastructure. There's a property that can be toggled to reduce the load to per-connection rather than per-request, naturally called SingleRADIUSServerAuthPerSession. There's a sample VBScript that'll toggle the property here.


Other RADIUS-related posts...


(Questions? Leave them in the comments, and I'll try to unvagueify).

Comments (0)

Skip to main content