The authentication feature for Web Applications in NetScaler goes by the name of AAA for Traffic Management (AAA for TM). Authentication is a critical area on NetScaler, as more and more enterprises continue to make their services available over the Internet. In this chapter we will cover the following topics, including troubleshooting:

Authentication is one of those areas where knowing the flow that one should expect to see in a trace goes a long way in helping with troubleshooting. The observations made from looking at a successful authentication can serve as a baseline and help in detecting the main point of failure. Once at this point, we can then turn our attention to the individual failures and the reasons for them. As such, we will spend a good part of this chapter looking into the flow of packets, explaining each step and the important things to look at as we go along.

AAA for TM functions in one of two ways from a User experience perspective:

In both cases, SSO is optionally possible so that the dialog box or the form presented by the application is autocompleted by NetScaler, by using credentials it obtains from the User as part of the initial authentication.

Regardless of the choice of User experience chosen by the Administrator, the underlying protocol handling remains the same. Let's start looking at these protocols and the associated flows one by one.

Lightweight Directory Access Protocol

LDAP is very popular both as a directory service and for authentication and authorization. It provides an excellent level of flexibility in identifying whether a User exists, whether the credentials are correct, and what groups the User is a part of (this is called group extraction).

The ports used for LDAP are as follows:

• TCP 389: Standard LDAP
• TCP 636: Encrypted LDAP
• TCP 3268: Global catalog, unencrypted
• TCP 3269: Global catalog, encrypted

Authentication flow

The following Wireshark snapshot shows what the exchange between NetScaler and the LDAP server should look like:

LDAP

The steps here are as follows:

• bindRequest: Here, the NetScaler is authenticating itself to the LDAP server
• bindResponse: If the method used (usually SASL – Simple Authentication and Security Layer) and the credentials provided are both okay, the LDAP server responds with a success
• searchRequest: At this point, NetScaler runs through the User authentication; it starts by verifying if the username provided exists
• searchResEntry: The LDAP server confirms the existence of a User in its database
• bindRequest with User credentials: The NetScaler provides the LDAP identifier for the User and the password for the LDAP server to confirm they match
• bindResponse: The server confirms they are indeed correct
• unbindRequest: NetScaler terminates the LDAP exchange

Troubleshooting LDAP

There are two things you can do to troubleshoot LDAP:

• Take a trace on the NetScaler and compare it to the screenshot we've reviewed to see where the flow deviates or breaks.
• Take a look at the very handy aaad.debug file using cat /tmp/aaad.debug from the shell. aaad.debug is a pipe-based file which is most useful to look at when you can have a test User log in at the same time. We will revisit this file at various times in the chapter as it is relevant to all types of authentication.

Running cat on aaad.debug will start by showing who the authenticating User is:

The query used to look for the User is shown as follows:

The output should conclude with sending accept, which indicates that the authentication attempt was successful. A sending reject would indicate the contrary: