You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update docs and examples to properly show required fields for adding new users #993
We need to review and update the docs around adding new users to clarify the required fields. In particular the examples as shown do not work because the name parameter really needs to be an email address rather than the user's actual name.
We can look at and crib some notes from the explanation of user-name in the REST API docs for Add User to Site.
In my experience, it needs to align with whatever the server identity store is configured to use. In the case at my company since we use active directory configuration, it needs to be their SAM Account Name and fully qualified domain name. I have found that either of the following formats works:
SAM@FQDN
FQDN\SAM
Email address does not work for me, but that may be a quirk of how our active directory is configured.
It looks like some of this is AD conventions that aren't always followed. "By convention", the SAM Account Name and UPN prefix are the same, and "by convention" the full UPN is an email address, not just bcantoni@salesforce.
@jorwoods Is your SAM Account Name the same as the user UPN prefix? It should be using UPN prefix when you include an @ symbol, apparently.
By default, if you are adding a user from Active Directory, the name that you provide in the user-name is matched against the Active Directory sAMAccountName attribute, which becomes the name that the user signs in to Tableau Server with.
Two exceptions are when the name that you provide: is longer than 20 characters; and includes an @ character. In these cases, Tableau imports the user using the Active Directory UPN. https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_ref.htm#add_user_to_site
In my case, no. The UPN and SAM are different. My SAM would be something like jorwoods but my UPN is Jordan.Woods@domain.com In my case, I also discovered that we have our AD configured with subdomains, so if a user is from a different country, we have to find what the subdomain is for that country, and add that as part of our lookup.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. If this is still relevant, please comment to keep it open.
Activity
jorwoods commentedon Feb 17, 2022
In my experience, it needs to align with whatever the server identity store is configured to use. In the case at my company since we use active directory configuration, it needs to be their SAM Account Name and fully qualified domain name. I have found that either of the following formats works:
SAM@FQDN
FQDN\SAM
Email address does not work for me, but that may be a quirk of how our active directory is configured.
jacalata commentedon May 15, 2022
It looks like some of this is AD conventions that aren't always followed. "By convention", the SAM Account Name and UPN prefix are the same, and "by convention" the full UPN is an email address, not just bcantoni@salesforce.
@jorwoods Is your SAM Account Name the same as the user UPN prefix? It should be using UPN prefix when you include an @ symbol, apparently.
jorwoods commentedon May 15, 2022
In my case, no. The UPN and SAM are different. My SAM would be something like
jorwoodsbut my UPN isJordan.Woods@domain.comIn my case, I also discovered that we have our AD configured with subdomains, so if a user is from a different country, we have to find what the subdomain is for that country, and add that as part of our lookup.jorwoods commentedon May 15, 2022
I have noticed that
FQDN\UPNseems to also work in our environment, as well as just the UPN or SAM if they are in the top level domain.github-actions commentedon Aug 6, 2026
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. If this is still relevant, please comment to keep it open.