I use Remote Desktop to do a credential swap where it goes from being the explicit user accessing the endpoint to a privileged credential.
What I do is, in the connection process with RDP, the user logs into the PAM tool as first name.last name, which is his normal domain account. However, BeyondTrust, with the remote desktop connection, substitutes the user's first name.last name with a privileged credential that looks like his name. It would be like A-first.last. This is so that we can also perform session recording and keystroke logging, as well as keep a detailed log of who is connected to which desktop and which account.
The most valuable suite feature for us is that it's light. It's built into the operating system and has a command line interface capability to insert credentials, IDs, a password, et cetera.
If anybody who's going to be using this, I’d warn that some of the dependencies that are very helpful when the window servers are running it would be best if they have network-level access enabled. It can speed up authentication. However, it really it also works well with TLS security as well as others on the certificate level. That said, I really don't know if I would start swinging in the dark after that.
Usually, during a privileged session, you don't want the privileged credential password being visible, nor maybe would you want keystrokes or screen scrapes to take place.
One of our first problems was the only time RDP ever gave me a problem was when an organization would build a new server. They would automatically build it. They would name it. They would put the connection settings on it. And then they would also put a certificate on it. Then the engineering team that ordered the server would then rename the server, which would nullify the certificate. That's the only time that RDP or remote desktop ever gave me a problem. And that was not the remote desktop's problem. It was a process flaw.
The only problems that you're going to have with the remote desktop are going to be firewall ports, security, and NLA, which is a net network level access control, or TLS transfer layer security or some other SSL-type of security. Those are the only times you get into any issues. And that's only due to the fact that the originating site is not compatible with the target site. However, that's rare. That said, even then, that's more on the rare side. I'm a PAM architect, a privileged access management architect. I usually knock down those problems before we get to them since I ran it all a hundred times.
I’ve used the solution for 20 to 25 years.
The solution is rock solid. It’s stable and reliable. There are no bugs or glitches, and it doesn’t crash or freeze.
The sky is the limit in terms of scalability. It’s not a problem at all if you need to expand. The only limiting factor is the budget. Obviously, the more you grow, the more you pay.
Tens of thousands of people use the solution. The primary use is to segregate a user from a direct login to a desktop.
The solution is actually built into the larger product. We pretty much just have to secure the connection.
It's actually maintained as part of the standard windows update tools and also could be updated manually with specific patches that might be something more specific to your organization. I've only experienced that once and that was years ago.
I’m implementing the remote desktop for customers.
It’s built-in. It’s free. It doesn’t cost extra.
We are Microsoft partners.
The deployment is both on-prem and cloud. If I was working with an organization that is a monster and they're distributed or maybe even a multinational or multi-state, I would use Azure Cloud and do use the Azure remote desktop solution.
There are so many different types of uses. In my use case, it is so painfully specific for connection brokering. We use it as part of the built-in connection process with our PAM tool. You can actually just sit down at your desktop and then do a start run, and then run MSTSC, which means micro soft terminal services client, which is a remote desktop. You can connect to one of your own computers at home, or you could connect to a server. However, you have to know the ID and password to connect. I circumvent that by doing a command line connection where I insert the credentials and the users connect, not even knowing what ID or password they're using to connect with.
I’d rate the solution ten out of ten. It’s a meat and potatoes product.