Hello, some of my users are reporting this issue when trying to log in via SSO on the desktop app and inside Revit. They can log in via SSO normally via the web app, and can also log in via email normally.
I told them to go trough the “Forgot your password?” process, then trying login in again via SSO, but they are still having the same issue. They are using version 2.3.0.1
Hmm this is only for some users and not others ?
Anything specific about their setup ? Do they have anything différent from the working sessions ?
So far the ones that reported this are both from outside of our organization contractually. From what is visible to me I don’t see any difference on their users when it comes to the AAD setup.
I am asking additional externals to check if they also have this problem to try and find out if this isolated or if all externals are having the same problem.
So far 4 users have faced this problem:
I asked my IT and they said from an AAD perspective there is no difference between internal and external users. IT suggested to have these try and login on different computers to test. I sent them this request and will check the results later.
thanks so much! this is helpful, and looking forward to hearing about the results of testing on a different machine.
We’ll keep looking on our end too.
Hi @FilipeFinco , we’ve added some extra logs to the SSO login process. Could one of the users experiencing the issue try again? This won’t fix it, but it will tell us more about the issue.
Please let me know when they do try again so we can take another look at the logs!
Yes I will ask them to try again today.
Also some additional information:
Another external user who was previously able to login with SSO normally reported that when trying to log in into a virtual machine they got the same error. The internal colleague who I reported having the issue earlier also had this issue on a virtual machine.
However the external colleagues who were never able to log in via SSO were on their local machines.
I was also looking into the Seats tab in the management console, and I noticed the “live sessions” option always shows users logged in as “Signed with a password”, even when login in via SSO. Maybe here it could distinguish if the user has signed in via SSO or with email+password?
Thanks for the help!
Thanks for this update ! interesting information indeed.
Looking forward to looking into the more detailed logs when users try again.
PS : sso login info on “seats” is resolved and will be reporting more accurately on new logins thank you for reporting.
This Seats information is very useful, thanks!
Btw, most of the users who are having issues have since already given SSO another attempt.
Good news! we found the cause on our end. We pulled the server logs for the failing attempts : when our server tries to read the user profile with the sign in token, Microsoft answers with “Insufficient privileges to complete the operation”. So the error message shown in the app is misleading (we will fix that text), the real issue is a missing permission, not an expired session.
What it means concretely : the Orkestra app in your Azure tenant needs the delegated permission “User.Read” (this is just “sign in and read the user’s own profile”). Azure records this consent per user unless an admin consents for the whole tenant. Your 4 affected users are missing that consent record, the others have it. This is why your IT sees no difference between the users when comparing them in AAD, the difference is not on the user objects but in the consent records of the app itself.
The fix is simple and on the tenant side : ask your IT to grant tenant wide admin consent for the delegated permission User.Read on the Orkestra app registration (Entra ID > Enterprise applications > Orkestra > Permissions > Grant admin consent). That fixes all 4 users immediately, no reinstall and no new version needed, and it prevents this from happening to anyone else.
On our side we are also preparing improvements so this cannot loop like this again : the app will request User.Read explicitly and will fall back to a full sign in when the silent one produces a bad token.
Thanks @m.elayoubi for the detailed explanation. I will forward this instructions to my IT update you about the result.
@m.elayoubi My IT come back saying they do not believe this is the issue, because they had already given the mentioned permissions.
I do not think the below explain the issue because on my end I have granted the below permission for the entire organization so it should not having issue if the user is request to have permission on user.read.
do the users with the ussie have a different domain in their email than yours? (you said they were external)
No, they have the same domain as our internal colleagues which they use for teams for example. However I think they have a different email which they use for Autodesk services, I don’t know if that has some influence, as it affects both plugin in Revit and also the desktop app. In Orkestra they are all registered with our common domain.
Update: Today my users have been able to log in to Orkestra in the desktop app and in Revit using SSO without any problems. Everyone who had issues before are now good.
