Inside Job (or give me a loop)

Let's pretend I'm a System Administrator (:)), and I've got to tweak some features and install some software in my client PC's and servers for end users and programmers usage.
I'm logged in as Administrator, so, some of the policies and configurations I'm pushing don't apply to my account.
I need to login as a test user with membership similar to my clients to verify if everything is working and in place. At the same time I'd like to keep my admin session open, so I can make some adjustments to the configuration.
If I'm logged into a workstation console and I try to open a different session as another user, I'm obliged to use the 'Fast user switching' service. But this locks my previous admin session. While still logged in into the computer's console, if I try to open an RDP connection to the machine, I get an error reporting that I'm already connected to the console of the local computer.

But, all this is possible as long as I use remote sessions from a Windows server product. This is to say that you can loopback thru RDP in Windows Server, meaning that something is diferent in its RDP implementation. Could it be that the client is different from the one in the Workstation product? I can't even see the remote console connection.

What is the logic of this? In Windows Professional Edition, this happens because of a Microsoft policy that allows only one console session at a time. But, as the server edition has a admin remote console mode shouldn't the same concept be applied to the workstation edition? Why can't I open a new RDP session thru local host, or loopback interface, while logged in the console?

I don't know.

Trying to understant the reasoning behind this limitation, I determined that the loopback blockage resides in the client and not in the server.
The key lies in a COM object provided by mstscax.dll.
I developed a PoC tool that demonstrates just this. The tool is a dll called gimmelooprdp.dll, available here, that you can inject into a mstsc.exe RDP client. Run the mstsc.exe, get it's PID, and use a dll injection tool to inject it to mstsc.exe process.

Afterwards you can proceed as usual. Set the machine local address in the Computer data field and press Connect. The tool only works in Windows XP sp2 (as Microsoft no longer offers support for it, I hope they don't get anoyed by this hack). So, you'll be able to establish the connection, but, as Windows XP Pro only allows one session at a time, your primary console session will be logged off. If you wish to proceed with two opened sessions in the Professional edition, it is indeed possible, but you'll have to 'explode' the sessions (see my previous post 'Exploding sessions').

The dll can be downloaded here.