Doublehop problem with iis 6 and sql 2016

Question

We've been having a problem with users are having an issue connecting to an internal (http) Intranet site.

For the majority of users this is not a problem, but for a certain subset it is growing.

Our Environment is a hybrid AD with on Prem IIS and SQL servers.

The website uses authentication to pass user login information to the SQL server to access specific user data they can update mainly for compliance, but we have other inhouse built applications as well, but the compliance is most pressing as the CCO has the problem too which is a bit embarrassing.

The original coder is long gone, and little documentation exists.

I had to update the NTLM permitted URIs a few years ago that only seems to work with Firefox if you don't want to be prompted to login every time.

This happens with older machines (including mine) and just build autopilot machines, but not all the machines, that have the same version of Firefox and are in both user and computer OUs that have the same GPO applied and happens for users who are in the same OU.

Looking at Wireshark I see the error (I can upload the capture if needed)

The user is also able to use a bastion server to open the page and go back to their own machine can now open as it's passing credentials.

We've review auth settings, but as it works for most not that.

Event Viewer shows the successful ones are listed as impersonation level: delegated

While the unsuccessful will show impersonation level: impersonation. If open in the bastion and go back, it still says impersonation level: impersonation.

I've double checked the Windows 11 version and firefox version (though it happens on others, just the one that passes the credentials)

The gpo that applies the Firefox settings are under Allow non fqdn, delegated, ntlm and spengo (the developer at the time wasn't sure which was correct so had me do all three)

These are my working notes

IIS

VMWare 6.5

Windows Server 2019 Dataserver, patched and up to date

8 cpu

Mem16GB

One LAN connector

Local Applications, using grape city (whatever that is)

Anonymous Authentication is disabled. Windows Authentication is enabled.

Enable Kernel-mode authentication

Enabled Providers; Negotiate first, NTLM second

Seperate Application Pool, managed pipeline mode integrated, own service AD account

SQL

VMWare 6.5

WIndows Server 2012 R2 Datacenter (we are migrating to latest) patched

SWL Server 2016

6 Cpu

MEM128GB

DB on separate drive

One LAN connector same subnet

Application Pool AD service count has Database Role

The issue

We have this intranet application written two DBA's ago with little knowledge transfer except some vague text files.

This application uses Windows Authentication to pass through IIS and then come back to the user to upload confidential finance information we require for compliance. We have other apps that have this as well, but this is the main one I'm concerned about.

Three years ago we started having tickets about Authentication Errors when connect to the http: site.

We discovered that the user could still use a bastion server to access so it wasn't a rights issue.

I also have had this issue and just ignore myself.

We could find no solution to this as it's slowly expanded, to even including our Compliance officer just recently.

We have users access these sites via Firefox, as our old DBA had told me that was the only one that realiably can be set to the Auth settings, so I use computer/policies/admin template/mozilla/firefox/authentication

Delegate, list of local siits

NTLM, same list

Spengo, same list

Everyone gets this same list

What I know

IIS security Event Logs shows impersonation level: impersonation for those who fail, and wireshark a blank auth

While the bastion server shows Delegated for impersonation level.

If you keep the Bastion open and go to the local machine it works, but impersonation level is still impersonation.

The correct user name must be passed correctly to login to their data.

The users who work and don't work are in the same OU, the machines are in the same OU, and I even moved the end user machine (mine in this case) to the same OU as the Bastion server OU (which has no specific Computer GPO even assigned)

Using wireshark I see an http/1.1 401 unauth error but I also see this in the successful one.

Answer 1

Hi David Kafrissen,

Thank you for posting in the Microsoft Community Forums.

1. Check IIS configuration

Authentication settings:

Ensure that the authentication settings on IIS are correct. For Windows authentication, enable “Windows Authentication” and disable other unnecessary authentication methods (e.g. anonymous authentication).

Check the “Authentication” section of IIS to make sure there are no configuration errors or conflicts.

SSL/TLS configuration:

If your application is served over HTTPS, make sure the SSL/TLS certificate is valid and properly configured on IIS.

Check if there are any SSL/TLS related errors or warnings in the IIS logs or Event Viewer.

2. Client Browser Settings

Firefox Settings:

You have already mentioned Firefox specific settings, but make sure that these settings apply to all users and that there are no omissions or errors.

Check Firefox's “Network” settings to make sure there are no proxy or VPN settings interfering with the authentication process.

Try clearing Firefox's cache and cookies, then try accessing the application again.

Other browsers:

Try accessing the application using another browser (e.g. Chrome, Edge) to determine if the issue is specific to Firefox.

If the problem occurs with other browsers, it may be a server-side issue.

3. Network security and firewalls

Firewall rules:

Check the firewall settings on both the server and the client to ensure that ports required for Windows authentication (e.g. 443 for HTTPS) are not blocked.

If using network level security devices (e.g. intrusion detection systems, web application firewalls), check for any rules that may interfere with the authentication process.

Network Segregation:

If your network is segmented into different zones (e.g. DMZ, intranet), make sure that authentication traffic traverses these zones correctly.

4. Application and server logs

IIS Logs:

Carefully review IIS logs for authentication-related errors or warnings.

Note details of any failed login attempts or authentication failures.

Application logs:

Check the application log files for any authentication-related errors or exceptions.

If the application has custom authentication logic, make sure that this part of the logic is free of errors.

5. Upgrades and fixes

Operating system and IIS:

Ensure that the operating system and IIS on the server are up-to-date and have all important security patches installed.

Outdated systems or components may contain known security vulnerabilities that can cause authentication problems.

Applications:

If possible, consider upgrading Intranet applications to the latest versions.

Check for available application patches or updates that may fix authentication-related issues.

6. Advice and support

Internal resources:

If your organization has an IT support team or network administrator, work with them to resolve the issue.

They may have expertise and experience in resolving such issues.

External support:

If the problem persists and cannot be resolved by internal resources, consider contacting Microsoft Support or a specialized IT service provider.

7. Alternatives

Consider alternative authentication mechanisms:

If Windows authentication continues to be a problem and there is no easy solution, consider implementing alternative authentication mechanisms (e.g., form-based authentication, OAuth/OpenID Connect, etc.).

This may require changes to the application code and configuration, but may be a viable solution in the long term.

Best regards

Neuvi