Setting up Trimble ID SSO
The Three Steps (Plus One) to SSO Joy
IMPORTANT NOTE
This article is intended for our North American Vista ERP Cloud customers ONLY. Vista ERP Cloud customers located in Australia or New Zealand CANNOT use this method. Please see the following link if you are located in ANZ:
The Three Steps to ANZ SSO Joy - Setting up Viewpoint ID SSO
Author: Eric Vasbinder
Overview
As mentioned in a previous FAQ article, Single Sign On (SSO) provides a powerful way to simplify user credential management, improve security, and allow end users to realize the full value of Trimble Viewpoint's solutions. To that end, Trimble ID was created as the successor to Viewpoint ID and includes the ability for Single Sign On (SSO) authentication for Trimble solutions, in addition to the Viewpoint solutions supported by Viewpoint ID.
Going forward, most new customers transforming into the Trimble Construction One (TC1) or Viewpoint One (VP1) cloud offerings will be set up to use Trimble ID SSO.
CRITICAL WARNING FOR CUSTOMERS OF TRIMBLE PRODUCTS AND / OR VIEWPOINT LEGACY AD AUTHENTICATION (CASCADE / AVD)
PLEASE NOTE THAT MOVING TO TRIMBLE ID SSO, ESPECIALLY IF YOU ARE ALREADY USING TRIMBLE SOLUTIONS OR OUR LEGACY INTERNAL AD (E.G. CASCADE / AVD), IS A COMPLEX PROCESS WITH SEVERAL GOTCHAS THAT WILL BREAK EXISTING FUNCTIONALITY.
HOWEVER, SINCE TRIMBLE ID IS THE WAY OF THE FUTURE, THIS COMPLEX PROCESS FOR EXISTING TRIMBLE PRODUCT / LEGACY AUTHENTICATION CUSTOMERS MUST BE UNDERTAKEN AT SOME POINT.
In addition, futureproofing aside, after moving to Trimble ID SSO, there will be several advantages that you will encounter, including:
The ability to require MFA logins for users who do not use your corporate email to log in to Vista Web
A single set of credentials for authentication to ALL Trimble solutions, not just Vista and Vista Web, but Viewpoint Analytics, Automatic Invoicing, SketchUp, ProjectSight, and more
Fortunately, workarounds exist for most all items that will break when moving to Trimble ID SSO.
PLEASE READ THE FOLLOWING SECTIONS TO LEARN MORE DETAILS ABOUT THE FUNCTIONALITY THAT WILL BREAK WHEN MOVING TO TRIMBLE ID SSO AND HOW TO COMPENSATE - BEFORE PROCEEDING.
Trimble ID SSO High Level List of Warnings and Gotchas
The following is a high level list of the items that may break when moving to Trimble ID SSO. Please note that the following sections will list out the specifics of each potential gotcha and available workarounds.
- Third Party Products are NOT Supported (e.g. SSMS, Crystal Builder, Spreadsheet Server, etc.)
- Customers using Cascade / AVD legacy logins (Use of Viewpoint AVD or SMB Share Mounting for Imports) will need three sets of credentials
- When using Entra ID (Azure AD) federation, your UPNs and primary email addresses MUST MATCH
Trimble ID Issue and Conflict DETAILS
The following sections detail the specifics of when you may encounter each of the issues listed above, and how you might work around them on your journey to Trimble ID SSO
TRIMBLE ID ISSUE DETAILS: Third Party Products Not Supported
Prior to beginning the process of moving to Trimble ID SSO, you should thoroughly understand the nature of Trimble ID. Specifically, the way that it functions, it only supports Trimble solutions, such as SketchUp, ProjectSight, Accubid, Vista, Spectrum, Vista Web, Viewpoint Analytics, and Automated Invoicing, along with many others.
The unfortunate caveat is that Trimble ID does NOT support various third party solutions, many of which customers consider to be part of Vista itself or that integrate closely with other Trimble Viewpoint solutions.
This holds especially true for customers who are already in our cloud and who are using our legacy internal Active Directory (i.e. Cascade / AVD) to authenticate to Vista, SSMS, SSRS, Spreadsheet Server, etc.
The following is a list, although not completely exhaustive, of the third party products that do NOT support Trimble ID and will thus require workarounds when moving to use Trimble ID:
SSRS's Actual Web UI
Using SSRS reports in Vista itself will work as Vista uses methods that force SSRS to work with the logged in Trimble ID SSO User
Those methods cannot work inside of the actual SSRS Web UI
Crystal Reports Builder
SSRS Report Builder
Insight Software's Spreadsheet Server
Methods to Address Issue
Consider Replacement Tools
Use SQL Authentication Accounts
Consider Replacement Tools
Various solutions listed above have equivalent tools that do not require authenticating directly to the Vista database. As such they can leverage your normal authentication methods such as Entra ID / Azure AD or even a Trimble ID in some cases.
The following is a list of potential substitute solutions that should be considered:
SSRS's Web UI
Consider Instead Viewpoint Analytics Paginated Reports or PowerBI
Viewpoint Analytics has a Paginated Reports function that allows for both custom SSRS and custom Crystal reports to be hosted in a multitenant, web-based environment that leverages Trimble ID for authentication. Custom SSRS and Crystal Reports may be easily added into Viewpoints Analytics for any customer that is on a Trimble Construction One (TC1) contract. Please reach out to your Trimble support or customer success representative for more details.
SSRS Report Builder
Consider Replacing with PowerBI or Analytics Entirely
Rather than continuing to use SSRS reports, you should consider migrating to a more future proof reporting toolset. For example, Microsoft themselves has expressed that PowerBI is the way of their future, rather than SSRS reports
Viewpoint Analytics also contains a significant number of built in dashboards and capabilities that do not require the use of SSRS.
Insight Software Spreadsheet Server
Insight software has available other reporting solutions that do not require direct authentication to the Vista database
Please reach out to your Insight Software representative for more details
Other solutions that do not require direct authentication for each end-user to the Vista database, such as Viewpoint Analytics or other third-party products, such as PowerBI or Prophix can also be used
Method to Address Issue - SQL Accounts
In the near term, if you cannot move from solutions that are incompatible with Trimble ID, there is another workaround that should be implemented. To work around the fact that these third-party solutions do not support Trimble ID SSO, we need to set up a separate method of authentication for users who wish to use these tools. As customers should not continue to use the legacy method of Cascade, which uses our internal active directory within viewpoints cloud and should really only be reserved for AVD logins, another method identified allow for login into these third-party products.
The proper method to use for authentication to these third-party products in our cloud, after moving to use Trimble ID SSO, is to use SQL authentication accounts. The advantage to this method is that most legacy solutions, such as SSRS, that had been previously used with the Vista ERP, support this method of authentication.
Please note that there are a few disadvantages to using SQL accounts that must be accepted when using this method:
Resetting passwords for these accounts is more difficult, requiring either a customer support case or the use of the Vista client itself after logging in
MFA is not possible for these accounts, necessitating that these accounts should only be used for the bare minimum level of access as required by these tools. Please note that these tools are, for the most part, confined to reporting use cases. As such, the SQL accounts that are created for these third-party solutions should be restricted to read only access into the Vista database.
To create the SQL account as needed for third-party products, please use the instructions link that the following cloud FAQ article: I need a dedicated SQL account for my integration to Vista in your cloud. How do I set that up?
TRIMBLE ID ISSUE DETAILS: Customers Using Trimble Viewpoint's Azure Virtual Desktop (AVD) OR Who Mount the Vista Pickup Folder Using SMB Over IPSEC VPNs Will Need THREE Sets of Credentials
If a customers and users are making use of Viewpoint's Azure Virtual Desktop (AVD), or if they area using SMB to mount the Vista pickup folder over the IPSEC VPN, it is likely that those end-users will need to make use of three sets of credentials once they have been migrated to Trimble ID SSO. The reason for this is that the authentication into our AVD environment (Microsoft terminal services housed within our Active Directory infrastructure) cannot be done through either a customer's own Active Directory, or through Trimble ID.
The key thing to remember, especially for existing customers in our cloud, is that you may be using our Viewpoint internal Active Directory, managed by the Cascade portal, to authenticate to these resources. These usernames are in the format of VIEWPOINT\username.companyCode. These "legacy Viewpoint AD" usernames are used for customers who, for the most part, have two major use cases: a need to use Trimble Viewpoint's own AVD instance in the cloud AND/OR who use SMB to mount the Vista pickup folder over an ISPEC VPN.
The following are the three sets of credentials that will be needed and the reason for their need:
Trimble ID SSO: Authentication into Viewpoint products, such as Vista, Vista Web, Viewpoint Analytics, Viewpoint Team, SketchUp, and more
Pure SQL authentication: for third-party products that perform direct queries on the Vista database, such as SSRS's actual web UI, SSMS, Crystal Builder, Spreadsheet Server, and more
As mentioned above, migrating to replacement solutions for these tools may be advisable not only for future proofing but to enable a more straightforward process for authentication for your end-users.
Cascade Legacy Viewpoint AD:
In order to utilize our AVD in our cloud, where we host Vista, and other required products such as Adobe Acrobat reader
In order to mount the Vista pickup folder, needed ONLY for automated server to server file imports
The account used to authenticate with SMB over the IPSEC VPN MUST BE an internal Cascade-managed Viewpoint AD account
Methods to Address Issue
Migrate to VRL
By installing the Vista rich client on your local workstations and using the Vista Remote Link (VRL) method to connect to Vista in the cloud, there is no need to have access to our Trimble AVD instance. As such, there would be no need for your users to manage Cascade credentials.
Leverage AppXchange / DataXchange Rather Than Imports
As a more modern method of connecting to the Vista solution to push data into Vista, wherever possible, we recommend the use of our AppXchange and DataXchange solutions. AppXchange (formerly Ryvit) (Cloud and Data Connectors)
Begin Using Customer-Managed AVD
In the event that VRL is not possible for you, usually due to a desire for a thin client consumption model or due to concerns around network latency and performance, it is highly recommended that a customer managed AVD instance be set up in the same datacenter as where Vista is hosted. The significant benefit to this solution is twofold:
Higher Performance, similar to Viewpoint AVD
Performance could be much more acceptable to your end-users as the network latency between the Vista rich client and the Vista server will be kept small; they're both running in the same datacenter.
Users Leverage Existing AD Logins
The AVD instance that will be used by your end-users will be managed within the same Active Directory (Entra ID) infrastructure as your standard computing systems. This means that your end-users will be able to authenticate into the AVD portion without needing to use Viewpoint-specific Cascade logins, but rather would use their own, already familiar, Active Directory logins.
To read more details on the use of a customer managed AVD solution to host the Vista Rich client please see Option A in the following cloud FAQ article. Please note that even though it references consultants, the details in this option are applicable to a customer managed AVD environment as well: Cloud Access for Third Party Consultants
TRIMBLE ID ISSUE DETAILS: ENTRA ID / AZURE AD FEDERATION - UPNs and Primary Email Mismatches
Prior to beginning the Federation process to Entra ID (Azure AD), you should understand the impact of enabling federation to Entra ID. Specifically, the way Microsoft Entra ID handles authentication can cause issues with licensing with certain Trimble products if your users have User Principal Names (UPNs) that do not exactly match the primary email address specified for the user in Office Microsoft 365. If you are using, or plan to use Trimble products such as SketchUp, Connect, ProjectSight, Accubid, etc., please read on for more details and considerations.
Circumstances to Manifest Issue
If the following circumstances are in place, after federation of your Trimble ID instance to Entra ID, you will likely encounter login and licensing issues with various non-Viewpoint Trimble products:
Your organization is a user of any of the following Trimble products: SketchUp, Accubid, Trimble Estimating, ProjectSight, Trimble Connect. There may be others, but those have been identified at this point as being of concern.
Your end users have UPNs that correspond a domain that is different from the primary email address for your end users; in other words, your user UPNs and primary email addresses in Office 365 do not match.
This is most common in a subsidiary / parent company relationship, where your organization has subsidiaries that use email addresses whose domains differ from the main email address used by the parent company.
For example, ABC Plumbing is a subsidiary of ABC Conglomerate. The email domain for ABC Conglomerate is "abc-conglomerate.com". The email domain preferred by ABC Plumbing employees is "abc-plumbing.com".
Impact of Issue
Once you have federated Entra ID to Trimble ID, you will see the following impacts if you use the products listed above and if your end users have UPNs that do not match their primary email addresses in Office 365:
Licenses for Trimble products will not be able to be assigned correctly as they are most likely being assigned to a different company account in Trimble licensing as compared to what Entra ID sends back in the approval to login message.
Logins for Trimble products will fail. This is due to the approval that is sent back from Microsoft Entra ID / Azure AD: it contains approval for the UPN for that user, NOT for the email address used by the end user to sign in.
For example, user "John" at ABC Plumbing attempts to log in to SketchUp after Federation is complete. He attempts to log in with his ABC Plumbing email of "john@abc-plumbing.com". In the past, that would have been successful, as the user was likely logging into Trimble ID with a standalone, non-Federated Trimble ID account. However, now that federation is complete, instead of his "abc-plumbing.com" account receiving approval to login, instead, his UPN will now be approved, which is "john@abc-conglomerate.com". That user account does not match the email he submitted initially, so login will be denied.
Methods to Address Issue
There are several methods available to address this Entra ID conflict. However, they may involve changes in how your end users operate:
Option A - Block, Migrate, and Educate (PREFERRED)
In detail, this option attempts to balance the need to retain the UPN as the parent company for management purposes, with the need to continue using the subsidiary email domain for ongoing branding and operational purposes. It allows for the UPN to remain mis-matched from the primary email address, but requires a few, careful, steps including the training on the changing of user behavior.
High Level Steps to Implement:
Obtain a list of subsidiary domains (e.g. "dba domains").
Add a TXT record provided by the Trimble ID team to the main DNS for each domain you own, including the dba domains and your main UPN domain. This proves to our team your ownership of those domains.
Work with Trimble ID team to block the creation of new standalone accounts that use the dba domains.
This functionality is similar to how Trimble can block the creation of new accounts from domains that are replete with cyber threat actors.
Identify with the Trimble ID team all users who have already created standalone Trimble ID accounts using your dba domains.
Reach out to those users to tell them that their accounts will be migrated to use your main management domain to login ("UPN domain").
NOTE: This will NOT impact their use of the dba domain for email and branding - ONLY logging in to various solutions.
The Trimble ID team will then, at your scheduled time, migrate those previously created standalone users from using dba domains to using your UPN domain.
Once the account migration is complete, you will need to test user login with standalone Trimble ID, using your "UPN domain" for all users who have been migrated.
Once successful, you can proceed with Federation as detailed below, later in this FAQ.
PROs:
If successful, would require no change to operations, nor would licensing be impacted.
CONs:
Requires a change in end user behavior to log in using your UPN domain, instead of their previous dba domain
Requires careful following of a series of complex steps
Option B - Update UPNs to Match Primary Email Addresses
PROs:
This option is often more palatable, as it allows end users in subsidiaries to continue to use their subsidiary email domain for day to day operations; no change to end user processes
Potentially preserves Trimble product licenses that may be set up at the subsidiary level
CONs:
More work for IT Team
This can cause issues with internal Entra ID domain management scripts and processes that will need to be updated, so be aware of those impacts prior to making this change.
Complicates licensing tracking if done at parent company level
Option C - Update Primary Email Addresses to Match UPNs
PROs:
Easiest from the standpoint of IT as most scripts and automation should be minimally impacted by this move.
CONs:
Impact to branding of subsidiary and day to day operations of end users
Option D - Remain with Standalone Trimble IDs for all Trimble and Trimble Viewpoint Products
PROs:
No impact to current operations and current products
Much less complex for end users and customer IT
Allows for preserving UPNs as parent company while email domains remain as subsidiary, preserving branding
CONs:
Lack of true SSO due to additional Trimble credentials needed
Not tied to the organization's overall, preferred IdP
Continued mismatch of UPN to primary email could cause issues with other solutions, even third party solutions, which might wish to federate at some point in the future
Three Steps (Plus One) to Enable Trimble ID SSO
There are three major steps to properly enable your environment for Trimble ID SSO.
Step 1 (Optional): Request Trimble ID federation with preferred authentication provider
Step 2: Set up Portal Administrator in Trimble Construction One (TC1) (formerly Team Enterprise Admin)
Step 3: Push Existing Vista Users into Trimble ID
Step 4: Configure Individual Trimble ID Users
See below for detailed steps and responsibilities.
Step 1 (Optional): Set Up Trimble ID Federation with Preferred Authentication Provider
If you have a need to associate your Trimble ID domain with an external authentication provider, such as Azure AD, OKTA, etc., you will need to first prove that you own the domain name in question. This requirement is for our own legal and compliance purposes. Once that is complete, you will need to work with our team to finalize the Federation process.
Proving Domain Ownership
CUSTOMER: If you are the customer's IT and you are unfamiliar with where you can edit the authoritative DNS server records, please go to https://mxtoolbox.com/SuperTool.aspx and type in the following into the search box:
soa: DOMAINNAME
"DOMAINNAME" is your exact domain name that you would like to check on
In the results, you should see the main email address of your DNS admin, the main name server's name, and critically the name of the DNS provider.
For example, if you type in "soa: whitestarmusic.com", you'll see that the record label, "Whitestar Music" has their primary DNS servers at A2Hosting. As such, if you were Whitestar's IT admin, you'd go to the A2Hosting DNS admin portal and add the TXT record needed there.
Figure 1: Using MXToolbox to find the authoritative DNS server
3. CUSTOMER: Work with your DNS Administrator (usually your IT admin or domain registrar) to add the following text as a TXT record in your domain's DNS settings - Choose based on whether you are a customer transforming into the cloud, or an existing cloud customer who had the Federation Google form submitted to start the process:
Transformation key: dmlld3BvaW50X2F6dXJlX2NvbW1vbg==
Existing Cloud Customer Key (For when Federation Google Form is used): YXp1cmVfY29tbW9u
NOTE: If you are unfamiliar with DNS record editing, please reach out to your IT or network admin before proceeding.
4. CUSTOMER: ONLY IF YOU ARE AN EXISTING CUSTOMER IN THE CLOUD - Proceed to the following Google form and fill it out to notify the Trimble ID team that you are ready for federation to commence: https://docs.google.com/forms/d/e/1FAIpQLScoUBor2SdTEfYcoM0Sev6dKyusO1OB9LkDKx_MAK3z0XQKtQ/viewform?usp=sf_link
NOTE: If you are going to be federating to Azure AD, please choose the Azure AD option and OIDC as the connection protocol. The rest of the questions should be filled out with the help of your Azure AD (Entra ID) IT administrator.
REMINDER: For Transformation customers, the Google form is NOT required as the transformation team will handle TID Federations through the standard transformation process.
Finalizing the Federation Process
Once you have completed the above verification steps in DNS and filled out the form, our Trimble ID team can proceed with the following major steps:
TRIMBLE ID TEAM: We will validate your domain ownership via "Verify Domains" process step.
TRIMBLE ID TEAM: We will add the required domain names to the Team Enterprise for your company to the Azure AD federation section and mark them as "Federated to Trimble ID".
TRIMBLE ID TEAM: Add customer's IT admin (usually Azure AD admin) email address (usually Azure AD UPN) through a test email (i.e. "Add Emails").
TRIMBLE ID TEAM: Finish Federation by claiming the domain (i.e. "Claim Domain").
Step 2: Set up Portal Administrator(s) in TC1
Formerly known as a Viewpoint Team Enterprise Admin, the TC1 Portal administrator is a critical user who must be setup prior to being able to "promote" or migration users into Trimble ID.
Please note that a CRITICAL requirement of any TC Portal admin is that their email address must fit the following three requirements:
Their email address must be unique
Their email address in the portal must EXACTLY match the email address for their account in Vista
No trailing or leading spaces can be present in either the TC1 Portal email address or the email addressed stored in Vista
Please note that Trimble highly recommends setting up a minimum of TWO portal admin accounts, both for redundancy as well as to allow for a smoother initial pushing of users into Trimble ID.
To verify that you have appropriate access, please log in to your TC1 portal at https://team.viewpoint.com and look to see if you have user management rights. If you do, then you are a portal admin.
Detailed Steps
CUSTOMER: Identify who should be your admin user(s) in the Team Enterprise. Both names and email addresses are needed. NOTE: If you will be federating to Azure AD (Entra ID), then at least one of your Team Enterprise Admins must be your Azure AD admin. This admin MUST have an email box to recieve the initial invitation. This is required so your admin can consent on behalf of the organization in later steps.
CUSTOMER: Create support request asking for the users identified in step 1 to be added as Enterprise Admins for your Team Platform instance.
VIEWPOINT: Add users as Team enterprise admins, inform customer, close case.
Finalizing Azure AD (Entra ID) Federation to Trimble ID Through TC1
NOTE: To proceed with this step, you MUST be using a FULL Microsoft Azure AD admin account that is capable of receiving email messages.
Even though we have already set up Trimble ID to Azure AD federation by this point in the process, we still need to "link" the Vista, Vista Web, and Team platform environments to Azure AD.
If you are NOT setting up Azure AD federation in step 1, you will then proceed to set up a standalone Viewpoint ID account with a new password. However, if you are finishing the set up of Azure AD Federation, please proceed with this next few steps:
CUSTOMER: You will receive an email invite for your admin users added in the previous section. Please click on it. This will take you to https://team.viewpoint.com to log in.
CUSTOMER: Once you arrive there, please enter your Azure AD email address.
CUSTOMER: You will be sent to a Trimble ID page where you will need to enter your email address again. Please enter it.
CUSTOMER: You MAY then see a screen to enter First and Last Name, which are required and phone number, which is not required. Please enter this information and click next.
NOTE: If you do not see this screen, then great! Your account was already set up in Trimble ID in the previous section for Step 1 above. Please proceed with the rest of these steps.
CUSTOMER: After entering your email address for your Team Enterprise Admin (who is also an Azure AD admin) in the login screen, you MAY then be presented with EITHER a login screen for Azure AD, if you have yet to log in for the day, or a "Permissions Requested" screen if you have already logged in today to Azure AD.
The Permissions Requested will be from the voidentity-production Azure AD Enterprise application.
Permissions requested should be:
"Sign you in and read your profile"
"Maintain access to data you have given it access to"
CUSTOMER: Assuming that this account as which you are logged in is an Azure AD admin, you MUST click on the checkbox "Consent on behalf of your organization", which will prevent this screen from being showed to all of your end users at login time.
CUSTOMER: Click "Accept".
Figure 2: Consent on behalf of your organization and click "Accept".
Step 3: CUSTOMER - Push Existing Vista Users into Trimble ID
Once you have assigned a TC1 Portal account to be a portal admin, you will need to log in to Vista with that account to push existing Vista users into Trimble ID SSO. That's always the first thing, right? Logging in so that things can be done - I know, master of the obvious, here.
Well, in the Viewpoint Vista Cloud, logging into Vista for this step will be done using SSO itself. "How does that work?", you might ask.
First, you will need to ensure that you are able to log in to Trimble ID overall. The next section of this article will walk you through that process.
a. CUSTOMER - Validating Your Trimble ID is Working
If you are unsure whether your Trimble ID account has been set up, or if you have concerns that it may not be working, please use the following steps to validate if your Trimble ID account is up and running:
Open a web browser.
Go to our Trimble ID Profile page: https://myprofile.trimble.com
You will then be prompted to log in.
If you are able to log in, you will see the Trimble ID Profile page.
If you see this page, then your Trimble ID account is set up properly.
If you are not able to log in, then please reach out to your Trimble Viewpoint support contact to verify if your Trimble ID account has been properly set up.
CRITICAL NOTE - SSO MIGRATION PORTAL FOR HUMAN END USERS ONLY - NOT SERVICE ACCOUNTS
The portal mentioned in the following section should only be used for migrating Vista human end user into SSO. It should never be used to migrate service accounts, such as Keystyle.svc, Ryvit, etc. Migrating Service accounts into SSO will break their functionality.
b. CUSTOMER - Promoting Users to Trimble ID
Once you have set up a TC1 portal admin account using the same email address as a Vista admin, you can then begin the process of promoting Vista users into Trimble ID SSO.
NOTE: Prior to beginning this process, please ensure your HQMA table is purged down to a reasonable size of no more than 1M records. Extremely large HQMA tables can extend the SSO migration process by days and dramatically impact system responsiveness. Please see this FAQ on Vista performance for more details: Optimizing Vista Cloud Performance
This method involves going to a specific website, clicking on the users that you would like to migrate to Trimble ID SSO, and then clicking the "migrate users" button.
CUSTOMER: Open your web browser of choice.
CUSTOMER: Open a web browser page to the following URL: https://CODE-sso.viewpointforcloud.com/vista/1
CRITICAL: YOU MUST HAVE VISTA FORM AND MENU ADMINISTRATOR ACCESS IN VISTA IN ORDER TO LOAD THIS PAGE.
CRITICAL: YOU MUST ALSO HAVE ENTERPRISE ADMIN RIGHTS IN THE VIEWPOINT TEAM PLATFORM TO LOAD THIS PAGE AND PROMOTE USERS TO SSO.
Replace "CODE" with your 3 to 4 character alphanumeric cloud code. This code is a unique identifier for each customer in our ERP cloud and can be obtained from your cloud support or transformations team.
IMPORTANT: The URL above is CASE-SENSITIVE. For example, it will fail if you try to use a capital "V" for "vista" https://CODE-sso.viewpointforcloud.com/Vista/1
CUSTOMER: On the resulting web page, click the users that you would like to migrate to Trimble ID SSO
Figure 3: Screen to Select Users to Migrate
4. CUSTOMER: Click on the checkbox for the user(s) you wish to migrate, or push, into Trimble ID.
5. CUSTOMER: Then click Migrate users.
The users will then receive invitations into Trimble ID and can create their new Trimble ID accounts. See step 4 below for more details.
NOTE: It is required for your end user to click on those emails from Viewpoint / Trimble ID and complete their account setup prior to any transformation go-live.
CRITICAL NOTE
DO NOT PERFORM USER MIGRATIONS TO SSO ONE USER AT A TIME.
If you do so, each SQL job to rename the user's name and audit trail entries will block the other SQL jobs, causing significant system slowness and potential many hours of downtime.
BEST PRACTICE FOR SELECTING USERS
Prior to leaving for the day, select your users to migrate, so that this process performs OVERNIGHT.
Choose 15-25 users. Then Click Migrate Users once all 15-25 are selected.
Continue performing the user migration nightly until all users have been promoted to SSO.
Step 4: CUSTOMER - End Users Finalize Trimble ID SSO Set up
The next step of the move to Trimble ID SSO authentication is for each end user to set up their own Trimble ID. If you have already set up Trimble ID SSO Federation to an external authentication system, this process will be as simple as receiving an email message, following the steps in the email message, clicking "next" a few times and then you will be done.
If you have not set up a federated authentication provider, the end user will need to set up their password for their Trimble ID account, ensure that the correct email address that corresponds to the address in Vista is set up in Trimble ID, and enable any multifactor authentication that your security processes and policies require.
Please see the following article for detailed, step by step guidance on setting up your Trimble ID account, once you have received your email invite:
Subsequent Logins - Trimble ID SSO
Admin logins to Vista that occur after the Vista admin account has been pushed into Trimble ID take place through the normal Trimble ID Vista login process. Please see this article for more details: Logging In - Via Trimble ID SSO
changelog
Friday, 21 June 2024 at 11:14AM:
Massive updates to incorporate latest learned best practices around issues that can arise when moving to TID SSO and how to accommodate and workaround them
Friday, 14 June 2024 at 10:06AM:
Added preferred tag to the warning around UPNs needing to match primary email addresses; added information around using UPNs experimental option
Friday, 31 May 2024 at 09:49AM:
Added critical warning about what happens when federation is set up when UPN mismatches primary email in Azure AD.
Thursday, 04 April 2024 at 12:15PM:
Updated and restructured organization of page to make steps clearer and point out responsibilities for each task.
Friday, 22 March 2024 at 11:17AM:
Added note that the migration portal is NOT for service accounts, but only for human end users.
Wednesday, 06 March 2024 at 10:18AM:
Added screenshot and information about consenting on behalf of the organization, which is required for Azure AD federation to Trimble ID SSO.
Tuesday, 28 November 2023 at 06:17PM:
Added link to Australia / New Zealand SSO Setup page
Monday, 13 November 2023 at 03:29PM:
Corrected rapid typing typo error.
Thursday, 02 November 2023 at 01:51PM:
Added required DNS TXT record key for customers using Federation who are ALREADY in the cloud, using the Google Form for Federation kickoff.
Wednesday, 01 November 2023 at 08:11AM:
updated to highlight in bold the need to not migrate large numbers of users one at a time.
Wednesday, 25 October 2023 at 10:30AM:
Added notes about permissions needed.
Thursday, 12 October 2023 at 04:16PM:
Additional clarification around finalizing federation.
Wednesday, 04 October 2023 at 03:13PM:
Added key and process for TID to Azure AD / Okta Federation.
Tuesday, 26 September 2023 at 08:37PM:
Noticed that the URL for SSO migrations for Vista users is case-sensitive.
Thursday, 25 May 2023 at 03:26PM:
Significantly revised to include instructions on how to set up Trimble ID Federation, and steps to set up the initial promotion of users from Vista into Trimble ID SSO.
Wednesday, 13 July 2022 at 04:38PM
Updated error in URL formatting for migration URL.
tags:
consent, Azure AD, Federation, SSO Setup, North America