lowellp

Oh yeah, thanks for that!

In the Network Scan tool (great add-in, BTW) when I sort by Host (IP address) it sorts improperly. For example, 10.10.1.112 comes before 10.10.1.12. It's sorting on the digits not on the last number. Is this a bug?

Nice! Thanks for the update! Will be nice to not have a workaround that adds its own insecurities.

Any update?

OK, that'd be great. One thing that's always impressive with RDM is how many features you folks keep adding, updating, and improving.

So the Duo bypass code is set up in Duo, in the user's section. You can set it with all sorts of parameters; single use, multiple use, time-limited, or unlimited use. In this case we'd set up an unlimited use code. It's just entered in when RDM asks for the MFA code.

As to where to configure it in RDM, that's what I'd like to see. In the credential, when using Passportal, it'd be great to have a password field that's for the Duo bypass code. But I also realize that the Passportal settings don't really have anything to do with Duo. That might be hard for RDM to do.

Thanks, Hubert. I did discover that we could set up a permanent bypass code, and once we used that in on RDM session it seemed to work (not prompt) when connecting to other computers. So that's not too bad of a workaround. We just want techs to use RDM more as there's good auditing both there and with Passportal/Duo, so the less speed bumps the better.

When we set up Passportal as a credential, it works great until we enable Duo MFA for the customer's Passportal tenant. We enforce Duo MFA for all users, so that includes the Support admin account which is used in RDM to access shared credentials.

That means that whenever we try to connect to a computer, it tries to get the credential and then asks for Duo MFA. That's fine, except that we don't want that in this case. We set the Support admin account in Duo to be bypassed completely. Yet RDM still asks for the Duo MFA code when using the credential.

I can log on to Passportal's website with the Support admin account without being prompted for Duo MFA when it is in bypass mode, so I know the bypass is working fine, just not within RDM. Whether or not Duo MFA is enabled for the Support admin account, RDM asks for a Duo MFA code.

A couple of ideas:

1. Ideally, I don't want to bypass MFA completely for the Support admin user account. I'd like to instead set up a permanent bypass code, then put that code into the credential so that RDM passes that each time the credential is used. Is that currently possible or would that take a feature change?

2. If the above will have to go to dev, could the issue be fixed in the meantime so when we've set the Duo user to be bypassed, RDM won't ask for MFA?

I am using 2021.1.36.0. Turns out I had to deactivate "Activate NLA" in RDM, properties, Connection tab, as NLA was disabled at my remote VM.

In this scenario my host computer is on a different domain, the remote computer is AAD-joined to a demo M365 tenant so it's not connected to our tenant.

Previous instructions I had gotten from the forum said to enable the Activate NLA setting. When I turn NLA on at the remote computer, I can't connect... maybe because they're on separate domains?

Just putting this here for anyone else who comes across it.

What do we have to change to make this work? At one point I had it working with all sorts of acrobatics around the RDP settings, and so forth. But that quit working months ago without warning.

I guess I'm looking for a document that shows *all* the requirements for being able to log on to a computer that's AAD-joined.

...and you'll still need to either rebuild all data sources or recover from a computer backup/previous version of the CFG file as your data-filled CFG file will be overwritten with emptiness.

Thanks, James!

(I've got a ticket in about this now but just posting it here in case anyone else encounters the same issue.)

I've upgraded only 2 computers now to RDM 2021.1.27.0 and in both cases all data sources and configuration has been deleted. I exit RDM and go to the .BAK file (to recover the CFG) but it's the exact same date and time as the CFG one, and when I use that file it is the same; all my data sources are gone.

I've recovered the (larger) CFG file from my computer backup this morning, and still the same; no data. I go to import the CFG file, and after RDM restarts, same thing. Anyone else seeing this?

I've just installed the latest version, 20203.12.0 and it broke my Azure AD logon. I noted in the release notes that there was an improvement to this kind of logon. I enabled the Azure AD host option, and that didn't work. I went to the credential and broke out the username and domain into the associated fields, that didn't work either. What should I be doing to get this working again with the new changes?

Great, thanks much!

When we set up folders in RDM we often make use of the custom images built in to RDM. I used to be able to hit "H" on the keyboard to skip to the first images with names starting with H, such as "HomeBlue". That stopped happening a few versions ago. I'm at the latest 2020.2.15.0 version.

It's a small thing but when we're setting up new folders it's actually a big time saver instead of having to scroll back and forth.

Thanks so much, Marc-Andre! This worked! Just adding that .\ at the beginning fixes things.

Eventually, could RDM have a checkbox for "Azure AD logon" that switches the credential fields to not have a domain, and have a little note/hint that you need to use AzureAD\username, and inherently add the .\ or just ignore the @ sign so that it doesn't split that out as the "domain"? I guess that should be in Feature Requests...

I'm not completely sure how CW Control does it; the first time I used the plugin I had to sign in but haven't had to for a very long time now. Being that you have a mechanism for reaching in to Passportal already within an individual session (I still have yet to get that working, have to revisit an open ticket we have on that) in theory we'd be able to leverage that for any connection signing in to that client. If we couldn't apply that at a global (client-level) point we'd have to apply that to each session configuration but you have batch tools for that.

And even if we had to sign in to Passportal once at the beginning of a day that'd be fine.

With ConnectWise Control they have a great Passportal plugin where you can side-dock the plugin, choose the client and credential, and use that for logging on to Windows or to websites or apps (most work) inside the session. And if it doesn't paste the credentials into the session at least you can copy the password right there instead of having to go to the Passportal website separately, go to Clients, select the client, Credentials section, open the credential and copy the password.

Here's a screenshot of what that looks like:

So in RDM it would be great to have this as a pop-out (pinned or unpinned) and ideally have it already set to the client we're logged into... but that's a "nice to have" so that bit could come later.

I'm not sure what else to do to make a functional RDP session file. The features above are set in the RDP file but it doesn't even connect with the username that's populated and saved in the RDP file. It just comes up to the main logon screen with another user that is available on the computer. If I cancel that user, then username@xxxxonmicrosoft.com is showing with no AzureAD and nothing for the domain below the sign-in fields.

Are there any other tricks to making a functional RDP file?

Interestingly enough, if I select "Open (Prompt for Credentials)" whether I use AzureAD\username@xxxx.onmicrosoft.com or put AzureAD in the Domain field, same thing; it fails to log on.

If I choose:

1. domain\user - it fails to log on, but does show the username portion of the account name, no domain shown.

2. user@domain - fails to log on, shows username@AzureAD in the account name, no domain shown.

3. user - fails to log on, shows username portion of account name, no domain shown.

Seems that say for option/format #1 above, RDM is ignoring anything after the @ sign in the user account name. It's assuming that's the domain, even though AzureAD is in the domain field.

Thanks for the hint Jeff!

We did that (it worked) and compared the settings with a non-working session. It appears that the default setting "Connect and don't warn me" has to be changed to "Warn me". So summarized three things have to be set to achieve the effect of RDP's "enablecredsspsupport:i:0":

• Advanced>Enable CredSSP support: FALSE

• Connection>Activate network level authentication NLA (SingleSignOn): uncheck

• Connection>If the actual verification does not meet minimum policy requirements: Warn me

We don't really understand, why this settings are the right ones, but at least they work;-)

This gets me closer. It still fails to authenticate the user. I've tried "Default" for credential settings and manually saving them into the RDM session either using AzureAD\username@xxxx.onmicrosoft.com or separating AzureAD to the Domain field. Neither work.

I've also tried storing this separately in a Credential and referencing that Credential entry. Same thing. What shows up is "The user name or password is incorrect. Try again." When I click OK, only the username@xxxx.onmicrosoft.com is in the user name field for Windows logon, and nothing in the "Sign in to" section that should say the domain.

When I change the username to AzureAD\xxxx.onmicrosoft.com in the Windows sign on screen and put in the same password, it logs me in OK.

So somehow it seems that RDM isn't passing through the AzureAD domain portion regardless of whether it's in the Username or Domain field.

I'm using the latest version of RDM at this time: 2020.1.20.0.

Every time I update RDM on all the computers we use it, the app is unpinned from the task bar. This is an issue unique to RDM. Isn't there a way for you to check first to see if it's pinned, and then pin it back once you're done? It's a small thing but really gets annoying with many computers, as there are often updates. I appreciate the rapid update cycle; you guys do a lot of great stuff in this app. Just want the upgrade process to be more convenient.

I did search for this in the forums and this link below came up in the search but the page is not reachable:

https://forum.devolutions.net/forum/topic27927-each-new-install-unpins-rdm-from-taskbar.aspx

Ping...