0

I am running Forefront TMG SP1 rollup 3. All desktop clients will have the Firewall Client installed. Servers will not.

I would like to segregate my outbound network traffic according to traffic which has been successfully authenticated in one rule and that which has not authenticated into another. This segregation will eventually be used to treat the traffic differently.

Given that I have two Internal->External HTTP / HTTPS allow rules listed - the first requiring authentication and the second not - would this provide the desired behavior? I know that any rule requiring authentication that blocks traffic will inherently block any traffic that does not have authentication enabled.. I'm just a bit fuzzy whether or not a similar issue would crop up with an allow statement. I'm also concerned if adding a rule containing authentication for HTTP / HTTPS like this would impact any non HTTP* rules, e.g. SMTP which I would like to keep lower in the rule chain.

Ricardo Polo Jaramillo
  • 2,039
  • 1
  • 18
  • 35
Tim Brigham
  • 15,465
  • 7
  • 72
  • 113

2 Answers2

0

I built a test environment and applied my proposed configuration onto a single IP. Unfortunately it appears that if an authenticated rule is used within Forefront the authentication isn't treated as part of the rule but is post processed - all traffic is routed to that rule and if the traffic is anonymous it is automatically discarded.

I had hoped that in a well designed product that the user criteria would be treated as part of the main rule definition - if the criteria is not met the traffic would roll to the next rule in the chain. This is not the case.

Tim Brigham
  • 15,465
  • 7
  • 72
  • 113
0

The answer above describes a rule ordering problem.

Anonymous rules must be processed before authenticated rules; it's not possible to ask a client for authentication speculatively, based on where you think it's going to end up going.

In HTTP terms, the first GET is always anonymous, so the anon rules have to come first in order not to be authentication-gated.

Practically speaking, this means that you can have multiple authenticated rules referring to the same destination, or a single anonymous rule first, but not an authenticated rule that doesn't cause the user to authenticate, and then an anonymous rule. I'm not sure there's a design that can accommodate this.

Auth'd rules for web proxy clients are partitioned by protocol, source, namespace, and various other knobs, so yep, you can have rules that apply to HTTP that don't necessarily authenticate SMTP (top tip: have separate web from non-web protocol rules); have rules that apply only based on source subnet or destination URL set, etc.

Still the best reference to ISA/TMG rule processing:

http://technet.microsoft.com/en-us/library/bb794766.aspx

Community
  • 1
TristanK
  • 8,953
  • 2
  • 27
  • 39
  • 1
    Thanks @TristanK. Pretty much the same thought I came up with. My gripe with this theology is simple. For an allow rule with authentication in place there is no reason that unauthenticated traffic should automatically be denied - if the traffic can't pass authentication it should continue being processed by rules lower in the rule chain. – Tim Brigham Oct 21 '11 at 13:29