RDP Inception and Password Changes

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).

NFSv4: Interop, ACLs & Automount

NFSv4 has been around for a long time but it still seems a bit foreign to me. The following is a quick rundown of things I recent learned related to NFSv4 from limited experience in implementing it.

Interoperability

Is it possible to setup NFSv4 along side NFSv3 on the same server, serving the same volumes? Of course. However, it might not always work exactly as expected with legacy clients.

A normal /etc/exports for NFSv3/v4 interoperability might look like so:

/export                   10.0.0.0/8(rw,no_subtree_check,fsid=0)
/export/namespace         10.0.0.0/8(rw,no_subtree_check)
/export/namespace/share1  10.0.0.0/8(rw,no_subtree_check)
/export/namespace/share2  10.0.0.0/8(rw,no_subtree_check)

With this configuration, we have the “virtual root” export (fsid=0), the namespace export (for mounting the whole namespace with one mount) and the individual “share” exports (for mounting individual shares, most likely with automount). The NFSv4 clients can perform mounts using the servername:/namepace syntax and the NFSv3 clients can mount the whole root, namepace or individual “shares” with servername:/export, servername:/export/namespace or servername:/export/namespace/share1.

All is well in the NFS world… or so it seems at first. It turns out that an older SunOS does not entirely like how this RHEL 6 NFS server is exporting the file systems:

hostname% cd /namespace
hostname% ls
share1     share2     share3     share4
hostname% pwd
/namespace
ubcpetnxi% cd share1
ubcpetnxi% pwd
/share1

Notice the final line. I was just in /namespace then I changed into /namespace/share1. Now pwd tells me the path is only /share1. I was expecting /namespace/share1. It looks to me like the SunOS NFS client is not behaving well with how the NFS server exporting the file systems and/or how the bind mounts are setup locally on the server to map the storage into the NFSv4 “virtual root”.

Please leave a comment to if you know of a different /etc/exports and/or mount configuration that would alleviate the SunOS NFS client issues noted here!

Access Control Lists

NFSv4 defines a model for Access Control Lists (ACLs) that has similarities to that of Microsoft’s NTFS. But don’t worry about interoperability: NFSv4 translates your existing “POSIX” ACLs on ext3,ext4,xfs,etc. to NFSv4 ACLs automatically.

The main gotcha with exporting a filesystem with “POSIX” ACLs with the NFSv4 server is that the normal getfacl and setfacl tools don’t seem to work on the NFS client side! Because the NFSv4 server only presents the translated NFSv4 ACLs to the clients, the nfs4-progs package must be installed and the nfs4_getfacl and nfs4_setfacl commands used instead to view and manipulate the ACLs on NFSv4 clients.

Also, the little + at the end of the rwxrwxrwx permissions listing you can see with some variant of ls -l, the symbol that normally indicates the presence of an ACL, it simply doesn’t appear on a (Linux?) NFSv4 mount where ACLs exist. Sadness.

Automount

Automount on RHEL 6 (and clones) appears to have a bug related to bind mounts. NFSv4 exports cannot (trivially?) be mounted locally on the NFSv4 server on itself with bind mounts as is possible with NFSv3 (or lower) exports. I have read that this inability is due to the “virtual root” abstraction that NFSv4 employs. Instead, automount should be performing true NFSv4 mounts when operating locally on the server… but it doesn’t do that on CentOS 6 (and in my experience RHEL 6):

See: http://bugs.centos.org/view.php?id=6101

The workaround is to specify port=2049 in the NFS mount options of the automount map in use (where 2049 is the port the NFS server is listening on). This appears to cause automount to immediately attempt an NFS mount, bypassing the (failing) attempt at a bind mount.

 

Sticky Scrolling Modifier (for Windows)

I’m a ‘baller, a trackballer.

Yes, I’m one of those people. My colleagues hate it. The director teases me about being a massive geek for using one. I love it.

The one thing that many trackballs seem to lack is useful scroll wheel or scroll wheel-like alternative. I have been using the Kensington Orbit w/ Scroll Ring and Expert Mouse and both of those have a decent scrolling mechanism (the “scroll ring” around the ball) but I wanted to explore the options available to ‘ballers on MS Windows whom do not have a (good) scroll mechanism on their device.

Enter X-Mouse Button Control. Among the multitude of features and options that it provides, just a single option is necessary to enable an interesting scrolling alternative: “Change Movement to Scroll”.

For my Kensington devices, I can configure pressing one or a combination of two physical buttons to send a mouse button event and then use X-Mouse Button Control to capture that event and map it to a sticky modifier for changing pointer device movement to scrolling. For non-kensington devices, use the driver/software bundled with the device to map the physical button to the desired button event.

Example

In Trackballworks, I set the left top button to “Button 5”:

2014-05-20 16_05_45-TrackballWorks

And in X-Mouse Button Control, I set “Mouse Button 5” to “Change Movement to Scroll (sticky)”:

2014-05-20 16_08_15-Program Manager

Now, when I press the top left button once, my trackball motion becomes a scrolling action and when I press it again, it switches back.