In our previous post we discussed handling pages and resources that are protected with Basic HTTP Authentication.  In this post we will provide a walkthrough of how to deal with advanced external authentication mechanisms with Apache JMeter, focusing on Windows protocols of NTLM and Kerberos.

In the Enterprise world  a domain-based approach is widely used for secure authentication and authorization, where credentials of currently loggedin Windows users are seamlessly passed to web applications allowing Single-Sign-On and automatic log-in using current credentials. JMeter lets you  simulate the interaction with the set of Microsoft security protocols to emulate requests being sent from a real-life user by constructing relevant headers and passing them along with the request to the protected area.

Infrastructure

For the demo we will use a Windows Server 2008 R2 machine running the domain blazemeter.local which has user1 account which will be used for external authentication.

The web server processing the test requests is Apache/2.2.14 Prefork on Ubuntu 10.04.

• NTLM authentication provided by PyAuthenNTLM2
• Kerberos authentication provided by libapache2-mod-auth-kerb

The Apache configuration is as follows:

AuthName "Kerberos Login"
AuthType Kerberos
Krb5Keytab /etc/krb5.keytab
KrbAuthRealm BLAZEMETER.LOCAL
KrbMethodNegotiate off
KrbSaveCredentials off
KrbVerifyKDC off
Require valid-user

 

   AuthType NTLM,basic
   AuthName BLAZEMETER
   require valid-user
   PythonAuthenHandler pyntlm
   PythonOption Domain BLAZEMETER
   PythonOption PDC 172.30.40.84
   PythonOption BDC 172.30.40.84

NTLM

This section highlights the specifics of handling NTLM authentication by Apache JMeter.

NTLM (NT LAN Manager) is a suite of authentication and session security protocols used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider ("NTLMSSP"). Originally used for authentication and negotiation of secure DCE/RPC, NTLM is also used throughout Microsoft's systems as an integrated single sign-on mechanism. It is probably best recognized as part of the "Integrated Windows Authentication" stack for HTTP authentication

See the “Security” chapter of PyAuthenNTLM2 page for the details.

From the JMeter point of view, handling the NTLM authentication challenge is simple enough. Just follow the steps from How to use HTTP Basic Authentication in JMeter guide and additionally provide a relevant domain to the “Domain” input.

Given the following domain structure:

The HTTP Authorization Manager needs to be populated as follows:

1. Username: must match “User logon name” for Windows Domain
2. Password: Windows Domain Password
3. Domain: should be “what you see in Windows Security pop-up” as this is what real browsers do. If you are uncertain you can type a fully qualified domain name into that field you can just use “blazemeter” or “blazemeter.local”.
4. Other fields like “Base URL” and “Mechanism” can be left as is.

Sample request with Authorization Manager disabled:

And in case of properly configured HTTP Authorization Manager:

The request to the NTLM-protected page succeeds. Pay attention to the NTLM header which is being sent along with the request.

Kerberos

In this section we describe a sample JMeter configuration for Kerberos authentication.

Underlying Windows 2000 security is the concept of user authentication. The centralized account management supported by Active Directory Services requires a corresponding authentication protocol for network log-on. Based on RFC 1510, the Kerberos Version 5 protocol provides enhanced authentication for the distributed computing environment and standardization to interoperate with other operating systems.

Kerberos Version 5 is standard on all versions of Windows 2000 and ensures the highest level of security to network resources. The Kerberos protocol name is based on the three- headed dog figure from Greek mythology known as Kerberos. The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). Three exchanges are involved when the client initially accesses a server resource:

1. AS Exchange
2. TGS Exchange
3. Client/Server (CS) Exchange

From the JMeter point of view an extra configuration is required to tell JMeter what is Kerberos Domain Controller, what options should be used for connection and what realms should be looked into.  There are 2 files under /bin folder of the JMeter installation which are used for Kerberos configuration:

• krb5.conf - file of .ini format which contains Kerberos configuration details
• jaas.conf - file which holds configuration details of Java Authentication and Authorization service

These files aren’t being used by default, so you have to tell JMeter where they are via system properties such as:

• -Djava.security.krb5.conf=krb5.conf
• -Djava.security.auth.login.config=jaas.conf

Alternatively you can add the next two lines to the system.properties file which is located at the same /bin folder.

• java.security.krb5.conf=krb5.conf
• java.security.auth.login.config=jaas.conf

As usual we recommend using full paths to files. If you run JMeter from a desktop shortcut its working directory may not be /bin and all relative file locations will be pointing nowhere.

Check out Apache JMeter Properties Customization Guide for more info on dealing with JMeter properties.

The minimum defaults for krb5.conf look like:

[libdefaults]
default_realm = BLAZEMETER.LOCAL

[realms]
BLAZEMETER.LOCAL = {
        kdc = 172.30.40.84
        admin_server = 172.30.40.84
}

[domain_realm]
172.30.40.84= BLAZEMETER.LOCAL
.172.30.40.84= BLAZEMETER.LOCAL

Where

• default_realm -  identifies the default realm to be used in a client host's Kerberos activity
• realms - contains subsections keyed by Kerberos realm names which describe where to find the Kerberos servers for a particular realm, and other realm-specific information
• domain_realm - contains relations which map subdomains and domain names to Kerberos realm names. This is used by programs to determine what realm a host should be in, given its fully qualified domain name

For this principal-only based example we use jaas.conf with default values, but if your Kerberos environment uses keytabs or any other mechanism you’ll need to put login config entries with the relevant configuration there.

Let’s return to JMeter:

The following parameters are being used:

• Realm - which should match the realm and must be in uppercase
• Mechanism - which must be “Kerberos” for this authentication type

Important: make sure that clocks are synchronized at all involved machines as the default Kerberos maximum allowable amount of clock skew is 300 seconds (5 minutes).

BlazeMeter support

As usual, BlazeMeter is 100% compatible with all version of Apache JMeter.

We fully support handling of NTLM and Kerberos properties and associated files so if you upload your krb5.conf and jaas.conf along with JMX script and set the properties mentioned above.

As long as your test domain controller is accessible from our hosts there shouldn’t be any issues with running your test. If not, checking the  following:

1. You can whitelist our IP addresses
2. We can provide a dedicated IP addresses set and bind them to the account
3. We offer on-premise testing solutions

See Top 3 Options for Running Performance Tests Behind Your Corporate Firewall for more details.

You might also want to view our on-demand webcast, How to Make JMeter Load Tests Highly Scalable and More Collaborative With BlazeMeter. 

START TESTING NOW

Related Resources

• Testing Windows Applications Using Taurus and Selenium: A Guide
• Apache Kafka vs. ActiveMQ: Key Benefits and Use Cases