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.
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:
.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 http://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 http://www.microsoft.com/ ,
Using NTLMSSP Authentication
- Request:
Command: GET
+ URI: http://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.
.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.
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.
.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.
.gif) 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.