Sam Spronk

Apologies for lack of response here, but just confirming we have also upgraded and set this option and it works as expected.

Hi Team

I had missed these above updates we will make plans to update and report back, just asking - there is no way to push this change out to all staff from within RDM ? Rather than editing the cfg file?

Hi Richard

Thanks for the update, sounds promising

Hello

Thanks for your post. I understand the issue that this is causing.

We retain the option of fixing this on our side, but it makes things very complicated for us: the relevant Microsoft library and it's dependencies are open source, so while we can fix this issue and build from source, it becomes a real integration headache when we see that some of the dependencies that we would have to rebuild, are also core dependencies of other dependencies in RDM (some of which are open source, some of which are not). There's also an ongoing maintenance burden, which is significant. We _have_ done similar things in the past, so I won't rule it out; but first of all I'd like to take another shot at getting Microsoft to fix this on their side.

I've updated the issue I created on GitHub (linked above) and explained the specific business case that you presented. Let's see what they say; they are usually pretty responsive to issues although that doesn't always mean things will get changed.

Thanks for your patience

Kind regards,

Thanks Richard, appreciate the response and efforts

Hi Team

Just jumping in to add that we recently upgraded from an older version where just the pop up would appear instead of the full browser window, Besides the slight annoyance factor of that process not being as smooth. This actually causes a problem for us. We have conditional access configured on access to Azure SQL resources and only a specific set of device IDs are allowed to access it.

When the old pop up method was in use that was fine and all staff could login (the device ID was sent during that method). Now that it uses the full browser method - if staff are using firefox or chrome that device ID does not get sent on and in the Azure sign in logs it shows as device unknown, therefore the staff are prevented from accessing the resource (The RDM database) and unable to login. If we set Edge as the default browser - Edge does pass on the device ID and staff can login.

For the moment we have 2 options - turn off the conditional access policy - something we don't really want to do

or

Ask staff to set their default browser to edge - something not all staff want to do for various reasons.

This was working yesterday on the older version of RDM that we were running.

I noticed this line in the latest Improvements

• Added default Duo settings to the system settings

Checking if that is related to this post or something else?

Hi Jafran

Thanks for the update, look forward to giving it a try

Hi Hubert

Sorry I have been away on leave, correct. you have nailed it.

Hi Hubert

Thanks for responding, I guess what I am really after is that this setting (in my screenshot below System Settings > Applications > Force application security with TOTP (authenticator) ) was compatible with Duo and not just the Authenticator app.

That setting allows us to force MFA as soon as staff use RDM, and a few other options such as on idle, on windows lock etc. The issue with applying Duo to the data source and potentially setting that option you have suggested - while that may somewhat work - we do connect to a lot of different customer VPNs, quite often when that VPN gets connected other local network settings are disabled and the staff member loses access to the RDM data source - in this situation it would go into offline mode, and then while the staff member is busy trying to connect to the customer's VPN they now have to complete a DUO MFA prompt because the data source has gone offline.

If it was possible to use Duo when opening RDM - it won't matter if the data source is offline or online.

Hi Team

We currently use Google Authenticator which prompts staff as they launch RDM - they cannot get into RDM without entering the OTP. I believe this is forced via a System Setting, under Applications Settings > "Force application security with TOTP (Authenticator). This works well but is not as nice of an experience as using Duo and a push notification. We are also transitioning a lot of our services over to Duo and would be nice to include RDM in that.

I understand we can use Duo in RDM to access a Data Source, which works really well, but is slightly different to the above situation. We allow staff to use the RDM data source offline - we do this as we can't afford for staff to not get access to RDM if the data source is offline for a period (this can also happen with the myriad of VPNs that we need to connect to that can sometimes force us to lose direct access to RDM). I looked at using the Duo MFA on the data source which does work nicely - however if the staff member doesn't have internet and launches RDM - no connection to the data source is made and then access is granted - I'm trying to avoid that loophole.

I also need to make sure this is governed by a system setting - we can't rely on staff to configure a setting themself. In an ideal world it would work exactly how we are currently using it with the force application security setting - but use Duo instead of TOTP (Authenticator) option.

I hope I've explained myself and made sense, also happy to try a few options if you think we can do this with what is currently in place. I did raise a support request already and support suggested I raise a feature request. Support request is: 00016992 in case you want to read that too.

We're currently on 2022.2.18.0 - I see a few Duo Improvements since this version but didn't look to cater for above.

Thanks

Sam