В нашей организации два компьютера под управлением 7 pro не могут зайти в программу по удаленному доступу (RemoteApp), который предоставляет удаленный сервер.
Все было настроено и работало, но через некоторое время при попытке подключиться выдает ошибку:
«Ошибка при проверке подлинности (код 0x607)»
Системный администратор удаленного сервера написал:
«Проверьте корректность установки сертификата.»
Я переустановил сертификат, именно в учетную запись компьютера, как и было указано в инструкции. Но ошибка так и осталась. Других мыслей, с чем может быть связана эта ошибка у техподдержки сервера нет.
Подключиться под той же самой учетной записью удается с другого компьютера под управлением Windows XP.
Просканировал на вирусы, все чисто.
Компьютеры абсолютно новые, на них было настроено соединение, люди работали, но через некоторое время перестало. Иногда, очень редко получается подключиться, но в этом случае
появляется окошко с надписью «не удалось проверить не отозван ли сертификат, продолжить соединение? да/нет», если нажать «да» то соединяет. Такое впечатление, что установилось какое то новое обновление безопасности и теперь ошибка.
Пожалуйста, посодействуйте решению этой проблемы.
Посмотреть скрин ошибки пожно по ссылке:
http://217.74.161.133/download/er.jpg
Там видно, что сертификат установлен в систему.
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 propertiesand in «security» change
«Encryption level» tolow. 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
11.1k4 gold badges32 silver badges59 bronze badges
1
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
1
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
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
При подключении к терминальным фермам, 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: Проверка и ручная замена сертификата службы терминалов
При подключении к терминальным фермам, 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: Проверка и ручная замена сертификата службы терминалов
В нашей организации два компьютера под управлением 7 pro не могут зайти в программу по удаленному доступу (RemoteApp), который предоставляет удаленный сервер.
Все было настроено и работало, но через некоторое время при попытке подключиться выдает ошибку:
«Ошибка при проверке подлинности (код 0x607)»
Системный администратор удаленного сервера написал:
«Проверьте корректность установки сертификата.»
Я переустановил сертификат, именно в учетную запись компьютера, как и было указано в инструкции. Но ошибка так и осталась. Других мыслей, с чем может быть связана эта ошибка у техподдержки сервера нет.
Подключиться под той же самой учетной записью удается с другого компьютера под управлением Windows XP.
Просканировал на вирусы, все чисто.
Компьютеры абсолютно новые, на них было настроено соединение, люди работали, но через некоторое время перестало. Иногда, очень редко получается подключиться, но в этом случае
появляется окошко с надписью «не удалось проверить не отозван ли сертификат, продолжить соединение? да/нет», если нажать «да» то соединяет. Такое впечатление, что установилось какое то новое обновление безопасности и теперь ошибка.
Пожалуйста, посодействуйте решению этой проблемы.
Посмотреть скрин ошибки пожно по ссылке:
http://217.74.161.133/download/er.jpg
Там видно, что сертификат установлен в систему.
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
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
При попытке подключения к серверу через протокол удалённого рабочего стола (RPD) пользователь может столкнуться с ошибкой подключения, сопровождающейся сообщением « Произошла ошибка проверки подлинности. Указанная функция не поддерживается ». Возникновение данной проблемы обычно связано с отсутствием необходимых обновлений на ПК клиента. А также рядом настроек на машинах сервера или клиента, блокирующих отдалённое подключение к ПК. Разберём, что является причиной проблемы, и как её исправить.
В апреле «Майкрософт» выпустила следующий апдейт, снабжающий пользователя более детальной информацией об ошибке во время использования клиента удалённого рабочего стола (RDP).
В мае 2018 года вышел финальный Update, изменяющий настройки сессии RDP c использованием CredSSP по умолчанию с « Vulnerable » (Уязвимый) до « Mitigated » (Смягчённый). Также это означало, что любое клиентское приложение, задействующее «CredSSP», будет невозможно откатить до небезопасной версии.
Если ваша рабочая станция получила майское обновление, а сервер его не получал, тогда рабочая станция (клиент) будет отображать сообщение об ошибке при попытке подключения к серверу с использованием RDP.
Разберём перечень способов, позволяющих эффективно избавиться от проблемы проверки подлинности RDP.
Установка апдейта, если указанная функция не поддерживается
Соответственно, основным способом, позволяющим исправить ошибку проверки подлинности RPD, является установка необходимого обновления ( CVE-2018-0886 ) как на клиентскую, так и на серверную ОС.
Выберите свою версию OS из списка снизу, и установите на вашу машину необходимый ей апдейт CVE-2018-0886:
Также можно перейти на сайт Майкрософта (при необходимости поставьте галочку и нажмите «Accept»), слева отыскать версию вашей системы (если не знаете, нажмите Win+Pause). Далее нажать справа на « Security Update », после чего вы получите возможность скачать нужное обновление.
Изменение настроек групповых политик
Если вы по каким-либо причинам не можете установить требуемые апдейты, существует паллиативное решение проблемы проверки подлинности RPD, состоящее в изменении настроек групповых политик. Не рекомендуется рассматривать его как основной вариант, так как таким образом вы сохраняете уязвимость вашей системы для действий злоумышленников.
Также вы можете осуществить данную операцию с помощью специальной команды, выполненной в командной строке с правами админа:
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
Отключение NLA для решения ошибки проверки RPD
Ещё одним способом решить ошибку проверки подлинности RPD является отключение NLA (аутентификации на уровне сети).
Заключение
Появление сообщения «Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается» обычно связано с отсутствием на ПК (обычно клиентском) необходимого обновления CVE-2018-0886, позволяющего ликвидировать ряд уязвимостей в системе. Необходимо установить требуемые обновления для вашей системы, а если такое временно невозможно – просто переключите параметр шифрующего оракула на «Vulnerable» (т. е. «Оставить уязвимость»), что позволит решить ошибку.
Ошибка CredSSP — Произошла ошибка при проверке подлинности
Windows
Всем добрый вечер, в декабре удаленно помогал одному из моих читателей с проблемой по которой, он оставил отзыв к статье — Не удается подключиться к удаленному рабочему столу и не смотря на то, что статья эта была написано аж в 2012 году, на нее до сих пор заходит большое кол-во пользователей и я не особо понимал причину такой популярности этой старой статьи до момента пока не стал разбираться с этой проблемой (ну по крайней мере я так думаю)) )!
Подсоединившись к его рабочему столу через TeamViewer и при подключение по RDP к серверу Windows 2012 у нас вылетела ошибка:
Произошла ошибка при проверке подлинности.
Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP
Дополнительные сведенья см. в статье https://go. microsoft. com/fwlink/?linkid=866660
An authentication error has occurred.
The function is not supported.
This could be due to CredSSP encryption oracle remediation.
начал разбираться и вот что могу рассказать об этой ошибке:
Что такое CredSSP
CredSSP — это протокол поставщика поддержки учетных данных который является поставщиком аутентификации, который обрабатывает запросы на аутентификацию для других приложений.
у протокола CredSSP было три релиза-обновления
Поэтому когда мы подсоединяемся к серверу по RPD и вас отфутболивают, то тут две могут быть причины, либо на вашем компьютере поставились обновления либо на сервере были установлены накопительные обновления март — май 2018 года в которых убирается уязвимость в системе безопасности и при попытке подключения с непропатченной версией CredSSP у вас будет вылетать ошибка:
Давайте перейдем к
Варианты исправления ошибки CredSSP
Вариантов по устранению причины ошибки CredSSP несколько и мы пройдемся по каждой отдельно!
Установка последних обновлений
в котором вам предлагается скачать вручную обновление и поставить его на клиента/сервер
Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:
Отключить уведомления об ошибке шифрования CreedSSP
Но есть и более простой способ (но не безопасный) как это можно обойти если нет времени заниматься скачиванием и установкой! Этим способом мы просто отключаем это уведомление об ошибки и спокойно продолжаем работать по RDP
Отключение через групповые политики
Если же вам удобнее использовать редактор локальных групповых политик, то следуйте след инструкции:
Вот так мы и победили эту ошибку с подключением RPD к серверу! Так что будут вопрос, обязательно пишите и я постараюсь вам помочь!
Очередные обновления к 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://it-doc. info/proizoshla-oshibka-proverki-podlinnosti-rdp-ukazannaya-funkciya-ne-podderzhivaetsya-reshenie/
https://www. nibbl. ru/windows/oshibka-credssp-proizoshla-oshibka-pri-proverke-podlinnosti. html
https://itpen. ru/proizoshla-oshibka-proverki-podlinnosti-rdp-kak-ispravit/
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Рисунок 1 — Ошибка проверки подлинности RDP
Появление ошибки обусловлено установкой данных обновлений безопасности:
- Windows Server 2016 — обновление KB4103723
- Windows 10 1609 — обновление KB4103723
- Windows 10 1703 — обновление KB4103731
- Windows 10 1709 — обновление KB4103727
- Windows 10 1803 — обновление KB4103721
- Windows 7 / Windows Server 2008 R2 — обновление KB4103718
- Windows 8.1 / Windows Server 2012 R2 — обновление KB4103725
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Рисунок 2 — Проверка подлинности
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
Локально заходим в групповые политики устройства, к которому пытаемся подключиться. Для того чтобы открыть редактор групповых политик выполним следующее действие: Нажимаете Win+R, а затем введите gpedit.msc. Переходите по данному пути: Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных > Защита от атак с использованием криптографического оракула.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters
Затем находим параметр AllowEncryptionOracle, открываем его и ставим значение 2.
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
Удаленный компьютер требует проверки подлинности на уровне сети
Удаленный компьютер требует проверки подлинности на уровне сети
Варианты сообщения, которое вы можете увидеть:
Удаленный компьютер требует проверки подлинности на уровне сети, которую ваш компьютер не поддерживает. Обратитесь за помощью к системному администратору или в службу технической поддержки.
Удаленный компьютер, к которому вы пытаетесь подключиться, требует проверки подлинности на уровне сети, но ваш контроллер домена 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 находящемся в домене, ошибка:
Подключение к удаленному рабочему столу
Удаленный компьютер требует включения проверки подлинности при подключении.
Удаленный компьютер: х. х. х. х
Подключение невозможно, поскольку не включена проверка подлинности.
На обоих ПК выполнил:
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Клиент подключения к удаленному рабочему столу > Настройка проверки подлинности клиента на сервере > Включить > Подключаться, даже если проверка подлинности не прошла
2). На ПК с 10-кой отключил брандмауэр.
Если Win7 с которых пытаетесь подключиться у Вас не в домене, Вам нужно Отключить проверку на Win 10.
The opinion expressed by me is not an official position of Microsoft
На 10-ке это сделано. После отключения этой опции как раз заявленная ошибка и появляется. До отключения была другая:
Удаленный компьютер требует проверки подлинности на уровне сети, которую данный компьютер не поддерживает. Обратитесь за помощью к системному администратору или в службу технической поддержки.
При попытке подключения удаленным рабочим столом с ПК на Windows 7 к ПК на Windows 10 находящемся в домене, ошибка:
Подключение к удаленному рабочему столу
Удаленный компьютер требует включения проверки подлинности при подключении.
Удаленный компьютер: х. х. х. х (адрес сервера Балабит)
Подключение невозможно, поскольку не включена проверка подлинности.
На обоих ПК выполнил:
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Клиент подключения к удаленному рабочему столу > Настройка проверки подлинности клиента на сервере > Включить > Подключаться, даже если проверка подлинности не прошла
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/
При попытке подключения к серверу через протокол удалённого рабочего стола (RPD) пользователь может столкнуться с ошибкой подключения, сопровождающейся сообщением « Произошла ошибка проверки подлинности. Указанная функция не поддерживается ». Возникновение данной проблемы обычно связано с отсутствием необходимых обновлений на ПК клиента. А также рядом настроек на машинах сервера или клиента, блокирующих отдалённое подключение к ПК. Разберём, что является причиной проблемы, и как её исправить.
В чем суть ошибки проверки подлинности RDP
В апреле «Майкрософт» выпустила следующий апдейт, снабжающий пользователя более детальной информацией об ошибке во время использования клиента удалённого рабочего стола (RDP).
В мае 2018 года вышел финальный Update, изменяющий настройки сессии RDP c использованием CredSSP по умолчанию с « Vulnerable » (Уязвимый) до « Mitigated » (Смягчённый). Также это означало, что любое клиентское приложение, задействующее «CredSSP», будет невозможно откатить до небезопасной версии.
Если ваша рабочая станция получила майское обновление, а сервер его не получал, тогда рабочая станция (клиент) будет отображать сообщение об ошибке при попытке подключения к серверу с использованием RDP.
Разберём перечень способов, позволяющих эффективно избавиться от проблемы проверки подлинности RDP.
Установка апдейта, если указанная функция не поддерживается
Соответственно, основным способом, позволяющим исправить ошибку проверки подлинности RPD, является установка необходимого обновления ( CVE-2018-0886 ) как на клиентскую, так и на серверную ОС.
Выберите свою версию OS из списка снизу, и установите на вашу машину необходимый ей апдейт CVE-2018-0886:
Также можно перейти на сайт Майкрософта (при необходимости поставьте галочку и нажмите «Accept»), слева отыскать версию вашей системы (если не знаете, нажмите Win+Pause). Далее нажать справа на « Security Update », после чего вы получите возможность скачать нужное обновление.
Изменение настроек групповых политик
Если вы по каким-либо причинам не можете установить требуемые апдейты, существует паллиативное решение проблемы проверки подлинности RPD, состоящее в изменении настроек групповых политик. Не рекомендуется рассматривать его как основной вариант, так как таким образом вы сохраняете уязвимость вашей системы для действий злоумышленников.
Также вы можете осуществить данную операцию с помощью специальной команды, выполненной в командной строке с правами админа:
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2
Отключение NLA для решения ошибки проверки RPD
Ещё одним способом решить ошибку проверки подлинности RPD является отключение NLA (аутентификации на уровне сети).
Заключение
Появление сообщения «Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается» обычно связано с отсутствием на ПК (обычно клиентском) необходимого обновления CVE-2018-0886, позволяющего ликвидировать ряд уязвимостей в системе. Необходимо установить требуемые обновления для вашей системы, а если такое временно невозможно – просто переключите параметр шифрующего оракула на «Vulnerable» (т. е. «Оставить уязвимость»), что позволит решить ошибку.
Ошибка CredSSP — Произошла ошибка при проверке подлинности
Windows
Всем добрый вечер, в декабре удаленно помогал одному из моих читателей с проблемой по которой, он оставил отзыв к статье — Не удается подключиться к удаленному рабочему столу и не смотря на то, что статья эта была написано аж в 2012 году, на нее до сих пор заходит большое кол-во пользователей и я не особо понимал причину такой популярности этой старой статьи до момента пока не стал разбираться с этой проблемой (ну по крайней мере я так думаю)) )!
Подсоединившись к его рабочему столу через TeamViewer и при подключение по RDP к серверу Windows 2012 у нас вылетела ошибка:
Произошла ошибка при проверке подлинности.
Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP
Дополнительные сведенья см. в статье https://go. microsoft. com/fwlink/?linkid=866660
An authentication error has occurred.
The function is not supported.
This could be due to CredSSP encryption oracle remediation.
начал разбираться и вот что могу рассказать об этой ошибке:
Что такое CredSSP
CredSSP — это протокол поставщика поддержки учетных данных который является поставщиком аутентификации, который обрабатывает запросы на аутентификацию для других приложений.
у протокола CredSSP было три релиза-обновления
Поэтому когда мы подсоединяемся к серверу по RPD и вас отфутболивают, то тут две могут быть причины, либо на вашем компьютере поставились обновления либо на сервере были установлены накопительные обновления март — май 2018 года в которых убирается уязвимость в системе безопасности и при попытке подключения с непропатченной версией CredSSP у вас будет вылетать ошибка:
Давайте перейдем к
Варианты исправления ошибки CredSSP
Вариантов по устранению причины ошибки CredSSP несколько и мы пройдемся по каждой отдельно!
Установка последних обновлений
в котором вам предлагается скачать вручную обновление и поставить его на клиента/сервер
Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:
Отключить уведомления об ошибке шифрования CreedSSP
Но есть и более простой способ (но не безопасный) как это можно обойти если нет времени заниматься скачиванием и установкой! Этим способом мы просто отключаем это уведомление об ошибки и спокойно продолжаем работать по RDP
Отключение через групповые политики
Если же вам удобнее использовать редактор локальных групповых политик, то следуйте след инструкции:
Вот так мы и победили эту ошибку с подключением RPD к серверу! Так что будут вопрос, обязательно пишите и я постараюсь вам помочь!
Произошла ошибка проверки подлинности 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://it-doc. info/proizoshla-oshibka-proverki-podlinnosti-rdp-ukazannaya-funkciya-ne-podderzhivaetsya-reshenie/
https://www. nibbl. ru/windows/oshibka-credssp-proizoshla-oshibka-pri-proverke-podlinnosti. html
https://itpen. ru/proizoshla-oshibka-proverki-podlinnosti-rdp-kak-ispravit/