Remote Desktop Gateway (RDGW) enables authorized remote users to connect to resources on the network. We can strengthen this in many ways and we start with a little closer look at the RDGW setup. That’s cool, depending on where I am my identity and access changes. With this, we maybe want to add a few more layers to protect this machine. This isn’t about Auditing, so I will save that for some other time.

Sure, we need to step up our game on logging and correlations of event logs to get a clear picture of who did what. Now when my user Tony connects to the server he is effectively a Domain Admin. So, we start with stealing the setup from part one and add the server to Domain Admins group. If we make that server a member of Domain Admins the user will become a Domain Admin only by landing on that machine, and it happens automatically only thru RDP. If a user RDP to a server with Restricted Admin mode, he will thru that machine connect to other resources in that context. In part one I wrote about RDPRA and how it flips the users identity to the servers identity he logon to. In this example, we will grant a user Domain Admin rights temporarily, and in other cases he will just be a regular user. With RDPRA we have the possibilities to be a special admin depending on which server we jump to. I don’t have JIT or JEA implemented so what can I do with built-in tools in the OS platform? I want to have a user dynamically/temporary member of an admin group. This time we will have a look at an interesting delegation model using RDGW and RDP Restricted Admin mode. This is part two of my RDP series on how to protect the communication, minimize the credentials exposure and how to use it in different delegation models.

Rd gateway mfa