Following on from yesterday’s post where the ISA Server wasn’t a member of either domain, this time we’re looking at how you’d configure a more seamless (eg, not prompted for credentials left and right) experience for the users in Domain A, while making the poor users in DomainB provide their credentials every time they tried to use the proxy.
[Aside: I’ll call it out here: for the best browsing experience for the users in both domains (outside of disabling proxy authentication altogether), you really want a Trust relationship between Domain A and B – that way, everyone can use Integrated authentication, and nobody gets prompted. If you’re pretty sure the other domain are out to get you (remember, a Trust doesn’t necessarily confer any permissions, but does increase the breadth of Authenticated Users), a resource domain model (ISA Server is the resource, the user domains are trusted by the resource) would probably work.]
Anyway, today, ISA’s a member of Domain A, which means that Integrated Authentication is on the cards for users from that domain.
We’re still going to have to use RADIUS for users from the other domain, because there’s no trust. (There are “account mirroring” solutions to this type of problem, but they’re a pain in the bum, so I’m not going to go into them.)
If you plonk one network adapter (or NIC, or network interface card) in each network, you can configure different authentication properties for each NIC’s Web Proxy listener.
This time around, ISA is a common point of access to the Internet, and could also be used as a router between the two internal networks, but we’re just focusing on the web proxy case for now.
The arrows on the Internal listener aren’t indicating confusion, just that the machine can also be authenticated against, as well as using the secure channel to talk to a DC.