Authentication

NeoLoad supports the following authentication mechanisms: Basic, Digest, NTLM, and Negotiate. When your application requires authentication, NeoLoad captures the credentials during recording and lets you configure how virtual users authenticate through the post-recording wizard.

Authentication in the post-recording wizard

After you finish recording a user path, the post-recording wizard opens automatically. If NeoLoad detected any authentication during the recording, the wizard includes an Authentication step where you configure how virtual users handle login credentials.

The wizard presents different options depending on the type of authentication your application uses.

Protocol-based authentication (Basic, Digest, NTLM, Negotiate)

When your application uses HTTP-level authentication (Basic, Digest, NTLM, or Negotiate), the wizard prompts you to choose how virtual users authenticate:

• Use the recorded account: All virtual users use the same credentials you used during recording. Choose this option when you want every virtual user to log in with the same account, for example when testing application performance rather than user-specific behavior.

• Use multiple accounts: Each virtual user uses a different set of credentials. NeoLoad gets the account data from a list of static values that you enter directly or import from a CSV file. Choose this option when your test requires unique logins per virtual user, for example when testing concurrent sessions or user-specific data.

Form-based authentication

When NeoLoad detects an HTML form with at least one text field and one password field, the wizard displays the detected authentication forms. This is common for web applications that use a custom login page instead of a browser authentication prompt.

To configure form-based authentication:

1. Review the detected forms in the wizard. NeoLoad lists all forms that match the login pattern.

2. Select the forms that represent actual authentication (some forms may be search boxes or other inputs that happen to match the pattern).

3. Choose to use a single recorded account or multiple accounts, the same way as protocol-based authentication above.

RealBrowser authentication

When recording with RealBrowser, the post-recording wizard handles authentication differently. The wizard displays an Authentication information step that shows where a login screen appeared during recording and asks you to enter your Login and Password.

NeoLoad stores these credentials and uses them to log in automatically during future test runs. If you skip this step, the test pauses at the login screen and waits for manual input.

For SSO and HTTP authentication with RealBrowser, you can also set credentials directly in the OpenBrowser action using the httpCredentials.login, httpCredentials.password, and httpCredentials.origin parameters. For details, see Authentication in RealBrowser.

Supported authentication mechanisms

The table below describes when each mechanism applies and how to fill in the authentication step:

Mechanism	How it works in NeoLoad
Basic	Sends credentials in Base64 encoding with each request. In the wizard, enter the username and password. Use multiple accounts when you need unique logins per virtual user.
Digest	Uses a challenge-response exchange to avoid sending passwords in clear text. In the wizard, enter the username and password. NeoLoad handles the challenge-response automatically.
NTLM	Uses Windows domain credentials. In the wizard, enter the username in DOMAIN\username format and the domain password.
Negotiate	Negotiates between Kerberos and NTLM. By default, NeoLoad uses NTLM as the sub-protocol. In the wizard, enter credentials in DOMAIN\username format. If your environment requires Kerberos, see SPNEGO and Kerberos below.
Form-based	Uses an HTML login page instead of browser-level authentication. In the wizard, select the correct form from the detected list, then enter the login and password values that match the form fields.

Negotiate scheme with SPNEGO and Kerberos

By default, NeoLoad uses NTLM as the sub-protocol for the Negotiate scheme because SPNEGO with Kerberos has a significant impact on Load Generator performance. When SPNEGO+Kerberos is active, a Load Generator cannot generate as many virtual users.

Only enable SPNEGO if your environment specifically requires Kerberos authentication. To enable SPNEGO, follow these steps:

1. Open <install-dir>/conf/controller.properties in a text editor.

2. Change the [Authentication]scheme.negotiate.subprotocol key from ntlm to spnego.

3. Open <install-dir>/conf/krb5.conf in a text editor.

4. Set the Key Distribution Center (KDC) for each Realm and Domain.

Scheme priority order

Some servers support multiple authentication schemes. NeoLoad prioritizes them in the order Negotiate, NTLM, Digest, Basic to match the order used by regular browsers.

To change this order, open <install-dir>/conf/controller.properties and edit the value of the [Authentication]scheme.priority key.

What's next

After configuring authentication, complete the post-recording wizard to finalize your user path. If you are using RealBrowser with SSO, see Authentication in RealBrowser for additional setup steps.