An authentication error has occurred 0x607

При подключении к терминальным фермам, RemoteApp или подключении по RDP к Windows машинам, иногда можно столкнуться с проблемой: Ошибка при проверке подлинности 0x607 (Authentication Error has Occurred (Code: 0x607)). Эта ошибка говорит о том, что существует проблема с сертификатом, который используется при подключении по протокому RDP. Если подключение выполняется к обычной, рядовой Windows машине, то скорее всего эта проблема связана с доверием к сертификату на этой машине. Если эта ошибка появилась при подключении к терминальной ферме, то проблема с сертификатом, уровнем доверия к нему или используемым именам, может быть на уровне сертификата роли Gateway, Connection Broker или SessionHost. Проблема с доверием к сертификату может быть вызвана следующими причинами:

1. Клиентская машина не доверяет вашему сертификату сервера
Вариант решения: Заменить сертификат на доверенный, либо установить на клиентский компьютер цепочку сертификатов центров сертификации, которые выдали сертификат для терминального сервера (Root CA и intermediate CA )

2. Клиентская машина не может проверить список отозванных сертификатов (certificate revocation list, CRL) выдающего центра сертификации.
Вариант решения: С клиентской машины проверить доступность списка отозванных сертификатов. Если этот список недоступен, обеспечить его доступность, либо перевыпустить сертификат, у которого указан корректный и доступный для клиентской машины адрес CRL.

3. При доступе к терминальному серверу через Gateway, имя или домен сервера указанные в сертификате не соответствует реальному имени или домену сервера с ролью Session Host)
Вариант решения: установить на серверы Session Host сертификат соответствующий имени сервера и его домену.

Для проверки и замены используемого сертификата службы терминалов (Terminal Services), можно воспользоваться статьей: TS: Проверка и ручная замена сертификата службы терминалов

Источник

Remove From My Forums

Question
I’ve set up an RDS 2012 R2 host farm, but have problems.

When I try to log on from an outside client, then I get this error…

«An authentication error has occurred (Code: 0x607)»

I’ve tried google it, but without any result.

Any idea how to fix this?
- Changed type
  
  Wednesday, May 7, 2014 1:18 AM
- Changed type
  Dharmesh SMicrosoft employee
  Wednesday, May 7, 2014 6:58 AM

Answers

I opened a case with MS.

They changed CAP and RAP to default values and lowered the collection security to low.

Things works fine now.
- Marked as answer by
  Dharmesh SMicrosoft employee
  Wednesday, May 7, 2014 6:59 AM

Источник

Содержание

User Manual
An authentication error has occurred 0x607
Answered by:
Question
Answers
All replies
RDS 2012 R2: An authentication error has occurred (Code: 0x607)
4 Answers 4
An authentication error has occurred 0x607
Answered by:
Question
Answers
All replies

User Manual

Источник

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’ve set up an RDS 2012 R2 host farm, but have problems.

When I try to log on from an outside client, then I get this error.

«An authentication error has occurred (Code: 0x607)»

I’ve tried google it, but without any result.

Any idea how to fix this?

Changed type Dharmesh S Microsoft employee Wednesday, May 7, 2014 1:18 AM
Changed type Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:58 AM

Answers

I opened a case with MS.

They changed CAP and RAP to default values and lowered the collection security to low.

Things works fine now.

Marked as answer by Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:59 AM

Please describe your current configuration in more detail.

1. What version of mstsc.exe are you using on the client PCs?

2. How many servers do you have, and what RDS Role Services and other Roles (like DC) are installed on each?

3. What type of certificate do you have, and how have you configured it?

4. What steps/changes have you performed in an attempt to troubleshoot this error?

5. Are you able to connect using Android, iOS, or Mac OSX Remote Desktop app?

Thank you for posting in Windows Server Forum.

Firstly please try to provide TP’s answer, and in addition to that let us know.
Which different ports you have enabled from your firewall?
Are you trying to access through RD Web access or remote desktop from outside?

You must have properly configured roles, ports, and certificates to connect from outside environment.

Do you have any update regarding your case? Can you let us know the present situation?

I opened a case with MS.

They changed CAP and RAP to default values and lowered the collection security to low.

Things works fine now.

Marked as answer by Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:59 AM

Glad to hear that you got it working.

Thank you for sharing your experience here. It will be very beneficial for other community members who have similar questions.

If you want any more solution in future, kindly place your post in Forum.

That is really not a solution since you are reducing encryption, however, if you are happy with it then great.

If it were me paying support I would insist on a real solution that allowed RDS to operate as it should without workarounds like reducing security or else I would want a refund. There is no reason why you should need to set the security level to low when using modern client devices.

If you would like my assistance solving the issue for real please let me know.

Edited by TP [] MVP Wednesday, May 7, 2014 7:14 AM

Hi TP, I have this exact problem and I would like to resolve it properly without reducing security. I would very much like your help if still available.

I contacted Support about this. They fixed it instantly, typical. They went onto my second session host server that is not authenticating properly and removed a particular registry key. They said it was a known issue.

ISSUE : Users unable to connect externally when session lands on session host 2 , it gives error 0x607

RESOLUTION : HKLM/SYSTEM/currentcontrolset/control/terminalserver/winstations/RDP-TCP , removed SSLbinding

Hope this helps someone else..

The reason this happens and partly why the solution was to change values or delete keys is probably something along these lines. When I followed Loin75’s suggestion of deleting a key

» ISSUE : Users unable to connect externally when session lands on session host 2 , it gives error 0x607

RESOLUTION : HKLM/SYSTEM/currentcontrolset/control/terminalserver/winstations/RDP-TCP , removed SSLBinding»

I took a look at the key that was being deleted since I was having a user with the same issue. The SSL binding that is attached to the registry is a SHA-1 binding. As we have seen of late, SHA-1’s are now being rejected by modern Web Browsers so when a user uses Google Chrome or Mozilla Firefox for instance, that web browser using the web feed hits the server that has the SHA-1 registry entry and you end up with the authentication error. We have SHA-2 certs for our site so I am wondering if this is something that Microsoft does when setting up the host farm. This seems like a more logical conclusion then it is a known issue.

Источник

RDS 2012 R2: An authentication error has occurred (Code: 0x607)

I’ve set up an RDS 2012 R2 host farm, but have problems.

When I try to log on from an outside client, then I get this error.

«An authentication error has occurred (Code: 0x607)»

I’ve tried google it, but without any result.

Any idea how to fix this?

4 Answers 4

This seems to have something to do with Certificates.

Make sure your RDS certificate is trusted on the remote host
Make sure you use the correct name to connect to the machine

If you have a self-signed certificate, this is what I found:

This is what I did to get RD session hosts bugged with 0x607 to work:

removed RD session host from collection,
deleted certificates from computer personal store on RD session host (this was plausible in my scenario),
removed RD session host role,
redeployed RD session host role from central RD administration.

This created a fresh self signed SSL certificate for internal RD session host FQDN and assigned it to RDP-tcp. Interestingly, that certificate doesn’t even appear in RD session host personal certificate store.

See this TechNet thread for more information.

Another possibility (mentioned in the same thread) is to lower your security settings (not advised for a production environment though):

Edit the session collection properties and in » security » change » Encryption level » to low . and save session collection. And try to access that session collection from win 8 or win7 sp1, voila, it solves issue except one warning.

Источник

An authentication error has occurred 0x607

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’ve set up an RDS 2012 R2 host farm, but have problems.

When I try to log on from an outside client, then I get this error.

«An authentication error has occurred (Code: 0x607)»

I’ve tried google it, but without any result.

Any idea how to fix this?

Changed type Dharmesh S Microsoft employee Wednesday, May 7, 2014 1:18 AM
Changed type Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:58 AM

Answers

I opened a case with MS.

They changed CAP and RAP to default values and lowered the collection security to low.

Things works fine now.

Marked as answer by Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:59 AM

Please describe your current configuration in more detail.

1. What version of mstsc.exe are you using on the client PCs?

2. How many servers do you have, and what RDS Role Services and other Roles (like DC) are installed on each?

3. What type of certificate do you have, and how have you configured it?

4. What steps/changes have you performed in an attempt to troubleshoot this error?

5. Are you able to connect using Android, iOS, or Mac OSX Remote Desktop app?

Thank you for posting in Windows Server Forum.

You must have properly configured roles, ports, and certificates to connect from outside environment.

Do you have any update regarding your case? Can you let us know the present situation?

I opened a case with MS.

They changed CAP and RAP to default values and lowered the collection security to low.

Things works fine now.

Marked as answer by Dharmesh S Microsoft employee Wednesday, May 7, 2014 6:59 AM

Glad to hear that you got it working.

Thank you for sharing your experience here. It will be very beneficial for other community members who have similar questions.

If you want any more solution in future, kindly place your post in Forum.

That is really not a solution since you are reducing encryption, however, if you are happy with it then great.

If you would like my assistance solving the issue for real please let me know.

Edited by TP [] MVP Wednesday, May 7, 2014 7:14 AM

Hi TP, I have this exact problem and I would like to resolve it properly without reducing security. I would very much like your help if still available.

ISSUE : Users unable to connect externally when session lands on session host 2 , it gives error 0x607

RESOLUTION : HKLM/SYSTEM/currentcontrolset/control/terminalserver/winstations/RDP-TCP , removed SSLbinding

Hope this helps someone else..

The reason this happens and partly why the solution was to change values or delete keys is probably something along these lines. When I followed Loin75’s suggestion of deleting a key

» ISSUE : Users unable to connect externally when session lands on session host 2 , it gives error 0x607

RESOLUTION : HKLM/SYSTEM/currentcontrolset/control/terminalserver/winstations/RDP-TCP , removed SSLBinding»

Источник

I’ve set up an RDS 2012 R2 host farm, but have problems.

When I try to log on from an outside client, then I get this error…

«An authentication error has occurred (Code: 0x607)»

I’ve tried google it, but without any result.

Any idea how to fix this?

asked Apr 27, 2014 at 6:56

This seems to have something to do with Certificates.

Make sure your RDS certificate is trusted on the remote host
Make sure you use the correct name to connect to the machine

If you have a self-signed certificate, this is what I found:

This is what I did to get RD session hosts bugged with 0x607 to work:

removed RD session host from collection,

deleted certificates from computer personal store on RD session host (this was plausible in my scenario),

removed RD session host role,

redeployed RD session host role from central RD administration.

This created a fresh self signed SSL certificate for internal RD
session host FQDN and assigned it to RDP-tcp. Interestingly, that
certificate doesn’t even appear in RD session host personal
certificate store…

See this TechNet thread for more information.

Another possibility (mentioned in the same thread) is to lower your security settings (not advised for a production environment though):

Edit the session collection properties and in «security» change
«Encryption level» to low. and save session collection. And try to
access that session collection from win 8 or win7 sp1, voila, it
solves issue except one warning.

answered Apr 27, 2014 at 7:12

MichelZMichelZ

11k4 gold badges31 silver badges59 bronze badges

I had the same nightmare with 0x607 and the above solution resolved the issue for me. I think the cause of the problem related to my having switched session hosts to different session collections and somehow the certs don’t update properly. Removing the session host from the collection and then remove the cert from the computer personal & remote desktop stores, restart and the certs are recreated and problem resolved.

I practically rebuilt the entire RDS farm over 4 days until I came across this, so frustrating!

answered Jun 14, 2014 at 16:12

After migrate an RDS Broker server to another WS2019,
I had the same error and I remove the registry key of the host session server as mentionned by sHolliday,

HKLM SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp
SSLCertificateSHA1Hash REG_DWORD

And it works again.

answered Oct 19, 2021 at 13:16

Источник

An authentication error has occurred (Code: 0x607)
Remote Computer: RDSHost.domain.local

A 0x607 error is caused by using an invalid security certificate for authentication. Certificate validation is picky, for good reason. While the error points to a failed certificate, it doesn’t share any information about which certificate failed or how it failed. I recently had a good bit of trouble weeding out the cause in new 2016 RDS build. I hope this saves someone a little trouble.

The Environment

It’s important to note that the domain had been around since 2000 (windows version, not build year) and it has hosted an RDP server since the beginning. When I first came on the scene there was a bare-metal 2008 server that was really having a tough time. I had replaced the previous server with a 2012 R2 deployment using a two server setup, both virtual machines. One server was setup as the gateway and the rest of the roles were on the other server. Pretty basic.

Fast forward to 2018. My 2012 R2 RDS deployment that was starting to struggle. My repair attempts had not been successful. Most of the issues only affected the management aspects, which I was able to work around, so I ignored the problems as long as I could. When it developed some performance problems that were affecting users negatively, I decided something had to be done. The fix for this new problem was a reboot. That is simple enough for a single workstations, but it becomes a big problem when it’s all of your users that get booted.

It didn’t help that it was unpredictable. A simple nightly reboot wasn’t enough. The problem could occur 1 hour or 1 day after the last reboot. After fighting with it for some time, I gave up on fixing it and moved toward building a clean deployment using the newest server edition. The old “time is money” philosophy.

The New 2016 Environment

Along with the new version, I had a few other improvements to incorporate as well. My intention was to add two more servers to the mix. The two extra servers would be session hosts. A few years of experience on our previous broker/host setup convinced me that separating the broker from the host makes more sense. Furthermore, 2 smaller hosts seemed less problematic from a user interruption perspective. With multiple hosts, I can service one host or even the broker, in limited capacity, without shutting out users during low traffic times.

The install process was pretty straight forward in 2016. Everything went according to plan with the install and deployment. Testing went great.

Then the Problems Started

Unfortunately, as soon as they started logging in from outside of the building, we started seeing the 0x607 error. At first, only one server had the issue, so I was able to by-pass the problem by disabling one of the hosts. Then, it started on the other, but not every time. With a little tracking I found that most of the time one 1-2 users were blocked each day. In most cases, temporarily disabling the server that any given user was having trouble with allowed them to connect to the other server. The intermittent occurrence drove me crazy.

This was a certificate error, so I went through the certificates and could not find any problems. There were only two certs involved. Both using the FQDN of our server, but they were issued by 2 different CA’s. The first was the self-signed cert generated by the deployment, located in the “Remote Desktop” folder of the certificate store. The second was the automatically generated cert from the domain CA, located in the “Personal” certificate store.

Just a Bit on RDS Deployments Since 2012

Microsoft made some pretty significant changes to the RDS environment with the 2012 release of Windows server. Previously, we had to configure every server role independently. The new approach is significantly faster and simplified for most deployments. Rather than individually configuring each server, you setup your deployment on a single machine through a wizard that pushes out the setup to the individual servers. The common settings are all relatively easy to find from server manager. More complicated or customized deployments will need to use PowerShell commands. My setup was very much a common setup.

About the Certs

Out of the box, the system is designed to use a third party SSL certificate to secure the user’s connection to the gateway server. Once through that layer, a domain CA cert is used to secure the connection to the broker. The broker then facilitates the connection to the session host using the host’s self-signed certificate. This is, of course, a over-simplification of the process, but diving into the multiple layers of security involved is outside of the scope of this problem.

The Foul Up

It took a lot of digging to find my problem and even more to find the cause. Remember, this is a clean install and, at first glance, there were no problems. My first impulse was to check the clients. This was a domain CA cert that was giving my grief, so I had thought it might be a client side issue. It was not.

I eventually found that the session hosts were using the cert from the domain CA instead of the built-in self-signed cert. You might be thinking, “Well that should work”, and it would if my broker is configure to use the domain cert. As it was, my broker (and therefore the clients) was expecting the self-signed cert and my hosts were proffering the other.

Proving my theory

The cert used by RDS is visible in both WMI and the Registry. I used PowerShell to pull the WMI class. Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices, does the trick nicely. There are only two properties important to this problem, SSLCertificateSHA1Hash and SSLCertificateSHA1HashType. The first gives us the thumbprint of the certificate.

If you really need to know which cert this is specifying, you can use something like $TP = (Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices).SSLCertificateSHA1Hash; Get-ChildItem cert:\LocalMachine** | ?{ $_.Thumbprint -match $TP} to figure it out, but I found my answer from SSLCertificateSHA1HashType. The default value is 1, but I had a 2 in that property. That told me two important details. The first, is that I am not using the self-signed cert, the second is that the cert I am using is dictated by Group Policy.

Let the Hunt Begin

I immediately opened gpedit to find this rouge setting in my RDP Servers GPO. It wasn’t there. I actually dug around for a while before I thought about using group policy results 😳 . Sure enough, buried down in one of our default server policies was a setting in “Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity” called “Server Authentication Certificate Template” that was instructing all of our servers to use the Domain CA certs that were automatically being issued for authentication.

The Fix

I’m sure this setting was configured well before we started using an 2012 RDS. It might have even dated back to the first RDP server install or perhaps it was part of an administrative RDP setup. Regardless, it was certainly the cause of my problem. As soon as I disabled that policy for our RDP server policy object and updated the hosts with gpupdate, those WMI values reverted back to defaults and everything worked perfectly.

The Loose Ends

I never did determine why this worked intermittently outside of the office or why the clients didn’t mind the cert mismatch when they were locally connected. I’m assuming the latter question had something to do with using the local authentication to handle the encryption layer, but I would have thought this problem would have affected them either way. The intermittent successes still don’t make any sense. With plenty of other issues on my agenda and this issue fixed, I moved on to ponder those questions on another day.

In Conclusion

I hope this saves someone the frustration I went through. It’s never any fun when you catch up with problems created in the past. Good Night and God Bless!

Источник

Hi all,

This one is driving me NUTS! The problem itself is when I go to connect to a session host using a web access server I get the error in the title. This is only happening to some of my session hosts and not all. I have compared them and can’t find
a single difference. I also cant find anything useful in the event logs about this. Below is my setup.

A full RDS environment using all Windows Server 2012 Data Center. Nothing 2008 R2. All Clean installs.

I have 6 servers a VM’s split evenly between 2 ESXi 5.1 Hosts.
1. MP-RDP-CB1.inucoda.net (Connection Broker 1)
2. MP-RDP-CB2.inucoda.net (Connection Broker 2)
3. MP-RDP-GW1.inucoda.net (Gateway Server 1)
4. MP-RDP-GW2.inucoda.net (Gateway Server 2)
5. MP-RDP-WA1.inucoda.net (Web Access Server 1)
6. MP-RDP-WA2.inucoda.net (Web Access Server 2)

inucoda.net is an network that is the Domain that all servers are joined to via 2 Domain Controllers splits between each ESXi Host.

My outside domain that you can get to from the web is ucoda.net

The connection brokers have all servers used including session hosts added to the server pool and are configured in HA mode. They use a SQL Server 2012 Fail-over cluster that is on a separate set of VMs for their database and the DNS is configured as round
robin. MP-RDP-CB.inucoda.net. There are two entries of this each with one of the two IPs of the CB1 and CB2 servers.

On each CB server there is a RDS License server role installed with CALs installed and activated/registered. Both LIC servers have been added to the RDS deployment properties.

The GW servers each have the NLB role installed with an extra network adepter for NLB use. There is a DNS name of MP-RDP-GW.inucoda.net that points to the NLB IP of the GW Cluster. Also both GW servers were added to the GW Server Farm part of the the
GW properties.

The WA servers are also in a NLB Cluster with an extra adapter and a DNS of MP-RDP-WA.inucoda.net pointing to the NLB IP.

Up steam from our inside Windows Domain at our ISP level there is a DNS entry of MP-RDP-WA.ucdoa.net and it points to the NLB IP of the WA NLB Cluster. (This is not a public IP, we require you be on our VPN to be able to access the IP).

For certificates we have a Comodo issued wildcard of *.ucoda.net with the corresponding Comodo Root Trust and Intermediate Certs. We also have a wildcard *.inucoda.net created by our inside CA.

The *.inucoda.net cert is used for the CB SSO, CB Publishing, and GW while the *.ucoda.net cert is used for the WA.

All session hosts have been configured to use the *.inucoda.net for their RDP sessions.

I can confirm that the *ucoda.net cert is used for the WA part and all other parts are reporting the *inucoda.net, all with no errors or warnings.

For each session collection only one session host is used with no apps, (just RDP). Security is set to only use NLA, SSL 1.0, High.

On each session host I have verified that the *inucoda and *ucoda certs are installed and the internal CA and Comodo CA/Intermediate CA is installed in the correct stores. I have also verified that COM Security has the domainTS Web Access group set
with full perms for the Access and Launch/Activation. Also for WMI RootCMIV2TermicalServcies Security has the domainTs Web Access group set with full perms. Lastly each group/user that has access to RDS is listed in the Remote Desktop users.

I’ve checked that both WA servers are listed in the TS Web Access group.

The GW servers RAS/RAP policies are set to be pretty open for testing with using any port, any network resource, and Domain Users and Domain Admins listed.

I have been trying to connect with Windows 8 and Windows 7 clients as the domainadministrator account. Some of my session hosts connect fine and other don’t . It’s always the same ones that connect and don’t connect. I can’t find any difference
between the. I’ve also blown away my entire RDS and started over with just a 3 server single node model with no NLB or RR DNS and the same exact error happens on certain servers. I have sense gone back to the 6 server setup described here
and again the same error on the same session hosts.

I have also tried Negotiate and RDS Compatible and disabling NLA only for security. No change. Now here is the interesting part. If I remove GW servers from RDS by just saying not to use them (not actually uninstalling them or anything), all
session hosts connect just fine every time. When I first did my RDS setup I got he same error with code 0x607 for every connection attempt and found i had to set the RAS/RAP to use any network resource instead of Domain Computers. However, it is
currently set like that and some still don’t connect. So it works with out the GW servers just fine. It also works without them in the 6 node setup as well as the 3 node setup.

I don’t want to use it without the GW servers because since I am using all inside subnets with a VPN I have to add the CB IP/Name to my host file or it will not resolve and give an error about reaching the Connection Broker. Because I want to use a HA setup
this is no good as there are two servers for it. That’s why I use the NLB IP of the WA and publish it with outside DNS with our ISP.

Any ideas at all??

Thanks,
Chris

Источник

Article, Hyper-V, Microsoft, Remote Desktop Services, Service Provider Foundation, Software, System Center, System Center Orchestrator, System Center Service Provider Foundation, System Center Virtual Machine Manager, Windows Azure Pack, Windows Servers 2012 R2

October 31, 2014September 20, 2015

1 Minute

If you are applying Update Rollup 4 for System Center Service 2012 R2 Service Provider Foundation and you have have configured Remote Console to use IPv4 by using this solution (by Marc van Eijk) you may receive the following error when you try to connect to VM:

An authentication error has occurred (Code: 0x607).

This can be easily fixed by editing the re-write rule on the SPF web config file.

Just open the web config file of SPF (usually located here C:inetpubSPF)

Find the re-write rule:

remove “negotiate security layer:i:1 “

Save the file. Do IISReset

After that you will be able to connect trough Remote Console.

Published by Stanislav Zhelyazkov

Stanislav Zhelyazkov has been working in IT since 2007. Stanislav has started his IT career as a Help Desk Specialist in 2007 while studying Informatics in the University of Ruse. He also worked in HP Enterprise Services (now known as DXC), maintaining large corporate IT infrastructures for clients in Holland, Switzerland and Germany and was involved in a Private Cloud project based on MS Hyper-V and System Center. He was also in the role of Principal Consultant in Lumagate developing and consulting companies on Azure, OMS, management and Private clouds. Currently he is Cloud Infrastructure Engineer at Sentia Denmark. Stanislav is active community member at MSDN forums providing answers on Azure. His blogposts can be found at www.cloudadministrator.net or www.systemcentercentral.com.
View all posts by Stanislav Zhelyazkov

Published
October 31, 2014September 20, 2015

Источник

Удаленный компьютер требует проверки подлинности на уровне сети

Варианты сообщения, которое вы можете увидеть:

Удаленный компьютер требует проверки подлинности на уровне сети, которую ваш компьютер не поддерживает. Обратитесь за помощью к системному администратору или в службу технической поддержки.

Удаленный компьютер, к которому вы пытаетесь подключиться, требует проверки подлинности на уровне сети, но ваш контроллер домена Windows не может связаться для выполнения NLA. Если вы являетесь администратором на удаленном компьютере, вы можете отключить NLA, используя параметры на вкладке «Удаленное» диалогового окна «Свойства системы».

Эта статья поможет вам с пошаговым руководством к этому решению. Однако вам может потребоваться более постоянное решение, потому что вы не можете запускать устройство вечно без активно включенного NLA. Так что вам нужно лучшее решение. Эта статья также предложит вам это.

1] Изменить настройки удаленного рабочего стола

Переход по маршруту настройки удаленного рабочего стола является более простым решением. Это будет работать для вас, и вы можете не чувствовать необходимости снова включать NLA. Итак, если вы готовы к этому решению, вот как вы поступите с этим. Следуйте инструкциям внимательно.

1] Перейдите в «Выполнить», введите «sysdm. cpl» и нажмите кнопку «Ввод».

3] Найдите «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с аутентификацией на уровне сети (рекомендуется)» и снимите этот флажок.

4] Нажмите «Применить», а затем «ОК» или нажмите «Ввод», чтобы отключить проверку подлинности на уровне сети.

5] Перезагрузите устройство и проверьте, можете ли вы подключать устройства удаленно.

Это исправление должно работать, потому что вы просто удалили единственное, что вызвало проблему. Но на случай, если это не сработало, или вы не хотите идти по этому пути, есть еще один вариант, которому также легко следовать.

2] Изменить реестр

Примечание: пожалуйста, сделайте резервную копию ваших данных перед внесением изменений в реестр системы.

Следуйте инструкциям очень тщательно, и вам будет хорошо идти. Вы уже создали точку восстановления системы, поэтому больше не о чем беспокоиться. Итак, поехали.

1] Перейдите в «Выполнить» и введите «regedit» и нажмите «ОК» или нажмите «Ввод». Это открывает редактор реестра.

2] Посмотрите на левую панель в окне редактора реестра и найдите раздел реестра с именем:

4] Найдите параметр «Изменить несколько строк» ??и введите «tspkg» в поле «Значение». Это будет единственная ценность.

5] После этого найдите следующий раздел реестра в области навигации: HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control SecurityProviders

6] Дважды щелкните SecurityProviders на правой панели, чтобы открыть его свойства.

7] Введите credssp. dll в поле «Значение» и пусть оно будет единственным значением.

8] Нажмите «ОК» и закройте редактор реестра.

Хотя второй метод более сложен и требует большего внимания, это рекомендуемое решение. Надеюсь это поможет.

Решения были переданы из обсуждения в Стэнфордском университете и в этом сообщении MSDN.

Ошибка при подключении по RDP (Исправление шифрования CredSSP)

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»

В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable:
С помощью gpedit. msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

Или через реестр (т. к., например, в Windows Home нет команды gpedit. msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т. к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Произошла ошибка проверки подлинности. Указанная функция не поддерживается

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc. exe и нажимаю «Подключить», появляется ошибка:

Произошла ошибка проверки подлинности.

Указанная функция не поддерживается.
Удаленный компьютер: computername

После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?

Ответ

Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.

В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:

The function requested is not supported.

Remote computer: computername

Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.

Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.

Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?

Отключение NLA для протокола RDP в Windows

Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).

В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».

Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — Gpedit.msc (в Windows 10 Home редактор политик gpedit. msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC. msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), Отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Проверка подлинности сети для удаленного компьютера

Проверка подлинности сети для удаленного компьютера Windows нередко вызывает недоумение у пользователей, так как возникает ошибка Удаленный компьютер требует проверку подлинности . Проблема с проверкой чаще встречается на более ранних версиях ОС до Windows 7. PClegko разберется с причинами и даст верные советы по исправлению ошибок подключения к удаленному рабочему столу.

Уверенные пользователи ПК наверняка слышали о фишке «удаленный рабочий стол» (Remote Desktop Connection). Она позволяет подключаться к другому компьютеру (удаленному) через свой ПК, планшет или телефон.

Вы можете удаленно управлять другим ПК, как будто вы находитесь за ним. Технология работает на всех операционных системах (ОС) включая Windows XP, Windows 7-10, Mac OS.

Требования к аутентификации на уровне сети

Remote Desktop Connection – это пошаговый процесс. Сперва нужно настроить ПК, над которым необходим контроль. Этот компьютер обязательно должен соблюдать такие требования.

1. Компьютер клиента обязан использовать Remote Desktop Connection версии 6.0 или выше.
2. Операционная система, установленная на ПК, должна поддерживать Credential Security Support Provider.
3. Должен быть запущен клиент Windows Server: 2008R2, W2012R2, W2016R2.

Причина ошибки подключения к удаленному компьютеру

Давно прошли те времена, когда RDC пользовались лишь системные администраторы. Сейчас эта функция – обычное дело в корпоративной среде. Огромной популярностью пользуется решение от компании Microsoft, в основном из-за добавления этой функции в состав серверных операционных систем (Windows Server).

Но этот гигант не останавливается на достигнутом и собирается догнать своего прямого конкурента CSTRIX, возможностями которого пользуются уже более 15 лет.

С выходом Windows Server, появилась возможность устанавливать защиту на сетевом уровне. Но, более поздние версии ОС эту возможность не получили. Теперь, при подключении к такому серверу, удаленный компьютер требует проверки подлинности на уровне сети, которую ПК не поддерживает.

Ошибка происходит по причине того, что Windows XP не может проверить подлинность на уровне сети. Эта возможность появляется только в будущих версиях системы. Позже разработчики выпустили обновление KB951608, исправляющее проблему.

Проверка подлинности сети для удаленного компьютера — решение проблемы

Проверка подлинности на уровне сети – метод проверки, при котором подлинность пользователя должна проверяться перед непосредственным подключением к удаленному рабочему столу. Этот метод безопасен и помогает защитить удаленный ПК от злоумышленников, и вредоносного программного обеспечения.

Чтобы воспользоваться функцией удаленного рабочего стола, нужно установить Windows XP Service Pack 3, (на других версиях ОС проблема не беспокоит) а после выполнить следующее.

Зайти на официальный сайт https://support. microsoft. com/ru-ru/kb/951608 скачать файл с автоматическими исправлениями. Кнопку «Скачать» можно найти в разделе «Помощь»

Запустите файл после загрузки. Откроется окно программы. Первый действием кликните на галочку «Принять» и нажмите «Далее».

После завершения процесса должно открыться новое окно с результатом исправлений. Обычно там написано, что исправление было обработано. Нажмите «Закрыть» и согласитесь с условием перезагрузить компьютер.

После всех выполненных действий, при новом подключении проверка подлинности на уровне сети проходит успешно.

В открывшемся окне укажите логин и пароль администратора для получения доступа.

Следующий способ называется «Атака в лоб» — выключить проверку Connection Broker в свойствах приложений. По умолчанию стоит «Разрешить подключаться только с компьютеров…», снимите галочку.

Теперь удаленное приложения обязательно откроется без злостной ошибки.

Существует и более безопасный способ – включить поддержку проверки подлинности на уровне сети. В этом случае, в свойствах коллекции не нужно убирать галочку, стоящую по умолчанию.

Вместо этого следует внести изменения в реестр :

1. Воспользуйтесь regedit (Win+R) и измените путь «HKLM/SYSTEM/ CurrentControlSet/Lsa» добавить значение tspkg в параметр «Security Packages».

2. «HKLM/SYSTEM/CurrentControlSet/SecurityProviders» добавить скрипт credssp. dll в «SecurityProviders».

После всех изменений перезагрузите компьютер. Если после перезагрузки при запуске приложения появиться ошибка «компьютер требует проверку подлинности на уровне сети» (код: 0x80090303)» – не беспокойтесь!

Для решения проблемы воспользуетесь хотфиксом (первый способ). После чего снова перезагрузите ПК и приложение обязательно запустится.

Разрешить удаленное подключение к компьютеру на Windows 10 проще простого. Важно, чтобы у пользователя была установлена профессиональная версия операционной системы (Pro).

Для разрешения подключения к удаленному ПК следует:

1. Откройте «Панель управления»
2. «Система».
3. «Настройки удаленного доступа».
4. Активируйте раздел «Разрешить удаленные подключения» и нажмите «Ок», затем «Применить» и покиньте меню.

После перезагрузки ПК будет поддерживать удаленные подключения по локальной сети.

Теперь нужно убедиться, что включено разрешение подключения по протоколу RDP.

1. Снова зайдите в «Свойства», «Настройки удаленного доступа».
2. Кликните по пункту «Разрешить удаленные подключения к ПК», если этот параметр будет неактивен.
Советуем прописывать именно тех пользователей, которые будут подключаться к системе. Эту процедуру нужно выполнить обязательно! Если не помогло, переходим ко второму способу.

Проверяем настройки брандмауэра

1. Переходим в «Панель управления».
2. «Брандмауэр» и нажимаем ставим разрешение на нужное приложение.

В настройках также нужно разрешить все входящие подключения к удаленному рабочему столу.

После проверки настроек проблема должна исчезнуть.

Главная особенность новой ОС – не нужно устанавливать дополнительное программное обеспечение для настройки удаленного рабочего стола. Просто откройте поиск и найдите «Удаленный рабочий стол». После чего откроется программа.

В ячейку нужно вписать IP-адрес требуемого ПК и ввести его учетные данные. Все просто.

Проверка подлинности сети для удаленного компьютера — банальные ошибки

Компьютер может не подключаться к удаленному рабочему столу еще по нескольким, банальным причинам:

1. Подключение не осуществляется, если учетная запись пользователя создана без пароля. Пароль можно добавить в настройках учетной записи.
2. Удаленный ПК может находиться в спящем режиме. Чтобы этого не происходило, в параметрах сна и гибернации установите параметр «Никогда».
3. Удаленный компьютер принимает подключения только от ПК с включенной проверкой подлинности (NLA). В статье мы привели примеры как разрешить проверну подлинности на уровне сети.

После проведения всех манипуляций, у Вас без сомнений получиться подключить к удаленному рабочему столу.

Ошибка при проверке подлинности код 0x507

Вопрос

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

Подключение к удаленному рабочему столу
Удаленный компьютер требует включения проверки подлинности при подключении.
Удаленный компьютер: х. х. х. х
Подключение невозможно, поскольку не включена проверка подлинности.

На обоих ПК выполнил:

Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Клиент подключения к удаленному рабочему столу > Настройка проверки подлинности клиента на сервере > Включить > Подключаться, даже если проверка подлинности не прошла

2). На ПК с 10-кой отключил брандмауэр.

Соединение удет не на прямую, а через железный файрвол — Балабит. Если подключаться минуя Балабит — подключается нормально. При этом с семерки на семерку, с хр на хр, с хр на сервер 2008 и через Балабит подключение проходит без ошибок.

Ответы

Вопрос решился после выполнения приложенной инструкции. Теперь другая проблема:

Все ответы

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

На обоих ПК выполнил:

2). На ПК с 10-кой отключил брандмауэр.

Если Win7 с которых пытаетесь подключиться у Вас не в домене, Вам нужно Отключить проверку на Win 10.

The opinion expressed by me is not an official position of Microsoft

На 10-ке это сделано. После отключения этой опции как раз заявленная ошибка и появляется. До отключения была другая:

Удаленный компьютер требует проверки подлинности на уровне сети, которую данный компьютер не поддерживает. Обратитесь за помощью к системному администратору или в службу технической поддержки.

При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:

Подключение к удаленному рабочему столу
Удаленный компьютер требует включения проверки подлинности при подключении.
Удаленный компьютер: х. х. х. х (адрес сервера Балабит)
Подключение невозможно, поскольку не включена проверка подлинности.

На обоих ПК выполнил:

2). На ПК с 10-кой отключил брандмауэр.

Соединение идет не на прямую, а через железный файрвол — Балабит. Если подключаться минуя Балабит — подключается нормально. При этом с семерки на семерку, с хр на хр, с хр на сервер 2008 и через Балабит подключение проходит без ошибок.

Произошла ошибка проверки подлинности RDP – как исправить

Очередные обновления к Windows постоянно создают какие-то проблемы. Так пользователи удаленных рабочих столов сталкиваются чаще с ошибкой проверки подлинности RDP. Обновление под номером KB4103718 и последующие версии не стабильны на многих компьютерах. Адрес RDP блокируется без возможности работы с его настройками и появляется сообщение об ошибке “Произошла ошибка проверки подлинности RDP” и подключение к удаленному рабочему столу не удалось.

Варианты решений “ошибка проверки подлинности RDP”

Деинсталляция обновлений

Временным решением и очевидным остается откат к предыдущей версии Windows. Необходимо полностью деинсталлировать весь софт, идущий с обновлением. Единственным недостатком остается временное устранение проблемы с RDP, ведь нет гарантий, что последующие анонсированные улучшения к Windows будут работать корректней. Хотя если такой расклад вас устраивает, работать без обновлений, то можно остановиться именно на данном пункте.

Кумулятивные обновления

Если такое определение для вас новое, тогда придется провести незначительный исторический урок. Сравнительно недавно «Microsoft» отказались от фрагментных патчей для своих операционных систем Windows. Теперь нет еженедельных загрузок. Вместо них предлагается система обновлений в режиме накопления. Кумулятивные обновления будут содержать софт, разработанный за целый месяц, что также подразумевает скачивание лишь 12 раз в год.

Это своего рода огромный патч. Если у вас «RDP ошибка проверки подлинности» появилась после незначительного обновления лишь одного модуля, то сделайте откат и инсталлируйте масштабную его версию. Глобально обновите вашу ОС из официальных источников «Microsoft».

Отключаем NLA

Потребуется отключить Network Level Authentication. Это делается через меню «Удаленный доступ», которое найдете в свойствах системы. Необходимо поставить галочку или точку напротив следующей категории: «Разрешить подключения только с компьютеров…..». Он разной версии Windows содержание может незначительно меняться. Ориентируйтесь на низ вашего окна. Необходимая команда размещается в самом низу и имеет подпункт.

Альтернативным вариантом остается отключение подлинности на уровне NLA.

Тут же подымаясь немного выше, замечаем пункт с названием «Требовать использования специального…». Он очень важен. Необходимо выставить корректный уровень безопасности. Переводим значение на нужный сервер RDP.

Обязательно перезапустите систему – без этого шага внесенные изменения не вступят в силу.

Заключение

Возможно не все способы описанные в статье помогут вам исправить “ошибку проверки подлинности RDP”. Если вы нашли способ, который помог именно вам – воспользуйтесь формой комментариев ниже и укажите ссылку на источник или опишите решение проблемы и мы дополним им нашу статью.
Скорее это временный баг, который уйдет сам после обновления версии Windows со следующим апдейтом.

Евгений Загорский

IT специалист. Автор информационных статей на тему Андроид смартфонов и IOS смартфонов. Эксперт в области решения проблем с компьютерами и программами: установка, настройка, обзоры, советы по безопасности ваших устройств. В свободное время занимается дизайном и разработкой сайтов.

Источники:

Https://llscompany. ru/java/oshibka-pri-proverke-podlinnosti-kod-0x507.html

Https://itpen. ru/proizoshla-oshibka-proverki-podlinnosti-rdp-kak-ispravit/

Источник

Hi,

I currently have the following setup;

2 x RDS Session Hosts (RDS1.domain.local , RDS2.domain.local) 2 x RD Gateway (RDS1.domain.local , RDS2.domain.local) 2 x RD Web Access (RDS1.domain.local , RDS2.domain.local) 2 x RD Connection Brokers (RDS1.domain.local , RDS2.domain.local) 2 x RD Licensing (DC1.domain.local, DC2.domain.local)

When I use RDWeb and click on the RDS icon I am faced with ‘0x607 An authentication error has occured — RDS2.domain.local’

If I take RDS2 out of the pool of available servers it works without any issues. Both RDS1 & RDS2 are set up identically, has anyone come across this where only one of the RDS servers in a farm reject logon through RDWeb?

I will add that I have come across many articles saying to delete the following Reg key;

HKLM SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-TcpSSLCertificateSHA1Hash

And to change the encryption level to Low in the session collection properties, neither of these have worked for me.

Thanks in advance.

Источник

В нашей организации два компьютера под управлением 7 pro не могут зайти в программу по удаленному доступу (RemoteApp), который предоставляет удаленный сервер.
Все было настроено и работало, но через некоторое время при попытке подключиться выдает ошибку:

«Ошибка при проверке подлинности (код 0x607)»

Системный администратор удаленного сервера написал:

«Проверьте корректность установки сертификата.»

Я переустановил сертификат, именно в учетную запись компьютера, как и было указано в инструкции. Но ошибка так и осталась. Других мыслей, с чем может быть связана эта ошибка у техподдержки сервера нет.

Подключиться под той же самой учетной записью удается с другого компьютера под управлением Windows XP.

Просканировал на вирусы, все чисто.

Компьютеры абсолютно новые, на них было настроено соединение, люди работали, но через некоторое время перестало. Иногда, очень редко получается подключиться, но в этом случае
появляется окошко с надписью «не удалось проверить не отозван ли сертификат, продолжить соединение? да/нет», если нажать «да» то соединяет. Такое впечатление, что установилось какое то новое обновление безопасности и теперь ошибка.

Пожалуйста, посодействуйте решению этой проблемы.

Посмотреть скрин ошибки пожно по ссылке:

http://217.74.161.133/download/er.jpg

Там видно, что сертификат установлен в систему.

Hi all,

A full RDS environment using all Windows Server 2012 Data Center. Nothing 2008 R2. All Clean installs.

inucoda.net is an network that is the Domain that all servers are joined to via 2 Domain Controllers splits between each ESXi Host.

My outside domain that you can get to from the web is ucoda.net