NTLM is the fallback when Kerberos fails. NTLM authentication sends challenge-response hashes that can be captured and cracked (Pass-the-Hash attacks). Kerberos is cryptographically secure and uses ticket-based authentication that cannot be replayed. IIS uses Kerberos when: the client is domain-joined, the server's SPN is registered in AD, and the request uses a proper FQDN (not IP or localhost). When users connect via IP address or a hostname without a registered SPN, IIS falls back to NTLM silently. Check whether your intranet apps use Kerberos: in Fiddler or browser DevTools, look for Negotiate in the WWW-Authenticate challenge. A successful Kerberos auth shows Negotiate XTID= (Kerberos token). NTLM shows NTLM in the token prefix. Enforce Kerberos only by setting authPersistSingleRequest in Windows Authentication settings and ensuring SPNs are correctly registered.
IIS Authentication and Security Hardening
Anonymous, Windows (NTLM/Kerberos), Forms, Basic, and Client Certificate authentication — combined with IIS hardening techniques: removing server headers, request filtering, IP restrictions, and the URL Rewrite security patterns that stop common web attacks.
🧒 Simple Explanation (ELI5)
IIS authentication is like the security desk at an office building. Anonymous authentication means anyone off the street can walk in and use the lobby (public website). Windows authentication means employees scan their badge (Active Directory account) to access the restricted floors. Forms authentication is like signing in at the front desk — you show ID, get a visitor pass (cookie), and use it to move around. Basic authentication is like faxing your password to security — it works but it's not very secure. Client certificate authentication is like using a government-issued security clearance that proves exactly who you are before you can even enter the building.
🔧 Why Do We Need It?
- Intranet authentication: Windows Authentication with Kerberos gives enterprise intranet users seamless single sign-on without any login prompts — critical for HR, ERP, and IT portals.
- Attack surface reduction: hard-ening IIS reduces server fingerprinting, limits request sizes (preventing buffer overflow and DoS), and blocks known-bad paths — the Request Filtering module is the first layer of a WAF.
- 401 vs 403 diagnosis: knowing the difference between "not authenticated" (401) and "not authorised" (403) is fundamental — they require completely different troubleshooting approaches.
- Compliance: security audits check IIS configuration for Server version header disclosure, directory browsing, weak authentication, and unlocked configuration sections — knowing how to remediate these is required for PCI, SOC 2, and ISO 27001.
🌍 Real-world Analogy
IIS security hardening is like a bank vault architecture. The outer wall (Windows Firewall + IP filtering) decides who can even approach the building. The front door (HTTPS binding) ensures all conversations are private. The security guards (authentication modules) verify identity. The safety deposit box room policy (NTFS + authorisation rules) says what each authenticated person can see. The security cameras and alarms (IIS logs + FREB + event auditing) record everything for later review. Removing the server version header is like removing the "Bank Model X Vault" nameplate — why help a thief know exactly what tools to bring?
⚙️ Technical Explanation
IIS Authentication Modes: IIS supports multiple authentication providers that can be enabled or disabled per site. Anonymous Authentication uses the IUSR account (or a configured anonymous user) for all requests without credentials — appropriate for public websites. Windows Authentication uses NTLM or Kerberos to authenticate users against Active Directory. Kerberos requires the server to have an SPN (Service Principal Name) registered in AD, and the client must be on a domain-joined machine. Basic Authentication sends Base64-encoded credentials over HTTP — requires HTTPS to be secure. Forms Authentication is an ASP.NET mechanism (not an IIS module) that redirects unauthenticated users to a login page and issues a forms auth cookie. Client Certificate Authentication requires the client to present a certificate during the TLS handshake — used for machine-to-machine authentication and high-security APIs.
Request Filtering is IIS's built-in module (requestFiltering) that provides first-line request validation before any application code runs. Controls: maximum request content length (maxAllowedContentLength, default 30 MB), maximum URL length (maxUrl, default 260 characters), maximum query string length, blocked file extensions (denying .bat, .cmd, .exe, config files), blocked HTTP verbs (denying TRACE, TRACK), double-encoded request rejection, hidden segment protection (blocking access to bin/, App_Data/, .git/), and request header length limits.
Security Response Headers: headers sent by IIS that instruct browsers on security behaviour. Critical headers: X-Content-Type-Options: nosniff (prevents MIME-type sniffing), X-Frame-Options: SAMEORIGIN (prevents clickjacking), Content-Security-Policy (restricts resource loading origins), X-XSS-Protection: 1; mode=block (legacy XSS filter hint). Remove: X-Powered-By (discloses ASP.NET version) and Server (discloses IIS version). These are standard security hardening requirements in penetration test reports.
🏢 Active Directory Basics for IIS Admins
Active Directory (AD) provides centralized identity and policy management for Windows environments. A Domain Controller hosts AD DS and validates user/computer credentials. In IIS enterprise setups, Users and Groups from AD are assigned access to applications, while Group Policy (GPO) enforces machine-wide security baselines (password policy, auditing, WinRM/RDP restrictions, firewall rules). Role-Based Access Control (RBAC) is implemented by mapping AD groups to roles (for example: App-Readers, App-Operators, App-Admins) and granting only needed permissions in IIS, NTFS, and backend systems. This is the practical identity model used in production Windows server operations.
📊 Visual Representation
⌨️ Commands / Syntax
# === Authentication (web.config) ===
# Anonymous Authentication disabled, Windows Authentication enabled
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
# === Request Filtering (web.config) ===
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="10485760" maxUrl="4096" maxQueryString="2048" />
<fileExtensions allowUnlisted="true">
<add fileExtension=".config" allowed="false" />
<add fileExtension=".cs" allowed="false" />
<add fileExtension=".vb" allowed="false" />
</fileExtensions>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="HEAD" allowed="true" />
<add verb="OPTIONS" allowed="true" />
</verbs>
<hiddenSegments>
<add segment="App_Data" />
<add segment="bin" />
<add segment=".git" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
# === Remove Server and X-Powered-By headers (web.config) ===
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
<security>
<requestFiltering removeServerHeader="true" />
</security>
</system.webServer>
# === appcmd: Enable Windows Auth on a site ===
appcmd set config "MySite" /section:windowsAuthentication /enabled:true
appcmd set config "MySite" /section:anonymousAuthentication /enabled:false
# === IP Restriction (PowerShell) ===
Add-WebConfiguration system.webServer/security/ipSecurity -Value @{ipAddress="10.10.1.0";subnetMask="255.255.255.0";allowed="true"} -PSPath "IIS:\Sites\AdminSite"
Set-WebConfiguration system.webServer/security/ipSecurity -Value @{allowUnlisted="false"} -PSPath "IIS:\Sites\AdminSite"
# === Check SPN for Kerberos auth ===
setspn -L DOMAIN\ServiceAccount # List current SPNs
setspn -A HTTP/webserver.corp.com DOMAIN\AppPoolAccount # Register SPN
💼 Example (Real-world Use Case)
A finance intranet API exposed payroll data and required seamless AD login. The team enabled Windows Authentication and disabled Anonymous Authentication. Users started seeing repeated credential prompts. Root cause: users accessed the API by IP address, which prevented Kerberos SPN matching, so IIS fell back to NTLM and looped on constrained delegation. Fix: force access by FQDN, register SPN for the app pool service account (HTTP/payroll-api.corp.local), and keep the site in the browser intranet zone. Result: silent Kerberos SSO and no prompts.
🧪 Hands-on
- In IIS Manager on a test site, disable Anonymous Authentication and enable Windows Authentication. Browse from a domain-joined client using FQDN and verify silent login.
- Enable Request Filtering and block
.configand.csfile extensions. Attempt to request a blocked file path and verify a 404.7 response. - Add security headers in
web.config:X-Content-Type-Options,X-Frame-Options, and HSTS. Verify with browser dev tools response headers. - Enable IP and Domain Restrictions for an admin-only path and set allowUnlisted=false. Test from allowed and blocked client IPs.
- Turn off directory browsing and verify directory URLs no longer list files.
Disable unused IIS modules, remove default site/sample apps, force HTTPS, disable weak auth methods (Basic unless absolutely required), set request size limits, remove server disclosure headers, run app pools as least-privileged identities, and patch monthly. This baseline alone eliminates most low-hanging pen-test findings.
🐛 Debugging Scenario
Failure: Users get 401.2 after enabling Windows Authentication on an intranet site.
- 401.2 means logon failed due to server configuration. Confirm Anonymous is disabled and Windows auth is enabled for the site only.
- Accessing via IP forces NTLM fallback and often fails with constrained delegation policies; switch to FQDN.
- Check SPN on the app pool account:
setspn -L DOMAIN\svc-iis. Add missing HTTP SPN if needed. - Verify browser intranet zone settings allow automatic logon.
- Check NTFS ACLs after auth succeeds; otherwise users move from 401 to 403 due to authorization mismatch.
🎯 Interview Questions
Beginner
401 is authentication failure: user is not yet authenticated or sent invalid credentials. 403 is authorization failure: user is authenticated but not allowed access due to ACL or policy restrictions.
Basic sends credentials Base64-encoded, not encrypted. Without HTTPS anyone on-path can recover username and password. HTTPS encrypts the transport so credentials are protected.
It blocks unsafe requests before application code executes: disallowed verbs, blocked file extensions, oversized payloads, suspicious URL patterns, and protected path segments.
By default it uses the built-in IUSR account (or configured custom account). File access checks run under that identity for anonymous requests.
They reveal stack details (IIS/version/framework) that help attackers tailor exploits. Removing them reduces passive fingerprinting.
Intermediate
Use FQDN access, register proper HTTP SPNs for the service account/computer account, keep clients domain-joined, and ensure browser intranet zone auto-logon. Then verify WWW-Authenticate/Negotiate flow.
Require HTTPS, disable anonymous auth, enable Windows or client certificate auth, restrict source IPs, add strict request filtering, and apply NTFS least-privilege on backend files.
Double-escaping encodes reserved chars multiple times to bypass filters. Blocking it in requestFiltering prevents path traversal and filter-evasion tricks.
Redirect moves current HTTP request to HTTPS. HSTS tells browsers to use HTTPS first on future requests, preventing SSL stripping after first trusted visit.
Apply in staging first, run smoke tests and auth tests, check logs for blocked legitimate traffic, then deploy progressively with rollback backups of applicationHost/web.config.
Scenario-based
Disable Directory Browsing at server/site level, confirm inherited settings, validate no path still exposes listings, and add a config policy check in CI/CD to prevent regression.
Allow Basic only on a dedicated endpoint over HTTPS, restrict source IPs, enforce strong password/rotation, monitor failed logons, and plan migration to token or cert auth.
Apply IP restrictions allowlist, require VPN/private network, disable anonymous access, and enforce MFA upstream via reverse proxy or identity provider.
404.7 indicates file extension denied by requestFiltering. Re-check blocked extensions and allow only required safe types for the app.
Script appcmd/WebAdministration checks for auth modes, headers, requestFiltering, TLS policy, and module inventory; compare against baseline and alert on drift.
🌐 Real-world Usage
Most IIS breaches begin with weak defaults: anonymous admin pages, Basic over HTTP, permissive request sizes, and verbose headers. Strong authentication choices plus baseline hardening materially reduce exploitability and audit findings.
📝 Summary
Pick the right auth mode per endpoint, prefer Kerberos for intranet SSO, and enforce HTTPS everywhere. Pair this with request filtering, header hardening, IP restrictions, and least-privilege identities to make IIS resilient by default.