Simulating Kerberos Authentications in NeoLoad

Kerberos is an authentication protocol that uses SSO (Single Sing-On) to secure networks and computer systems. It is developed by Microsoft as a part of its Kerberos protocol suite. It is a secure way of authenticating a user’s identity and granting them access to a network or system. Kerberos works by having a central authentication server that verifies user credentials and provides a ticket to the user, which is then used for authentication with other systems. Kerberos also encrypts data for added security. It is widely used in many networks and computer systems, including Windows, Linux, and Mac OS X.

Single Sign-On:

Single Sign-On (SSO) is an authentication process that allows users to access multiple applications or websites with one set of credentials. It eliminates the need for multiple usernames and passwords, allowing users to access all accounts with a single set of credentials. SSO provides a more secure, streamlined process for users to access the necessary systems.

Kerberos allows secure communication between two or more entities over a network. It works by authenticating each entity to one another and then allowing them to exchange information securely. Three major components are listed below.

1. Authentication Server

The first part of the Kerberos authentication protocol is the Authentication Server (AS). This server is responsible for authenticating users, and issuing tickets to the users that they can use to gain access to network services. The tickets contain information about the user’s identity, as well as a timestamp and a cryptographic signature.

Simulating Kerberos Authentications in NeoLoad 1

2. Ticket Granting Server (TGS):

The second part of the Kerberos authentication protocol is the Ticket Granting Server (TGS). The TGS is responsible for verifying the user’s ticket and granting them access to resources on the network. When a user attempts to access a service, they must present their ticket to the TGS, which then verifies the ticket, checks the user’s credentials, and grants access to the requested service.

Once the Client has the initial ticket then it can request a service ticket from the Ticket Granting Server (TGS). The TGS verifies the initial ticket and then issues a service ticket. This service ticket contains information about the network resource the user is requesting access to and how long the user is allowed to access it. The Client then sends the service ticket to the network resource, which verifies it.

3. Client / Users:

The third part of the Kerberos authentication protocol is the Client (Cl). The user (Client) first requests access to a network resource from the Client. The Client then sends a request to the AS, which authenticates the user and issues an initial ticket. This initial ticket contains information about the user, such as their identity and how long they are allowed to access the network.

The Client is responsible for requesting tickets from the AS and then presenting them to the TGS when attempting to access a service. The Client must also ensure that the ticket is still valid and that the user

Kerberos Configuration:

The Kerberos authentication protocol involves two main configurations:

The Kerberos Key Distribution Center (KDC): This is the server that is responsible for authenticating users and granting them access to resources. It uses a combination of encryption and authentication protocols to securely authenticate a user.
The Ticket Granting Server (TGS): This is the server that is used to grant a user access to a resource. It is responsible for issuing tickets to users to authenticate them to the resource.

How to configure Kerberos in NeoLoad?

Step 1: Go to the NeoLoad installation path, under the “conf” folder.
Example: C:\Program Files\NeoLoad 9.2\conf

Step 2: Open the file “krb5.conf”

Krb5.conf is a configuration file used to configure the Kerberos authentication system, including the default realm and any other realms that may be needed. The file contains information about the authentication realm, key distribution center and the Kerberos server.

Step 3: The configuration file contents is shown below:

Default realm: The default realm in Kerberos is the DNS domain name of the Kerberos server. Mostly it is the application host.
KDC: It is the key distribution center, referring to the KDC server.
Domain realm: Domain realm is a way of mapping an authentication realm to a domain name. The realm name is an identifier for the authentication realm.

All the above information can be procured from the Sys Admin, Principle Devs and Architects.

Step 4: Go to Edit -> Preferences -> HTTP Recorder

Enable the “Use NeoLoad to negotiate” option.

This will allow NeoLoad to automatically Negotiate the authentication with the Kerberos servers. As highlighted, this is not compatible with HTTP/2.

Step 5: Continue recording the workflow using an HTTP recorder.

Most of the requests will be equipped with the key “Authorization”, the value starts with Negotiate followed by the token as shown below.

Authorization: Negotiate + TokenKey

At times, due to compliance and policies, the performance testers are not enabled with the right krb5 configuration. Without the configuration, it is not possible to proceed with the scripting using the HTTP protocol. The alternate solution for such a blocker could be the RealBrowser protocol.

RealBrowser protocol simply bypasses most of these complexities, I recommend to check-out the RealBrowser protocol in this NL – RealBrowser Protocol.