About policy enforcement

Many property sheets include an Apply button, which you can click to save the configuration changes to memory. However, changes to the configuration are not actually saved to storage until you click the Apply button on the Apply Changes bar.

The Apply Changes bar appears automatically, whenever you make configuration changes. To apply the changes, click the Apply button on the Apply Changes bar. To discard the changes, click the Discard button on the Apply Changes bar. If you click Discard on the Apply Changes bar, any configuration that had been saved to memory is discarded.

When applying changes to firewall policy, Microsoft Forefront Threat Management Gateway ensures that all existing client connections comply with the new policy and terminates connections that are not allowed.

Policy enforcement takes place when a connection is established and when certain rule elements change:

• From (source) address and port
• To (destination) addresses, names, and URLs
• Schedule: When a Firewall policy rule includes a schedule, Forefront TMG will continuously ensure that a request matching that rule has not expired. If it has expired, Forefront TMG will terminate the connection if it is not currently allowed. Note that this could be caused by a change in policy or by a change in the time on the Forefront TMG server, for example, if the Forefront TMG server is rejoined to a domain and the local clock is synchronized with the domain.
• Other policy elements: User Sets and Content Types that are used to evaluate policy when the connection is first established are also used for reevaluation.

Notes:

• After you click Apply in the details pane, the policy is updated and policy reevaluation starts in background. When the reevaluation process finishes, an alert will be raised notifying that all existing firewall connections except HTTP requests were reevaluated.
• Reevaluation of existing HTTP sessions takes place the first time there is a traffic exchange along the corresponding connection. Thus it is possible that some HTTP sessions may exist in the Session Monitoring view even if they are not allowed by the new policy, as long as they do not pass any traffic.
• No custom policy elements associated with application filters are considered in policy reevaluation. For example, if you add an interface to an RPC definition used in a deny rule, existing connections to that interface will not be terminated. Similarly, if you disable an SMTP command in the SMTP Filter, existing connections that use that command will not be terminated.
• Modifications in protocol definitions (changes in protocol properties or addition of new protocols) do not affect existing connections. A connection is associated with a specific protocol (e.g., HTTP, FTP) only during connection establishment, and this association remains unchanged through the lifetime of the connection. For example, if a connection was associated with FTP protocol (port 21) and later another protocol element with the same port 21 was added, the connection will still match policy rules containing FTP protocol and will not match policy rules that do not contain FTP protocol, even if they contain the newly defined protocol.

Examples

Here are some examples of scenarios in which you change your firewall policy, to illustrate how the enforcement is applied.

Requiring Authentication

Firewall client and Web client authentication take place when the connection is established or when the first HTTP request is made. If you had initially allowed anonymous access and then changed the firewall policy to require authentication, authentication cannot be applied to the existing client connection. In this case, the connection will remain anonymous (unauthenticated) and will be terminated if there is not a rule that allows it.

Changing the Authentication Scheme

You may change the type of authentication required in a publishing rule. In this case Forefront TMG will use previous authentication information provided by the client. This may result in the session continuing, even if the client would not have been authenticated under the new scheme.

Changing the Allowed Content Type

If initially there was no restriction on the content type allowed in an HTTP access rule and a new rule allows access only for specific content types, a request for an allowed content type may be denied, and a session that uses the allowed content type may be terminated. However, in some cases, the content type can be derived from the requested URL path, and then this information will be used to match the policy. No renegotiation with the Web server will be performed.

Note:

In general, policy reevaluation of existing connections uses information that was obtained during the initial establishment of the connection rather than renegotiating the establishment of the connection with the server. If the new policy is more restrictive, that might result in termination of the connection, even if the new policy might allow it.