none
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.

    Monday, June 07, 2010 4:29 PM

Answers

  • 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
    • Proposed as answer by Randy Wiemer Monday, November 08, 2010 10:26 PM
    • Marked as answer by cdrobison Thursday, June 02, 2011 4:37 PM
    Monday, November 01, 2010 9:07 AM

All replies

  • I'm facing the same problem.

    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?


    Hallis
    Thursday, June 24, 2010 11:14 AM
  • *bump*

    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?

    Wednesday, September 15, 2010 9:31 PM
  • We also have the same issue in one of our application. Everything works fine in IE but fails in other browsers. Ours is pretty much a run through ADFS installation on the same machine as Active Directory. Any clues as to how to get around this? 

     

    Friday, October 08, 2010 9:12 AM
  • 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
    • Proposed as answer by Randy Wiemer Monday, November 08, 2010 10:26 PM
    • Marked as answer by cdrobison Thursday, June 02, 2011 4:37 PM
    Monday, November 01, 2010 9:07 AM
  • 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

     

    This solution worked beautifully for us!

    We were completely baffled by this problem. Our setup and testing:

    • AD-FS is on Domain1
    • Web Server is on Domain2
    • Domain1 trusts Domain2 but Domain2 does not trust Domain1
    • This problem was reproducible when browsing in IE, FireFox, and Chrome from the Web Server
    • This problem was NOT present on a Vista client (Domain2 - same as Web Server) in IE, FireFox, or Chrome (all successes!)
    • This problem was reproducible on a Win7 client (workstation - no domain) in FireFox and Chrome but NOT present in IE.

    This was driving us absolutely bonkers! Thank you for this solution!

    Thursday, June 02, 2011 4:25 PM
  • This fixed my problem, thanks a lot!

    I was only encountering this issue when attempting to Load Balance (NLB) the ADFS servers. Everything else looked good, but still integrated auth was failing with the 0xC00035b error. Turning off Extended Protection did the trick. I didn't try configuring CBT checking.

    Tuesday, February 14, 2012 10:11 PM
  •  Thanks Ran...Its working...You saved a day for me... :)
    Tuesday, February 21, 2012 11:04 AM