Answered by:
Remote Desktop Authentication Error Has Occurred. The function requested is not supported.

Question
-
Since the Microsoft Security Patch on Tuesday, we've received many reports of users having connection problems like this:
An authentication error has occurred. The function requested is not supported Remote computer: <computer name=""> This could be due to CredSSP encryption oracle remediation. For more information, see https:/go.microsoft.com/fwlink/?linkid=866660
The error impacts:
- Remote Desktop Connection
- Remote Desktop Connecting to Azure VMs
- VPN Network Connections (before one can even try to use Remote Desktop)
This is quite a mess and seems to be related to the security patch increasing security requirements, but not implementing the change to give the machine the increased security levels. The latter doesn't seem to occur if the machine has automated Windows Updates turned off.
Unfortunately, Windows Update can't be automated in many environments such as development, build, test, staging and production without creating other problems.
Wrote a blog post about our findings so far with a workaround on how to reduce Remote Desktop security settings to get around this problem. It doesn't require touching registry settings or other complicated steps:
Remote Desktop Authentication Error Has Occurred. The function requested is not supported. CredSSP
Would appreciate any insight on handling this across an enterprise without manually modifying the connecting and host machines.
A common scenario is a person working from home not being able to connect to their own computer in the office or a VM.
Thanks.
Luke Chung
Microsoft MVP
President of FMS, Inc.
Blog Facebook Twitter- Edited by LukeChungMVP Saturday, May 12, 2018 12:08 PM
Answers
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable à Apply
Thanks and Regards,
Regu
- Proposed as answer by vor0nwe Wednesday, May 16, 2018 10:22 AM
- Marked as answer by LukeChungMVP Thursday, May 24, 2018 6:29 PM
All replies
-
-
-
Thank you for sharing.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
Have this issue as well in our environment. Typical untested patch that makes a headache for large groups of people. Very irresponsible of the patch team.
Remove the tick from the "Allow connections only from computers running Remote Desktop with Network Level Authentication" got us working again
Windows Desktop Client to Server 2012 R2
- Proposed as answer by thomfl Wednesday, May 30, 2018 4:23 PM
-
Or you can just uninstall update KB4103725
https://support.microsoft.com/bg-bg/help/4103725/windows-81-update-kb4103725
worked for me
- Proposed as answer by Viktor L. Takacs Tuesday, June 5, 2018 8:52 AM
-
Thanks for sharing..
it works with me after following this instruction https://blogs.technet.microsoft.com/mckittrick/unable-to-rdp-to-virtual-machine-credssp-encryption-oracle-remediation/
we have big headache after KB4103725 patched get installed on clients win8. so should i update the kb4103725 on RDP host server 2012 r2 as well or wait for any further security kb?
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable à Apply
Thanks and Regards,
Regu
- Proposed as answer by vor0nwe Wednesday, May 16, 2018 10:22 AM
- Marked as answer by LukeChungMVP Thursday, May 24, 2018 6:29 PM
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable àApply
Thanks and Regards,
Regu
- Proposed as answer by RedITAdmin Friday, May 18, 2018 2:47 PM
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable à Apply
Thanks and Regards,
Regu
This fixed it for me, thank you!
Windows 10 Pro --> Logging into a Windows server 2012 R2 on a domain
- Proposed as answer by Seth Weisblatt Thursday, May 17, 2018 4:15 PM
-
- Proposed as answer by techguest Tuesday, September 4, 2018 4:34 PM
-
You need to make sure both your workstations and servers are patched with the March CredSSP patch. On May Patch Tuesday, Microsoft released a patch that basically enforces the March patch, so if your workstation got the May patch but you're trying to connect to servers that haven't received the March patch, you'll get this error.
As a workaround, you can push a Group Policy out or edit a registry key locally, but neither one of those is considered a long-term permanent solution.
You can read - How to Fix Authentication Error Function Not Supported CredSSP Error RDP for more information on the Group Policy and registry key.
For the Group Policy, you'll need the ADMX files from a patched server. In the article above, there's a link to those files from a patched Windows 2012 R2 server which should work.
Policy path: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation Setting name: Encryption Oracle Remediation
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002- Proposed as answer by Waterman981 Monday, May 14, 2018 9:12 PM
-
Are those instructions for end users or administrators?
Most users can't change registry settings on their own, much less the HKLM hive.
They can change the check box on the Remote Desktop dialog.
If it's a setting on the network that's changed, will that support people's home PCs and devices they use to remote into their office PC?
Luke Chung
Microsoft MVP
President of FMS, Inc.
Blog Facebook Twitter
- Edited by LukeChungMVP Monday, May 14, 2018 4:41 PM
-
Hi and thanks for your observations.
Don't you think its ironic that the security patch enforced on us poor sods forces one to operate in a less secure manner and the eta of the patch for the patch is unknown. Thanks again Microsoft, you bunch of gimps.
KillerWombat
-
-
-
-
-
Hi Luke,
Regu Sankar's solution using gpedit.msc is not the same as your solution for the following reason:
I was able to use gpedit.msc on my local client (which fixed the issue), whereas I was NOT able to open the system properties on the server, because that's a VM running in Azure.
To change the server's system properties, I would need to connect to that machine via Remote Desktop. See the problem?
- Edited by vor0nwe Wednesday, May 16, 2018 10:35 AM
-
Thank you for this article, Luke.
In my user's case, the issue was resolved by updating Windows 10 to the most current version (16299.431 as of today, May 16th, 2018). The machine was missing 2018-05 Cumulative Security Update 1709 - KB4103727. My own Windows 10 box was able to connect to the RDP computer without issue, which helped to lead me in the direction of checking revisions. Being more current, my machine had no problem connecting to the RDP machine. I did not want to reduce the security by unchecking the box for Network Level Authentication, so I was glad that Windows updates fixed this.
Best regards,
Philip Schember
Senior IT Technician
University of Tennessee -
-
-
This worked for me.
I installed the Windows 10 "Upgrade" to the latest version, which shows to be Version 1709, build 16299.431. After that update completed, I received this authentication error. Using the Fix first posted by Regu Sankar, it worked immediately.
So thank you, Regu!
-
Hi All,
I just provisioned a Windows Server 2012 R2 server in Azure. Everything has installed properly. I can see the boot screen. I cannot RDP to the newly provisioned server from a Windows 7 Enterprise RDP Client.
It is not showing the CredSSP part of the message.
Thanks,Ken
-
My ability to remote in stopped this week when the update caused the error you mentioned in the original post. My Remote settings were actually already set the way that you suggested - I checked that first per your suggestion.
I wanted you to know that the fix that worked for me was going into gpedit.msc as suggested by Regu. I was one of those employees/end users who needed to remote in from home, and as you mentioned, I wasn't sure I'd have the permissions to go in there, but it turns out that I did.
Thank you for starting this discussion because in it I found a solution to my issue. I hope my feedback helps you or someone else.
-
It works for me.
Windows 7 connecting to Windows Server 2016 error.
Solution:
In the server you are connecting(in my case winserver 2016) uncheck the "Allow Connections only from computers running Remote Desktop with Network level Authentication(recommended)".
<img alt="System Properies -> Remote tab -> Uncheck" src="http://blog.fmsinc.com/wp-content/uploads/2018/05/remote-windows10.png" />
-
OK!
I think I have fixed the issue for me, so let me tell you what I did as it may help others.
Seeing that 'windows update KB4103725' was a bad release and it was released on the 5/8/18. None of the advice I found worked.
1) Change:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002
(isn't there in windows 7)
2) Remove:
Remove the tick from the "Allow connections only from computers running Remote Desktop with Network Level Authentication"
(isn't there in windows 7)
3) Delete:
Delete windows update 'KB4103725'
(isn't there in windows 7)
4) Click the tick:
Click the tick from the "Allow connections from computers running any version of Remote Desktop"
(as shown at:
http://blog.fmsinc.com/remote-desktop-authentication-error-function-requested-is-not-supported-credssp/
,but isn't there on my windows 7)
Finally I saw a windows update 'KB4103718' which was installed on my computer on 5/9/18. As it looked similar to 'KB4103725', I deleted it and restarted my computer. I could then connect! -
-
-
-
-
-
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable à Apply
Thanks and Regards,
Regu
-
-
This worked for me (Windows 10 Pro).
Thanks a lot "Ragu Sankar".
- Edited by Eddie.Kumar Sunday, May 20, 2018 8:01 PM
-
-
I've updated my blog post with the information shared here about editing Group Policy and setting it to Vulnerable. It's an option if you can't modify the target PC/VM, and have administrator rights to your PC.
The update includes screenshots and step-by-step instructions for doing so:
Sorry to see there are still so many people suffering from this problem in the second week. Hope it helps.
Luke Chung
Microsoft MVP
President of FMS, Inc.
Blog Facebook Twitter
- Edited by LukeChungMVP Monday, May 21, 2018 8:03 PM
-
Thanks
This worked for me..
"Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection levelàVulnerable à Apply
Thanks and Regards,
Regu"
- Edited by VaGangal Monday, May 21, 2018 6:45 PM
-
-
-
-
-
-
-
-
Hiu Guys.
Thanks you for share this info.
It worked for me.
Client Win7/10 to connect Win Srv 2012/2012R2.
Have a Niece Day.
"Here is the FIX for this issue ..--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection levelàVulnerable à Apply "
- Edited by carlyML587 Friday, May 25, 2018 9:21 PM
-
-
Guys, when specifying fixes, please clearly state if the specific fixes/workarounds pertain to the client or the server. My understanding is that unchecking NLA pertains to the server, not the client.
I'm assuming that the 5/16 update pertains to the client, since it was mentioned to be a Win10 patch, not the server, correct?
A consultant can't RDP into our servers which may be behind in patches, but have NLA disabled throgh local GPO.
I am unable to reproduce the problem but my personal Win10 desktop is fully patched and on build 1803.
My laptop was on build 1709 and not yet having patches from 5/8 but after fully patching it, it will be on build 1803. Our corporate Win10 workstations are managed by SCCM. I suspect they are still on build 1709 and have received the 8/5 patch, so my tests are probably not exact to reproduce the problem.But with all these discussions/comments, many are lacking Win10 builds involved and if the recommended changes are to be applied to client or server.
-
-
-
Have this issue as well in our environment. Typical untested patch that makes a headache for large groups of people. Very irresponsible of the patch team.
Remove the tick from the "Allow connections only from computers running Remote Desktop with Network Level Authentication" got us working again
Windows Desktop Client to Server 2012 R2
- Edited by MRR111 Tuesday, May 29, 2018 3:07 AM
-
-
use this link:
https://gallery.technet.microsoft.com/Remote-desktop-authenticati-a9f4b9f8
- Proposed as answer by NICOLA FER Thursday, June 7, 2018 1:05 AM
-
Thank you. This solution worked for me. Hopefully, Microsoft will fix this patch soon.
- Proposed as answer by ALICE FONTINE Saturday, June 9, 2018 4:45 AM
-
-
-
-
-
Or you can just uninstall update KB4103725
https://support.microsoft.com/bg-bg/help/4103725/windows-81-update-kb4103725
worked for me
This is the best and safest fix suggested so far, not compromising security like the other suggestions.
And it works.
Thank you.
-
Hi and thanks for your observations.
Don't you think its ironic that the security patch enforced on us poor sods forces one to operate in a less secure manner and the eta of the patch for the patch is unknown. Thanks again Microsoft, you bunch of gimps.
KillerWombat
-
-
-
-
Here is the FIX for this issue ..
--> Change the Group Policy on your local client to use the vulnerable setting
Run: gpedit.msc
Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Open - Encryption Oracle Remediation à choose Enable à change protection level àVulnerable à Apply
Thanks and Regards,
Regu
-
-
-
You dont necessarily have to RDP to remote machine when you can manage it using other methods (Powershell/Remote registry) to name a few.
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2
-
Thanks
- Proposed as answer by Siddharth Chaudhary Wednesday, June 13, 2018 11:52 PM
-
-
-
-
You should take into account that by applying your workaround, you're putting at risk the source and destination computer for the RDP connection.
Microsoft suggests applying the pertinent Security Patch in both ends.
There's an article from Microsoft for all the scenarios:
CredSSP encryption oracle remediation
Regards.
- Edited by fedayn2 Thursday, June 21, 2018 9:56 AM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
I ended up going in and running the Security Only updates for all of my Server 2012 R2 hosts and VMs.
Now RDP from my Windows 7 Pro PC is connecting to them all normally without any workarounds or decreased security.
The weird thing to me is that this started happening outside of any Windows Updates. In fact, it was almost dead in the middle of my standard patch cycle. So I don't even know if it started with something about my Windows 7 install or something about the Server 2012 R2 installs. I'm guessing it's the Windows 7 installs because I hadn't patched the servers in a while because of fear of this exact thing happening.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
In my opinion, Microsoft fixed something that wasn't working before. In many environments, you don't want anyone to be able to remote into a server without network authentication, even if they don't have domain admin security permissions on the server. A simple check mark in remote settings on servers that are going to be accessed by non domain admins seems much better to me than anyone able to remote into one of the companies critical servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Have this issue as well in our environment. Typical untested patch that makes a headache for large groups of people. Very irresponsible of the patch team.
Remove the tick from the "Allow connections only from computers running Remote Desktop with Network Level Authentication" got us working again
Windows Desktop Client to Server 2012 R2
Thank you. Such an easy fix, but worked for me. -
-
Hello. I have Windows 7 Home Premium, and since the 8th May 2018 Update I can't login via Remote Desktop. I tried several things, including unistalling all updates until that day. I managed to install gpedit even if I am home premium, but of this: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation, I haven't "Credentials Delegation", and I am a no point.
Also, with regedit, of this path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters I haven't CredSSP.
Someone can help me? It's absurd. Thanks!
- Edited by Emanuele Salvatore Tuesday, February 26, 2019 7:35 PM more info
-
Hi,
Similar to this I have faced a problem to login the hyper-v server. The error shows like this.
The problem caused after promoting a new domain controller by removing old domain controller which was exceeded the tombstone lifetime. Please advice.
Note: we cannot log to the server hence the error appears saying "Trust relationship between this workstation and the primary domain failed"
- Edited by Aravinda Napagoda Wednesday, March 13, 2019 4:49 AM edited
-
-
-
-
-