How does Negotiate authentication work on the AAA-TM vServer?

When an AAA-TM authentication virtual server uses the Negotiate method as its only form of authentication, it will challenge the client to use either Negotiate or NTLM authentication.

Internal clients that are on the domain and able to reach the KDC for a ticket will opt for Negotiate. Note that in order for the internal client to be able to obtain a ticket for the TM vServer, a service principal name needs to be created for the relevant virtual servers on the KDC.

External clients that are not able to reach the KDC will choose NTLM. An NTLM path needs to be specified in the Negotiate Server configuration to accommodate these external clients.

In both instances, after authenticating through the AAA vServer, Kerberos Constrained Delegation is used to single sign on to any backend resource that uses Kerberos authentication.

Negotiate with KCD SSO (Internal) Process

1. When a client makes a request to access a Traffic Management virtual server that is protected by a 401-based AAA virtual server, the TM vServer will reply to a client request with a 401 Unauthorized response. The response will specify Negotiate and NTLM as the authentication choices for the client. If the client is able to contact the KDC, it will use the Negotiate method over NTLM.
   • 
2. The internal client requests a ticket for the TM vServer, such as a Content Switch or Load Balancing vServer FQDN. The KDC deals with the client authentication by requesting their username and password in an encrypted format.
   • 
3. The KDC uses the client's private key to decrypt the credentials and authenticate the client. It then issues the client with a ticket to access the TM vServer.
   • 
4. The client sends the ticket along with another GET request to the TM vServer. At this point, front end authentication is complete and the NetScaler forwards the GET request to the backend web server. If the web server also requires Negotiate authentication, the NetScaler will need to provide its own ticket to access the resource.
   • 
5. The NetScaler uses the Kerberos daemon (part of the AAA process) to communicate with the KDC and request a ticket to access the web server.
   • 
6. The NetScaler must submit its credentials, which are usually in the form of an encrypted keytab file. The KDC then provides the NetScaler with a ticket to access the web server.
   • 
7. Now the NetScaler is able to access the website hosted on the web server and send this back to the client.
   • 

Take a look at the following flow chart for this process:

In this flow, the client is contacting the KDC after we purged tickets on the client, the KDC, and the NetScaler.

1. The client makes a GET request to the LB vServer. The LB vServer contacts the AAA vServer.
2. The AAA vServer is configured with a Negotiate policy and therefore returns a 401 unauthorized back to the client.
3. The client then contacts the KDC and authenticates itself. The client is on the domain and the browser is configured to automatically pass through their domain credentials for Windows Integrated Authentication. Therefore the client does not need to enter their username and password. You can identify the user in the AS Request by checking the cname.
4. Once authentication is successful, the client requests a ticket to access the LB vServer. You can see the request for HTTP/LB vServer FQDN in the SNameString.
5. The KDC provides a ticket to the client. You can see the lb vserver FQDN in the SnameString of the response.
6. The client then sends another GET request along with the ticket. You will see the encrypted ticket in the Negotiate field of the HTTP header. At this point, authentication at the front end is complete.
7. The NetScaler contacts the backend webserver with a GET request.
8. The web server is also configured with Negotiate authentication and therefore sends a 401 unauthorized response.
9. The NetScaler contacts the KDC and must authenticate itself. It needs to use the delegated username and password as the client did not provide their own password when authenticating.
10. At this point the NetScaler receives a TGT from the KDC (located in /var/krb) in the AS Response.
11. After successful authentication, the NetScaler requests a ticket on behalf of the user. It extracts the username from the ticket that the client sent to the NetScaler and places this in the first TGS-Request, as part of the ‘Kerberos > tgs-req > padata > PA-DATA PA-FOR-USER > padata-type > padata-value > name > name-string > KerberosString’.
12. The KDC provides an s4u2self ticket for the NetScaler delegated user. You can see this in Kerberos > tgs-rep > ticket > sname > sname-string. The s4u ticket is located in /var/krb.
13. The NetScaler then makes a TGS request for the http/web server FQDN service using the client’s cname. You will see the client’s cname and the http/web server fqdn sname as part of the AS Response.
14. The NetScaler makes a TGS request for the realm using the delegated user. You can see the NetScaler KCD cname and the sname realm in the AS Response.
15. The NetScaler then makes another GET request and sends the negotiate ticket with the request.
16. The backend returns a 200 OK, which the NetScaler forwards to the client.