Here's a quick checklist of the items that need to be in place for KCD to function properly:
- On the Active Directory Server:
- AD account representing the NetScaler as a system User that can obtain tickets for other users
- Keytab for this NetScaler User
- Constrained delegation enabled for the NetScaler system account
- List of resources that the end User can delegate to NetScaler for authentication
- On the Web Server:
- Kerberos enabled on the site
- Best practice is to have NTLM enabled as fallback
- On the NetScaler:
- Authentication on the LB VIP. The server is added on the NetScaler with its domain/hostname – this is very important. The domain controller should also be able to resolve the hostname correctly:
- Authentication vServer with authentication and session/traffic policies
There are a couple of choices available for implementing Kerberos:
- Impersonation versus Delegation: To impersonate a User in the impersonation scenario, NetScaler needs the credentials of the User. It then uses these User credentials to obtain tickets on behalf of the User. In the case of delegation, the User provides just the username to the NetScaler, which has a delegation-capable account on AD created for it and can do the rest. The ability to get tickets this way is very powerful because it means the User can, for example, just send a certificate and NetScaler can SSO the User by obtaining tickets on behalf of the User.
- Kerberos with and without Protocol Transition: Kerberos can be deployed end to end if all machines accessing the resource are part of a domain and can talk to the KDC. More common, however, is the scenario of users coming in externally, using a different authentication mechanism (such as Client Certificates, or LDAP or SAML), and then have the NetScaler talk Kerberos in the backend. This is called Protocol Transition (S4USELF).
The following trace snapshot, taken on a client, shows the exchange that needs to happen so that end-to-end Kerberos authentication (in other words, without Protocol Transition) can work:
The flow as it happens:
- The client tries to access a page hosted via the NetScaler.
- NetScaler challenges the client, and on seeing the possibility to negotiate (that is, see the negotiate header), which indicates Kerberos is available, the client chooses to use it, since it's the preferred authentication mechanism. The following is how that negotiated response looks:
- The client then requests a TGT from the KDC using the
AS-REQrequest. - The AS component of the KDC provides the TGT in the response
AS-REP. A session key is also provided in this response. This TGT is something you can see on the client machine and this is handy for troubleshooting. - The client still needs a ticket for the specific service it's trying to access. It sends a
TGS-REQfor this purpose to the TGS component of the KDC. This will contain the clients TGT it obtained in the previous step along with something called an authenticator. This is basically an encrypted form of the client's name and the current time stamp. The presence of this timestamp helps offer protection against replay attacks. - The TGS responds with a service ticket along with a session key.
- The client now sends the same request but, to prove it has authenticated, presents the service ticket and again, an authenticator (see the following figure).
- The NetScaler, which is fronting the server, is happy to let the client through this time and provides the resource requested (200 OK).
Here's a screenshot of Kerberos in action:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.