Dear wM fans!

We have a wM 10.3 installation here on an IBM AIX server.
I want to consume a SOAP webservice using pub.client:soapClient. The webservice is hosted on an IIS and requires NTLM authentication.

When calling the webservice on our productive system everything works fine.
When calling the webservice on our test system I get an “Authorization Required: Unauthorized” error.

I checked prod and test server and cannot find any difference that may be the reason for this problem.
There is no firewall problem.

The strange thing is: When checking the IIS server logs it seems as if the test server would not send the credentials (at least we see domain\username when the request is done by the productive server - we see no domain\username when the request comes from the test server).

Is there any setting that could cause this behaviour?

Cheers,
Christoph

I did further research.
I set some server logging facilities to DEBUG and checked the log file.

I found the following:

HTTP/1.1 401
← Content-Type: text/html
← Server: Microsoft-IIS/8.5
← WWW-Authenticate: Negotiate
← WWW-Authenticate: NTLM
← X-Powered-By: ASP.NET
← Date: Fri, 20 Nov 2020 09:49:24 GMT
← Content-Length: 1293
Unexpected NTLM message sequence. The expected message type is not NTLM Type 1 Message.
Exception → org.apache.axis2.AxisFault: [ISC.0064.9314] Authorization Required: Unauthorized
→ HTTP/1.1 403 Service Error
→ Content-Type: text/html; charset=UTF-8
→ Content-Length: 19360

Can I deduce from this that the problem is that the webMethods server expects NTLM Type 1 but the server sends something else (type 2)?
If yes: How/where can I set force the IS/axis to accept the (probably) NTLM type 2 message?

Cheers,
Christoph

Hi Christoph,

This problem is not related to NTLM type 1 message. Instead the actual issue is printed in the very next line that ‘[ISC.0064.9314] Authorization Required: Unauthorized’. Is both PROD & TEST env have same core fix level? If yes, then please mention the core fix level installed? Use wireshark to intercept request/response & check whether username is getting passed to IIS server or not?

Thanks,
Nilima

Hi Nilima,

Thanks for giving some clues/ideas.

We have

• IS_10.3_Core_Fix5 on PROD - where it works and

• IS_10.3_Core_Fix13 on TEST - where it does not work.

We are ahead on the TEST server in order to “test” whether the new fixes cause any problems. I don’t know if this is the case here and we have to “go back”.

Regarding sniffing network traffic: I already requested this from the “network guys” but they refused by bringing forward the argument that this is not a problem of the network/firewall.
But I will continue to beg them and let you know.

Anyway: If I discovered that the username is not passed to the IIS then what could I do to force Integration Server to send it?

With many thanks,
Christoph

Hello,

I finally managed to get the network traffic of the two webservice calls.
Comparing them with Wireshark I found the following (remember: it works on PROD but not on TEST).
Both calls start with an HTTP request without any Authentication information.
The IIS responds with “HTTP/1.1 401 Unauthorized” and “asks for”
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

So far so good. Both clients try again with something that Wireshark sums up as:
“HTTP/XML 1094 POST /<path to service> HTTP/1.1 , NTLMSSP_NEGOTIATE”
In other words: the clients both want to negotiate. But they do it differently:

The PROD client wants to negotiate as follows:

NTLM-Negotiate from PROD1233×305 16.6 KB

whereas the TEST client want to negotiate as follows:

NTLM-Negotiate from TEST1283×308 16.6 KB

Differences are in the

• “Negotiate Flags” (I highlighted the differences)
  PROD: 0x20080235, Negotiate 128, Negotiate Extended Security, Negotiate NTLM key, Negotiate Seal, Negotiate Sign, Request Target, Negotiate UNICODE
  TEST: 0xa2088201, Negotiate 56, Negotiate 128, Negotiate Version, Negotiate Extended Security, Negotiate Always Sign, Negotiate NTLM key, Negotiate UNICODE

• the “Calling workstation domain”
  NULL from the TEST client, correctly set be the PROD client

• the “Calling workstation name”
  NULL from the TEST client, correctly set be the PROD client

So: the TEST client wants to negotiate differently.
How can I influence the negotiation parameters?

best regards
Christoph

Hi,

can you check for the contents of the “version 5.1 /Build2600: NTLM Current Revision 15” block on TST, please?
Eventually this will contain additional helpful informations.

Regards,
Holger

Hallo Mr von Thomsen,

as you can see above the hint of Nilima solved the problem. I changed the format of the user in the NTLM authentication to <user>@<domain> and it worked.

Nevertheless, I would like to ask you to give me a hint where I can find the block that you mentioned.
Just for completeness.

Thanks,
Christoph

Hi Christoph,

in the second of the two screenshots above there is an additional line “version 5.1 /Build2600: NTLM Current Revision 15”, which has a sign in front of it which I assume is to indicate that it can be expanded with further entries.
These entries might be of interest for further investigations on this.

Regards,
Holger

Hallo Holger,

Sorry for not having seen what you meant.
Here is the information that you referred to.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/af073f2200692f55255ee3452b26d91e43356be3_2_1035x309.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/af073f2200692f55255ee3452b26d91e43356be3.png 2x" data-dominant-color="ECF0E9">

NTLM-Negotiate from TEST - NTLM Current Revision1264×379 22.2 KB

Is there anything more that I could deduce from this?

Cheers,
Christoph

Hi Christoph,

thanks for providing the info.

As we are not using NTLM auth in our project I will not be able to assist you further in this case.

Regards,
Holger

Hi Christoph,

In TEST env, can you please try sending username in ‘user@domain’ format. Also IS_10.3_Core_Fix 13 contains a patch to upgrade NTLM flags and username as per NTLM guidelines.

Thanks,
Nilima

Hello Nilima,

Thanks so much for your hint!
The “problem” was indeed the format of the username. We sent it like <domain>\<user>.
I changed to <user>@<domain> and it works!!

Great. I’m very thankful.

I wish you all the best,
Cheers,
Christoph