PWV

Extra note on the previous . I know from the past that when I restart RDM everything works fine again for a while , mostly for weeks . The before mentioned manual procedure does it , I don't know which exact circumstances trigger the 'seems like wrong caching' problem .

Hi,

A few questions before reporting a bug:

Are you using JIT privilege elevation?

When you say that mstsc works correctly, do you mean after performing JIT privilege elevation with RDM, and then running mstsc?

Have you try to configured a replication latency in the JIT privilege elevation provider settings? If not, I suggest you try a 5-second delay, just for testing. If it's works, you can try lower value.

Best regards

Simon Leroux

@Simon Leroux

Hi Simon,

we are not using JIT escalation yet , we purchased the license recently as we do it manual at this moment (just adding accounts manually in the correct AD group which has RDP rights on the server).

If I am correct when we start to use JIT our user account will be automatically added to a newly created group which will be made member of a dedicated AD group with RDP rights . So , in our manual procedure we have one hop less .

Next are the steps we take :

1) add the user account to the dedicated group

2) klist purge on the client to retrieve new Kerberos ticket

3) connect to server using RDM : fails

4) connect to server using Windows mstsc.exe : succes

I checked replication between our DC's , this is 100% Ok.

Even now (3 days after giving myself RDP rights to a server) I still cannot RDP via RDM . I can when I switch to FreeRDP or use mstsc .

Kind regards,

Carlo.

Hi , I have reported the same issue a few years ago which resulted in nothing , the possible CredSSP issu was not known at that time I suppose and as soon as I restarted RDM (to get full functionality again) the issue was gone and it was not on a frequent base to happen again. So I dropped it .

It didn't happen a lot since so I ignored but the last week I have had it a few times. We recently upgraded to 2026.2.7.0 (we constantly follow updates) and the update before . It might be related to 2026.2.x or not at all , who knows .

Case :

AD joined PC , 2 domain controllers , no RDP rights .

When someone needs to RDP I make him member of a dedicated AD group and he has to perform klist purges locally to get new Kerberos tickets containing the new group membership . Then he can RDP .

At the moment for my own setup I have two servers which I should be able to RDP to , membership has been changed 2 days ago . Manually do mstsc works fine.

RDP using RDM doesn't, the security logs show event 4825 (no RDP rights) , before that event 4627 Group Membership enumeration showing the old memberships , so its normal that the server rejects the RDP .

It is 100% clear that RDM sends some cached version of the (I suppose?) Kerberos ticket ? A network trace shows that my client sends a KerberosV5 TGS request for TERMSRV/pwvprint06 , and he receives a TGS Response on that.

I just tried switching to the FreeRDP as mentioned above and that works also . It's a workaround maybe but I'd rather see it working with the default RDP . As an extra test I reverted to RDP (latest) and I couldn't connnect again .

Should I register a case for this or is there a known definitive solution to it (preferable in the RDM software , no manual regkeys/... on the 10 clients using RDM) .

Kind regards, Carlo.

I have the same kind of a request .

We have 2 AD user types we want to manage with PAM .

-Remote support users with password rotation : these accounts always have to be expired or disabled . When disabled we get a constant heartbeat failure alert . Password rotation does keep working (luckily) . Pam could enable these accounts on rotation or check out . Disable them on check in .

-Internal temporary server admin accounts : we only want to do temporary elevation on them . The password on these accounts are private and not to be set/reset by PAM . So the password is unknow , heartbeat check failures as a result .

Kind regards,

Carlo.