Jump to content
alank2

Are there any other NTLM options?

Recommended Posts

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.

Share this post


Link to post

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

 

Share this post


Link to post

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.

Share this post


Link to post

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

 

Share this post


Link to post

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!

Share this post


Link to post
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.

 

 

Share this post


Link to post

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

Share this post


Link to post

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!

 

Share this post


Link to post

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

 

Share this post


Link to post

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?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×