Hello World, 

If you are following us since a long time, you probably know that we have been writing about RDS (remote desktop Services) infrastructure.  RDS provides a lot of possibility and certainly helps organizations to consolidate their infrastructure.  Recently, we have been called to fix a “small” issue with a RDS infrastructure used to deliver RemoteApp applications.  As soon as we saw the error message, we understand immediately what the problem was (as the problem/issue was already discovered some time ago..)

So, let go through this quick post…. 

Situation

So, basically, the customer was running the RDS infrastructure and was delivering applications the RemoteApps configuration.  Users would connect to a web site and select the application they would need to work on.  The infrastructure is running on Windows 2012 R2 machines and suddently the service was not available anymore.  The error was not affecting all the users, the behavior looked random.  The following message error was thrown when the user tried to start the remoteapp from the web interface 

Click on Picture for better Resolution

The error message was : An authentication error occured.  This could be due to CredSSP encryption Oracle remediation. for more information, see link….

Explanation 

The problem/issue encountered here is due to the fact that a patch was deployed through the infrastructure but apparently something went wrong and only a subset of the infrastructure got the updates and the other one not.  You can find more information about the patch, the issue and the possible remediation here.So, on machines where the patch has been installed, connection to the RDS infrastructure (which was not patched) was blocked and the quite explanatory message was shown to the users…  

So, lnow that we have identified the issue, it’s time to see how we can restore the remoteapp functionality….. 

The Solution 

To fix this situation, multiple options are made available.  The best option would be to patch the infrastructure accordingly.  The patch needs a reboot and in a production environment it might not be always possible to apply patches and updates as quickly as possible.  Hopefully, the update comes with some possible mitigation options. In our specific scenario, most the Windows clients were patched and were trying to perform a connection to a RDS infrastructure which was not patched… So the easiest solution here was to create a GPO and apply them to the Windows Client settings. 

On a system where the patch has been applied, open the GPMC console, create a new GPO and navigate to Computer Settings > Administrative Templates > System >Credentials Delegation.  If the system has been patched; you can see the option Encryption Oracle Remediation option

Click on Picture for better Resolution

Double-click the option and you can see the settings that can be configured…

Click on Picture for better Resolution

Based on the screenshot above, you can see that Microsoft offers you three options 

• Force Updated Clients –  If you select this option, client and servers needs to have the patch installed in order to perform the CredSSP connection.  If one of them is not patched, the fallback to an insecure connection will not work 
• Mitigated – If servers are unpatched, the connection can still go through from clients that have been patched providing a temporary solution and have functionality back
• Vulnerable – This option will ensure that unpatched client will be able to perform the connections where fallback to insecure versions is allowed which can expose the servers to attacks

The option that have been selected was the mitigated one and we have been able to restore the RemoteApp functionality and people were finally able to connection to their application.   This was obviously a temporary situation and after 2 weeks the infra was fully patched and business as usual returned back… 

Final Notes 

This is it for this post ! Patching cycle and procedures within an organization is really important as we have discovered in this scenario.  The situation described above was generated by the fact that the patching cycle for workstations is different than the one for the servers infrastructure.  Moreover, we discovered that not regular updates mechanism was implemented.  A long delay existed between the release of a patch and the rollout through the organization.   Quality assurance was also missing as nobody is following up on patches and nobody test them in a stating infrastructure to see any possible side effects.  

With this information, the IT Department has started putting a plan together and are working in improving the process of patching their infrastructure…. So, this small issue is having a positive effect after all 

This is it for today 

Till next time 

See ya