Chapter 4. AAA for Traffic Management

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:

  • Lightweight Directory Access Protocol (LDAP)
  • Remote Authentication Dial-In User Service (RADIUS)
  • Certificate authentication
  • NTLM and Form Based Authentication (FBA)
  • Kerberos, which is fast and quite mature in the enterprise
  • SAML

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:

  • Using a HTTP 401 type of authentication, where the User sees a dialog box prompting them for credentials.
  • Using FBA, where the User will be redirected to a login page. FBA is used for apps which have their own logon page. Outlook Web App (OWA) is the most common example.

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:

Authentication flow

LDAP

The steps here are as follows:

  • bindRequest: Here, the NetScaler is authenticating itself to the LDAP server
  • bindResponse: If the method used (usually SASLSimple 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:

Troubleshooting LDAP

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

Troubleshooting LDAP

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

Troubleshooting LDAP
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.40.118