Closed alec-eu closed 2 years ago
I'd start by clearing the cache and site data for *.awsapps.com
(your start URL's domain) and device.sso.*.amazonaws.com
(with your SSO region), and OneLogin's domains. Does this happen only with aws-sso-util login
or does it also happen with the AWS CLI's aws sso login
?
Ah. We had a custom SSO URL prior to the migration but it looks like it reverted back to a generated URL. Using that seems to have fixed the problem. Thank you for pointing out an obvious overlook 👍
Oh, this is something I haven't tried. If your start URL is https://example.awsapps.com/start, can you create https://aws.example.com that redirects to https://example.awsapps.com/start, and use https://aws.example.com in your AWS SSO configuration?
Or are you saying you had https://example.awsapps.com/start, and it reverted to https://d-123abc.awsapps.com/start?
So I had https://example.awsapps.com/start. When I switched the provider, it seemed to have permantley mapped the old IdP to that URL, as I cannot update the new https://d-123abc.awsapps.com/start to https://example.awsapps.com/start. However I was able to add an alias and changed it to https://example-onelogin.awsapps.com/start.
Notably, that doesn't seem to reflect in aws-sso-util. I had to provide the new generated URL for it to work.
Trying to CNAME redirect now. Interesting idea, will let you know how it goes.
Note that if it's a CNAME, you'd have to use https://aws.example.com/start
. If you use an HTTP redirect, it could in theory be just https://aws.example.com
. I'm not sure if either is likely to work.
I would open a support case; the custom start URL is tied to the identity store directory, not the SSO instance, but you should be able to reclaim that custom domain for your new directory.
@alec-eu did the CNAME redirect work?
Hello, I have been using AWS Managed AD for SSO's IdP, but recently migrated to using OneLogin. Since the change, I am greeted with an error whenever trying to initiate a login via my shell:
Has anyone seen such behavior before? I would not expect the underlying IdP to break this command.