Tspkg.dll Version With Credssp Update

[Raina Giorno]

Im activating the Network security: Restrict NTLM: Incoming NTLM traffic, Network security: Restrict NTLM: NTLM authentication in this domain and Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, to deny all incomming or ougoing NTLM from/to clients/servers.

I've check the providede link and both my win 10 client and my windows servers 2019 are completly updated and their tspkg.dll are in an upper version than the one with the patch for the credssp/oracle remediation CVE.

For me, when the Default Domain Policy has Restrict NTLM "Deny for domain servers" active and servers have NLA checked, it seems Remote desktop connection (mstsc.exe) works only with DNS names, when using real server IP's it does not work.

There is no way to have NLA on and NTLM disabled. I've tested this on Windows server 2012 and 2016. I've tried all the standard group policy changes with setting cred ssp oracle remediation to vulnerable, but it has no effect.

Microsoft released a security update that fixes a remote code execution vulnerability in the Credential Security Support Provider Protocol (CredSSP) in March 2018. This vulnerability (CVE-2018-0886) allows an attacker to remotely execute arbitrary code on a vulnerable Windows host with an open RDP port (TCP/3389).

The best way to check whether your computer is affected by this change is to determine the %systemroot%\system32\TSpkg.dll version and compare it to the table below per operating system.

The CredSSP updates for CVE-2018-0886 were first released in March 2018 for systems running on Windows 10 1709 and Windows Server 2016 1607 and lower. Since then, newer Windows versions already include this security patch.

This issue has been a thorn in my side for the past several months. While investigating I've read every post/article I could find on the topic and wanted to share my findings, as well as include instructions how to recreate the issue which I haven't seen elsewhere.

In Server 2012r2 and Server 2016 RDS environments, while in published RemoteApp applications, the Caps lock/Numlock keys become inverted from the local computer. For example, the keyboard indicator shows Caps Lock is off, but capitalizes all characters in the RemoteApp application.

Currently none. We placed a paid ticket with Microsoft Support where we explained the issue and provided instructions on how to recreate. The ticket was escalated, and we were eventually informed that this is a known issue that hasn't been documented. We were then provided a refund and informed that they would let us know when a fix is in place.

Clicking anywhere outside of the RemoteApp applications will correct the inversion. We typically recommend clicking the task bar. Another option is minimizing and maximizing the application manually or by pressing Win+D twice. Many of our users use the caps lock key in place of the shift key. I'm not sure how effective it has been but we are instructing users to use the shift key, especially when entering credentials.

I have Windows Server 2019 Standard installed on Vmware Vsphere 6.7. I have activated the License of the Server & joined the server to the domain controller. After that I have tried to Install Remote Desktop Terminal Services . I am getting the below error.

2) On the normal DPI screen, full screen. Displays at the full resolution for the monitor hardware (1920x1080) everything is the correct size except the mouse pointer is TINY. What's worse, the vertical I-beam text cursor doesn't appear at all (I suspect because an I-beam bitmap for the cursor set that small doesn't exist). Editing any kind of text is unusable because you lose the mouse pointer when hovering over those areas.

1) On the high DPI screen, full screen. Displays at the full resolution, but with correct 200% scaling so everything looks as expected. One minor issue is that if that screen has a windows toolbar, "full" screen doesn't quite fit and we end up with scrollbars. This can be fixed by auto hiding or removing the task bar from that screen.

2) On the normal DPI screen, full screen. Displays at the full resolution for the monitor hardware (1920x1080) everything is the correct size but this time the mouse pointers are the expected "normal" size. Works completely as expected.

The RDP client has come a long way recently but still has a way to go until it properly supports the scenario as mentioned above. I haven't tried but believe that connecting to newer windows OSes is fine.

Just like in Windows 10 1803, Microsoft had some severe issues with RemoteApp, but replacing the mstsc.exe and mstscax.dll files, from a build prior to 1803, fixed the issue. This is also true in the Windows 10 1903 build.

According to Microsoft its not Windows 10 1903 that is the root cause, but instead several large and independent mouse manufacturers (Logitech, Razor, Steelseries, etc), that is the root cause. But using the same mouse on other Windows 10 versions, works perfectly... Also if replacing the mstsc.exe and mstscax.dll in the 1903 build, using the files from 1809, works with the high-end mouses.

We have windows 2012 R2, with RDWeb. on the RD Session Client Settings, if I enable to option of Drive redirection, and if I try to open My Computer from the published app in browser, the application hangs and then eventually I have to restart the server, as cannot end or terminate the application even through powershell/cmd, get Access Denied.

A remote code execution vulnerability exists in Windows Remote Desktop Gateway (RD Gateway) when an unauthenticated attacker connects to the target system using RDP and sends specially crafted requests. This vulnerability is pre-authentication and requires no user interaction. An attacker who successfully exploited this vulnerability could execute arbitrary code on the target system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Detailed Overview: I'm running Server 2012 R2 and we have 30 users. A majority of the users have local printers connected via USB. Printer redirection has been working successfully for these users for over 2 years, up until Monday 5/14/18. I started receiving calls from multiple users, stating they cannot print in remote desktop.

I updated the local printer drivers on the user side, as well as on the server to match. The printer works perfectly for a few hours. Then I receive calls from these users that their printer is no longer working. No print errors in the remote desktop session, in fact it acts like it sent the print job. If I have them perform a test print locally, the printer works fine, have them test print through RDS, the print job isn't sent to the printer. I see it flash in the print queue briefly on the RDS side.

(2) Rebooting the server will force all users off, as a result once they log back in, everyone is able to print for 2 hours or so before it stops working. Network share printers are not impacted by this issue.

I am new to RDS and I am thinking of having RDS Web Access and RDS Gateway both sitting in my DMZ. I am however not aware if i want those servers domain joined or not. I do not know if they need to be for RDS and being part of the farm.

i hop you are good, i want to present you the alternative of RDCMAN, the RDC-ON that i created when Microsoft removed RDCMAN for vulnerability, this tool is very secure, easy to use, and propose more functions that RDCMAN, of corse free.

in the Session Host Server (Session Collection Timeout Idle time) not getting updatd in the registry in the server also the Application hosted opens multiple sessions due to this) is the best approcah is to manage the settings by group policy or by reapplying the settings related to the collection,

I've installed the MSI, the GPO administrative templates and it looks OK. The thing is that my users are still at home using Zoom directly from their computer. When part of the staff return to work with their Dell-Wyse thinclient, they'll probably ask me for an USB camera. Will my RDSH servers cop with the load ..?

FAQ

1. Customers are reporting that the file version of CREDSSP.DLL is reverting back to 10.0.14393.0 after installing monthly cumulative updates and whether the new updates contain the CredSSP hardening change introduced in 3B kB 4088787. Why is this occurring?

A1: The updated binary for CredSSP hardening occurs in tspkg.dll, NOT credssp.dll, The table below lists the version of credssip.dll installed by fixes released between March and June.

All packages contain the same binary contents cressp.dll file as March 2018 "3B" KB 4088787 but the file version for CREDSSP is reverting back to the RTM version in some monthly updates. This is a minor annoyance. Specifically, the file version inconsistency may trigger some security vulnerability scanners that check for binary versions and flag systems as vulnerable if the binary is not updated, even though the contents of the credssp.dll file are the same.

For this reason, the "File changes" section of KB 4093492 was updated with the following text:

I've got a small "lab environment" with two 2019-servers and one laptop at home.

One of the servers works just as intended, and I'm allowed to RDP in to it from whatever I want to using the user account I want to. (If it matters, I've also verified that users that shouldn't be allowed to RDP can't do so.)

On the other server things don't act as I want...

I can RDP into it from non-domain computer (for instance my work computer which is member of another domain) using the administrator account, but using the account created for this purpose won't work - I'm getting a bad credentials error..

Using the same user from either the domain-joined laptop or from the other server, the user can get in just fine.

(Yes, I've tried hundreds of times from different computers, both in the network, through VPN and through WAN with port forwarding to that server. I am 100% sure the password is correct.)

Any ideas what this could be? I've also tried to add the domain\user to "allow log on through remote desktop services" in the default GPO, and I've added this user to the list of users allowed to RDP into the server (and yes, I know this isn't usual - it's just something I've tried in order to get through the problem...)

3a8082e126