locked
WCAT Frustration - works great but won't authenticate RRS feed

  • Question

  • User1026589974 posted

    The WCAT documentation provides a succinct example, and one that looks like it's missing a hop/pair anyway. When I set up a script to access a remote server and pattern my NTLM or BASIC communication per the provided example, I get the following output:
    ...
    All clients connected, Test beginning.
    Invalid code received.
    Error accepting remote connection.
    message: Run error detected, terminating clients...
    message: Terminating all instances of wcclient...
    Connecting to:
    ...

    My scenario works just fine when I comment out the 3 auth-centric lines. It fails when they are uncommented. The WCAT client is able to parse the scenario, but I've not actually dug into the parsing mechanism yet to see whether it's parsing correctly.

    (I've already fixed the bug that prevents connection from multiple remote clients, but there may be more.)

    Here's the pertinent part of the scenario:

        request
        {
            url         = "http://weatherforecast-d/";
            statuscode  = 401;
        }
    
        request
        {
            url         = "http://weatherforecast-d/";
                   // problems begin here...
              authentication = "ntlm";
              username = "my username";
              password = "my password";
            statuscode  = 200;
        }
    

    If anyone has a running, functional example of a WCAT NTLM script, I'd be much obliged. Thank you.

    After a couple hours work over 2 days, I've cleaned up the logging in wcat.wsf and done numerous comparisons. There's got to be a better way to do this, but I don't know it.

    • "authentication" parses while other parm names do not
    • "username" and "password" don't cause fatal errors on their own
    • If I comment out the single parm line "authentication" the test runs
    • If I uncomment the same line it errors fatally
    • The script output is exactly the same up until the failure
    • basic or ntlm result in the same failure, as does any garbage text

    The problem seems to be hidden deep in the wcclient. I see someone once answered a WCAT question here so I'll hope again.

    Tuesday, February 10, 2009 5:25 PM

Answers

  • User744767459 posted

    Hi, 

    I am sorry that the documentation was not useful. The documentation I referred is provided with Wcat5.2 which is included in the IIS 6.0 Resource Kit Tools.

    The definition of the attribute “authentication” was changed in the later version. Additionally, you are right to point out that the value of the attribute “authentication” should be a keyword [BASIC, NTLM]. The keyword is different with the dynstring. Hence, you need to remove the double quotation marks. The settings look like this:

    request
        {
             url         = "http://weatherforecast-d/";
                   // problems begin here...
              authentication = NTLM;
              username = "my username";
              password = "my password";
            statuscode  = 200;
        }

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Tuesday, February 17, 2009 2:39 AM

All replies

  • User1026589974 posted

    Well, I don't guess there's any joy in Mudville.

    New tack. Has Microsoft published the source for wcclient? I REALLY don't want to look for another tool when I'm so happy with this one. :-/

    Thursday, February 12, 2009 9:00 AM
  • User744767459 posted

    Hi,

    You need assign a DWORDValue to the "authentication". For your convenience: "For Authentication, 0 means anonymous and is the default; 1 means Basic authentication, and 2 means Microsoft NTLM authentication."

    You can find more information about the HTTP Request Commands in the WCAT Client Documentation (WCAT->Main Page->Running a WCAT Test->Preparing the Controller Input Files->Editing or Creating a Script File-> Table 2  HTTP Request Commands).

    Sunday, February 15, 2009 9:33 AM
  • User1026589974 posted

    Thank you, Leo, for your response. I'd like to mark it as an answer, but I can't get it to work for me.

    Could you possibly link to the documentation you reference? The documentation provided with the product does not say a word about the authentication parameter needing a DWORD value. The documentation is very clear that a text value is required, "authentication = keyword [BASIC|NTLM]". I've tried all sorts of values instead of the mandated strings, and receive only errors.

    Could it be the authentication parameter actually belongs in the request header section of the scenario?

    Anyway, the WCAT main page on iis.net says, "Documentation: N/A," and I'm unable to Google up anything that might align with the page progression you reference above.

    Monday, February 16, 2009 10:13 AM
  • User744767459 posted

    Hi, 

    I am sorry that the documentation was not useful. The documentation I referred is provided with Wcat5.2 which is included in the IIS 6.0 Resource Kit Tools.

    The definition of the attribute “authentication” was changed in the later version. Additionally, you are right to point out that the value of the attribute “authentication” should be a keyword [BASIC, NTLM]. The keyword is different with the dynstring. Hence, you need to remove the double quotation marks. The settings look like this:

    request
        {
             url         = "http://weatherforecast-d/";
                   // problems begin here...
              authentication = NTLM;
              username = "my username";
              password = "my password";
            statuscode  = 200;
        }

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Tuesday, February 17, 2009 2:39 AM
  • User1026589974 posted

    Grrr. The documentation clearly shows NTLM enclosed in quotes, and it never occurred to me that a KEYWORD would be stopped by the quotes. Thank you very much.

    The NTLM authentication is now working, and I have marked your reply as an answer.

    If you want to play a little more, I cannot seem to find a combination that gives me any relief from unexpected states. Every transaction results in an error. The documentation instructs me to create 2 requests, one without auth info expecting a 401, and a second with auth info expecting a 200. An actual NTLM transaction requires 3 requests, though. Either way, no matter what combination of 200's and 401's and 2 or 3 requests, and with or without supplying auth info, I get a mess of unexpected status codes. As a rule the number of unexpected status codes is exactly 1/2 of either the 401's or the 200's, but I cannot discern where my error lies.

     Thank you again for your timely help on the KEYWORD issue.

    (Here's an example output from one transaction combination.)

           Transactions =                     1962 (                     196/sec)
         Normal Requests =                     7844 (                     784/sec)
         Secure Requests =                        0 (                       0/sec)
        Normal Responses =                     5881 (                     588/sec)
        Secure Responses =                        0 (                       0/sec)
              Status 200 =                     3920 (                     392/sec)
              Status 401 =                     3924 (                     392/sec)
            Total Errors =                     1962 (                     196/sec)
          Connect Errors =                        0 (                       0/sec)
             Send Errors =                        0 (                       0/sec)
          Receive Errors =                        0 (                       0/sec)
          Parsing Errors =                        0 (                       0/sec)
       Unexpected Status =                     1962 (                     196/sec)

    Tuesday, February 17, 2009 10:16 AM
  • User989702501 posted

    Those 401.x errors are expected as part of the handshake, since the client will always connect as anonymous first like browser, after being challenge then it will response accordingly. I kinda forgot how many times, but I think IIS 5 is 2, then IIS 6 above is 3... you can check the IIS log file to double confirm.

    Wednesday, February 18, 2009 9:11 AM
  • User1026589974 posted

    Thank you, Bernard. I understand the points you are making here, and still cannot resolve my "Unexpected Status" errors. I'm under the impression I should be able teach WCAT to expect a predictable pattern of 401's and 200's, but so far I'm still struggling.

    What I've done is try several transaction patterns. In each transaction, I hit the same default web page several times in a row. Sometimes I supply auth information and sometimes I don't, and each time I try it with a different Expected Status. Here are a few of them. Transaction #3 is exactly per documented specs. I'll list the expected status and whether I send auth info:

    Transaction #3: 401, 200 with auth (100% of 200's are unexpected) 

    Transaction #4: 401, 401 with auth, 200 with auth (50% of 200's are unexpected)

    Transaction #6: 401, 200 with auth, 200 with auth (50% of something unexpected)

    Transaction #7: 401, 200 with auth, 200 (50% of 200's are unexpected)

    There should be some combination of expecting 401's and 200's with and without authentication information that results in 100% of the return status codes being expected, right? I've also tried this with and without cookies enabled, since the authentication information is stored in cookies.

    Thank you for your continued help!

    Kevin

     

    Wednesday, February 18, 2009 9:44 AM
  • User-863034566 posted

     Hi

    did you resolve this NTLM unexpected status codes issue. I'm having the same issue ...now thinking of setting statuscode = 0...been at this for a while now

    Thanks

     

     

    Friday, August 14, 2009 6:45 AM
  • User1026589974 posted

    I eventually just settled for 80% accuracy. If I send one or two 401's and a 200, I get 80% of my requests come back as something "expected." In the end, I decided that was good enough for what I was doing. As long as I was getting back some 200's I had plenty of throughput for my testing.

    Friday, August 14, 2009 8:58 AM
  • User1810063233 posted

    My app home page redirects to an IDM app which accepts username and password. Upon successful authentication, the IDM module redirects to my app home page. How can I get this working on WCat?

     The first request to the home page returns with a 302.

    Wednesday, August 26, 2009 3:22 PM
  • User1026589974 posted

    Forgive me, but why would you want to load test a redirect? Just test the authenticated connection. The point of a load test is resource usage, not functionality, and the redirect is ~0 overhead. Take a Fiddler snapshot of the interaction and simulate the connections that're going to generate the most load and simulate those.

     WCAT is capable of "expecting" a 302 reply, so you could create connections that expect 302 and go from there. I've never done it, and don't know any of the gotchas you'll encounter.

    Wednesday, August 26, 2009 4:26 PM
  • User1365990429 posted

    I'm having the same issue, however. I get too many unexpected 200's and only a few 401's during the warmup.

     Here's the script

     

        transaction
        {
            id = "ntlm authentication on pxeclient 2.0";

           weight = 100;
            //401's are expected as part of the handshake
            request
            {
                url = "/website/page.castle";
                statuscode = 401;
            }

            request
            {
                url = "/website/page.castle";
                authentication = 2;
                username = "user";
                password = "pass";
                statuscode = 200;
            }
        }

     

    settings

    scenario
    {
        name    = "HIT default page PXEC";

        warmup      = 30; // warmup period
        duration    = 20; // number of seconds
        cooldown    = 10;

        /////////////////////////////////////////////////////////////////
        //
        // All requests inherit the settings from the default request.
        // Defaults are overridden if specified in the request itself.
        //
        /////////////////////////////////////////////////////////////////
        default
        {
            // send keep-alive header
            setheader
            {
                name    = "Connection";
                value   = "keep-alive";
            }

            // set the host header
            setheader
            {
                name    = "Host";
                value   = server();
            }

            // HTTP1.1 request
            version     = HTTP11;

            // keep the connection alive after the request
            close       = ka;
        }
    }

     

    What am I missing?

    Friday, January 8, 2010 8:25 AM
  • User1026589974 posted

    Hey Callidus,

     I tore down my test bed for this a while back, and have not been asked to set up another one. Sorry. FWIW, I eventually tuned my script to give me about 75% successful connections, and just went with it. I never hit anything near 100%, but I was able to load the machine and exercise the code repeatably. That was good enough for the kind of error tracing I needed to do.

     Sorry I couldn't be more help.

    Friday, January 8, 2010 9:50 AM