Error: Issues during redirection to aws roles page. The error response <Response [401]>

[leoww11Ptr]

aws-adfs version: 0.4.0 python: tried on 2.7,3.4, and 3.6 urllib3 version: (1.10.2) setup: Duo 2FA, and multi-role account

I get this error after passing the 2FA with successful auth: "Going for aws roles".

Two requests follow: first being a POST to adfs with cookies set, which results in 302. the following request is a GET to adfs which "should" retrieve the aws sign in form, but does not in this case.

when using the --verbose option, I noticed that the redirection (see the logs) points to: ..../wia?loginToRp=urn:amazon:webservices instead of: .../IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices

any idea what might be causing this erroneous redirection_location?

2017-10-14 11:28:40,271 [connectionpool connectionpool.py:_make_request] [19156-MainProcess] [139651693283136-MainThread] - DEBUG: https://adfs.xwz.com:443 "POST /adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices HTTP/1.1" 302 0

2017-10-14 11:28:40,332 [connectionpool connectionpool.py:_make_request] [19156-MainProcess] [139651693283136-MainThread] - DEBUG: https://adfs.xwz.com:443 "GET /adfs/ls/wia?loginToRp=urn:amazon:webservices HTTP/1.1" 401 0

[venth]

Hi @leoww11Ptr,

would you like to verify if a previous version works correctly? The previous version can be installed with: pip install aws-adfs==<version to install>.

If you could also share anonymized logs from version: 0.4.0 I would appreciate it. Please send the logs on my address: artur(dot)krysiak(dot)warszawa(at)gmail.com

[leoww11Ptr]

Logs delivered. tried the following versions with no success: 0.3.0, 0.3.3, 0.3.9, 0.3.18

[venth]

Please try most recent version. There was a fix for windows machine delivered. I hope it will solve the issue for you as well.

[leoww11Ptr]

Thank you, I will.

On Nov 19, 2017 7:24 AM, "Artur Krysiak" [email protected] wrote:

Please try most recent version. There was a fix for windows machine delivered. I hope it will solve the issue for you as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/venth/aws-adfs/issues/57#issuecomment-345512599, or mute the thread https://github.com/notifications/unsubscribe-auth/AfSSTBTiILRggLz0NQjZEeikBiRdCdodks5s4B3lgaJpZM4P5lhf .

[venth]

@leoww11Ptr any success with the most recent version?

[max-nearmap]

Hi @venth and @leoww11Ptr , having same issue on windows 10 with aws-adfs v0.11.0, logs are pretty consistent with @leoww11Ptr 's ones. Did you manage to solve the issue? Cheers

[venth]

Unfortunately I didn’t manage to solve it. I don’t have access to windows machine. Perhaps do you want to use workaround with docker? I can provide Dockerfile or compose with aws-adfs installed, which will interact with windows and let you overcome currrent issue.

[max-nearmap]

ok tx @venth, please provide both cheers

[max-nearmap]

@venth this is my contact max[dot]guglielmi[at]nearmap[dot]com cheers

[abohne]

Any progress on this issue? I'm running into it here. aws-adfs (0.12.0) duo mfa

Our setup worked fine with aws-adfs until we enabled duo.

[venth]

Hi,

Sorry for the lack of response. I was pretty busy. Now, I started my vacations, so I count to have more time for aws-adfs.

Wiadomość napisana przez Andy Bohne [email protected] w dniu 27.07.2018, o godz. 18:13:

Any progress on this issue? I'm running into it here. aws-adfs (0.12.0) duo mfa

Our setup worked fine with aws-adfs until we enabled duo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[abohne]

@venth Any updates here?

[abohne]

@venth ?

[venth]

Sorry for the delay. During summer time I’ve checked few scenarios. Unfortunately none of them gave me a clue about the cause of your trouble. Perhaps we could meet over zoom or teamwork to nail the issue?

[abohne]

I'd be happy to do a zoom session with you.

[copperorange]

Hi,

I have the same issue. I can't see too much differences before the following apart from attribute sequences.

Trying to find the underlying reason but this is what I see in the debug trace which is basically a 401. I also noticed that the working cookie sent a header of MSISAuth1= where the fail sent MSISAuth=. This was interesting as I noticed that there was a previous ref to that higher up on the first response where I see DEBUG: Kerberos Authentication succeeded - error=0 authenticated=True for the windows path. I'll look into that a little.

Some Output for success and failure.

On a Mac the success looks like

Going for aws roles
2018-11-29 15:45:28,967 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [59863-MainProcess] [140735988052864-MainThread] - DEBUG: context: XXXX1
2018-11-29 15:45:28,968 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [59863-MainProcess] [140735988052864-MainThread] - DEBUG: sig_response: AUTH|XXXX2
2018-11-29 15:45:29,053 [connectionpool connectionpool.py:_make_request] [59863-MainProcess] [140735988052864-MainThread] - DEBUG: https://yourfs:443 "POST /adfs/ls/idpinitiatedsignon/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices&client-request-id=XXXX3 HTTP/1.1" 302 0
2018-11-29 15:45:29,237 [connectionpool connectionpool.py:_make_request] [59863-MainProcess] [140735988052864-MainThread] - DEBUG: https://yourfs:443 "GET /adfs/ls/idpinitiatedsignon/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices&client-request-id=XXXX3 HTTP/1.1" 200 6758
2018-11-29 15:45:29,239 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [59863-MainProcess] [140735988052864-MainThread] - DEBUG: Request:
            * url: https://yourfs:443/adfs/ls/idpinitiatedsignon/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices&client-request-id=d74f274a-f79e-436a-fe81-0080010000d8
            * headers: {'Accept-Language': 'en', 'Accept-Encoding': 'gzip, deflate', 'Accept': 'text/plain, */*; q=0.01', 'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko', 'Connection': 'keep-alive', 'Cookie': 'MSISSamlRequest=XXXX4; MSISAuth1=XXXX5'}
        Response:
            * status: 200
            * headers: {'Content-Length': '6758', 'Set-Cookie': 'MSISAuth=XXXX6; path=/adfs; HttpOnly; Secure, MSISAuth1=XXXX7; path=/adfs; HttpOnly; Secure, SamlSession=XXXX8; path=/adfs; HttpOnly; Secure, MSISSamlRequest=; expires=Wed, 28 Nov 2018 20:45:29 GMT; path=/adfs, MSISAuthenticated=XXXX9; path=/adfs; HttpOnly; Secure, MSISLoopDetectionCookie=XXX10; path=/adfs; HttpOnly; Secure', 'Expires': '-1', 'Server': 'Microsoft-HTTPAPI/2.0', 'Pragma': 'no-cache', 'Cache-Control': 'no-cache,no-store', 'Date': 'Thu, 29 Nov 2018 20:45:28 GMT', 'P3P': "ADFS doesn't have P3P policy, please contact your site's admin for more details", 'Content-Type': 'text/html; charset=utf-8'}
            * body: <html><head><title>Working...</title></head><body><form method="POST" name="hiddenform" action="https://signin.aws.amazon.com:443/saml"><input type="hidden" name="SAMLResponse" value="XXX11" /><noscript><p>Script is disabled. Click Submit to continue.</p><input type="submit" value="Submit" /></noscript></form><script language="javascript">window.setTimeout('document.forms[0].submit()', 0);</script></body></html>
        

On Windows the failure looks like

Going for aws roles
2018-11-29 16:09:30,460 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [9852-MainProcess] [8964-MainThread] - DEBUG: context: XXXX1
2018-11-29 16:09:30,461 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [9852-MainProcess] [8964-MainThread] - DEBUG: sig_response: AUTH|XXXX2
2018-11-29 16:09:30,473 [connectionpool connectionpool.py:_make_request] [9852-MainProcess] [8964-MainThread] - DEBUG: https://yourfs:443 "POST /adfs/ls/wia?loginToRp=urn:amazon:webservices&client-request-id=XXXX3 HTTP/1.1" 401 0
2018-11-29 16:09:30,476 [_duo_authenticator _duo_authenticator.py:_retrieve_roles_page] [9852-MainProcess] [8964-MainThread] - DEBUG: Request:
            * url: https://yourfs:443/adfs/ls/wia?loginToRp=urn:amazon:webservices&client-request-id=XXXX3
            * headers: {'Content-Length': '1861', 'Accept-Language': 'en', 'Accept-Encoding': 'gzip, deflate', 'Accept': 'text/plain, */*; q=0.01', 'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko', 'Connection': 'keep-alive', 'Cookie': 'MSISSamlRequest=XXXX4; MSISAuth=XXXX5', 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'}
        Response:
            * status: 401
            * headers: {'Date': 'Thu, 29 Nov 2018 21:09:29 GMT', 'Content-Length': '0', 'WWW-Authenticate': 'Negotiate, NTLM', 'Server': 'Microsoft-HTTPAPI/2.0'}
            * body:

Edit:

Almost as soon as I posted this I noticed the outstanding pull request. That is close to the approach I was trying to test. That PR led me to https://github.com/venth/aws-adfs/pull/97/commits/3a625263143d9034ad15ab2cadebd4c9c9005344

Which is effectively stopping the observation above from occurring.

The option --no-sspi stops the first auth from running and creating a valid MSISAuth which was conflicting with the Duo Flow. It is perhaps not the final answer but is has solved this issue for me. I will keep looking once I have more time.

This final command is

aws-adfs --verbose login --adfs-host yourfs/adfs/ls/idpinitiatedsignon --region us-east-1 --no-sspi

Note: is that PR now defunct?

Edit:

I spoke too soon. The second time round it failed. That is a puzzle. Again, the one time it did work MSISAuth1 was present.

It worked once so hopefully I can get a little closer. Any advice?

Edit: And now it works all the time when I traced the traffic through Charles Proxy using --no-sspi

Edit: How does adfs_cookies come into play here? I'll wait for an answer.

[clintonwanner]

I am running into this 401 issue after Duo MFA on Windows as well. Is there a workaround in Docker at this time?

[slyoldfox]

@mighteemouse we have put together a docker image for our employees that use windows.

docker run -it --rm -v %userprofile%/.aws:/root/.aws beforeach/adfs:1.12.2 login --adfs-host your.sts.host.name --profile yourprofile --region us-west-1  --session-duration 14400

Note that we don't provide support for this image in anyway way and use it at your own risk.

[FixItDad]

I was running into this issue on a Linux system. The ADFS server is looking at the user agent string being used and determining that the request is from a Windows system that supports NTLM (or some form of Windows authentication). Of course the script does not support this functionality.

I was able to work around the problem by modifying the script to use a different user agent header string ('Mozilla/5.0 (X11; Linux x86_64) Gecko/20100101 Firefox/60.0'). A more generic UA string would probably be better.

Changed _duo_authenticator.py, html_roles_fetcher.py, and account_aliases_fetcher.py. Search for 'WOW64'. Comments in html_roles_fetcher.py made me think that a Windows-ish UA string is needed for SSPI to work properly, so this probably needs some testing with and without SSPI.

Hopefully someone more familiar with ADFS can make a determination if this type of change could be developed into an actual fix.

[copperorange]

@FixItDad I figured I get back to this and I have to say I think that worked. On the Windows desktop, it was fine as is but on a Mac, I changed the header and I think it is far more consistent now. I will try and find time to dig in deeper.

[Dobatymo]

Encountering this issue as well after confirming 2FA with Duo. aws-adfs 1.24.5 Python 3.7.4 Windows 10

[hcsyash]

Getting same issue on both MacX and Windows :-

Response: * status: 401 Error: Issues during redirection to aws roles page. The error response <Response [401]>

Provider : ADFS 2FA : DUO aws-adfs : 1.24.5 Python : 3.9.0 OS : Windows 10 & Mac Catalina

Help anyone ? @venth @FixItDad @slyoldfox @copperorange

[pdecat]

The work-around is usually to also pass --no-sspi to aws-adfs login.

[trehman-sb]

I was having this issue in Python 3.8.7 on Windows 10. Passing --no-sspi resolved it for me.