0xc000035b error during windows integrated login

Question

I've been trying to setup an ADFS SQL farm. I've been running into an issue when trying to authenticate a use using Windows Integrate Authentication. I get it in all the browsers that I've tried (IE, Firefox, Chrome). What's happening is that the HTTP challenge
box keeps popping up. I put in valid credentials (I've entered them in in various forms, UPN, domain\username, etc.), but the system never accepts them and keeps challenging until I cancel or I get a 401. When I look into the logs I see the following:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: portaluser1
Account Domain: vo
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000035b
Sub Status: 0x0
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: CROBISON-PC
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process:
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
During the setup of the ADFS SQL farm, I got a warning about the service principle name being already taken by some other AD object. Upon further investigation, that error is appearing because the setup is trying to assign an SPN to a domain user that is
already assigned to the machine in the AD. So, I found ADFS docs that show how to manually assign an SPN to a service account. Still no go. 
So here is a run down on how ADFS is being accessed. We have a reverse proxy that all web traffic is going through. The ADFS server farm (a farm of one server) is behind this reverse proxy. I've tried assigning SPNs to the service account that ADFS is running
under that reflect external and internal DNS names. Can anyone shed some light on this? Windows integrated auth works great when I setup a stand-alone server and don't have to do all the service account stuff.

Answer 1

Hallis:
I have a web application running on Azure, the ADFS server is published to the internet using TMG.
When accessing the application from my internal network everything works as expected. I see from the logs that the user is loggen on using Kerberos. This works for both domain joined computers and others.
But, when accessing the application from outside my internal network I get the same behaviour as you described.
The only difference in these scenarios is the reverse proxy. When it fails NTLM is used, when it works Kerberos is used. Maybe ADFS does not support NTLM?
pagefaulted:
I'm having the same issue except replace a reverse proxy with a F5 Bigip. Anyone out there have any solutions or at least explain why it is failing?
Hi all,
I've encountered the same issue a few of you mentioned above, when using a reverse proxy. In my case, the solution was to turn off Extended Protection (see
Configure Extended Protection in IIS 7.5 or
Windows Extended Protection) on the LS folder, or to configure it to match your use scenario and not perform channel-binding token (CBT) checking.
To turn Extended Protection off, on the AD FS server, launch IIS Manager, then, on the left side tree view, access
Sites -> Default Web Site -> adfs -> ls. Once you’ve selected the “/adfs/ls” folder, double-click the
Authentication icon, then right-click Windows Authentication and select
Advanced Settings… On the Advanced Settings dialog, choose Off for
Extended Protection.
HTH, 
-Ran