IIS (2012R2) Simple Basic Authentication on a Folder

We recently transitioned from a 2003 to a 2012R2 IIS box and I'm at a loss with regards to not getting Basic Authentication to work to protect a simple folder.

Previously we forced a URL to HTTPS with a rewrite for a given folder, set the folder to Basic Authentication, set the Domain the domain the server was in and set the realm to '/'.  That was it, pretty simple.

IIS 8 seems even more simple on this front, set Require SSL, Disable Anonymous and Enable Basic at the folder.  Same Domain and Realm settings.  However, when the folder is accessed from a browser (IE, FF, C) it immediately gives a 401.2 error without prompting for user ID/PWD.

Most searches are turning up complex issues regarding asp/.net apps and issues between application pool identities.  I must be leaving out something pretty simple, but not figuring it out.  I do have .php files we would like to use, but the same effect occurs with regards to a simple html or pdf file... all view just fine if anonymous is turned back on.

What am I missing?... and is there a good article/whitepaper that someone can direct me to that details it as the TechNet and MS KB's I've finding from IIS 7 - IIS 8 do not go into any further detail than what I've figured on my own.
jirikiAsked:
Who is Participating?
 
jirikiConnect With a Mentor Author Commented:
OK, a little more digging.  For some reason (my ignorance) the 'ExecuteURL' type option for custom errors does not process the error code as you would think... not only does the client get the wrong code (i.e. 401.2 and 401.1 does not go back), but how IIS handles it is different... I just can't determine the what and why.

Changing the custom error to type of 'File' resolves the issue, however your custom error pages do not resolve (you get the generic white page with generic "You do not have permission to view this directory or page"... even with show friendly http errors option unchecked in IE.  If you change your file path to an absolute path... (i.e. c:\myroot\blah\ from /blah/) you get a generic error "The page cannot be displayed".

After a bit of more scrounging around, I found that even though the default file location is an absolute path (%SystemDrive%\inetpub\custerr\<LANGUAGE-TAG>\...) a custom absolute path will NOT work by default.  You have to enable the option allowAbsolutePathsWhenDelegated option for the site.  To do this you have to go into the sites main home screen in the IIS manager, click Configuration Editor, select system.webServer/httpErrors in the Section dropdown, then change the From <sitename> Web.config to ApplicationHost.config <location path='<sitename>' />... (I assume you could probably manually edit the ApplicationHost.config file itself, but but this works).  THen change the above attribute to True.

Once you do this, you can change the custom error type to File and use an absolute path.   Now, why can't I use a relative path is beyond me.   You can put the customer_err.htm file in the root of the site and then in the File location field just put the file name, it will work ... i.e. a limited relative path if it is on the root of the site, but who wants to clutter the root of their site with custom error pages vs having in a sub folder or folder outside of the site tree?

Anyway, after doing all this, I seem to get the results that I was originally looking for.  Just frustrating about all the little tidbits that are undocumented.
0
 
FarWestCommented:
please check allow/deny configuration in authorization. also verify that you don't have cached username/pass in client using network password management,
did you enabled integerated authintication?
0
 
jirikiAuthor Commented:
Thanks for replying.  I've cleared browser cache both via utility and manually.  I have storing form and passwords turned off across all 3 browsers (IE, FF, C).  In i.e. the website is not in trusted or local list and the IE Option Logon is set to Automatic only if in Intranet zone (default), but same results if I set to Prompt.  Have tried from multiple clients, all of which produce the same result so I'm fairly confident it is server config.

I've not touched Authorization Rules for the folder which are inherited from the sites: Allow | All Users

Can you go into details regarding 'enabling Integrated authentication' ?  The only Auth protocols I have installed are the defaults (Anonymous | ASP.NET impersonation | Basic Auth | Windows Auth... with the only one enabled being Basic Auth).  So if you mean Windows Authentication ~ to integrated, then no I do not and I do not want that (at least I don't think so.  In IIS6 there was issues with multi-domain forests and Windows Auth so that users from another domain could not auth.   Whether this was a limitation of Windows Auth in II6 or how our Forest was setup... we have 5 sub-domains... I don't know as I am not privileged for that info nor able to get any change on that front, but I do know that Basic Auth in IIS6 functioned fine for us cross domain. ).

I've checked the applicationHost.config and it is registering the proper settings for that location:
<location path ="sitename/folder">
  <system.webServer>
      <security>
          <access sslFlags="Ssl" />
          <authentication>
                <anonymousAuthentication enabled="false" />
                <basicAuthentication enabled="true" realm=""    defaultLogonDomain="" />
                <windowsAuthentication enabled ="false" />
          </authentication>
      </security>
   </system.webServer>
</location>

Open in new window


... I've tried setting realm to "/" and domain of which this system is a Member Server of, but my understanding is that leaving them blank does basically the same thing.  I've tried copying these same settings to the web.config file in the folder, with no change in symptoms.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
jirikiAuthor Commented:
... update with regards to "Integrated Authentication", if you were meaning the IE Advanced setting "Security | Enable Integrated Windows Authentication", then yes, this was check on all systems tested from.  However, unchecking this and restarting the computer (edited from orig. saying IE, but setting requires Windows restart) still produces the same result.
0
 
FarWestCommented:
I've not tested if BasicAuthintication options are shown when you did not add it to server role
please verify the server roles
please check this

http://www.iis.net/configreference/system.webserver/security/authentication/basicauthentication
0
 
jirikiAuthor Commented:
Yes, basic authentication is installed.  Under the security section I have Request Filtering, Basic Authentication, IP and Domain Restrictions, URL Authorization and Windows Authentication Installed.
0
 
FarWestCommented:
did you try to temporarily enable NTFS access for everyone on the folder
0
 
jirikiAuthor Commented:
Well, I'm at a complete loss.  I created a completely new site with the same config... base root allowing non-ssl and anonymous with a subfolder set to force SSL, disallow Anonymous and enable Basic configuration and it is functioning as I think it should be (with prompt and all).  I've spent almost 2 hours scouring folder ACL rights, IIS config entries and .config file entries and I cannot discover the reasoning behind the failure under the original site.

It has got to be something simple I'm missing... possibly a corruption of one of the .config file entries that I'm just not picking up on... but its obviously isolated to a specific site.
0
 
jirikiAuthor Commented:
Not actual answer, but isolated as a system/config specific problem.
0
 
jirikiConnect With a Mentor Author Commented:
Strangely enough, I've isolated the problem down to custom error pages that were enabled for the site.  So at the root of the site I have various custom error pages.  401.2 and 401 had to be removed (leaving one or the other was not enough).  After removing the custom error pages for those specific errors, I am prompted properly for the username and password.  So it was indeed a site specific configuration issue.

Why this is the case I have no idea.  Will have to look into this.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.