SUPPORT WIKI: Kerberos with NetScaler

SUPPORT WIKI: Kerberos with NetScaler

book

Article ID: CTX227056

calendar_today

Updated On:

Description

Kerberos:

  • Kerberos is a network authentication protocol.
  • Kerberos was originally started in the 1989 at M.I.T to provide authentication in an unsecure world.
  • Allows user access to servers distributed throughout network.
  • In a Kerberos scenario, clients authenticate to the Key Distribution Centre or KDC and mostly Microsoft AD.

Why Kerberos?

  • Sending usernames and passwords in the clear text jeopardizes the security of the network.
  • Each time a password is sent in the clear text, there is a chance for interception.

Terms used in Kerberos:

  • REALM: It could be termed as a “group”. Machines that belong to this group.
  • KDC: (Key Distribution Center) This is the machine that controls the access, Domain Controller will be a KDC.
  • Principal: A Kerberos principal is a unique identity to which Kerberos can assign tickets. Traditionally, a principal is divided into three parts: the primary, the instance, and the realm Example: primary/instance@REALM
  • KEYTAB: A file that contains the encrypted information allowing users/machines to authenticate themselves.
  • AS: Authentication Server, A server that issues tickets for a desired service which are in turn given to users for access to the service.
  • TGT: Ticket-granting Ticket, A special ticket that allows the client to obtain additional tickets without applying for them from the KDC.
  • TGS: Ticket-granting Server, A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC.

Kerberos is based on the premise that client and KDC:

  • Communicate a list of available encryption models and select highest in common.
  • The Client sends its password to the KDC in an encrypted format.
  • The KDC decrypts and authenticates the user
  • The KDC sends back a Ticket Granting Ticket or TGT.
  • The TGT is the used moving forward to gain access to specific Ticket Granting Services or TGS.
  • The TGS gives the user credentials to access to a specific service.  A service may be a Telnet Server, Web Site, etc.
  • The TGT and TGS have short time spans. Typically 6-24 hours.

NetScaler Kerberos Overview

Starting from 10.1.120.e - Netscaler use nskrb deamon.

Major Value add with nskrb:

  • Domain Join is no longer required.
  • Kerberos tickets are cached on NS.
  • User Impersonation is supported.
  • 3 options to enable NS Kerberos Constrained Delegation. (Keytab/DelegatedUserPassword/DelegatedUserCert)
  • PKINIT Support

User-added image

Requirements on NetScaler:

  • A load-balanced virtual server
  • A back-end resource with “Windows Authentication” enabled and the correct providers set (Negotiate and NTLM)
  • AAA virtual server for authentication.
  • An authentication negotiate policy (client side authentication)
  • An authentication negotiate server (client side authentication)
  • A NTLM path URL (client side authentication)
  • A session policy/Traffic Policy for single sign on.
  • A Kerberos account
  • Some SPN’s

There are two primary forms of authentication that are typically handled through Netscaler:

  1. Kerberos Authentication (Client side).
  2. Kerberos Constrained Delegation (KCD).
  3. Kerberos Impersonation.

Kerberos Authentication (Client side):

  • Used for logging into AAA TM V server on Netscaler just like other authentication mechanisms.
  • Not to be confused with SSO to backend.
  • With the release of Netscaler 11 build 64.34, the requirements and configuration for NTLM authentication have changed.
  • Where the Users can authenticate via Kerberos when internal on the network but fall back to NTLM when external and the users active directory is unreachable.

Kerberos Constrained Delegation:

  • Can be used even when user’s password is not available to Netscaler.
  • All forms of client authentication methods are supported.
  • Examples: Smart cards, Certificates, SAML, Kerberos, OTP, forms login.
  • Extra configuration required on AD and on Netscaler.
  • On AD, a delegated user account needs to be created.
  • On Netscaler, extra parameters need to be specified in KCD Account For each realm, a separate delegated account needs to be created to delegate services in that realm.
  • A delegated account cannot be used to obtain tickets for the realm it does not belong to.

Kerberos Impersonation:

  • Can be used when Netscaler has AD password of the user.
  • No additional configuration is necessary on AD.
  • User can access service belonging to any realm without any configuration.
  • User and service can be in different realms.
  • E.g.: AD/Radius login