CODEWITHSUNDEEP
authenticationiis-7
Dubya
Dubya

Reputation: 13

IIS 7 Windows authentication with default app pool setup problems

I have IIS 7.5 site:

  1. Authentication = Windows Aythentication enabled
  2. Application Pool = DefaultAppPool
  3. DefaultAppPool Identity = ApplicationPoolIdentity
  4. Load User Profile = True

On the filesystem,

  1. DefaultAppPool has Read and Execute privileges to the entire site.
  2. Also added a security group with Read and Execute privileges to the entire site.

With these settings, only users in the security group are able to access the site. All others get a AD login window, which has no affect. I'm not understanding this behaviour.

From research, it looks like I don't need to add the DefaultAppPool to the filesystem, if users are only executing, but still doesn't explain why they get the login challenge.

I'm also unclear if i need to set the AuthenticatedUserOverride (in Config Editor) from UseAuthenticatedUser to UseWorkerProcessUser if i want to use the filesystem security of DefaultAppPool. When i set this, i get an access error, not even the login challenge.

Note: site is not in the Default Web Site, but on a specific port number.

I'm unclear why i seem to need users listed in an ACL rather than using the generic DefaultAppPool.

Upvotes: 0

Views: 852

Answers (1)

Josh
Josh

Reputation: 10604

Windows authentication determines how you determine who is who. Impersonation means which user account the security context runs under. Because you are loading the user profile, the context is taking on the AD user's security. Your DefaultAppPool identity is now out of the picture which is why you need ACL's on your files / folder.

Users will continue to receive the login prompt who are not cleared at the ACL level because IIS doesn't know what to do until an account that can access the files is provided. Watch in fiddler and you'll continue to see challenge messages from the server.

Upvotes: 1

Related Questions