Improving Web Proxy Client Authentication Performance on ISA Server 2006

  • Article

This document provides information about exciting new improvements in performance and scalability when existing environments are configured to use Internet Explorer 7 with ISA 2006.

We’ll review two scenarios. The first scenario we’ll review will be an environment using Internet Explorer 6 (or lower) and ISA Server 2006. We’ll explore the drawbacks of relying on the fact that the most secure method of proxy authentication IE6 is capable of is NTLM.

In the second scenario, we’ll view the same environment, but the client will use Internet Explorer 7. We’ll recognize the vast performance improvements using Kerberos authentication against the proxy will make possible

Current Web Proxy Authentication

In our first scenario, we have is a mixed environment where the clients are using Windows 2000, Windows XP and Windows Vista. Our sample company, Contoso is trying to restrict the Internet access for some users or groups and with this the need to authenticate each access against the Domain Controller is inherent.

Bb984870.36e240ab-653d-4827-9e7c-774bed3e67cf(en-us,TechNet.10).gif

Figure 1 - Existing mixed scenario.

How NTLM works on Web Proxy's Authentication

The NTLM authentication method (used since Windows NT) will be used if the Internet Explorer is configured to use “Windows Integrated Authentication” and if it is configured to use a Proxy Server. This is a known limitation in Internet Explorer 6 (or lower) and is explained in KB 321728 that you can find at Microsoft Help and Support.

Although in the first scenario (see figure 1) we have a Windows Server 2003 Domain and the native support to use Kerberos, NTLM will still be preferred authentication method for Internet Explorer 6 while browsing the Internet through a Proxy.

In larger environments with high volumes of NTLM authentication requests, the ISA Server must constantly validate users’ credentials against the Domain controllers and his authentication can became a bottleneck. The reason why it can be considered a bottleneck is due the limitations on NTLM to distribute the authentication load among the Domain Controllers available on the domain.

On the diagram below we have an example of how the NTLM authentication happens on this scenario:

Bb984870.c036f348-a615-4a78-8ee9-b92ae8cc3c70(en-us,TechNet.10).gif

Figure 2 – Internet Explorer 6 using Windows Integrated Authentication and Proxy.

On the sequence below you have the network traffic caused by the flow described on the Figure 2:

Packet 1:

09:01:40.997ClientSRVISAHTTPHTTP: Request, GET https://www.microsoft.com/

Packet 2:

09:01:41.046SRVISAClientHTTPHTTP: Response, HTTP/1.1, Status Code = 407

Frame:

+ Ethernet: Etype = Internet IP (IPv4)

+ Ipv4: Next Protocol = TCP, Packet ID = 49356, Total IP Length = 1500

+ Tcp: Flags=....A..., SrcPort=HTTP Alternate(8080), DstPort=1076, Len=1460, Seq=3551532728 - 3551534188, Ack=2130687314, Win=65247 (scale factor not found)

- Http: Response, HTTP/1.1, Status Code = 407

- Response:

ProtocolVersion: HTTP/1.1

StatusCode: 407, Proxy authentication required

Reason: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )

Via: 1.1 SRVISA

+ ProxyAuthenticate: Negotiate

+ ProxyAuthenticate: Kerberos

+ ProxyAuthenticate: NTLM

Connection: Keep-Alive

Proxy-Connection: Keep-Alive

Pragma: no-cache

Cache-Control: no-cache

ContentType: text/html

ContentLength: 4106

HeaderEnd: CRLF

+ payload: HttpContentType = text/html

Packet 3:

09:01:41.050ClientSRVISANTLMSSPNTLMSSP: 74 Bytes

Frame:

+ Ethernet: Etype = Internet IP (IPv4)

+ Ipv4: Next Protocol = TCP, Packet ID = 2797, Total IP Length = 428

+ Tcp: Flags=...PA..., SrcPort=1076, DstPort=HTTP Alternate(8080), Len=388, Seq=2130687314 - 2130687702, Ack=3551537239, Win=65535 (scale factor not found)

- Http: Request, GET https://www.microsoft.com/ , Using NTLMSSP Authentication

- Request:

Command: GET

+ URI: https://www.microsoft.com/

ProtocolVersion: HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Accept-Language: en-us

UA-CPU: x86

Proxy-Connection: Keep-Alive

UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)

Host: www.microsoft.com

+ Authorization: NTLM TlRMTVNTUAABAAAAB7IIogkACQAtAAAABQAFACgAAAAFAs4OAAAAD1NQU1JWTldUUkFERVJT

HeaderEnd: CRLF

Packet 4:

09:01:41.506SRVISA DCNWTR MSRPCMSRPC: c/o Request: unknown Call=0xB Opnum=0x27 Context=0x0 Hint=0x154

Packet 5:

09:01:40.507DCNWTR SRVISA MSRPCMSRPC: c/o Response: unknown Call=0xB Context=0x0 Hint=0x25C Cancels=0x0

Packet 6:

09:01:41.328SRVISAClientHTTPHTTP: Response, HTTP/1.1, Status Code = 200

As you can see, using NTLM for Web Proxy authentication makes the ISA Server the main resource in use. In other words, all authentication requests that are sent to the ISA Server needs to be checked with the Domain Controller and ISA will be responsible for doing that all requests that needs authentication.

Looking into the performance monitor on the Domain Controller we can see that the counter NTDS\NTLM Authentications increased during this operation.

Bb984870.aa62545b-69d6-4bd1-86e1-c7339bdf2db6(en-us,TechNet.10).gif

Figure 3 – Performance Monitor from the DC1.

Recently Microsoft release an update for Windows Server 2003 SP1 and SP2 that allow you to obtain more information regard the NTLM authentication. For more information about this update and how to use it, see the New performance counters for Windows Server 2003 let you monitor the performance of Netlogon authentication at Microsoft Help and Support.

NTLM and Heavy Load Authentication Traffic

As prior explained, the NTLM will make the ISA Server busy trying to authenticate user’s access for each request. There are problems that might happen when the environment and the authentication request grow.

The main problem arrives due the fact that the ISA Server will send NTLM authentication request to the Domain Controller that it has already established a secure channel with. This means that in an environment with three Domain Controllers (as show in the figure 2), the ISA Server does not load balance the authentication request among them.

You can improve the authentication throughput by changing the parameter MaxConcurrentApi as described on the article How to configure an ISA Server computer for a very large number of authentication requests at Microsoft Help and Support, but this will also continue to put pressure on a single Domain Controller.

When the Domain Controller is too busy to handle the amount of authentication requests sent by the ISA Server it will start to queue up those requests. If this happen the error “NlAllocateClientApi timed out” and “NlpUserValidateHigher” will be logged on the netlogon.log of the ISA Server. When the netlogon log shows that the API timed out, it typically means that it was waiting longer than 45 sec for a slot to open up, as no slot opened up, ISA abandons the authentication attempt. To see this log it is necessary to enable the logging of the netlogon service. To know how to enable the Netlogon logging use the Microsoft KB Article Enabling debug logging for the Net Logon service at Microsoft Help and Support.

Bb984870.adcf9ef5-408b-4f8d-8d04-01c40bbb241f(en-us,TechNet.10).gif

Figure 4 – Logon related API calls with MaxConcurrentAPI.

As you can see on the figure above when the MaxConcurrentAPI parameter is incremented, more logon calls will be sent at the same time on the same existing secure channel between ISA Server and the Domain Controller. As previously stated, increasing this parameter to more than five can affect the performance of the Domain Controller where this parameter was changed.

Note

Although the default value is 0, this zero doesn’t means that no API calls will be used. The default value means that one logon will be send on the secure channel. More information about this parameter see the MaxConcurrentApi at Microsoft Registry Reference.

When the ISA Server quits due to no response from the Domain Controller the events below will be logged on the event viewer:

Type : Error

Event ID : 5719

Source: NETLOGON

Message: This computer was not able to set up a secure session with a domain controller in domain DOMAINNAME.

Type: Error

Event ID: 5783

Source: NETLOGON

Message: The session setup to the Windows NT or Windows 2000 Domain Controller \\DCNAME for the domain DOMAINNAME is not responsive.

Note

This is not an exclusive situation where those events will appear on the Event Viewer. For more information about other scenarios where these logs might appear, see the article Troubleshooting Intermittent Pop-up Credentials in ISA Server 2004 at the ISA Server Team Blog.

The ISA Server at this point will reset the secure channel with this Domain Controller and will try to establish a new secure channel with a different DC. The problem with this gap is that it will enough to the client receive the authentication window asking for the user to type the credential.

Multiple Domains Scenario and the Impact on the Authentication

The fact that the Domain Controller might be so busy to answer the request in timely fashion is not the only scenario that can expose this problem. There are others situations where this also can happen. The scenario below is another example of an environment where this issue is predisposed to happen:

Bb984870.1d5c2d08-4646-47dd-9ab7-fb2d50a17894(en-us,TechNet.10).gif

Figure 5 – Scenario where the client tries on a remote domain tries to access the Internet through the ISA Server using NTLM.

Following the arrows (blue for request and red for answer) we can see the whole path that it takes to the client be allowed to access the Internet from the remote branch. The problem might happen here if the branch office connects to headquarter through a slow WAN link. This environment is predisposed to have the issue mentioned because the remote Domain Controller (Rdc1.branch.nwtraders.msft) might take too much time to answer the request from the Domain Controller located on the headquarter (Dc1.nwtraders.msft). If this happen the DC1.nwtraders.msft will start to queue up the request and the ISA Server in certain point might reset the secure channel because is not receiving an answer from the DC1.

This kind of scenario is really hard to identify who is the culprit because monitoring only the servers located in headquarter might hide the root cause. The server’s performance might show that they are with free resource available and that they are not busy at all. On large environments where the whole Internet access is concentrate on one single point the authentication throughput will be really heavy and this issue might be exposed in some situations.

Distributing the Load with Kerberos

Using Kerberos to authenticate user’s credential via Internet Explorer is much more optimized and robust. When the environment required load distribution among the Domain Controllers, the Kerberos can optimize the authentication process and avoid authentication bottlenecks during the authentication.

Here are some advantages to using Kerberos authentication on Internet Explorer 7 using ISA Server as Proxy when compare with NTLM:

  • Removes the high intensive workload that we have from the ISA Server to a single Domain Controller;
  • The client is responsible to obtain the authorization (Kerberos Ticket-Granting Service Request) from the Domain Controller when ISA Server requests authentication to access a web site;
  • The authentication request will be distributed among all Domain Controllers (KDCs) available in the domain.

With this in mind, the following is the step by step authentication process using Kerberos. It is important to emphasize the following components on this scenario:

  • Client workstation is a Windows XP SP2 with Internet Explorer 7 using ISA Server’s FQDN on the Proxy Server option;
  • On the ISA Server we have a firewall rule that allows only members one specific group to access the Internet;
  • ISA Server is a domain member;

Understanding the Authentication Process

On following the network monitor trace it will be possible to understand the advantages mentioned on the previous session:

Bb984870.263685d6-ca53-494f-8a99-ab6f9dbbfb5a(en-us,TechNet.10).gif

Figure 6 – Internet Explorer 7 using Windows Integrated Authentication and Proxy.

  1. Client sends the request to the ISA Server to access the URL www.microsoft.com/donwloads
    09:19:35.76710.10.10.10010.10.10.1HTTPHTTP: Request, GET https://www.microsoft.com/downloads

  2. ISA Server checks that authentication is require and sends the authentication request:
    09:19:35.83810.10.10.110.10.10.100HTTPHTTP: Response, HTTP/1.1, Status Code = 407
    Frame:
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Next Protocol = TCP, Packet ID = 52025, Total IP Length = 1500
    + Tcp: Flags=....A..., SrcPort=HTTP Alternate(8080), DstPort=1118, Len=1460, Seq=3345821577 - 3345823037, Ack=58669284, Win=64952 (scale factor not found)
    - Http: Response, HTTP/1.1, Status Code = 407
    - Response:
    ProtocolVersion: HTTP/1.1
    StatusCode: 407, Proxy authentication required
    Reason: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )
    Via: 1.1 SRVISA
    + ProxyAuthenticate: Negotiate
    + ProxyAuthenticate: Kerberos
    + ProxyAuthenticate: NTLM
    Connection: Keep-Alive
    Proxy-Connection: Keep-Alive
    Pragma: no-cache
    Cache-Control: no-cache
    ContentType: text/html
    ContentLength: 4106
    HeaderEnd: CRLF
    + payload: HttpContentType = text/html

    Note

    As you can see ISA Server sends the authentication options that are supported.

  3. The Internet Explorer 7 configure with the ISA Server’s FQDN as Proxy will use Kerberos as preferred method and it will send the KRB_TGS_REQ (Kerberos Ticket-Granting Service Request) to the Domain Controller (KDC).
    09:19:35.83610.10.10.10010.10.10.9KerberosV5KerberosV5: TGS Request Realm: NWTRADERS.MSFT Sname: HTTP/srvisa.nwtraders.msft
    Frame:
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Next Protocol = UDP, Packet ID = 467, Total IP Length = 1396
    + Udp: SrcPort = 1119, DstPort = Kerberos(88), Length = 1376
    - Kerberos: TGS Request Realm: NWTRADERS.MSFT Sname: HTTP/srvisa.nwtraders.msft
    - TgsReq: Kerberos TGS Request
    + ApplicationTag:
    - KdcReq: KRB_TGS_REQ (12)
    + SequenceHeader:
    + Tag1:
    + Pvno: 5
    + Tag2:
    + MsgType: KRB_TGS_REQ (12)
    + Tag3:
    + PaData:
    + Tag4:
    - ReqBody:
    + SequenceHeader:
    + Tag0:
    + KdcOptions: 0x40800000
    + Tag2:
    + Realm: NWTRADERS.MSFT
    + Tag3:
    + Sname: HTTP/srvisa.nwtraders.msft
    + Tag5:
    + Till: 09/13/2037 02:48:05 UTC
    + Tag7:
    + Nonce: 616863697 (0x24C497D1)
    + Tag8:
    + Etype:

  4. The Domain Controller (KDC) replies with the Ticket-Granting Service Reply KRB_TGS_REP.
    09:19:35.83810.10.10.910.10.10.100KerberosV5KerberosV5: TGS Response Cname: Administrator
    Frame:
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Next Protocol = UDP, Packet ID = 46775, Total IP Length = 1371
    + Udp: SrcPort = Kerberos(88), DstPort = 1119, Length = 1351
    - Kerberos: TGS Response Cname: Administrator
    - TgsRep: Kerberos TGS Response
    + ApplicationTag:
    - KdcRep: KRB_TGS_REP (13)
    + SequenceHeader:
    + Tag0:
    + PvNo: 5
    + Tag1:
    + MsgType: KRB_TGS_REP (13)
    + Tag3:
    + Crealm: NWTRADERS.MSFT
    + Tag4:
    + Cname: Administrator
    + Tag5:
    + Ticket: Realm: NWTRADERS.MSFT, Sname: HTTP/srvisa.nwtraders.msft
    + Tag6:
    + EncPart:

    Note

    When the Kerberos client receives the KDC's reply, it extracts the ticket and the user's copy of the session key, putting both in the user credentials cache (located RAM, not on disk).

  5. The client sends the answer back to ISA Server (the request was done on step 2) with the authorization (service ticket) to access that resource.
    09:19:35.84010.10.10.10010.10.10.1KerberosV5KerberosV5:
    Frame:
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Next Protocol = TCP, Packet ID = 468, Total IP Length = 1500
    + Tcp: Flags=....A..., SrcPort=1118, DstPort=HTTP Alternate(8080), Len=1460, Seq=58669284 - 58670744, Ack=3345826088, Win=65535 (scale factor not found)
    - Http: Request, GET https://www.microsoft.com/downloads
    - Request:
    Command: GET
    + URI: https://www.microsoft.com/downloads
    ProtocolVersion: HTTP/1.1
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
    Accept-Language: en-us
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
    Host: www.microsoft.com
    Proxy-Connection: Keep-Alive
    Cookie: MC1=GUID=511df6e3353e114484771baab2025cc0&HASH=e3f6&LV=20078&V=3; A=I&I=AxUFAAAAAABzBwAA/1L4rtZO5r4ju9WXeqEdeA!!&CS=101CF\0; stI=Fri, 17 Aug 2007 02:39:47 UTC; WT_FPC=id=72.190.78.223-1555963424.29874931:lv=1186702800657:ss=1186702800657
    - Authorization: Negotiate YIIFKwYGKwYBBQUCoIIFHzCCBRugJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBPEEggTtYIIE6QYJKoZIhvcSAQICAQBuggTYMIIE1KADAgEFoQMCAQ6iBwMFACAAAACjggP3YYID8zCCA++gAwIBBaEQGw5OV1RSQURFUlMuTVNGVKIoMCagAwIBAqEfMB0bBEhUVFAbFXNydmlzYS5ud
    WhiteSpace:
    - NegotiateAuthorization:
    - Scheme: Negotiate
    Kerberosv5:

  6. ISA Server sends the page to the client:
    09:19:42.18210.10.10.110.10.10.100HTTPHTTP: Response, HTTP/1.1, Status Code = 200

Next time that the client workstation needs to access another web page it will send to the ISA Server a message that consists of the ticket, which is still encrypted with the server's secret key, and an authenticator, which is encrypted with the session key. The ticket and authenticator together are the client's credentials to the server.

The client does not need to go back to the Domain Controller (KDC) each time it wants access web sites through ISA Server, this because service tickets can be reused. To guard against the possibility that someone might steal a copy of a ticket, service tickets have an expiration time that is specified by the KDC in the ticket's data structure. The default ticket expiration time is 10 hours.

You can manage the tickets that were issued using the utility klist. To find more information about Kerberos List, see “Windows Server 2003 Resource Kit Tools Help” in the Tools and Settings Collection.

Additional Information

Additional ISA Server 2006 documents are available on the ISA Server 2006 Guidance page at the Microsoft Windows Server System Web site (https://www.microsoft.com).

Also, refer to the following Knowledge Base (KB) articles and Microsoft TechNet Web articles:

Do you have comments about this document? Send feedback.

Credits

Author:

Yuri Diogenes (Microsoft Security Support Engineer – ISA Server Team)

Technical Reviewers:

Adam Richards (Microsoft Security Support Engineer – ISA Server Team)

Tristan Kington (Microsoft Escalation Engineer – ISA Server Team)

Masoud Hoghooghi (Microsoft Escalation Engineer – ISA Server Team)

Jim Harrison (Microsoft Product Team Manager – ISA Server Team)

Doron Juster (Senior SDE – FroreFront Product Team)

Ming Chen (Microsoft Escalation Engineer – Directory Services Team)

Editor:

Nathan Bigman (Microsoft Content Manager – ISA Server Team)