IIS 101: The Basics of IIS Authentication

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

IIS authentication determines who is making an HTTP request; authorization determines whether that identity may access a site, URL, file, or application function. For a public website, Anonymous Authentication is usually correct. For a domain-based intranet, Windows Authentication is generally the best fit. Basic Authentication can work for simple clients only when protected by HTTPS, while client certificates suit selected machine-to-machine scenarios.

IIS can authenticate a request at the web-server layer, or it can let the application handle login with cookies, tokens, OAuth 2.0, or OpenID Connect. Choosing the right approach depends on your users, clients, trust boundary, and whether you need Windows identities or modern application identity.

#	Preview	Product	Price
1		IIS 8 Administration: The Personal Trainer for IIS 8.0 and IIS 8.5	$39.99	Buy on Amazon
2		Microsoft IIS 5 Administration: A Authoritative Solution (Sams White Book Series)	$229.97	Buy on Amazon
3		Professional Microsoft IIS 8	$52.77	Buy on Amazon
4		IIS 6 Administration	$33.60	Buy on Amazon
5		Learn Windows IIS in a Month of Lunches	$43.50	Buy on Amazon

Authentication and authorization are different

Authentication answers “Who are you?” It verifies credentials, a security token, or a client certificate and establishes an identity for the request.

Authorization answers “Are you allowed to do this?” It determines whether the authenticated identity may access a particular URL, file, operation, or business function.

#1 Best Overall

IIS 8 Administration: The Personal Trainer for IIS 8.0 and IIS 8.5

$39.99

Buy on Amazon

Authentication does not automatically grant access. A user can authenticate successfully and still be rejected by IIS URL Authorization, NTFS permissions, or application-level rules.

A typical request passes through several layers:

Client request
    ↓
IIS authentication module
    ↓
Authenticated identity or authentication challenge
    ↓
IIS URL Authorization
    ↓
NTFS permissions, where applicable
    ↓
Application authentication and authorization
    ↓
Response

IIS authentication settings belong to the system.webServer/security/authentication section. Server-wide settings are commonly stored in ApplicationHost.config, while application-specific settings can be stored in Web.config. See Microsoft’s IIS authentication documentation and IIS authorization documentation.

IIS authentication methods at a glance

IIS also supports additional authentication modules, and the application may implement another identity system independently.

How Anonymous Authentication works

Anonymous Authentication allows a client to request content without first presenting credentials to IIS. It is normally enabled by default and is appropriate when the resource is genuinely public.

Anonymous does not mean that the request has no security context. IIS can process anonymous requests using the configured anonymous account; Microsoft’s IIS documentation identifies IUSR as the default anonymous account. That account, or the configured replacement, must have the necessary NTFS permissions when IIS serves files directly.

This creates an important distinction:

• A public page can be reachable through Anonymous Authentication.
• A specific directory or URL can still have authorization restrictions.
• A public IIS endpoint can still require the application to validate a login, cookie, token, or API key.

If a site is supposed to be protected by Windows, Basic, or Digest Authentication, disable Anonymous Authentication at the protected scope. Leaving Anonymous enabled is one of the most common reasons a supposedly protected site remains publicly reachable.

Read more in Microsoft’s Anonymous Authentication reference.

How Windows Authentication works

Windows Authentication uses Windows-integrated protocols and is designed primarily for environments where clients and servers share a Windows or Active Directory trust relationship. It is common for intranets, internal line-of-business applications, administrative tools, and Windows-integrated APIs.

The provider list normally contains:

• Negotiate, which attempts Kerberos when the environment supports it.
• NTLM, which may be used as a fallback or where Kerberos is unavailable.

“Windows Authentication” is therefore not synonymous with “NTLM.” A successful sign-in also does not prove that Kerberos was used. The client may have authenticated through NTLM fallback.

Windows Authentication is a good choice when employees need single sign-on, the application needs Windows usernames or group membership, or clients are domain-joined. It is a poor fit when users are anonymous members of the public, use unmanaged devices, or need a modern consumer identity experience.

Its security and reliability depend on the surrounding configuration: protocol negotiation, DNS, hostnames, service principal names, browser and proxy behavior, domain trust, TLS, and authorization rules. Microsoft’s Windows Authentication documentation and provider documentation describe the available configuration.

Rank #2

Microsoft IIS 5 Administration: A Authoritative Solution (Sams White Book Series)

• Used Book in Good Condition

$229.97

Buy on Amazon

Configure Windows Authentication in IIS

Prerequisites

• Windows Server with the Web Server (IIS) role installed.
• Administrative privileges.
• The Windows Authentication role service installed.
• A target site, application, directory, or URL selected in IIS.
• Windows accounts and clients configured for the intended domain or trust environment.

Windows Authentication is not included in every default IIS installation, so install the role service before enabling it for a site.

Install it with Server Manager

1. Open Server Manager.
2. Select Manage → Add Roles and Features.
3. Choose Web Server (IIS).
4. Expand Web Server → Security.
5. Select Windows Authentication.
6. Complete the installation.
7. Open IIS Manager and select the target site or application.
8. Open Authentication.
9. Select Anonymous Authentication and choose Disable.
10. Select Windows Authentication and choose Enable.

Exact screens vary between Windows Server releases, but the stable feature path is Web Server (IIS) → Web Server → Security → Windows Authentication.

Install it with PowerShell

Run this from an elevated Windows PowerShell session:

Install-WindowsFeature Web-Windows-Auth -IncludeManagementTools

To inspect the feature names available on the target build first, use:

Get-WindowsFeature *Web*Auth*

The -IncludeManagementTools switch also installs applicable management tools. Microsoft’s current Install-WindowsFeature reference documents this pattern.

Configure it in IIS Manager

1. Select the site or application in IIS Manager.
2. Open Authentication.
3. Disable Anonymous Authentication.
4. Enable Windows Authentication.
5. Open Providers… to inspect the Negotiate and NTLM providers.
6. Test from an authorized client.

Changing IIS configuration normally reloads the relevant application configuration; a full server restart is not normally required.

Configure it in Web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
</configuration>

This enables IIS Windows Authentication for the applicable scope. It does not specify which users or groups may access the content.

Configure it with Appcmd.exe

%windir%system32inetsrvappcmd.exe set config "Default Web Site" ^
  -section:system.webServer/security/authentication/anonymousAuthentication ^
  /enabled:"False" /commit:apphost

%windir%system32inetsrvappcmd.exe set config "Default Web Site" ^
  -section:system.webServer/security/authentication/windowsAuthentication ^
  /enabled:"True" /commit:apphost

Replace Default Web Site with the actual IIS site name.

Restrict access to a Windows user or group

After authentication establishes the user’s identity, add authorization if only selected users or groups should enter.

Use IIS Manager

1. Install the URL Authorization role service if it is not already installed.
2. Select the site, application, directory, or URL.
3. Open Authorization Rules.
4. Choose Add Allow Rule….
5. Select the appropriate users or roles/groups.
6. Add a deny rule where required.
7. Test with both an allowed and a denied account.

Use Web.config

This example allows only the local or domain-qualified Windows group named Administrators:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <security>
      <authorization>
        <clear />
        <add accessType="Allow" roles="Administrators" />
      </authorization>
    </security>
  </system.webServer>
</configuration>

For a domain group, use its resolvable domain-qualified name:

Rank #3

Sale

Professional Microsoft IIS 8

$52.77

Buy on Amazon

<add accessType="Allow" roles="CONTOSOIIS-Readers" />

The domain, group name, trust relationship, and group membership must be resolvable in the server’s security context. A typo, broken trust, or stale group-membership state can look like an authentication failure even though the user authenticated successfully.

IIS authorization rules also support special identifiers:

• users="*" means all users.
• users="?" means anonymous users.
• An empty verbs value applies to all HTTP verbs.

See Microsoft’s authorization rule syntax.

Basic Authentication: simple, but only with HTTPS

Basic Authentication sends a username and password in an HTTP authentication header. The credentials are encoded using Base64. Base64 is encoding, not encryption.

Use Basic Authentication only when:

• The client supports HTTP Basic.
• HTTPS/TLS is mandatory and correctly enforced.
• Credentials are unique, managed, and rotated appropriately.
• You understand account lockout, password policy, exposure, and replay risks.

Never treat Basic Authentication as safe over plain HTTP. Do not use it as a substitute for multifactor authentication or modern federation. It can be practical for a tightly controlled API or legacy client, but the complete design must include TLS and credential-management controls.

Microsoft’s Basic Authentication documentation covers its IIS configuration.

Digest Authentication

Digest Authentication uses a challenge-response mechanism rather than sending the raw password in the same way as Basic Authentication. However, it is not a general replacement for HTTPS.

Digest does not protect the HTTP message body, is less widely used, and can introduce compatibility and operational complexity. Use it only when a legacy or specialized client specifically requires it, and continue to use HTTPS to protect the complete connection. See Microsoft’s Digest Authentication reference.

Client certificate authentication

Client certificate authentication is a form of mutual TLS. The server presents its certificate to the client, and the client presents a certificate to the server. IIS can validate the certificate chain and map or evaluate the client identity.

It is suitable for selected scenarios such as:

• Service-to-service APIs.
• Managed corporate devices.
• Private partner integrations.
• High-assurance administrative portals.

It is not usually a beginner-friendly replacement for an ordinary website login. You must operate certificate issuance, enrollment, renewal, revocation, trust stores, device configuration, and client compatibility. IIS has distinct certificate-based options, including ordinary IIS Client Certificate Mapping and IIS Client Certificate Mapping Authentication; they should not be treated as identical features.

Kerberos, NTLM, and the double-hop problem

Windows Authentication often becomes difficult when a request involves more than one server.

Negotiate does not guarantee Kerberos

The Negotiate provider attempts Kerberos when the required conditions are present. If Kerberos cannot be negotiated, authentication may fall back to NTLM. Hostname aliases, DNS, service accounts, SPNs, load balancers, browser settings, and domain relationships can all affect the result.

Rank #4

Sale

IIS 6 Administration

$33.60

Buy on Amazon

Therefore, a working login is not proof that Kerberos is in use. Verify the negotiated protocol with appropriate diagnostics. Microsoft’s Windows Integrated Authentication diagnostics address protocol identification and delegation troubleshooting.

What the double hop means

Suppose a user authenticates to an IIS front end, and that front end then tries to access another service on the user’s behalf:

• IIS accesses a file share.
• IIS calls a back-end HTTP service.
• IIS connects to SQL Server using the user’s identity.

Authentication to the front-end server can succeed while the second request fails. Passing the user’s identity to the second service requires delegation and an appropriate Kerberos configuration; it is not automatically granted by enabling Windows Authentication.

Keep these identities separate when troubleshooting:

• The user authenticated to the front-end IIS server.
• The IIS worker process or application-pool identity accessed a resource.
• The user’s credentials were, or were not, delegated to a second service.

Do not casually disable security controls as a fix. Delegation is an advanced design and configuration topic.

When Anonymous Authentication is the right choice

Use Anonymous Authentication when the resource is intentionally public, including:

• Public websites and documentation.
• Static files and images.
• Public JavaScript or CSS assets.
• Unauthenticated health-check endpoints.
• Applications that handle login entirely through their own identity system.

A site can use Anonymous IIS access while ASP.NET Core or another application framework requires a cookie, bearer token, OAuth 2.0 token, or OpenID Connect login for protected operations. In that design, IIS is not the component that identifies the end user.

IIS authentication versus application authentication

IIS authentication runs at the web-server layer. The application can then consume the established Windows identity, or it can implement a separate authentication pipeline.

Common application-level approaches include:

• ASP.NET Core authentication handlers.
• Cookie authentication.
• JWT bearer tokens.
• OAuth 2.0 and OpenID Connect.
• Legacy ASP.NET Forms Authentication.
• API keys or custom middleware.

These combinations are all possible:

1. Anonymous IIS access with application-level login.
2. Windows IIS Authentication with the application consuming the Windows identity.
3. Basic IIS Authentication protecting a compatible API.
4. IIS authentication protecting the outer site while the application applies finer-grained rules.

Do not assume that an application setting alone enables the IIS feature. For example, an ASP.NET <authentication mode="Windows"> setting belongs to the application’s configuration model; it does not install or enable the IIS Windows Authentication role service. IIS settings belong under system.webServer.

For public-facing applications that need social login, multifactor authentication, conditional access, or users outside a Windows domain, application-level federation or token-based identity is often a better fit than an IIS challenge.

Troubleshooting IIS authentication

1. Confirm the scope

In IIS Manager, verify that you selected the intended server, site, application, virtual directory, or URL. Authentication settings are inherited, and a more-specific scope can override a broader one.

Best Value

Learn Windows IIS in a Month of Lunches

• Used Book in Good Condition

$43.50

Buy on Amazon

Inspect effective configuration and look for relevant <location> elements. Avoid blindly changing global ApplicationHost.config; keep application-specific rules in source-controlled Web.config where appropriate.

2. Confirm the feature is installed

If Windows, Basic, Digest, or certificate options are missing from IIS Manager, confirm that the corresponding IIS role service or authentication module is installed.

3. Check Anonymous Authentication

For a protected Windows, Basic, or Digest scope, confirm that Anonymous Authentication is disabled at that same scope or at any more-specific scope. Conversely, do not disable Anonymous globally when only one application needs protection.

4. Check providers and client compatibility

For Windows Authentication, inspect the provider order and test from a client that belongs to the expected domain or trust boundary. Browser, proxy, and intranet-zone behavior can affect integrated authentication.

5. Check names, DNS, and Kerberos prerequisites

Use the intended hostname rather than assuming an IP address or alias will negotiate identically. If Kerberos matters, investigate DNS, SPNs, service accounts, aliases, and load balancers. Verify whether the request used Kerberos or NTLM instead of assuming it.

6. Check group membership and authorization

A user can authenticate successfully but fail an authorization rule. Confirm that the account is a member of the exact domain group named in the rule and that the server can resolve that group.

7. Separate URL Authorization from NTFS permissions

These controls operate at different layers:

• URL Authorization controls access at the IIS URL or application level.
• NTFS permissions control file-system access.
• Application authorization controls business permissions inside the code.

Passing one layer does not automatically pass the others.

8. Interpret 401 responses carefully

Subcodes can vary by configuration and hosting stack. Confirm the detailed IIS log entry and use Failed Request Tracing when necessary instead of diagnosing from the top-level 401 alone.

Microsoft also documents a specific 401.1 pre-authentication-header scenario involving kernel-mode authentication. Do not treat disabling kernel-mode authentication as a general Kerberos fix; it is a targeted workaround for a particular scenario.

9. Test more than one account and client

Use a small test matrix:

• An allowed account.
• An authenticated but unauthorized account.
• An anonymous request.
• A public endpoint, if the application has one.
• A protected endpoint.
• A client inside the expected domain.
• A client outside the domain or trust boundary, where relevant.

Browser success may not predict behavior in curl, Postman, JavaScript fetch, mobile applications, reverse proxies, or CORS-enabled APIs. Windows Authentication also does not automatically solve CORS, CSRF, token management, or cross-origin credential behavior.

Choosing the right IIS authentication method

The server layer and application layer can be combined, but document which component owns authentication and which component owns authorization. Ambiguity is a common cause of unexpected prompts and access failures.

Final checklist

• Define whether the content is public or protected.
• Choose authentication based on users, clients, and trust boundaries.
• Install the required IIS role service or module.
• Disable Anonymous Authentication for protected scopes.
• Enable the selected IIS authentication method.
• Add URL Authorization when only certain users or groups should enter.
• Check NTFS permissions separately from IIS rules.
• Use HTTPS for Basic and Digest deployments.
• Do not assume Windows Authentication means Kerberos.
• Investigate delegation separately when a back-end service is involved.
• Decide whether the application should handle cookies, tokens, OAuth, or OpenID Connect.
• Test allowed, denied, anonymous, public, and protected requests.

Conclusion

IIS authentication is the web-server layer that establishes request identity. Anonymous is right for genuinely public resources; Windows Authentication is usually the natural choice for domain-based intranets; Basic is acceptable only with properly enforced HTTPS; Digest is mainly a specialized or legacy option; and client certificates are best reserved for managed-device and machine-to-machine scenarios.

Whatever method you choose, authentication is only the first step. Confirm authorization rules, NTFS permissions, application behavior, configuration inheritance, and—when Windows Authentication crosses server boundaries—the Kerberos and delegation design.

Quick Recap

Bestseller No. 1

IIS 8 Administration: The Personal Trainer for IIS 8.0 and IIS 8.5

$39.99

Bestseller No. 2

Microsoft IIS 5 Administration: A Authoritative Solution (Sams White Book Series)

Used Book in Good Condition

$229.97

SaleBestseller No. 3

Professional Microsoft IIS 8

$52.77

SaleBestseller No. 4

IIS 6 Administration

$33.60

Bestseller No. 5

Learn Windows IIS in a Month of Lunches

Used Book in Good Condition

$43.50

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.