Understanding how NTLM Credentials are validated, with ProxySG, to explain the root cause of Frequent User account lockout.

Products

• ProxySG Software - SGOS
• ASG-S200
• ASG-S400
• ASG-S500

Issue/Introduction

For the client authentication modes description, refer to the snippet below. What you have shared shows that all three client authentication methods are supported. It's always going to be the customer's choice to decide on what mode they chose to check and allow. Symantec/Broadcom does not control that.

By default, all credential types are allowed and the ProxySG appliance will try to use Kerberos (the default authentication method for Windows clients), but will automatically downgrade to a different challenge type depending on the browser/user agent capabilities.

• Allow Basic credentials—Prompts the user for a username and password to authenticate the user against the Windows Active Directory.
  
  
• Allow NTLM credentials—Uses an encrypted challenge/response that includes a hash of the password.
  
  
• Allow Kerberos credentials—Uses a ticket containing an encrypted session key in place of a user name and password. If you select this option, NTLM is automatically selected as well; in the event that the browser/user agent and/or the ProxySG are not configured properly for Kerberos, the appliance will automatically downgrade to NTLM.

Environment

IWA and Microsoft Active Directory

Cause

The lockout of a specific AD account reported in this case is, clearly not caused by/linked with the ProxySG but a clear challenge with the client sending incorrect credential, in its Type 3 message to the ProxySG, which in the final validation, gets locked out by the Active Directory.

Resolution

 

To understand how NTLM credentials are validated, and further explain how NTLM works with ProxySG, we will utilize the diagram in the snippet below.

NTLM is the password authentication protocol. IWA will prompt the user if no password was used at login. If the current user is a domain user who login with the password, the browser won't prompt for a password, assuming the Realm was properly configured. Windows caches a hash of the password at initial login. The password does not cross the wire. A different hash is sent every time. SGOS enables multiple connections to Active Directory for the validation of credentials, eliminating any possible bottleneck.

1. The process begins when a client makes a request to the ProxySG, which for the purpose of this example, is operating in Explicit Proxy mode. The ProxySG replies with a 407 HTTP response code, which prompts the client to resend the request, this time, including the credentials. The client resends the request, this time, including the NTLM Type 1 message, encoded in base 64. Please note that the client user agent (browser) is fully responsible for choosing the most secure way to pass the credentials to the ProxySG.
2. The ProxySG responds to the client with a NTLM Type 2 message. The client receives the Type 2 message which includes the challenge and calculates, using the user's password, the Type 3 message for that challenge. The client sends the Type 3 message to the ProxySG as a base 64 encoded string. The ProxySG uses the Windows NETLOGON service (Schannel communication) to pass the information to the domain controller for the final validation. If the Type 3 message contains the correct response to the challenge, the domain controller authenticates the user.
3. At this point, the ProxySG passes the original request to the Origin Content Server and the user starts receiving the requested data.

NOTE: Netlogon service on Domain Controller is responsible for creating Secure Channel between Domain Controllers and clients. Secure Channel is created to pass the authentication packets.

Once more, please note that NTLM - uses an encrypted challenge/response that includes a hash of the password. NTLM requires two trips between the workstation and the appliance, and one trip between the appliance and the Domain Controller. It therefore puts more load on the network than Kerberos, which only requires one trip between the workstation and the appliance, and doesn’t require a trip between the appliance and the Domain Controller.

The difference between hashing and encryption is that encryption enables information to be decrypted and read, while hashing is a mathematical function used to verify the validity of data. For example, a system might not need to know a user’s password to verify that password. The system can run a hash function on the password and confirm that the mathematical result matches that specified for the user.

Comparing NTLM and Kerberos:  Refer to the snippet below.

In summary, Kerberos is the recommended authentication protocol for IWA, because it is more secure than NTLM, puts the least load on the network, and is more scalable. To ensure that IWA uses the Kerberos authentication rather than downgrading to NTLM, you just need to make sure that authentication requests are directed to the Kerberos Service Principal Name associated with the ProxySG. The way you do this depends on how your IWA Realm connects to the Active Directory. Use Kerberos instead of NTLM, whenever possible.