Hello World,
In the previous post, we have describe a small issue that user can encounter when using mstsc.exe and switches tool in the wrong way. In this post, a end user and an administrator can be blocked in their attempt to use the Remote Desktop Services technology if you security guys have hardened too much your servers and workstations.
Let’s quickly explain the problem and the quick fix to such situation…..
The Problem
We have been deploying 2012 R2 RDS infrastructure and some of the administrators need time to time to perform Remote Desktop Connection to other servers for administration purposes. The user with administrative rights was trying to perform a remote desktop connection from a Windows 2012 server and it failed with the following error message
Account restrictions are preventing this user from signing in. For example, blank Passwords are not allowed, sign-in times are limited or a policy restriction has been enforced.
Click on Picture for Better Resolution
If you have deployed Windows 8 (or later) in your infrastructure, end users accessing the RemoteApp infrastructure might also end up with the same situation.
As a first debug steps, the user had checked that
- password was not blank
- password was not expired or locked out
- rights to access remotely servers was granted
Everything was OK and still it was not able to connect to the server…What’s was happening ?
The Solution
Basically, there is a new Group policy settings that can prevent a system to pass credentials to a remote server. This was exactly the issue. As I said, our security team (more focused on blocking access to system than helping us in providing good service to our customers) decided without discussing with us to apply this new group policy settings.
As you can see in the screenshot below, there is indeed a new settings available since Windows 8/Windows 2012 and later called “Restrict delegation of Credentials to remote Servers”.
Click on Picture for Better Resolution
When this setting is enabled on the machine from which you are trying to launch the remote desktop client (and not on the target remote server), you will receive the error message we have seen above.
So, if you encounter such message and you are using recent operating system, you can be sure that your security team has been messing around with this new GPO.
Final Notes
Implementing new group policies without testing and coordinating between teams can have an important impact on your infrastructure. In our case, we had users not being able to connect to the RemoteApp infrastructure because of this Group policy setting. As we are working in a large and distributed environment, it took us about 5 hours to revert back to a normal situation.
We were not happy with this change…
Now, you know as well. so, if you ever got this kind of error message, you know what to do (disable this gpo and you should be good to go !)
Till next time
See ya
The point of this group policy setting is to use Kerberos authentication instead of NTLM. This is a useful group policy object assuming that the source computer is Windows 8.1+ and the server is Windows 2012 R2+. You would not have received this message, and a hash of your password would not have been left on the server that you were remoting to. As a network security admin, I feel like this blog post is pretty useless in making an actual point besides “some team broke it and I never took the time to understand why something like this would be important”. Just my two cents.
Hello Chris,
Thank you for your visit and your comments.
maybe some clarifications about rdp and restricted admin mode and your comments
-If you use RDP and Network level authentication, you can already use kerberos authentication instead of NTLM (with no use of Restricted Admin Mode)
-Restricted Admin mode is designed to help protecting Admin accounts by ensuring that Admin credentials (or hash) are not stored on the target machine -> this feature does not work for normal user accounts
– You stated that this approach would be more secure because no hash present on the machine but studies have shown that this feature is not really helpful as pass-the hash attack is still possible (see https://labs.portcullis.co.uk/blog/new-restricted-admin-feature-of-rdp-8-1-allows-pass-the-hash/)
Reading the post again, I have noticed that we are speaking about admin users and also normal end-users. Our security team only took into account the admin aspect and implemented a security feature with no coordination of the system owner and with not understanding fully the in and out of enabling this feature on all systems. Moreover, our security team implemented half of the solution (server side was not configured) -> meaning nobody was capable of working anymore
We think that this post is useful as it provides hints on where to look if security settings are implemented in the wrong way. We think that coordination between teams provide better results. That’s the all point of this post. It seems that there is a disconnect between Security team and system owners and your comments has simply confirmed that…. each teams should speak to each other and implement the best solution
Till next time
see ya
See ya
I have had the same issue with that.
I do remember creating a GPO for the CREDSSP issue but I think that this has caused the issue where it has basicly stopped the RDP Sessions from authenticating,
A way around that was to remove the GPO that was in place and go GPUPDATE /FORCE.
After this things came back to normal.
I will also point out that when this gpo was in use i could not access any file services on the server that had it and also no other server for that matter. Once I removed it it was like a sweet victory dance
I read the comment by someone about this post not being really useful: in my case, where a team implemented blanket changes on Windows 2016 servers with a “hardening policy” which included the remote credential guard setting, this posting was key to figuring out the RDP issues that came up. (We had the same generic and not very useful error when trying to connect from a Windows 2016 jump host to a Windows 2012 R2 DC, where the policy was applied to the jump host thus preventing an RDP connection to the DC.)
I found another article that allowed me to easily test this where I set a registry setting on the remote system, the domain controller, and then could connect via RDP.
So, my summary would be similar to the one in this post: you cannot just implement security settings at will without properly vetting them for their potential effects. In our case, either pushing out the registry change to all DC’s or disabling the remote credential guard is the answer, indicating a half-implemented solution in our case. I definitely *want* the remote credential guard for it’s benefit to overall security, but it will require more than just simply enabling a policy setting in an environment with different OS versions running.
Thanks for the post!
And I also just read another comment left by someone mentioning a similar issue with CredSSP, which I also ran into. Almost the same scenario, except with CredSSP it also involves patching (of lack thereof in some cases). I also found in this case that a registry setting could be made to work around the problem of mis-matched patches and policy settings. The CredSSP issue really just required getting all systems up-to-date with the latest CredSSP patch.
@Rob Ingenthron,
Nowadays security settings and hardening system is really important and I think that all sysadmin understand that. However, as mentioned in this post/comment, I think that the security people needs to work in collaboration with the sysadmin in order to implement a full working solution and not as you said half config or simply breaking user capabilities. This is missing in so many projects that avoidable downtime could be avoid…
Till next time
See ya