0

Recently a custom application of mine that is hosted on IIS 8.5, Windows Server 2012 R2 that uses Windows Integrated Authentication against Active Directory stopped working properly on some Windows Clients.

The site uses SSL and has a valid certificate.

  • Windows 7 Enterprise clients who are actively logged in to AD hang for a while when accessing the site, then get 401.1 invalid credentials. Previously they would transparently authenticate via WIA and access the site.
  • Windows 10 clients are still able to access the site, but get prompted for their AD credentials, unless they go to Internet Options and add the site FQDN to their "local intranet sites". This is likely expected, but wasn't necessary before, for whatever reason.
  • Windows 7 Ultimate client who is not actively logged in to AD can still access the site, is prompted for AD credentials, authenticates and accesses the site.

The only change I've been able to determine is a Microsoft Windows patch was applied to the server by the server admin, which mentions an update to Windows Integrated Authentication and Windows cryptography.

I suspect something changed with WIA but I have not found anything in the event logs or otherwise that would help me understand what I need to do to restore the transparent WIA for my Windows 7 Enterprise clients.

Tim M.
  • 11
  • 3

1 Answers1

1

The issue appears to have been resolved with Microsoft security patches deployed around the 3rd week of November. I suspect the initial patch was to address security issues but caused problems with Integrated Windows Authentication. These were resolved with later patches, however in Windows 10, the FQDN of the web site using Integrated Windows Authentication over SSL has to be added to Local Intranet Sites on the client workstation, or else the Authentication between the client logged in to AD and the web site using IWA will not negotiate without user intervention, causing a prompt for AD credentials.

Tim M.
  • 11
  • 3