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
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
11k4 gold badges31 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
Некоторые пользователи, которые подключаются через удаленный доступ RDP в Windows 10/7, получают ошибку «Произошла ошибка проверки подлинности. Указанная функция не поддерживается» может быть комментарий, что «Причиной ошибки может быть исправление шифрования CredSPP«. Большинство пользователей столкнулись с этой ошибкой после обновления системы Windows 10/7. Дело в том, что Microsoft выпустила микро-патч для удаления уязвимости в RDP. По этому CredSPP должен быть обновлен на обоих ПК и всех устройствах, к которым вы пытаетесь подключиться удаленно. Другие сообщили, что в групповых политик сбросились значения. И лично я столкнулся с этой проблемой, и решил её редактированием реестра. Разберем основные решения, чтобы исправить ошибку проверки подлинности при подключении удаленного доступа RDP.
1. Снять ограничения
В большинстве случаев нужно всего-лишь снять галочку на проверку подлинности. Нажмите сочетание кнопок на клавиатуре Win+R и введите sysdm.cpl, чтобы открыть свойства системы. Перейдите во вкладку «Удаленный доступ«, ниже установите «Разрешить удаленные подключения к этому компьютеру» и снимите галочку «Разрешить подключения только с компьютеров, на которых работает проверка подлинности«.
2. Обновление Windows 10/7 и обновление CredSPP
Во первых, обновите все свои устройства в «Центре обновления Windows«, которые подключаются через удаленный доступ. Во вторых, проверьте специальные патчи обновления, которые устраняли уязвимость в RDP, их можно посмотреть на официальном сайте Microsoft CVE-2018-0886, и обновите свои Windows 10/7, Server, RT, LTSB для всех ПК. Тем самым вы обновите CredSPP.
3. Групповые политики
Нажмите Win + R и введите gpedit.msc, чтобы открыть редактор групповых политик. В политиках перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Система» > «Передача учетных данных» > справа найдите «Защита от атак с использованием криптографического оракула» (Oracle Remediation) и нажмите по этой политике два раза мышкой, чтобы открыть свойства.
- В свойствах выберите «Включено» и ниже в графе «уровень защиты» поставьте «Оставить уязвимость«. Нажмите применить и следуйте сразу ниже пункту.
- Запустите теперь командную строку от имени администратора и введите
gpupdate /force, чтобы обновить политики и применения вступили в силу. Проверьте устранена ли ошибка проверки подлинности RDP, если нет, то перезагрузите ПК.
4. Редактор реестра
Нажмите Win + R и введите regedit, чтобы открыть редактор реестра. В реестре перейдите по пути:
HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters- Справа дважды щелкните по AllowEncryptionOracle и поставьте значение 2.
- Перезагрузите ПК и надеюсь, что проблема с проверки подлинности RDP при подключении удаленного доступа решена.
Если вы не делали способ 2, то у вас не будет папки
CredSSPParameters. Проделайте способ 2 или создайте вручную папкуCredSSPс подпапкойParametersи ключом AllowEncryptionOracle со значением 2.
Смотрите еще:
- Подключение к удаленному рабочему столу в Windows
- Служба профилей пользователей не удалось войти в систему windows 10
- Произошла неустранимая ошибка при выполнении программы sysprep
- Операционная система не найдена при включении компьютера
- Не найден сетевой путь ошибка 0x80070035
[ Telegram | Поддержать ]
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-подключений? Обращайтесь к нам!
После установки обновления 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 серверу аналогичная ошибка выглядит так:
An authentication error has occurred.
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 серверу?
- Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
- Временный способ 1. Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
- Временный способ 2. Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда
REG ADD
HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).Это единственный способ доступа к удаленному серверу по RDP, если у вас отсусвует возможность локального входа на сервер (через консоль ILO, виртуальной машины, облачный интерфейс и т.д.). В этом режиме вы сможете подключиться к удаленному серверу и установить обновления безопасности, таким образом перейдете к рекомендуемому 1 способу. После обновления сервера не забудьте отключить политику или вернуть значение ключа AllowEncryptionOracle = 0 :
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 0
Отключение 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) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.