book
Article ID: CTX222444
calendar_today
Updated On:
Description
How does LDAP Authentication work with Single Sign On using Kerberos Impersonation?
In this flow, the NetScaler is contacting the KDC after we purged tickets on the KDC, and the NetScaler.
- The client makes a GET request to the LB vServer.
- The LB vServer is configured with Form-based authentication. It therefore sends a 302 redirect to tell the client to go to the AAA vServer FQDN.
- The client contacts the AAA vServer FQDN, which is configured with an LDAP policy. The client enters their username and password in the fields provided. This is submitted as a POST request to the AAA vServer.
- The NetScaler contacts the AD to validate the users credentials.
- The AD replies with a bind response success if the credentials are valid.
- The AAA vServer sends a 302 response to the client redirecting them back to the LB vServer FQDN along with an authentication cookie.
- The client sends another GET request to the LB vServer along with the cookie. The LB vServer contacts the AAA vServer to validate the cookie.
- The NetScaler sends a GET request to the web server which is configured with Negotiate authentication.
- The web server returns a 401 Unauthorized and offers Negotiate or NTLM authentication.
- At this point the NetScaler authenticates to the KDC, impersonating the client by sending their username and password that they submitted at login. This is when the SSO Session policy is used which is configured with a ‘dummy’ KCD account that does not have a delegated user.
- The NetScaler makes two ticket requests, impersonating the client; one for the http service on the web server and the other for the realm.
- When the NetScaler receives the ticket, it makes another GET request and sends the ticket to the web server.
- The web server replies with a 200 OK and this is sent back to the client, allowing them to access the web server.
You can see the Impersonate ticket that was obtained from the KDC, located in /var/krb directory: