Web Farms
On a Web farm, the AuthFilter allows an authenticated user on one server access to a site on another server without the user having to resubmit login information. However, if the request is sent with the Post method using non-sticky load balancing, any information contained in the header body is lost during the required redirection. Only use the Post method with sticky load balancing. If using non-sticky load balancing, always use the Get method (and HTTPS if concerned about security).
When using the AuthFilter, follow these deployment scenarios:
Have all sites in the same directory, for example, www.microsoft.com/bookstore and www.microsoft.com/msdn. Do not have one site in the subdirectory of another site, for example, www.microsoft.com and www.microsoft.com/bookstore.
Use dissimilar names for sites in the same directory. A site name should not be a subset of another site name, for example, www.microsoft.com/retail and www.microsoft.com/retail2.
These requirements are due to the dependence of the AuthFilter on cookies. If the AuthFilter is not used and the ticket is placed in a URL query string, a site can be in a subdirectory of another site.
When the authenticated user arrives at a new server for the first time, the following steps are performed:
The AuthFilter checks for the correct URL (auto-corrects for case sensitivity).
The AuthFilter checks for session-cookie support.
The AuthFilter checks for the MSCSAuth ticket.
The AuthFilter checks that the MSCSAuth ticket is valid (by comparing the current time to the last login time plus the time window specified on the ticket).
Since the password cache is not shared between hosts, and this is the first time the user visited this site, there is no entry in the cache corresponding to the user ID in the ticket. Detecting this, the AuthFilter resets the MSCSFirstRequestedURL cookie property to the current requested URL.
Processing is passed to the login page.
On the login page, once it is verified that this is not a Submit action and the user has a valid MSCSAuth ticket, the user ID is retrieved from the ticket and used to retrieve the profile of the user.
The password of the user is retrieved from the profile and appended to the requested URL query string along with the user ID. The password must be available in clear text. For more information about using a clear text password, see Clear Text Password in Active Directory.
The user is redirected to the requested URL and, when notified of the event by IIS, the AuthFilter removes the user ID and password from the query string and places them into the cache.
When the browser resubmits the request, the AuthFilter checks the cache, finds the corresponding entry, and checks if the current time is within the time window.
If the current time is within the time window, the AuthFilter passes processing to IIS.
If the user has access rights to the requested URL, it is processed and returned by IIS.
Web Farms Using Proxy Accounts
Consider a user, with a valid ticket which contains a proxy account ID, who visits a new site on a Web farm. The AuthFilter uses the proxy account ID to retrieve the profile of the user. Since the proxy account ID does not have a profile associated with it, the ticket is considered invalid. The user is denied access and is redirected to the login page. For more information, see Proxy Accounts.
To circumvent this, add the custom guid property to the ticket using the AuthManager object. Once set, the AuthFilter uses the guid property to access the password cache instead of the proxy account ID. When the GUID is not found in the password cache, the AuthFilter uses the user ID from the MSCSAuth ticket, instead of the proxy account ID, to look up the profile. In this case, the profile should exist, and the user is redirected to the originally requested URL. For more information about this technique, see Distributed Denial of Service Attacks.