Forum Discussion
Login failure from tssdis.exe on RDS server
ExceedKevin, having the same issue as you now that we have a SIEM capturing failed login information on all our key servers. After doing some more research, I've decided to implement the third step in the solution of the following article to see it gets resolved (see https://learn.microsoft.com/en-us/answers/questions/194082/rdp-logon-fails-observing-error-34an-error-occurre.html). If it does, then I will provide feedback over the next week or two as we monitor activity. I feel confident it's not a security issue, but still concerned whether there is an operational deficiency somewhere. Hoping someone from Microsoft can shed light on this.
ExceedKevin, the third step did not work. After doing some more research found information implying that it could be a result of using NTLM v1 (which has its own set of issues) instead of enforcing NTLMv2 for authentication. Since there are no legacy devices in our environment I will changing this across the domain to see if it resolves the "failed logins".
- Hey, possibly too early to tell, but wondering if this made an difference?
Hi,
We're in the middle of deploying NTLM blocking on our network, and this is very similar to an issue we encountered with the tssdis service during this process.
Brokers use kerberos correctly when first started, but would randomly switch to NTLM fallback about once a month, after which the service needed restarting.
It turned out that these correlate perfectly with the Connection Broker server *changing it's machine account password in AD*.
We've had some success with a scheduled task triggered off NetLogon event ID 5823 (the machine account password) which restarts the tssdis service.
