When working with Windows Authentication in IIS, you might encounter a scenario where authentication works perfectly when accessing the site via hostname (e.g., http://mysite) but prompts for credentials when using the FQDN (http://mysite.something.com). This behavior stems from how Windows Integrated Authentication handles SPN (Service Principal Name) and security zones in Internet Explorer.

The root cause typically relates to Kerberos authentication failing and falling back to NTLM. Kerberos requires proper SPN registration for the FQDN. Try these verification steps:

setspn -L myserver
# Check if HTTP/mysite.something.com exists
# If missing, register it with:
setspn -A HTTP/mysite.something.com myserver

Internet Explorer treats FQDNs differently from simple hostnames in terms of security zones. Ensure both URLs are in the same security zone (typically Local Intranet):

# Check current zones with PowerShell:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains"

Modify your web.config to explicitly enable Windows Authentication and disable anonymous access:

<system.webServer>
  <security>
    <authentication>
      <anonymousAuthentication enabled="false" />
      <windowsAuthentication enabled="true">
        <providers>
          <clear />
          <add value="Negotiate" />
          <add value="NTLM" />
        </providers>
      </windowsAuthentication>
    </authentication>
  </security>
</system.webServer>

For proper name resolution, ensure your hosts file contains both entries:

127.0.0.1 mysite
127.0.0.1 mysite.something.com

Enable failed request tracing in IIS to capture authentication attempts:

1. Open IIS Manager
2. Select your site
3. Double-click "Failed Request Tracing"
4. Create a new rule for status code 401

After making changes, test with different browsers and clear credentials cache:

klist purge  # Clears Kerberos tickets

---

When working with Windows Integrated Authentication in IIS, you might encounter a peculiar scenario where authentication works flawlessly when accessing the site via shortname (http://mysite) but suddenly prompts for credentials when using the FQDN (http://mysite.something.com). This behavior isn't just annoying - it breaks the seamless SSO experience we expect from Windows authentication.

The root cause typically lies in how Windows Authentication handles SPN (Service Principal Name) registration and the browser's security zone settings. Here's what's happening under the hood:

• IE/Edge assigns different security zones to shortname vs FQDN URLs
• Kerberos authentication requires proper SPN registration
• The browser may downgrade to NTLM when SPN issues exist

First, let's verify the authentication methods being used with this PowerShell snippet:

# Check IIS authentication settings
Import-Module WebAdministration
Get-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name enabled -PSPath IIS:\Sites\YourSiteName
Get-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name providers -PSPath IIS:\Sites\YourSiteName

The most reliable solution is to ensure proper SPN registration for your website. Run these commands as domain admin:

setspn -S HTTP/mysite.something.com DOMAIN\ServerAccount
setspn -S HTTP/mysite DOMAIN\ServerAccount

For websites using multiple hostnames, you might need:

setspn -S HTTP/mysite.something.com DOMAIN\ServerAccount
setspn -S HTTP/alternate.alias.com DOMAIN\ServerAccount
setspn -S HTTP/mysite DOMAIN\ServerAccount

Ensure your FQDN is in the Intranet zone. For IE/Edge, add these registry settings:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\something.com]
"mysite"=dword:00000001

Make sure your IIS bindings include both hostnames:

# PowerShell to check bindings
Get-WebBinding -Name "YourSiteName" | Select-Object protocol,bindingInformation

And set the proper authentication providers in IIS configuration:

# Configure authentication providers
Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name providers -Value @('Negotiate','NTLM') -PSPath IIS:\Sites\YourSiteName

If you're still having issues, check delegation settings in Active Directory:

# Check constrained delegation (PowerShell)
Get-ADComputer -Identity ServerName -Properties msDS-AllowedToDelegateTo

After making changes, test with this command to verify Kerberos is working:

klist get HTTP/mysite.something.com

Remember to restart the IIS service and clear the browser cache before testing changes.