Tag: security

RDP Inception and Password Changes

rthomson 1 Comment

A common pain point that seems to come up regularly among technical folks is how to change a Windows account password over an RDP connection.

The correct answer is Control+Alt+End, right? Of course.

However, this doesn’t work as you might expect when you’re lost in RDP “Inception“. RDP inception is when you’re multiple levels deep with RDP connections, such as would be common when using one or more “jump boxes” or intermediate systems.

Example: Local Device->RDP1->RDP2->RDP3

When you’re lost in RDP inception, the Control+Alt+End command is sent to the very first RDP session you are connected to. In our example above, that would be RDP1. So what about changing your password on RDP2, RDP3 or any other systems beyond RDP1? The On-Screen Keyboard (osk.exe) is your new friend. Using osk.exe to bring up the Control+Alt+Del menu is not necessarily intuitive, though.

The Method

  1. Launch osk.exe in the RDP session for which you want to change your password.
  2. Hold down Control+Alt on your physical keyboard connected to your local device.
  3. Click “Del” using the On-Screen Keyboard running in the RDP session for which you want to change your password.

The Control+Alt+Del menu will now appear within the desired RDP session, allowing you to change your password.

Note: The “Desktop Experience” feature appears to be required for osk.exe to launch on Windows Server 2012 and perhaps also 2008 (untested).

Remote Access Solution: Follow Up

rthomson Leave a comment

Yes! We’ve implemented what I think is the best compromise for our remote access problem that I outlined earlier.

Three major things happened that made it possible to compromise:

1. I received an OK from the higher-ups that indeed it would be ok to mandate that users who want remote access to our system have all their Internet traffic routed via the VPN.

2. The VPN configuration that was proposed is not that of a private group but the generic campus-wide VPN solution with ACLs to allow VPN clients to access our resources.

3. The generic campus-wide VPN service does *not* implement any outgoing restrictions, unlike the private VPN groups do. This makes it possible for VPN users to do whatever they want when connected, with the stipulation that it’s akin to bringing your personal computer to campus in terms of privacy.

This really is the best of both worlds (security, ease of use). The campus VPN service is super-simple to use and we restrict access to our services to VPN users instead of the whole Internet. While we don’t control who gets access to the VPN, the pool of users is MUCH smaller and at least semi-trusted by the organization. Thus the risk is greatly reduced.

I’m happy.

Cfengine 3 Snippets Part 2: sudo

rthomson 3 Comments

It’s been a while since I’ve really had time to delve too much further into cfengine 3 since my previous post on the subject way back in May but I do have another simple example to share. This time it’s about managing your sudo policy via the sudoers file.

The example is that of a very, very basic sudoers policy but the principles are easily extended to create much more complex policy. The general idea here is that we want cfengine to ensure that specific rules are always in place. Instructed properly, cfengine accomplishes this very well.

Warning: I don’t know anything. I’m just someone learning cfengine 3 and posting about it. If I’m wrong about something, let me know! If you find this at all useful, be my guest. That is all.

Read More