VNC Server Setup on Rocky Linux 8.4 (Red Hat 8.4 Variants)

These instructions worked for me on Rocky Linux 8.4. The configuration instructions for various Red Hat 8.X VNC server setups have varied substantially over the 8.X versions.

These instructions do not involve setting up an encrypted data channel. Only use this setup on a known secure local network or consider using a SSH tunnel between the client and server.

The graphical system needs to be running at bootup:

systemctl set-default

Install the VNC server binaries:

dnf install tigervnc-server

Configure the firewall to accept connections to the port:

Note: The following steps are done per user changing the port number for each user: ‘1’ = port 5901, ‘2’ = port 5902, etc.

 firewall-cmd --get-default-zone
 firewall-cmd --permanent --zone=public --add-port 5901/tcp
 firewall-cmd --reload 

Create the VNC user password:

 su - <username>
     Note: View Only = "n" 

Create a port mapping per user:

 echo ':1=<username>' >> /etc/tigervnc/vncserver.users

Create a systemd unit file:

 cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service 

Enable and start the VNC service:

 systemctl enable vncserver@:1.service
 systemctl start vncserver@:1.service 

Get server status:

 systemctl status vncserver@:1.service 

How to Break DHCP with a Firewall Configuration

If a client does not have an IP address and it need to use DHCP, it will assign as the source IP and as the destination IP address until the DHCP server returns the appropriate LAN address.

Block and/or and you can stop the client from getting an assigned DHCP address.

Throw in LAPS for additional painful excitement.

Windows 10 – Network Drive has the Wrong Cached Credentials

The short scenario: The help desk got a call from our senior accountant that her various drives were not mapping and she had to keep entering her login credentials.

Two things to also note: The cached credentials were to another account, not her domain login account, and this happened during COVID-19 when people were switching between working at home and at the office. In this case, she was in the office that day.

The help desk employee could not figure out why this was happening and contacted me and I was also off site. Not sure what was happening, I went back to the beginning. I started by making sure her Active Directory account had not changed because her 5 network drives are mapped via a batch script at log in. I then had the help desk make sure she was logging in with her domain account. We then followed that up by changing her password since I needed to rule out any possible mismatch that may have happened while she was working from home.

The key to solving this issue was that when she was prompted to provide her credentials to connect to the drive, the wrong account was presented, indicating that it had be entered incorrectly at some point and was being cached. The help desk also reported that one of the network drives connected at log in then disconnected prior to the prompt being displayed. In short – her AD account was functioning as it should but the computer was overriding the drive mapping.

The walk through. Open a command prompt as the logged in user. Verify the proper account:


What drives are mapped:

net use

Show the credentials that the computer has cached:

rundll32.exe keymgr.dll, KRShowKeyMgr

This popped up a window and we could see the server name and the incorrect user account. We deleted the server name entry and rebooted. All 5 network drives connected properly at user login.

While we didn’t test this, I believe we could have also gotten access to the stored credentials through windows settings by searching for “credentials”, credential manager, windows credentials.