locked
AD FS Windows Authentication Throws 400 Bad Request

    Question

  • I was referred here by someone from the Windows Directory Services forum.  Please advise if I'm posting in the wrong place.

    AD FS 3.0 (part of Windows Server 2012 R2) is installed in preparation for deploying an Office 365 hybrid configuration.

    The default install of AD FS fails when users authenticate via the pop-up dialog when connecting from the intranet using Windows Authentication.  The /adfs/ls/idpInitiatedSignon.aspx URL pops up an authentication dialog, completion of which results in a 400 Bad Request error.  This occurs even when connecting using IE on the server itself.  After changing AD FS to use forms authentication for intranet connections, the forms logon screen appears and upon filling in the ID and password, the logon is succesful.

    Where do I start diagnosing this?  I have been through the few articles on the Internet about the 400 Bad Request errors but none seem relevant.

    Thanks in advance.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, May 6, 2014 1:04 PM

Answers

  • Also, check that you're not using CNAME records in AD FS for the federation service  .. an A record should be used... I seem to recall badly behaving configurations in the past with SPNs and CNAME...

    http://blog.auth360.net


    • Edited by Mylo Thursday, May 8, 2014 10:23 AM
    • Marked as answer by Ed CrowleyMVP Thursday, May 8, 2014 7:09 PM
    Thursday, May 8, 2014 10:22 AM

All replies

  • Bad request errors with integrated authentication might have to do with your users being member of many many groups.

    Have you tried creating a new user and just do a test login with that? That could be an easy way to exclude the group membership (token bloat) issue.


    http://setspn.blogspot.com

    Tuesday, May 6, 2014 2:32 PM
  • You may also find the cause in the Application event log in the form of an exception. If you do see one we might be able to help a bit more. Alternatively you can enable tracing to try and find the exception as well.

    Developer Security MVP | www.syfuhs.net

    Tuesday, May 6, 2014 4:18 PM
  • Prior to posting, I found articles describing the large token issue.  The account I'm using is a test account with minimal group ownership (Domain Users).

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, May 7, 2014 2:10 PM
  • There is nothing in the application log.  I also enabled tracing but I don't see anything in the tracing log that tells me anything, but it could be that I don't know where to look.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."


    Wednesday, May 7, 2014 2:10 PM
  • I think there's a way in Internet Explorer to show "less user friendly" errors. That should give you more details regarding why the request is bad. E.g. "header size to big" = typical token bloat.

    You could also use network traces, but that would require you to also import the certificate private key in your tracing tool so you can see what's going on.


    http://setspn.blogspot.com

    Wednesday, May 7, 2014 2:14 PM
  • The "More information" in the browser says:

    This error (HTTP 400 Bad Request) means that Internet Explorer was able to connect to the web server, but the webpage could not be found because of a problem with the address.

    When I uncheck "Show friendly HTTP error messages" in IE 11, there is no error thrown, just a blank page with the /adfs/ls/wia URL.

    Something I didn't say before is that after clicking Sign in, two authentication dialog boxes are presented before the error (or blank page) is shown.

    Thanks for your help.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."


    Wednesday, May 7, 2014 2:26 PM
  • multiple authentication boxes might point out to kerberos issues. Or like the classic "backConnectionhostnames" stuff. In some cases you need to add alias' to that registry key. YOu can find many blogs about this. Here's just one: http://blog.aggregatedintelligence.com/2012/01/windows-authentication-fails-when-using.html However, I can't recall having to set that one for ADFS though.

    You could try this article to get more info on the bad request error:

    http://www.iis.net/learn/troubleshoot/diagnosing-http-errors/troubleshooting-http-400-errors-in-iis

    They mention fiddler or a tracing tool or even more interesting:

    The next step is to look at the httperr.log file in the C:\Windows\System32\LogFiles\HTTPERR directory for the entry that corresponds to the bad request:

    I'm really curious to know if you have such an httperr.log file


    http://setspn.blogspot.com

    Wednesday, May 7, 2014 2:38 PM
  • If there's a Kerberos problem, I don't know where to look.  I have already verified the SPN that was created by the installation and it looks to be valid.

    There is an httperr1.log file, but it doesn't contain anything that looks useful.  The only entries for today (and I've been testing today) are five Timer_ConnectionIdle entries.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, May 7, 2014 2:50 PM
  • Regarding tracing, you'd want to look for warnings or errors. If you're saving the logs as *.svclog you can use SvcTraceViewer.exe to get a better view of the logs. Otherwise you could also provide a link to them (or email) and we can take a look.

    Alternatively it might be useful to get a fiddler trace with Decrypt SSL enabled. That might provide a bit more detail.


    Developer Security MVP | www.syfuhs.net

    Wednesday, May 7, 2014 3:54 PM
  • There's nothing in the tracing logs save for an error on the device enrollment certificate, but I am not using that feature.

    Do you have documentation on the fiddler trace, and what I should be looking for?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, May 7, 2014 3:58 PM
  • Okay, I've reproduced the problem in my own lab, which rules out any of my customer's unusual security configurations.  It's a default installation of Windows Server 2012 AD FS.  I am using a valid SSL cert that has a CN adfs.company.com and two SANs, adfs.company.com and enterpriseregistration.company.com.

    Are there configuration steps I'm not aware of that makes Windows Authentication work properly?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, May 7, 2014 6:39 PM
  • Hi Ed,

    IdP initiated workflow is somewhat different (behavior-wise) than an RP/SP initiated logon... when I've seen this in the past it's normally related to token size (as mentioned by the previous poster) or max cookie length on an intermediary device in front of ADFS.. in your lab configuration:

    (a) if you enable FBA instead of IWA, does logon work?

    (b) is the behavior the same for every user versus if you create a clean user (only membership of Domain Users)?

    (c) are there any "specials" in your configuration aside from the default configuration.

    (d) Why are users getting the popup?.. Is the AD FS federation services URL  added to the Local Intranet Zone of the browser? If you're getting the popup, having made the local Intranet zone change,  that can indicate an SPN issue...


    http://blog.auth360.net


    • Edited by Mylo Wednesday, May 7, 2014 10:13 PM
    Wednesday, May 7, 2014 10:12 PM
  • Thanks, Mylo, for the response.

    (a) Yes, FBA works fine.

    (b) This is a lab with really simple users with no significant group memberships.  In the production environment, I am also testing with a clean user.  So I think that eliminates the token size from being at issue.

    (c)  I wasn't sure about the production environment; they are a heavily locked-down organization with lots of hardening, so I built an AD FS server in my lab, which is really generic, and it displays exactly the same error.

    (d)  I disabled EAC on the browser completely, and I'm using the browser on the AD FS server itself.  I have verified that the documented SPN is present, apparently created by the installation.  The service account is associated with the FQDN of the AD FS URL.  That is correct, right?

    Is there a way to test RP/SP initated logon?  Is that the type of session that Office 365 and Outlook clients would use?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, May 7, 2014 10:59 PM
  • Testing locally is mostly not really a good idea. I've seen many cases where webapplications behave differently. Especially when using an alternate name (alias).

    I would use a browser from another machine. Perhaps do a klist purge first and then klist after trying to reach the adfs site. That way you can see if you get a kerberos ticket or not.

    If you really want to test from the server itself, I think backconnectionhostnames is biting you in the ass.

    If you want to test from another client, make sure to add the ADFS service url to the local intranet sites of your browser like Mylo suggested.


    http://setspn.blogspot.com

    Thursday, May 8, 2014 9:22 AM
  • Also, check that you're not using CNAME records in AD FS for the federation service  .. an A record should be used... I seem to recall badly behaving configurations in the past with SPNs and CNAME...

    http://blog.auth360.net


    • Edited by Mylo Thursday, May 8, 2014 10:23 AM
    • Marked as answer by Ed CrowleyMVP Thursday, May 8, 2014 7:09 PM
    Thursday, May 8, 2014 10:22 AM
  • I should have posted that the behavior is the same when testing on a browser from a different machine.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Thursday, May 8, 2014 3:23 PM
  • Good catch, Mylo.  It was indeed that the DNS record was a CNAME.  Changing it to an A record fixed the problem in both my customer's production and in my lab.  Thanks!

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Thursday, May 8, 2014 7:10 PM
  • Can't say I've seen that before. Great catch Mylo!

    Any idea why that would be problematic though? Is there a reverse lookup going on?


    Developer Security MVP | www.syfuhs.net

    Thursday, May 8, 2014 7:28 PM
  • Hi Steve,

    Yes (as I understand it), the authentication process does not work because only the Service Principal Name (SPN) for the A resource record is registered on the account that is used for the authentication. I'm not sure if the Microsoft Kerberos implementation attempts to resolve CNAME records or reverse lookup of the IP address or if there's something hard-wired in AD FS.. I could be wrong of course, but experience as shown (at least in this case) to avoid using CNAME records for AD FS....


    http://blog.auth360.net

    Thursday, May 8, 2014 10:00 PM
  • How the SPN is built clientside depends on the application. IE (and browsers generally) I guess use the host part of the URL. BUT in case it's a cname they'll resolve it to the original name behind the alias. And that is then typically the hostname of the machine.

    HTTP/hostname is typically registered on HOSTNAME$ (computer in AD) but your service (adfs, or web service) is running under s_adfs. And thus things break.

    This is pretty common in Kerberos web services. I try to explain it here a bit: http://setspn.blogspot.be/2010/06/kerberos-basic-troubleshooting-tip-3.html Check halfway

    Basically: always use A records for Kerberos enabled services


    http://setspn.blogspot.com

    Thursday, May 8, 2014 10:20 PM