Logon loop with Microsoft authentication starting from version Version 2022.3.26.0
Hi Devolutions Team
Starting with version 2022.3.26.0 we are facing a logon loop when using Microsoft authentication.
This does not happen with version 2022.3.24.0 and older, but still in version 2022.3.27.0.
What happens when starting RDM is, the browser is opening up, I click on the "Microsoft" button, it authenticates and the same browser windows opens again and again.
Could you please have a look at this issue?
Our Devolutions server is up to date with version 2022.3.7.0.
Best regards
René
Hello René,
We did not receive any looping reports with RDM 2022.3.26+ with a Devolutions Server data source. Is this occurring for all your users?
Could you also try to clear the local storage from your default browser to see if it helps? https://kb.devolutions.net/kb_how_clear_browsers_local_storage.html
Best regards,
Richard Boisvert
Hi Richard
Yes, it's hapening to all users, I've tested with it. Luckily I have not yet rolled out the new version to all users.
I have even added a new Microsoft 365 account on the Devolutions Server and logged into a computer with that account, where this user have never logged on before.
Same behaviour. The browser pops up again and again, asking to authenticate.
Best regards
René
Hello René,
As a test, would it be possible for you to create a portable installation of the latest version of RDM and see if this issue still occurs? To do so, you will need to do the following:
1- Download the .zip file below:
https://remotedesktopmanager.com/home/thankyou/rdmbin
2- Create a new folder on your Desktop
3- Extract the content of the .zip file into the folder created at #2
4- Go to this folder once the .zip file has been extracted and run remotedesktopmanager.exe
5- Connect to your data source
This test will allow us to rule out your local installation of RDM as a possible cause for this issue.
If the above does not work, I would suggest writing to service@devolutions.net so we can book a session to have a look at the issue.
Best regards,
Richard Boisvert
That's exactly what I do to test new versions on my device. I have installed the msi version for daily use and the bin version for testing.
It's happening with the bin version as well on another computer with a msi version installed.
I will send an email on Monday, so we can have a remote session to analyze.
Thanks in advance for your help.
Hi,
We are facing the same problem, in our case the problem came from the data source settings, in the old versions it was not mandatory to fill in a user, on the new version it became mandatory.
No matter what information is filled in, it cannot be changed once on the login page
And the problem is that the username variable (%username%) does not return the UPN on an Azure AD joined machine so it can't be used.
As it is, we cannot deploy the new version unless we ask each user to modify the data source manually, which is not an option....
Best regards,
download.png
Hello,
There is a UPN variable that you can use for the username in your data source:
$USER_PRINCIPAL_NAME$
If it does not work in your environment, but the %username% does return the correct information, you can always add "@domain.xyz", for example:
%username%@acme.loc
Hopefully this will let you help you with your issue!
Best regards,
Richard Boisvert
It doesn't seem to work with the $USER_PRINCIPAL_NAME$ variable:
As for variable concatenation, this does not work in our case since the %username% variable refers to the profile path name and not the exact UPN prefix:
%username% = FirstnameLastname (no dot between the first name and the last name)
UPN (Whoami /UPN) = Firstname.Lastname@domain.abc
Thanks,
Hello,
Unfortunately, in your case, your users will need to enter their UPN under File > Data Sources the first time they use RDM. There are no system variables for the first name or last name, only %username%. This only needs to be done once, and will persist with upgrades of RDM.
Best regards,
Richard Boisvert
Hi Richard,
The problem is that we are working on a VDI environment, so this option mean that the users will need to enter their UPN in every host. And for the upgrade we are using a rdi file, maybe the configuration will be overwritten?
Anyway, I have a ticket open, I will ask if it's possible to return the result of "whoami /upn" command on the data source settings or as before the upgrade have the choice to not fill this parameter.
Thank you for your time
Hello Mehdi,
Is it possible your VDI machines are Azure joined? If so, there appears to be an issue with the 2022.3.26+ version of RDM, it does not recogniez the $USER_PRINCIPAL_NAME$ variable.
If this is the case, could you try with the 2022.3.24 version and see if it returns the correct value? https://cdn.devolutions.net/download/Setup.RemoteDesktopManager.2022.3.24.0.exe
Best regards,
Richard Boisvert
Hi Richard
Any news regarding the Azure AD only authentication issue?
Best regards
René
Hello René,
In your case, are you able to use either $USER_PRINCIPAL_NAME$ or %username%@yourdomain.com? The username field must be filled out with a value in File > Data Sources > Devolutions Server connection, or you will not be able to authenticate.
I just tested it on my end, and with %username%@yourdomain.com, it is working properly with RDM 2022.3.30 and Devolutions Server 2022.3.8.
Best regards,
Richard Boisvert
Unfortunately, we cannot use both. $USER_PRINCIPAL_NAME$ gives us the authentication loop and %username%@ourdomain.com reports back the sAMAccount Name in our case, not the UPN. Although the device is Azure AD only.
Using the full e-mail address, it's working, but that's not a solution to deploy the new version to all our users.
Hello,
I will verify with the engineering team if anything else could be provided, but, for now, the users would need to enter their email address in the username field.
Best regards,
Richard Boisvert
Yes, please. Thank you in advance.
There must have been a change in code, since the older versions are still correctly working with $USER_PRINCIPAL_NAME$
Hello,
The RDM team is investigating a DLL that may be the culprit, we will keep you posted.
Best regards,
Richard Boisvert
Great news, thank you for the update.
Any news on this issue? The newest build .32 still has this issue
Hello,
The source of the issue has not yet been identified, unfortunately. For now, the 2022.3.24 release is the last version that did not have an issue with the UPN variable in the username.
In a related note, the team will allow an empty username in an upcoming release for a Devolutions Server data source. This will allow the end user to enter their username in a prompt and it will populate the username that way.
Best regards,
Richard Boisvert