Kernel-Mode Authentication Research

My initial testing and dev was done against a single-page vibe coded dummy webapp running on IIS with Windows Authentication enabled. With the above reworks implemented, everything was running smooth, but things got more complicated when I tried testing against real enterprise software. I obtained a trial of Passwordstate Password Manager and stood it up in my lab, relayed against it, and the debugging got nasty. My relays succeeded and the initial page loaded fine; however, on the first navigation click, I was re-prompted for basic auth. Each subsequent click simply brought up another basic authentication browser prompt, and all requests failed after this point.

My first suspect was IIS’s auth persistence settings. authPersistSingleRequest instructs IIS to re-challenge for auth on each request, but it defaults to false, and I confirmed this setting remained intact for Passwordstate along with all IIS defaults. However, even when set to true, this wouldn’t explain what I saw: 30 to 50 authenticated requests returning 200 successfully, followed by a sudden HTTP 401 response. AuthPersistNonNTLM was also irrelevant, as it applied to Kerberos only. After days of scrutinizing IIS settings and defaults, I noticed that, unlike my manually installed dummy app, Passwordstate installs with IIS defaults, which include the Kernel Mode Authentication setting.

This setting moves auth logic from IIS usermode execution, to the kernel level in the HTTP. sys listener. Windows makes auth decisions before they even reach IIS or the application layer. After combing through request logs for days, I noticed a pattern: the 401 re-challenge for auth always came after successful requests to certain endpoints. On closer look, despite the web root requiring Windows Authentication, these virtual directories and URL paths for static content (CSS files, JavaScript, images, fonts, etc.

) were set to Anonymous Authentication.