Windows Authentication

Leverage the host (Windows / Active Directory) credentials for transparent authentication. This chapter shows enabling integrated auth and reading the resulting principal.

Full source

File: pwsh/tutorial/examples/8.6-Windows-Authentication.ps1

<#
    Sample: Windows Authentication
    Purpose: Leverage Windows credentials for seamless authentication.
    File:    8.6-Windows-Authentication.ps1
    Notes:   Demonstrates integrated Windows authentication.
#>
param(
    [int]$Port = 5000,
    [IPAddress]$IPAddress = [IPAddress]::Loopback
)
# 1. Logging
New-KrLogger | Add-KrSinkConsole | Register-KrLogger -Name 'console' -SetAsDefault | Out-Null

# 2. Server
New-KrServer -Name 'Auth Claims'

# 3. Listener
Add-KrEndpoint -Port $Port -IPAddress $IPAddress -SelfSignedCert


# 5. Windows authentication
Add-KrWindowsAuthentication

# 7. Finalize configuration
Enable-KrConfiguration

# 8. Map policy-protected routes

Add-KrMapRoute -Verbs Get -Pattern '/' -ScriptBlock { Write-KrTextResponse 'You are authenticated with Windows Authentication' }


# 9. Start server
Start-KrServer


Step-by-step

  1. Logger: Register console logger as default.
  2. Server: Create server named “Auth Claims” (reused naming from earlier sample).
  3. Listener: Add HTTPS listener (loopback 5000) with self-signed certificate.
  4. Windows auth: Enable with Add-KrWindowsAuthentication (negotiates with the client).
  5. Enable config: Enable-KrConfiguration finalizes the pipeline.
  6. Route: Root / returns a confirmation including the identity name.
  7. Start: Launch server with Start-KrServer.

Accessing the identity

Within a route you can read:

$Context.User.Identity.Name

If the client negotiated successfully this contains the Windows (domain) user.

Try it

Invoke from a Windows client (PowerShell will automatically send current credentials when using Invoke-WebRequest with default settings for trusted loopback):

Invoke-WebRequest https://127.0.0.1:5000/ -SkipCertificateCheck | Select -Expand Content

To test an alternate identity, run the PowerShell session with runas or launch a browser in a different user context and browse to the same URL.

References

Troubleshooting

Symptom Cause Fix / Action
401 Unauthorized Negotiation failed / unsupported Use a client supporting Windows auth (IE/Edge)
Empty identity name Auth not applied to route Ensure auth enabled before Enable-KrConfiguration
Cert warnings Self-signed certificate in use Trust cert or supply valid cert

Notes

  • Windows authentication is only supported on Windows hosts.
  • Use claims/policies chapter if you need authorization beyond identity presence.
  • Combine with other schemes using route groups if partial site needs Windows auth.

Previous / Next