Are there any other NTLM options?

[alank2 5]

I am using TSslHttpCli to access a webapi that requires NTLM.  An odd thing is happening.  With their production environment, it works, but with their development environment, it doesn't.  I have tested both with curl using the --ntlm option and with curl, they both work, but with my code/ICS, only the production works.  With the development I get a "401 - Unauthorized: Access is denied due to invalid credentials." returned.  I thought it was their login in formation, but since it works with curl I have to assume there is something different in their webapi between the two environments.  Are there any settings or things I can configure in ICS to try something different?  I am setting:

 

SslHttpCli1->ServerAuth=httpAuthNtlm;

 

currently.

 

I also upgraded from ICS 859 to 869 with no change in behavior.  production api still works, development api does not.

[Angus Robertson 577]

Sorry, NTLM is primarily designed for use on corporate LANs in an Active Directory domain on Windows Servers, and I don't have Active Directory set-up.  So our testing of NTLM is limited.  It was implemented many years ago for Windows Server 2003 or something, and doubtless Microsoft has been changing it regularly since. 

 

I did test NTLM against the ICS web server recently, and you've found it sometimes works, but I've no idea why it fails in one environment. 

 

Angus

 

[alank2 5]

I appreciate the reply Angus; I think this particular webapi is going to be changed next year anyway, so maybe I can live without the developer environment until that happens.  Just trying to see if there was anything else I could try tweaking.

[Angus Robertson 577]

There are no NTLM settings as such, all I can suggest is looking through the version notes in OverbyteIcsHttpProt.pas and OverbyteIcsNtlmMsgs.pas about changes over the years.  You might also try tracing through the different messages passed during the handshaking to see where it dies.  Are your two environments running the Windows Server version? 

 

Angus

 

[alank2 5]

Thanks for the tips - I'll take a look at the two pas files and see if anything jumps out.

 

>You might also try tracing through the different messages passed during the handshaking to see where it dies.

 

I'm not sure how to do this exactly.  Could I attach the .pas to my project and then set some breakpoints?

 

>Are your two environments running the Windows Server version?  

 

They say they are the same, but I have to think there is something different.

 

I appreciate the help!

[FPiette 385]

Quote

>You might also try tracing through the different messages passed during the handshaking to see where it dies.

 

I'm not sure how to do this exactly.  Could I attach the .pas to my project and then set some breakpoints?

Yes, you can add part or all ICS source code to your project so that you can trace everything and put breakpoints where you want. Don't use runtime package to build your executable.

 

 

[Angus Robertson 577]

I was going to suggest testing NTLM using the OverbyteIcsHttpRestTst sample which includes logging of all headers, but it seems this logging ignores the internal handshaking (and redirection) requests that the HTTP client component does, so will not help. 

 

Diagnosing will need some more logging added.  But probably something we should do, NTLM is not going away in a hurry, despite modern OAuth2 , etc. 

 

Angus

[alank2 5]

Thanks FPiette and Angus for the help; I appreciate it!

[alank2 5]

After looking through the source recommended above (OverbyteIcsHttpProt.pas and OverbyteIcsNtlmMsgs.pas), I found a LM compatibility level.  It was set to 0 and I don't see it exposes in the properties of SSLHTTPCli, but I changed it using:

 

SslHttpCli1->LmCompatLevel=1;

 

And this fixed the issue!

 

[Angus Robertson 577]

I've changed LmCompatLevel from public to published, so it becomes more obvious. 

 

The notes suggest setting it from the registry, but the LSA\LMCompatibilityLevel key doesn't exist on my Windows 11 PC, so no idea how you find the settings.

 

Angus

 

[alank2 5]

I saw those notes, but I wondered if they meant that a system follows the compatibility level of the registry setting.  I figured the compatibility level that the library/components were using was separate from that, or is LmCompatLevel picked up someone from the registry somewhere?