Win 2025 RDP host - users get booted and cannot reconnect until an admin changes security groups.

Posted by Glasofruix@reddit | sysadmin | View on Reddit | 15 comments

Hey there,

We are having a problem that's killing what's left of my hairline.

The situation, a classic domain with a bunch of win 2022 servers, two DCs, fileserver, app servers etc...

The client wanted a self contained machine to run a multi user app (minimal spending/resources). We've basically installed a classic poor man RDS farm with the broker, rds licensing server + host on the same VM (something we hate, but we've seen working on hundreds of sites). No user containers, fslogix or anything fancy. Juste one VM to rule them all. Users click on rdp file, enter their domain credentials, get connected to a desktop from which they would run their app, no printing, file sharing, pure remote desktop one app use.

The problem: after a while, 8-10 hours they get disconnected from the server and cannot reconnect. With the classic message saying "this user cannot open a remote desktop connection because he's not authorized" or some such. BUT, the user is authorized, either through an AD group allowed in the collection settings our directly with their domain account. It does not happen gradually, everyone gets the same treatement even users who did not connect that day. Basically any user not in the admin group gets the stick.

We've found out that modifying the collection authorizations, either by adding or removing a group or a user (even a rando test user not even in the same group) fixes the immediate problem. The users can reconnect and work for the next 8 hours or so.

We've tested the kerberos connections to the DCs, we've disabled every firewall rule between the affected machine and the rest of the network, there are no session expiration rules/gpos in place. The network is clean and every bit of trafic gets where it should to through the correct ports.

There are no errors reported in the event viewer when the problem occurs, all we can see are events

261 - connection received

1149 - authentication succeeded

when everything is working an event 263 connection established usually follows, but not this time.

It's like the groups get reset after 8 hours and mucking around renews something somewhere but we really have not clue where, how and why.

At this point we suspect a bug in win 2025, but the OS is up to date.

If anyone has a clue, please share ;)

[-]

Glasofruix@reddit (OP)

I've found a GPO with a setting that looks suspicious: Policies -> windows settings -> security settings -> restricted groups with only domain admins in there. So this might override our collection group authorizations?

WorkFoundMyOldAcct@reddit

If it’s set to Update then yes.

MagosFarnsworth@reddit

I might be wrong on this but are there timesynch issues? "10hours" is the default tts of Kerberos tickets, re-ticketing might fail due to timesynch issues. Add precision clock to VM.

The next time this happens, instead of adding/removing users from groups to trigger a refresh, try resetting the Remote Desktop Connection Broker Service and see if that resolves the issue. If it does, you have your root cause. You said you’ve checked all Kerberos settings, but you might want to take a look at the entire Kerberos flow to see where the breakdown is. I suspect the issue is more in line with a broker service that depends on Kerberos instead, and it’s losing its AD binding some time within the Kerberos ticket lifespan, which only shows its symptom at the Kerberos renewal point.

Broker service restart does not correct the problem.

I have a window of about 5 minutes of debugging before users start go crazy, spice must flow as it said. But i will try a broker service restart to see if it allows people to connect. Should be able to do this tonight.

BeagleBackRibs@reddit

Sorry HR policy is after 8-10 hrs you have to stop working for the day

brazzala@reddit

Make the local GPO for Kerberos

Conscious-Arm-6298@reddit

Have you checked GPOs already?

Yes, nothing exotic there either the VM is pretty much fresh in it's own OU with only a GPO to prevent automatic updates.

St0nywall@reddit

First side note, why not publish the one app on the RDS farm and let them launch that. No need to RDP into the server and less overhead for the server.

RDS on 2025 has always been problematic.

Second side note, 2025 RDS cals will authorize 2022 RDS hosts too without any downgrades. FYI

The remote app configuration is not supported by the app vendor, in other words we get no support if we don't do it their way.

Stonewalled9999@reddit

why are you bothering with broker role for a single RDSH ? Also we had so many unresolved issues with 2025 in RDS we reverted to 2022

I was thinking the same thing

laserpewpewAK@reddit

This smells like a kerberos issue. 10h is the default lifetime of a ticket. Changing a user's group membership will force them to get a new ticket instead of refreshing an existing one, so I would wager that machine is not able to refresh tickets for some reason. You can try purging the cache with klist, after that I would remove it from the domain and re-add it as a next step. The issue is most likely client-side since I'd expect a LOT more problems if it was on the DC side.