May 20, 2018
  • What we have here, is a failure to communicate…

IIS Security versus Keith Davis = I Win (IIS Security & Security Part Deux)

Well, if I’m going to complain, then I ought to share the solution when I find one…and I did. It involves:

  • Delegation
  • SPN
  • FQDN
  • Integrated Windows Authentication

Really, it was easy to fix once I figured it out. The primary component in our configuration that may not common is that we use Windows Authentication exclusively, so that last part was easy. I did have Digest Authentication enabled, and that cannot be, but it was no big deal to turn it off.

Then what I had to do was enable Delegation for the web server in Active Directory. Next, I registered the SPN for the web server.  This part is not necessary if you use the actual host name to access your web server (ex. app01.pridedallas.com), but we do not, we use intranet.pridedallas.com. Finally, and this is more of a process issue, you MUST use the FQDN. So, on our Intranet, I changed our home page in AD to http://intranet.pridedallas.com, and added code to our site that redirects all users to the FQDN if they get there otherwise.

Consequently, I found that VisualCron does not like that forced redirection. Had to modify all of our HTTP jobs….there were a lot.

And whala! It worked. Thank God. I can put the AK back in the box….