Automating RDP App Login with Bash & xdotool (Because Sometimes TPS Reports Won’t Generate Themselves)

 (Originally published in LinkedIn)

When working with legacy systems or remote apps that require GUI interaction, automation can be... frustrating.

In my case, I needed to access a remote Windows application via RDP. Not only did I need to connect to the host machine, but also type in a username and password inside the remote app's login dialog — every single time. No API, no command-line interface, just a GUI prompt.

So, I did what any pragmatic engineer would do: I automated it with Bash, xfreerdp3, and xdotool.

Let me walk you through how I did it.

---

🛠️ Step 1: The RDP Connection Script – connect.sh

#!/bin/bash

if [[ $# -ne 2 ]]; then
    echo "Usage: $0 <username> <password>" >&2
    echo "Error: This script requires a username and password to be passed as arguments." >&2
    exit 1
fi

USERNAME="$1"
PASSWORD="$2"

xfreerdp3 -f "/u:$USERNAME" /d:Initech "/p:$PASSWORD" /load-balance-info:'tsv://MS Terminal Services Plugin.1.QuickSessionCollection' /app:program:'||TPSReportGenerator' -decorations /v:Initech.com:9983

This script does the heavy lifting of opening the remote app (TPSReportGenerator) using xfreerdp3:

• /u:$USERNAME and /p:$PASSWORD authenticate the user.
• /d:Initech sets the domain.
• /app:program: opens a specific app inside the session.
• /v:Initech.com:9983 connects to the remote host and port.

The script expects two arguments: username and password. Simple. Controlled. Effective.

---

🎯 Step 2: Automating GUI Input – login.sh

#!/bin/bash

USERNAME="michael.bolton"
PASSWORD="MyOwnNameNotHis!"
RDP_WINDOW_NAME="Login Dialog - TPS Report Generator"

echo "Starting RDP connection in the background..."
./connect.sh "$USERNAME" "$PASSWORD" &

This script starts the RDP session in the background and prepares to automate the login within the remote application window.

# Poll for the window to appear, with a 30-second timeout
WINDOW_ID=""
for ((i=0; i<30; i++)); do
    echo "Polling for the RDP window..."
    WINDOW_ID=$(xdotool search --onlyvisible --name "$RDP_WINDOW_NAME" | head -1)
    if [[ -n "$WINDOW_ID" ]]; then
        break
    fi
    sleep 1
done

A polling loop checks for the appearance of the application's login window (named "Login Dialog - TPS Report Generator"), giving it up to 30 seconds to appear.

Once detected:

echo "RDP window found $WINDOW_ID. Sending login credentials..."
sleep 2 # A brief pause for the window to be ready for input

xdotool windowactivate "$WINDOW_ID"
xdotool type "$USERNAME"
xdotool key Tab
xdotool type "$PASSWORD"
xdotool key Return

Wait a couple seconds to be sure the window is active. Remote applications can have their lag... It simulates typing the credentials and hitting Enter — just like a real user would.

---

🧠 Why This Matters

Automation isn't just about efficiency; it's about making repetitive tasks invisible. While RDP and GUI-based apps aren’t ideal targets for automation, tools like xdotool give us a workaround when there's no better alternative.

This is especially useful in:

• Legacy environments
• Remote apps with no CLI or API access
• Quick fixes when better integration isn’t feasible

---

⚠️ A Word on Security

Let’s be clear: storing credentials in plain text within scripts is a bad practice.

This example is purely for demonstration purposes. In production, consider safer alternatives like:

• Environment variables
• Encrypted credential stores (e.g., pass, gnome-keyring, HashiCorp Vault)
• Interactive prompts
• Secrets management tools

Never compromise security for convenience — unless you're debugging a TPS report generator in a hurry. 😉

---

I won’t say more. I’ll just ask: Have you filed your TPS reports today?

---

Have you ever had to automate something similarly odd or unexpected? Drop your story or workaround below — I’d love to hear it.