401/403 Permission Error on New IIS Setup

When a new IIS site using Windows Authentication returns 401 for regular users and works for administrators, the cause is almost always NTFS permissions on the site folder rather than the IIS authentication configuration.

The mechanism

With Windows Authentication and Anonymous Authentication disabled, IIS authenticates the caller against Active Directory and then accesses the file system using that account's token. There is no application pool identity fallback for the file read. The authenticated user needs NTFS read access to the site directory.

If the Users or Authenticated Users group lacks read access to the site folder and its parents, every non-privileged caller gets 401 or 403 while the site itself is configured correctly.

Why it passes internal testing

The asymmetry is what makes this hard to diagnose from the technology group's side.

• Whoever configured the server is typically in Administrators or a Developers group that already holds read access to the path
• That account loads the site without error
• IIS logs show authentication succeeding, so the authentication configuration appears correct
• Regular users across the organization receive 401 and report the site as down

The result is a support ticket the technology group cannot reproduce.

Diagnostic sequence

1. Confirm the failure is user-specific, not universal. An administrator loading the site successfully while a standard user cannot is the signature.
2. Check the sub-status code in the IIS log. 401.3 indicates an ACL problem on the resource, which distinguishes it from 401.1 (logon failed) and 401.2 (server configuration).
3. Inspect NTFS permissions on the site folder and every parent directory. Inheritance is frequently broken at a parent level, so read access on the site folder alone is not sufficient.
4. Verify the authentication configuration (Windows Authentication enabled, Anonymous Authentication disabled) to rule out the case where anonymous access was intended.

Resolution

Grant read and execute permission to Authenticated Users, or to a domain group containing the intended audience, on the site directory and its parent chain. Prefer a scoped domain group over Everyone, and apply it at the level where inheritance can flow to the content.

Where the application writes to disk (logging, uploads, temporary files), those specific directories need write permission for the same principal, granted narrowly rather than at the site root.

Where this recurs

The pattern appears most often on internal Angular or React applications served from IIS with Windows Authentication. Static assets are served directly from disk under the caller's token, so the failure affects every request rather than only API calls, and the application appears entirely unreachable to affected users while rendering correctly for the team that deployed it.