0

We have an existing server with HTTPS set up and an certificate signed by an internal custom CA cert.
It runs an app which uses windows authentication

e.g. https://internalserver

We browse to this from a windows box using IE/Edge/Chrome/Firefox and they'd all just load the page and not prompt for credentials - using your logged-on windows domain credentials. The web server and all the windows clients are on the same domain. So far so good

We've enabled a new DNS alias using an SSL cert purchased from a real CA, and using internal DNS - this is basically to get round having to install our internal custom CA all over the place (linux, mac, android)

e.g. https://internalserver.local.company.io

I've configured this certificate in IIS and I can browse to it, but when I do, all browsers prompt me for a username/password. I enter my domain credentials and it works, but why is the prompt occurring?? Is there something in IIS that makes NTLM authentication only work for some specific host name? And how might I change that?

I'm not sure that HTTPS or the certificate has anything to do with it, but it's mentioned in case it's relevant

Thanks

Orion Edwards
  • 202
  • 4
  • 10

3 Answers3

1

Sending creds to a web server is risky. Each browser has a policy setting or file that determines if the browser sends creds without prompt. Chrome and FF here. https://specopssoft.com/blog/configuring-chrome-and-firefox-for-windows-integrated-authentication/

markgamache
  • 195
  • 4
0

I've tracked this down.

The old DNS record was considered by Internet Explorer (and thus Edge and Chrome, which share it's security settings) to be in the "Intranet" zone. "Automatic Logon" is enabled for sites in the intranet zone, but disabled for other sites.

The new DNS record had a different suffix and so is not considered to be part of "Intranet" but instead is "Internet" and thus automatic NTLM logon does not take place.

I asked our domain administrators to add the new suffix (local.mycompany.io) to the group policy list of "Intranet" domains. Once group policy refreshed, IE, Edge and Chrome all allowed automatic NTLM logon without prompting for a username and password, which solves the issue.

Firefox requires local.mycompany.io to be added to network.automatic-ntlm-auth.trusted-uris in it's about:config, however that's always a required step for firefox, so no change there

Orion Edwards
  • 202
  • 4
  • 10
  • This is done because NTLM itself is already quite weak; sending NTLM creds automatically to foreign sites would be nearly as bad as sending your password. (Kerberos does not have this problem, if it's not too complex to set up – but it also needs to be whitelisted for user privacy.) – user1686 Feb 26 '19 at 23:37
-1

In the IIS Admin for the site having the issue go to Sites, <the website>, IIS>Authentication and ensure that Anonymous Authentication is Enabled. If it is, go to Application Pools, <the application pool for the website>, Advanced Settings and ensure that a username (& password) for an account with appropriate physical directory permissions to the web root is assigned to the Identity.

This wasn't required before since your users are all on the same LAN and the "." in the URL prevents automatic negotiation/authentication for users to your local server.

Be aware that this means that if you were requiring users to login in order to be able to access specific information or user-level data before, you should be aware that this will allow anyone with the URL (if it's routed publicly) to access the content.

shawn
  • 99
  • 1