Thursday, June 26, 2014

IIS 7.5 + Windows Authentication: some users still getting prompted for credentials

It has been a while since I created an intranet web app that uses Windows Authentication. I recently ran into a problem where some users were able to authenticate correctly while others were prompted for credentials. I spent a lot of time checking and verifying a number of things in the process of trying to figure this out:

Settings Checked

IIS Authentication settings

Made sure Anonymous was disabled, Windows Authentication was enabled.
I saw a number of sites that said to bump up NTLM to the top of the Providers list…which isn’t recommended. (Didn’t work anyway.)

Web.config Settings - made sure the settings were correct there:

<authentication mode="Windows" />
<identity impersonate="false" />

Browser-based settings for users who were prompted for credentials:

Also added the app to the Trusted Sites just to make sure.


I realized that setting Windows Authentication in IIS causes the current user’s identity to be used when the site’s files are accessed on disk. In the case of the users who were prompted, they weren’t in an AD group that had permission to the root directory. But granting access to the root folder isn’t an option for security reasons, especially if you’re storing a database connection string in the web.config file.

Thanks to this post, I learned IIS 7.5 has a setting that forces IIS to utilize another identity for disk access even when Windows Authentication is utilized. The key is to set the authenticatedUserOverride option to use the “UseWorkerProcessUser” value. Of course, make sure the worker process has permissions to the app's directory.




One more thing

User.Identity.Name no longer works once the change is made. To compensate, you can use the altnerative: Request["LOGON_USER"].

Friday, June 20, 2014

No endpoint listening: WinRT calling a WCF service on the corporate network

Scenario: WinRT app interacting with CSLA business objects hosted in a WCF service on an app server in the corporate domain.

As is typical, early in development the data portal is hosted locally on my dev machine. And the transition to hosting the data portal on a separate app server is generally straight forward. But with this WinRT app, the first I've done for the corporate environment, I ran into this problem:

Drilling down, the inner-most exception message was actually this:
"An attempt was made to access a socket in a way forbidden by its access permissions."
But everything was set up the same way my recent MVC projects have been set up. All permissions in IIS were correct.

The problem, it turns out, was not with IIS or the remote data portal. This article pointed to the necessity of declaring the right capabilities in the WinRT app's package manifest.