Overview
If a user is experiencing an authentication loop when trying to access the CloudRadial portal - where the login page keeps redirecting back to itself without completing sign-in - the issue may be caused by the system clock on the user's device being out of sync.
Authentication tokens used during the login process are time-sensitive. If the device clock is significantly off from the actual time, the tokens may be rejected, causing the login to loop repeatedly.
Symptoms
- The user clicks the login link or enters the portal URL in their browser
- The login page loads but redirects back to itself in a loop
- The issue may affect only specific users or specific devices
- Clearing the browser cache alone does not resolve the issue
- Other users on different devices can log in without problems
Resolution
To resolve this issue, have the affected user perform the following steps on their device:
-
Sync the system clock: Open a Command Prompt (Run as Administrator) and run:
w32tm /resync. Alternatively, the user can manually sync the time by going to Settings > Time & Language > Date & Time and clicking "Sync now." You can also run a manual time sync to time.windows.com. - Clear the browser cache: After syncing the clock, clear the browser cache and cookies for the CloudRadial portal domain.
- Retry login: Close and reopen the browser, then attempt to access the portal again.
Additional Troubleshooting
If the time sync does not resolve the issue, consider the following:
- Check if the issue is specific to one browser - try a different browser to rule out browser-specific problems
- Verify that any conditional access policies in the client's Microsoft 365 tenant are not blocking the CloudRadial app
- Confirm that the user account is properly synced in CloudRadial under Partner > Clients
- Re-authorize the Microsoft 365 connection under Partner > Settings > Integrations > Microsoft 365 if the issue persists across multiple users in the same tenant
Cross-Partner Email Conflict
If a user's email address is active on more than one CloudRadial partner portal (for example, the user works for one partner but is also added as a user in a different partner's portal to assist with their tenant), the login flow can route back to the user's primary portal instead of the intended tenant. The login link in the email can also silently fail because the request resolves to the wrong tenant.
Things to try in this scenario:
- Have the user open the destination portal URL in a private/incognito window so existing session cookies do not redirect them to their primary portal.
- Confirm the user's email is added as an active user on the destination portal under Partner > Clients > [client] > Users.
- If the user is already active on another partner's CloudRadial tenant, the partner administrators may need to coordinate access via a different email alias for the secondary portal.
- Use the "Send Email Login Link" option from the destination portal directly, then open the link in a new private window to ensure the URL resolves to the correct tenant.
Related Articles
Duplicate Inactive PSA Contact
If a single user can sign in on the web but is stuck in a login loop in the Desktop app (or on a specific portal), and the clock-skew and cross-partner steps above have already been ruled out, the next thing to check is whether that user has a duplicate, inactive Contact in your PSA.
The portal matches each sign-in to a single PSA Contact. When two Contact records exist for the same user, and at least one of them is marked inactive, the match can resolve to the inactive record and prevent the sign-in from completing.
To check and resolve:
- Open your PSA and search for the affected user by email address.
- If you find more than one Contact for that email, identify the active one.
- Merge or delete the duplicate inactive Contact in the PSA.
- Trigger a sync from CloudRadial (Partner > Clients > client > Sync) so the cleaned-up Contact list flows back into CloudRadial.
- Have the user close the Desktop app fully and sign in again.
This pattern most commonly shows up after a contact has been re-created in the PSA, after a name change, or after a user was offboarded and later rehired.
Comments
0 comments
Article is closed for comments.