All DUO authentication methods currently failing

[Leglaw]

Likely related: https://status.duo.com/incidents/cp1rl1hw2zpx

However DUO resolved the issue now causing all authentication methods to fail?

[dcibarra]

Same issue here

[Leglaw]

Disabling the user-agent entirely is a workaround:

_headers = {
    "Accept-Language": "en",
    # "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) like Gecko"
    # if platform.system() in ("Linux", "Darwin")
    # else "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
    "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
    "Accept": "text/plain, */*; q=0.01",
}

[VTantillo]

Unfortunately that didn't seem to work for me :/

[hcsyash]

Getting same issue, getting following error:- Error: Cannot begin authentication process. The error response: {"stat": "FAIL", "message_enum": 7, "data": {}}

Also, the default authentication setting (Duo Push in my case) is not getting retrieved from DUO server No default authentication method configured. Please enter your desired authentication method (e.g. "Duo Push", "Passcode", "Phone Call", or "WebAuthn Security Key"): Duo Push No default authentication device configured. Please enter your desired authentication device (e.g. "phone1" with "Duo Push" or "Phone Call"), or "None" with "WebAuthn Security Key" or "Passcode": Phone1

[erpel]

Digging into the source code right now. It seems we're hitting

    if 'sid' not in query:
        # No need for second factor authentification, Duo directly returned the authentication cookie
        return (None, None, None, None, _js_cookie(html_response)), True

in duo_authenticator.py and returning without a sid, even though a second factor is definitely needed in our setup. The code tries to extract a SID from the query string but it's not present there. We do find a sid hidden input in the response body. Trying to use that one just leads to a new error message: Error: Cannot begin authentication process. The error response: {"stat": "FAIL", "message": "Authentication access denied."}

[mattmauriello]

I noticed the same issues for my MFA authenticated ADFS farm last night around 10pm US/Eastern, still behaving the same way this morning. my Non-MFA connections seem to be fine. the header changes mentioned above didn't do anything for me (Leglaw). im going to try to dig in more throughout the day, but not sure I have the expertise for this one, and I also dont know what the Duo response "used" to look like to compare.

[erpel]

Removing the user agent from multiple (all) locations did "fix" the login. This was repeated for 2 users in our org.

diff --git a/aws_adfs/_duo_authenticator.py b/aws_adfs/_duo_authenticator.py
index 24dab39..29f6526 100644
--- a/aws_adfs/_duo_authenticator.py
+++ b/aws_adfs/_duo_authenticator.py
@@ -38,7 +38,7 @@ from . import roles_assertion_extractor

 _headers = {
     'Accept-Language': 'en',
-    'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko',
+    # 'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko',
     'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
     'Accept': 'text/plain, */*; q=0.01',
 }
@@ -418,7 +418,7 @@ def _initiate_authentication(duo_host, duo_request_signature, roles_page_url, se
         verify=ssl_verification_enabled,
         headers={
             'Host': duo_host,
-            'User-Agent': "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36",
+            # 'User-Agent': "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36",
             'Accept': "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
             'Accept-Language': "en-US,en;q=0.5",
             'Accept-Encoding': "gzip, deflate, br",
diff --git a/aws_adfs/_duo_universal_prompt_authenticator.py b/aws_adfs/_duo_universal_prompt_authenticator.py
index fe2c623..1460b57 100644
--- a/aws_adfs/_duo_universal_prompt_authenticator.py
+++ b/aws_adfs/_duo_universal_prompt_authenticator.py
@@ -39,9 +39,9 @@ from . import roles_assertion_extractor

 _headers = {
     "Accept-Language": "en",
-    "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) like Gecko"
-    if platform.system() in ("Linux", "Darwin")
-    else "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
+    # "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) like Gecko"
+    # if platform.system() in ("Linux", "Darwin")
+    # else "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
     "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
     "Accept": "text/plain, */*; q=0.01",
 }
diff --git a/aws_adfs/account_aliases_fetcher.py b/aws_adfs/account_aliases_fetcher.py
index 204ceb7..7fdf25b 100644
--- a/aws_adfs/account_aliases_fetcher.py
+++ b/aws_adfs/account_aliases_fetcher.py
@@ -16,7 +16,7 @@ def account_aliases(session, username, password, auth_method, saml_response, con
         verify=config.ssl_verification,
         headers={
             'Accept-Language': 'en',
-            'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko',
+            # 'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko',
             'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
             'Accept': 'text/plain, */*; q=0.01',
         },

If the 2fa login was completed the unpatched version also works for reset/login if the cookies file remains intact.

[mattmauriello]

Thank you @erpel , I can confirm your patch did indeed solve my issues.

[pdecat]

Hi all, I'm no longer using aws-adfs as we moved from MS AD-FS to another SSO solution, so I cannot reproduce nor test your fixes.

Feel free to submit a PR, and if several people can test and validate that branch, I'll merge and release the fix.

[mattmauriello]

for the record, I tried updating the header to the same thing my browser (chrome) sends when doing console login: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

it didn't help. while it doesn't feel right, i dont have a better solution than removing the header, though I can't. I'm happy to write a PR, but @erpel deserves the glory if willing to submit it.

[trav-c]

I've got several users running into the same issue, I can confirm that in my case commenting out the User-Agent in both places in _duo_authenticator.py resolved the problem for me (using the legacy duo prompt).

I also tried updating all instances of the User-Agent string to my browser: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0 and had the same result as @mattmauriello - it didn't help, even after clearing the cookie

[pdecat]

Found this documentation about user-agent policies: https://duo.com/docs/policy#browsers

[pdecat]

Fix released in https://github.com/venth/aws-adfs/releases/tag/2.8.2