Skip the Choose your authentication method page.

Hello,

At the moment, when enabled, only the Domain or Devolutions Server user authentication methods can be set as the Primary authentication method.

I will ask our engineering if they can do something about it or why it's not possible with Microsoft authentication and I will get back to you.

Thank you for your patience.

Best regards,

Hello,

Currently, when Microsoft Authentication (Azure AD) is set as the primary authentication method, there is no built-in mechanism to seamlessly switch back to alternative authentication methods without manual intervention. This is because, when it is configured as the primary authentication method, it takes precedence over other available authentication methods, and DVLS relies solely on Azure AD for user authentication. As a result, other authentication methods become inaccessible by default.

To switch back to a different authentication method, the DVLS administrators would need to modify the configuration settings and change the Primary authentication parameter to the desired method or disable it.

In fact, there is currently no elegant way to handle switching between Azure AD authentication and other methods when Azure AD is set as the primary authentication method.

If our engineering team finds a way to allow this configuration, we will let you know.

Thank you for understanding.

Best regards,

Hello,

For your information, I moved that thread in "Feature Request" section, I have created a ticket on our side and we will see what could be done to improve that. As my colleague said, if we find a way to allow this configuration, we will let you know.

Best regards,

When doing our configuration, I noticed the the "devolution login" is alway there and thus for "seamless usage with our users, having only one choice, or simply login with the default IDP automatically would be great.

For some deployments the bulk of users will just be using a single standard logon method (i.e. AzureAD) and having to click the Microsoft button everytime they need to authenticate is a waste of peoples time. Would it be possible to just have a seperate URL for emergency or alternate login methods if/when they are actually needed, and the respective users could bookmark it?

Hello,

Thank you for your input. We understand that it can be a waste of time to have to click on the AzureAD button. We will try to find a good solution for that problem. We will let you know as soon as we have something for that.

Best regards,

I would like to revive this topic as I think it's important to improve here.

This change is an opportunity to greatly improve the user experience. Users don't have patience and are even annoyed by unneccessary manual interactions. 99,9% of our logins are Entra ID based, therefore we don't need the selection page in everyday use cases. Please provide a method to skip this soon.

If you want to preserve a fallback, you may provide two different entry points. One URL to automatically redirect directly to Entra ID, and another one as fallback for local login to devolutions server.

Hi all,

When I initially created the ticket to create that feature (in 2020 I believe...), I had described such a capability. I even wanted to have a specific URL for each IdP, but sadly I was told it was impossible as Erica answered above.

We are not ignoring you request, it's just that we havent found a way yet. That being said, keep the votes coming! It helps us to focus on the bigger pain points.

Hi Maurice,

"if IDP quantity = 1, then try autologin"

"if autologin fails, present "devolution login"

I don't think it needs to be "over engineered" beyond that.

Hi Maurice,

Another idea would be have a configurable countdown timer for a prefered authentication method. This way users could be shown the initial screen to choose an authentication method, but if they dont manually click something within a few seconds it automatically continues with the prefered method.

The absense being able to save users having to manually click an option every time they login does have a rather significant impact on user experience, as the login screen can show up frequently in various usage scenarios, for example due to temporary network interuptions, and/or tightly controlled session timeouts which may be nessary to accomodate sufficient security to PAM and/or lateral movement to resources stored in RDM.

Thanks

Joe

"The absense being able to save users having to manually click an option every time they login does have a rather significant impact on user experience"

I would actually rephrase this and say "it has a rather significant impact on user ADOPTION".

Even the best security practices are worth nothing if there is no user adoption.

Being at the doors of 2024, I have a really hard time understanding why such a "simple" thing is not already in place.

When I initially created the ticket to create that feature (in 2020 I believe...),

tbh, I am shocked this topic didn't make any progress for more than 3 years. As others have already mentioned: A smooth login experience is key for user adoption.

What can be done do raise more internal awareness?

Renewed activity on this thread made it happen, a pragmatic solution is being put in place at this moment.

Thanks to all!

Great !

What kind of ETA should we expect ?

Hello,

We are analyzing different solutions. Our plan would be to include an improvement in a minor version of 2023.3. We will post back here once we have something.

Best regards,

Hi Folks,

Just saw the backlog tag on this topic, and after this features seems not to appear in 2023.3.24.0 I'm afraid that this task has being postponed at least to the next backlog grooming, in worst case for several month. Any plans for getting this one done in the next release?

Really hoping and waiting for a solution in this case.

Several month would be unacceptable.

This has been pushed back for several months since 2020.

Hello,

We are working on a solution. I can't tell you exactly when it will be integrated in a release version, but you could expect a fix in a few weeks. We will post here once we have a version with that improvement.

Best regards,

Great to hear that! Sorry for asking, but "a pragmatic solution is being put in place at this moment." sounds really different, then tagging it to "dev backlog".

Excited to hear that there will be a fix for this soon.

Hello,

Version 2023.3.10.0 has been released earlier this week. It contains improvements for what you asked. The user experience should be improved by remembering the last login type and automatically selecting it, even for Microsoft or Okta.

Let us know if that helps.

Best regards,

Great news! We will check this out in our testenvironment and will post the results.

That's great that is *should* finally be incoporated in DVLS, but is the "Chome/Edge/etc.." module been updted has well ?

If the servers can do it, the "helper" apps will have to do it also.

Considering our users is using credential injection, they rarely go on the full web site of the vault.

True. The breakthrough for our users' experience comes once the browser extensions also don't ask for the identity provider anymore. Almost none of our useres go on the dvls website.

Hello,

Thank you for your feedbacks. The login improvement should work for all clients using Devolutions Server login (RDM, Workspace Browser Extension Module (DWL), Workspace powershell). Could you tell us more on what doesn't work with the other client ? Of course, you will have to specify the login type once at the first login. After, all others login should reuse the same authentication type.

@francoiscollerette: Could you tell us what you meant by "...is the "Chome/Edge/etc.." module been updted has well ?"

Best regards,