Creating new QUICKSIGHT user (author) with API returns InviteUrl that does not DNS resolve

Question & Answer
,
1

Calling register-user with QUICKSIGHT identity and role AUTHOR returns the below InviteUrl. I masked the token and client_id here. Not able to complete the user set up because d-9067d37955.awsapps.com does not DNS resolve and browser returns the below error

Check if there is a typo in d-9067d37955.awsapps.com.
DNS_PROBE_FINISHED_NXDOMAIN

InviteUrl:
https://d-9067d37955.awsapps.com/auth/?#invite:token=<>&redirect_uri=https://us-east-1.quicksight.aws.amazon.com/sn/start&client_id=<>

Any suggestions on how to proceed ?

2

Tried creating a new namespace and creating QUICKSIGHT user in that namespace. I get a different InviteUrl domain d-9067d37b2d.awsapps.com but same behaviour. DNS does not resolve. I can use some help.

3

Hi @metrics

Thanks for posting your question!

Please refer the below post this might be helpful for you to resolve the DNS_PROBE_FINISHED_NXDOMAIN error.

1 Like
4

Thanks for the link.

When calling register-user with QUICKSIGHT identity and a namespace, for the InviteUrl returned to work, my understanding is DNS resolver needs to work in the computer where the user Clicks on InviteUrl.

To narrow the issue, from home computer (windows) using nslookup.exe with Google DNS resolver returns Non-existent domain for the domain part of the InviteUrl
nslookup.exe d-9067d364e3.awsapps.com 8.8.8.8

Also tried Cloud flare DNS resolver 1.1.1.1 with same result

Using DNS Checker it appears it does not resolve in any locale

Still not sure what I am missing. InviteUrl links used to work fine and now get a DNS error

5

UserInviteUrl returned from register-user CLI call works fine (DNS resolves ok) with default namespace.

Appears the DNS resolve issue is specific to non-default namespace and the issue can be recreated from any client machine.

I have raised a support ticket for this to be looked into.

6

@metrics ,

I understand you are trying to create user in a non-default namespace. The only way to access this namespace for the user is through federation .

Supporting multitenancy with isolated namespaces - Amazon QuickSight [ read through limitations ]

here for example Workshop Studio

Federated users, IAM users and QuickSight managed users can all be created in secondary namespaces. However, only Federated and IAM users in secondary namespace will be able to access QuickSight console directly. You can user QuickSight managed users with secondary namespaces if your use case requires only embedded access. Both dashboard and session/author embedding is possible with QuickSight managed users in secondary namespaces.

Kind regards,
Koushik

1 Like
7

I encountered the same issue. Upon check with AWS support, as what @Koushik_Muthanna highlighted, unfortunately, this approach is no longer supported. Would be good to give a heads-up for such change.

This change was introduced only a few months ago. Old users are still able to login using the credentials created using this approach before. A workaround I found was to create the user under the default namespace via the UI. Afterwards, apply the necessary permission and RLS to the user to control the access. With this, user will still be able to login directly via Quicksight URL.

2 Likes
8

Thanks Koushik.

Value for embedded dashboards is so that application has the autonomy to decide application functionality. Tightly coupling dashboarding solution with authentication methods like requiring Federated single sign comes across as pushing application towards fewer options like Okta, Ping that AWS decides for the application rather than leaving that for the application to decide what is best.

9

Thanks for sharing your experience and suggestions.

10

@metrics
In an embedding scenario, you can use QuickSight identity type for a non-default namespace. In that scenario, the users are accessing the dashboard within your application.

For the user which you created in your non-default namespace , go ahead and test the generate-embed-url-for-registered-user — AWS CLI 1.34.15 Command Reference . The embed url will show you the dashboard. Here you can handle user authentication and authorization of your application without having to use Okta , Ping etc.

Kind regards,
Koushik

1 Like