{"id":2270,"date":"2011-06-10T15:04:00","date_gmt":"2011-06-10T19:04:00","guid":{"rendered":"http:\/\/www.webperformance.com\/load_testing\/blog\/?p=2270"},"modified":"2012-02-01T14:38:54","modified_gmt":"2012-02-01T18:38:54","slug":"enhanced-integrated-windows-authentication-support-in-load-tester-4-2","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2011\/06\/enhanced-integrated-windows-authentication-support-in-load-tester-4-2\/","title":{"rendered":"Enhanced Integrated Windows Authentication Support in Load Tester 4.2"},"content":{"rendered":"

Load Tester 4.2 offers a substantial number of enhancements over the 4.1 release. One of the last features, which was not available in the 4.2 beta cycle, is completely redesigned support for Connection Authentication Negotiation. For IIS users, just think of \u201cConnection Authentication Negotiation\u201d as support for IIS’ \u201cIntegrated Windows Authentication<\/a>\u201d. Load Tester’s CAN support is a bit more abstract to encompass other servers as well. In fact, the term \u201cConnection Authentication Negotiation\u201d is used to provide support for negotiation of an authentication scheme at the HTTP layer, which may be used to authenticate the browser’s connection to the server. For Load Tester 4.2, CAN supports NTLM and Negotiate using NTLM.<\/p>\n

Let’s start by looking at a recording which uses NTLM. When we go to our server, we get a prompt for credentials from the browser instead of a web page, since the authentication is being performed at the HTTP layer.\"Recording<\/p>\n

Note that for some sites, this prompt may not even appear at all (the browser may use your local account credentials or other cached credentials).<\/p>\n

Once you enter your credentials and finish your recording, you will wind up with a testcase in Load Tester which looks something like this:\"testcase<\/p>\n

The \u201c401 \u2013 Unauthorized\u201d may look strange here, but it’s actually normal. This is how robots (such as Google) will see your page. When the server sends this page, the browser recognizes the HTTP headers as a request for credentials and displays the Username & Password pop-up instead.<\/p>\n

For more information on what to expect when looking at a “raw” authenticated recording, see “How HTTP Authentication works and why load testers should care<\/a>“.<\/p>\n

Now that the recorder has recorded what actually happened, we want to configure the testcase to represent what we intend to happen: we request the home page, and authenticate if & when required. To get started, start the Testcase Configuration Wizard from the Wizard launch button.\"Testcase
\nPressing one of the green play buttons to run a replay will cause the same wizard to be launched, since this testcase has not yet been configured for replay.\"Testcase<\/p>\n

On this wizard, the \u201cConfigure user identity for connection authentication\u201d is selected so we can enter user identities for virtual users to use when the server requires them to authenticate.\"CAN<\/p>\n

The next step allows us to define if the same credentials can be used for simultaneous sessions. There are a couple options:<\/p>\n