AD FS Web App Proxy authentication stuck at login adfs screen

EJ Pennyman III 1 Reputation point
2020-07-28T00:08:10.39+00:00

We're having a weird issue. I've configured my AD FS WAP for use with Office 365. I use split DNS with internal DNS pointing to the AD FS server and external DNS pointing to the AD FS WAP which is on a DMZ domain in my DMZ. The Office 365 RCA says it's configured correctly.

I can use a browser and authenticate corrected (via portal.office.com, which redirects to adfs.mydomain.com). This only works from inside my network.

Externally, I get the adfs.mydomain.com login page and when I enter my password, the page reloads. If I enter an incorrect password, I get the error that the password was incorrect. I get the same behavior from Office Applications (like Excel) when I attempt to register them.

Initially I got the same odd behavior internally when I used any browser besides IE. I resolved this by setting the WIASupportedUserAgents to allow Chrome and Firefox. Now I have that same behavior externally from any browser. This feels like I need to modify the external Agent string, but I'm not sure which command to use as get-adfs* doesn't work in powershell on the WAP.

Please help!

Active Directory Federation Services
Active Directory Federation Services
An Active Directory technology that provides single-sign-on functionality by securely sharing digital identity and entitlement rights across security and enterprise boundaries.
1,240 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. 9704244848 186 Reputation points
    2020-07-28T15:40:23.313+00:00

    Which IP address get you if you run nslookup adfs.domain.com on your WAP, internal oder external?
    Which operatation system you use for AD FS and WAP servers? Especially for Windows Server 2012(R2) with AD FS 3.0 it exist some updates, which must be installed.
    Did you check the claim rule and their access control already?

    Double check your current AD FS configuration for Office 365 with follow blog articles:
    https://simpleitpro.com/index.php/2018/08/24/step-by-step-o365-configuration-for-single-sign-on-with-adfs-2016-2/
    http://www.thatlazyadmin.com/configure-adfs-office-365/


  2. Pierre Audonnet - MSFT 10,181 Reputation points Microsoft Employee
    2020-07-28T17:57:49.05+00:00

    I'd suspect that you use custom certificates (as opposed as the default self-signed) and that the Token Encrypting certificate you use in your ADFS deployment does not have the proper KeySpec. If the KeySpec is not set to 1 (AT_KEYEXCHANGE), you can't use Form Based Authentication as ADFS can't encrypt stuff. This will fail because ADFS used that certificate in the process. It will just loop. This certificate is not used when you use Windows Integrated Authentication. Hence you don't have the problem internally. And you fixed the internal clients using Form Based Authentication thanks to WIASupportedUserAgents.

    Anyhow, run the following PowerShell cmdLets on your primary ADFS server to determine the KeySpec of your Token Decrypting cert:

    $cert = (Get-AdfsCertificate -CertificateType Token-Decrypting).Thumbprint
    certutil -v -store My $cert | Where-Object {$_ -like "*KeySpec*"}
    

    If the output is not:

        KeySpec = 1 -- AT_KEYEXCHANGE
    

    Then we found our problem. And we can fix it by re-importing the certificate. You would delete from the store (you can use the MMC) and re-import it with specifying the KeySpec like:

    certutil -importpfx Token-Decrypting.pfx AT_KEYEXCHANGE
    

    Let us know! 🤞


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.