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

Устранение ошибок проверки подлинности при использовании RDP для подключения к виртуальной машине Azure

Эта статья поможет устранить ошибки проверки подлинности, возникающие при использовании подключения по протоколу удаленного рабочего стола (RDP) для подключения к виртуальной машине Azure.

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

Симптомы

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

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

Причина

Существует несколько причин, по которым NLA может блокировать доступ по протоколу RDP к виртуальной машине:

Виртуальная машина не может взаимодействовать с контроллером домена (DC). Эта проблема может помешать сеансу RDP получить доступ к виртуальной машине с помощью учетных данных домена. Однако вы по-прежнему сможете войти в систему с помощью учетных данных локального администратора. Эта проблема может возникнуть в следующих ситуациях:
- Канал безопасности Active Directory между этой виртуальной машиной и контроллером домена не работает.
- Виртуальная машина имеет старую копию пароля учетной записи, а контроллер домена — более новую.
- Контроллер домена, к которому подключается эта виртуальная машина, неработоспособен.
Перед устранением неполадок

Создание резервного snapshot

Чтобы создать snapshot резервной копии, выполните действия, описанные в разделе Создание моментального снимка диска.

Удаленное подключение к виртуальной машине

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

Клиентская служба групповой политики

Если это виртуальная машина, присоединенная к домену, сначала остановите службу клиента групповая политика, чтобы предотвратить перезапись изменений политикой Active Directory. Для этого выполните следующую команду.
```
REM Disable the member server to retrieve the latest GPO from the domain upon start REG add "HKLM\SYSTEM\CurrentControlSet\Services\gpsvc" /v Start /t REG_DWORD /d 4 /f 
```
После устранения проблемы восстановите возможность связи этой виртуальной машины с доменом для получения последнего объекта групповой политики из домена. Для этого введите указанные ниже команды:
```
sc config gpsvc start= auto sc start gpsvc gpupdate /force 
```
Если изменение отменено, это означает, что проблема вызывается политикой Active Directory.

Обходной путь

В качестве обходного решения для подключения к виртуальной машине и устранения причины можно временно отключить NLA. Чтобы отключить NLA, используйте приведенные ниже команды или DisableNLA скрипт в разделе Выполнить команду.
```
REM Disable the Network Level Authentication reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 
```
Затем перезапустите виртуальную машину и перейдите к разделу об устранении неполадок.

После устранения проблемы повторно включите NLA, выполнив следующие команды, а затем перезапустите виртуальную машину:
```
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds /t REG_DWORD /d 0 /f REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /f 
```
Устранение неполадок
1. Устранение неполадок виртуальных машин, присоединенных к домену.
2. Устранение неполадок с автономными виртуальными машинами.
Устранение неполадок виртуальных машин, присоединенных к домену

Чтобы устранить эту проблему, выполните приведенные ниже действия.
1. Проверьте, может ли виртуальная машина подключаться к контроллеру домена.
2. Проверьте работоспособность контроллера домена.
Для проверки работоспособности контроллера домена можно использовать другую виртуальную машину, которая находится в той же виртуальной сети, подсети и использует тот же сервер входа.

Подключитесь к виртуальной машине, на которую возникла проблема, с помощью последовательной консоли, удаленного CMD или удаленного PowerShell в соответствии с инструкциями, описанными в разделе Удаленное подключение к виртуальной машине .
```
set | find /i "LOGONSERVER" 
```
```
Test-ComputerSecureChannel -verbose 
```
Если канал не работает, выполните следующую команду, чтобы восстановить его:
```
Test-ComputerSecureChannel -repair 
```
```
Reset-ComputerMachinePassword -Server "" -Credential
```
Если обмен данными между контроллером домена и виртуальной машиной является хорошим, но контроллер домена недостаточно работоспособен для открытия сеанса RDP, можно попробовать перезапустить контроллер домена.

Если предыдущие команды не исправили проблему связи с доменом, вы можете повторно присоединить эту виртуальную машину к домену. Для этого выполните следующие действия:
```
cmd /c "netdom remove > /domain:> /userD:> /passwordD:> /reboot:10 /Force" 
```
```
cmd /c "netdom join > /domain:> /userD:> /passwordD:> /reboot:10" 
```
При этом виртуальная машина в домене присоединяется с использованием указанных учетных данных.

Если канал Active Directory работоспособен, пароль компьютера обновляется, а контроллер домена работает должным образом, попробуйте выполнить следующие действия.

Если проблема не исчезнет, проверка, отключены ли учетные данные домена. Для этого откройте окно командной строки с повышенными привилегиями и выполните следующую команду, чтобы определить, настроена ли виртуальная машина для отключения учетных записей домена для входа в виртуальную машину:
```
REG query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds 
```
Если для ключа задано значение 1, это означает, что сервер был настроен для запрета учетных данных домена. Измените этот ключ на 0.

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

Проверьте MinEncryptionLevel

В экземпляре CMD выполните следующую команду, чтобы запросить значение реестра MinEncryptionLevel :
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel 
```
В зависимости от значения реестра выполните следующие действия.
- 4 (FIPS): проверьте подключения, совместимые с алгоритмами FIP.
- 3 (128-разрядное шифрование): задайте для серьезности значение 2, выполнив следующую команду:
```
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel /t REG_DWORD /d 2 /f 
```
```
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel /t REG_DWORD /d 1 /f 
```
Перезапустите виртуальную машину, чтобы изменения реестра вступили в силу.

Версия TLS

В зависимости от системы RDP использует протокол TLS 1.0, 1.1 или 1.2 (сервер). Чтобы запросить настройку этих протоколов на виртуальной машине, откройте экземпляр CMD и выполните следующие команды:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled 
```
Если возвращаемые значения не являются 1, это означает, что протокол отключен. Чтобы включить эти протоколы, выполните следующие команды:
```
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f 
```
Для других версий протокола можно выполнить следующие команды:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS x.x\Server" /v Enabled reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS x.x\Server" /v Enabled 
```
Получите версию X.x SSH/TLS из журналов гостевой ОС об ошибках SCHANNEL.

Проверка подключений к алгоритмам, совместимым с FIP

Удаленный рабочий стол можно принудительно использовать только подключения алгоритма, совместимые с FIP. Это можно задать с помощью раздела реестра. Для этого откройте окно командной строки с повышенными привилегиями и запросите следующие ключи:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled 
```
Если команда возвращает значение 1, измените значение реестра на 0.
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled /t REG_DWORD /d 0 
```
Проверьте текущий minEncryptionLevel на виртуальной машине:
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel 
```
Если команда возвращает значение 4, измените значение реестра на 2.
```
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel /t REG_DWORD /d 2 
```
Перезапустите виртуальную машину, чтобы изменения реестра вступили в силу.

Дальнейшие действия
- Метод SetEncryptionLevel класса Win32_TSGeneralSetting
- Настройка уровней проверки подлинности и шифрования сервера
- класс Win32_TSGeneralSetting
Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.

Обратная связь

Были ли сведения на этой странице полезными?

Обратная связь

Отправить и просмотреть отзыв по

Проверка подлинности на уровне сети

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

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

Для того, чтобы Вы могли со своего компьютера под управлением ОС Windows XP подключиться к удаленному рабочему столу сервера необходимо установить Service Pack 3 (SP3), а после сделать следующее:

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

Так же Вам доступна англоязычная страница https://support.microsoft.com/en-us/kb/951608 на которой Вы можете скачать данный файл нажав кнопку «Download» в разделе «How to turn on CredSSP»

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

После того как загрузка файла будет закончена запустите его на выполнение. После запуска данного файла Вы увидите окно программы. В нем на первом шаге установите галочку на «Принимаю». На втором шаге нажмите кнопку «Далее»

По выполнению установки Вы увидите следующее окно с уведомлением «Это исправление Microsoft Fix it было обработано» Вам остается только нажать «Закрыть».

После того как Вы нажали кнопку «Закрыть» программа укажет Вам чтобы изменения вступили в силу необходима перезагрузка компьютера, нажмите «Да» чтобы перезагрузить.

Далее пробуем вновь подключаться к серверу и видим, что проверка подлинности на уровне сети происходит и подключение к серверу работает нормально.

Вам необходимо только указать Ваш логин и пароль, для доступа к серверу (см. в личном кабинете).

Решить проблему самостоятельно без загрузки файла

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

1. Нажмите кнопку Пуск (Start), выберите пункт Выполнить (Run), введите команду regedit и нажмите клавишу Ввод (Enter)

2. В области переходов найдите и выделите следующий подраздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. В области сведений найдите параметр Security Packages и нажмите кнопку Изменить (Modify)

4. В поле Значение (Value) введите tspkg, остальные параметры оставьте без изменений и нажмите кнопку ОК

5. В области переходов найдите и выделите следующий подраздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
6. В области сведений найдите параметр SecurityProviders и нажмите кнопку Изменить (Modify)

7. В поле Значение (Value) введите credssp.dll, остальные параметры оставьте без изменений и нажмите кнопку ОК

Не удается установить подключение к терминальной ферме

Добрый день! Уважаемые читатели и гости компьютерного блога pyatilistnik.org. В последнее время я очень часто пишу, об ошибках которые встречаю в работе подключения к терминальному серверу или фермам RDS. Технология отличная, но как водится у Microsoft, имеет ряд сложностей. Сегодня я хочу с вами поделиться, каким образом решается ошибка при попытке пользователем подключиться к удаленному серверу для повседневной работы и звучит она вот так «Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена«. Ниже будет описан метод моего решения.

Как выглядит ошибка подключения

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

Клиентский компьютер работает на операционной системе Windows 10 1709, терминальная ферма собрана из Windows Server 2012 R2, выступающих в роли хостов для подключения, в качестве посредников подключения (Connection Broker) выступают два сетевых балансировщика Kemp LoadMaster. И все как обычно, вчера работало, сегодня нет.

Варианты устранения проблемы с подключением по RDP

Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена
- Первое, что нужно сделать, это проверить DNS записи, которые отвечают за резолвинг имени фермы, сделать это можно с помощью команды nslookup. Открываем командную строку или power shell и вводим там команду:
nslookup имя вашего терминального сервера

Как видим имя ts4.pyatilistnik.org разрезолвилось в два ip адреса, и применив команду ping мы видим, что сервер отвечает и его TTL 64, что говорит, что в роли Connection Broker выступает, что-то на операционной системе Linux. Проверьте по записям, правильно ли разрешается имя, в нужные ли ip адреса.
- Если с записями все хорошо, то нужно посмотреть логи системы на посредниках к подключению, это как раз те сервера, которые отвечают по команде nslookup, хочу отметить, что Connection Broker может и не быть, и DNS может перекидывать на членов фермы, по технологии Round robin, простым перебором, где могут быть проблемы либо с отдельной нодой, либо со всеми, об этом мы поговорим ниже. Очень часто, достаточно перезагрузить посредника, удобно если их два в HA.
Как я и писал выше в моем случае в роли посредником по подключению выступают две сетевые железки Kemp LoadMaster. Заходим в веб интерфейс, переходим в пункт «View/Modify Services». В данном пункте будут описаны правила, которые обрабатывает Kemp LoadMaster. Вижу, что у меня есть правило TS4. В столбце Real Servers я вижу на какие сервера оно применяется. Тут логика какая, создается виртуальный интерфейс отвечающий по нужному порту, в данном случае 3389, и идет форвардин на список Real Servers по разным критериям, коих у Kemp много.

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

Редактируем правило, через кнопку Modify. Находим в списке IP Address нужный вам сервер и выключаем/Удаляем его соответствующей кнопкой.

Посмотреть список шаблонов на Kemp LoadMaster можно на вкладке Manage Template, они подгружаются сюда отдельно с официального сайта

https://support.kemptechnologies.com/hc/en-us/articles/210136133-Templates

После этих манипуляций ошибка ушла.
- Если у вас нет Kemp LoadMaster или нет вообще Connection Broker, то попробуйте подключиться не по DNS имени фермы, а отдельно по RDP на конечный хост (Session Host). Проверьте, что у него стоят правильные настройки проверки подлинности.
Для этого зайдите в свойства системы, на вкладке «Удаленный доступ» проверьте наличие галки:

NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети

Так же в такой ситуации, когда был конфликт в версиях RDP клиента и вам отвечает не Session Host являющийся членом фермы, а как в моем случае левый сервер, то выскакивала ошибка: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору

PS. Советую сделать на каждом сервере, что входит в состав терминальной фермы команду RSOP в командной строке, чтобы понять какие групповые политики прилетают и посмотрите, что у вас там

Как отключить NLA (Network Level Authentication)

Если у вас еще много не обновленных клиентов со старыми версиями RDP, то можете отключить пока NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети. Либо вручную, как я показывал, выше, но правильнее это сделать централизованно.

Если захотите воспользоваться реестром Windows, а потом раскидать ключик, через тужу политику. то вам нужна ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. В ней найдите ключ SecurityLayer и поставьте ему значение 0. Это отключит NLA (Network Level Authentication).

Обновление 28.11.2022

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

Если вам известны еще какие-либо методы решения, то просьба написать о них в комментариях.

Популярные Похожие записи:
- Ошибка Cannot create another system semaphore на RDS ферме
- Бесконечное подключение по RDP в Windows 11
- Перенастройка базы данных RDS фермы
- Ошибка Remote Desktop Connection Broker Client failed to redirect the user
- Ошибка The number of connections to this computer is limited
- Ошибка RDS: Cannot get role and feature data
Пользователь не может пройти проверку подлинности или должен пройти проверку подлинности дважды

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

Доступ запрещен, ограниченный тип входа

В этом случае пользователю Windows 10, пытающимся подключиться к Windows 10 или Windows Server 2016 компьютерам, будет отказано в доступе со следующим сообщением:

Подключение к удаленному рабочему столу. Системный администратор ограничил тип входа (сетевой или интерактивный), который вы можете использовать. За помощью обратитесь к системному администратору или в службу технической поддержки.

Эта проблема возникает, когда для подключений по протоколу RDP требуется проверка подлинности на уровне сети (NLA), а пользователь не является членом группы «Пользователи удаленного рабочего стола «. Это также может произойти, если группа «Пользователи удаленного рабочего стола » не назначена право доступа к этому компьютеру из сетевого пользователя.

Чтобы решить эту проблему, выполните одно из следующих действий.
- Измените членство пользователя в группе или назначение прав пользователя.
- Отключите NLA (не рекомендуется).
- Используйте клиенты удаленного рабочего стола, отличные от Windows 10. Например, у клиентов Windows 7 нет этой проблемы.
Изменение членства пользователя в группе или назначения прав пользователя

Если эта проблема затрагивает одного пользователя, наиболее простым решением этой проблемы является добавление пользователя в группу «Пользователи удаленного рабочего стола «.

Если пользователь уже является членом этой группы (или у нескольких участников группы есть одна проблема), проверка конфигурацию прав пользователя на удаленном Windows 10 или Windows Server 2016 компьютере.
1. Откройте редактор объектов групповая политика (GPE) и подключитесь к локальной политике удаленного компьютера.
2. Перейдите в раздел Конфигурация\ компьютераПараметры\Windows Параметры безопасности Локальные\политики\Назначение прав пользователя, щелкните правой кнопкой мыши доступ к этому компьютеру из сети и выберите Свойства.
3. Проверьте список пользователей и групп для пользователей удаленного рабочего стола (или родительской группы).
4. Если список не включает ни пользователей удаленного рабочего стола , ни родительскую группу , например Все, необходимо добавить ее в список. Если в развертывании несколько компьютеров, используйте объект групповой политики. Например, членство по умолчанию для доступа к этому компьютеру из сети включает все. Если в развертывании для удаления всех используется объект групповой политики, может потребоваться восстановить доступ, обновив объект групповой политики, чтобы добавить пользователей удаленных рабочих столов.
Доступ запрещен, удаленный вызов базы данных SAM запрещен

Это поведение, скорее всего, произойдет, если контроллеры домена работают Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настраиваемого приложения для подключения. В частности, приложениям, которые получают доступ к данным профиля пользователя в Active Directory, будет отказано в доступе.

Это поведение является результатом изменения Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь входит в удаленный рабочий стол, удаленный диспетчер подключений (RCM) обращается к контроллеру домена (DC) для запроса конфигураций, относящихся к удаленному рабочему столу, в объекте пользователя в доменные службы Active Directory (AD DS). Эти сведения отображаются на вкладке Профиль служб удаленных рабочих столов свойств объекта пользователя в оснастке ПОЛЬЗОВАТЕЛИ И КОМПЬЮТЕРЫ ACTIVE DIRECTORY MMC.

Начиная с Windows Server 2016 RCM больше не запрашивает объект пользователя в AD DS. Если вам требуется RCM для запроса AD DS, так как вы используете атрибуты служб удаленных рабочих столов, необходимо вручную включить запрос.

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

Чтобы включить устаревшее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра, а затем перезапустите службу служб удаленных рабочих столов :
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\\
  - Имя: fQueryUserConfigFromDC
  - Тип: Reg_DWORD
  - Значение: 1 (десятичное)
  Чтобы включить устаревшее поведение RCM на сервере, отличном от сервера узла сеансов удаленных рабочих стола, настройте следующие записи реестра и следующую дополнительную запись реестра (а затем перезапустите службу):
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
  
  Пользователь не может войти в систему с помощью смарт-карта
  
  В этом разделе рассматриваются три распространенных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью интеллектуальной карта.
  
  Не удается выполнить вход с помощью интеллектуальной карта в филиале с контроллером домена только для чтения (RODC)
  
  Эта проблема возникает в развертываниях, включающих сервер RDSH на сайте филиала, использующем RODC. Сервер RDSH размещается в корневом домене. Пользователи на сайте филиала принадлежат к дочернему домену и используют смарт-карты для проверки подлинности. RODC настроен для кэширования паролей пользователей (RODC принадлежит к группе разрешенной репликации паролей RODC). Когда пользователи пытаются войти в сеансы на сервере RDSH, они получают такие сообщения, как «Попытка входа в систему недопустима. Это происходит из-за неправильного имени пользователя или сведений о проверке подлинности».
  
  Эта проблема вызвана тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователя. Корневой контроллер домена использует ключ шифрования для шифрования учетных данных, а RODC передает клиенту ключ расшифровки. Когда пользователь получает ошибку «недопустимая», то есть два ключа не совпадают.
  
  Чтобы обойти эту проблему, попробуйте выполнить одно из следующих действий.
  - Измените топологию контроллера домена, отключив кэширование паролей в RODC или разверните на сайте филиала доступный для записи контроллер домена.
  - Переместите сервер RDSH в тот же дочерний домен, что и пользователи.
  - Разрешить пользователям выполнять вход без смарт-карт.
  Имейте в виду, что все эти решения требуют компрометации с точки зрения производительности или уровня безопасности.
  
  Пользователь не может войти на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2) с помощью интеллектуальной карта
  
  Эта проблема возникает при входе пользователей на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2), который был обновлен с помощью KB4093227 (2018.4B). Когда пользователи пытаются войти с помощью смарт-карта, им отказано в доступе с помощью таких сообщений, как «Допустимые сертификаты не найдены. Убедитесь, что карта вставляется правильно и плотно помещается». В то же время компьютер Windows Server записывает событие приложения «Произошла ошибка при получении цифрового сертификата из вставленного смарт-карта. Недопустимая подпись».
  
  Не удается выполнить вход с помощью интеллектуальной карта и служба служб удаленных рабочих столов зависает
  
  Эта проблема возникает при входе пользователей на компьютер с Windows или Windows Server, который был обновлен с 4056446 базы знаний. Сначала пользователь может войти в систему с помощью смарт-карта, но затем получает сообщение об ошибке «SCARD_E_NO_SERVICE». Удаленный компьютер может перестать отвечать.
  
  Чтобы обойти эту проблему, перезагрузите удаленный компьютер.
  
  Чтобы устранить эту проблему, обновите на удаленном компьютере соответствующее исправление:
  - Windows Server 2008 с пакетом обновления 2 (SP2): кб 4090928, дескриптора утечек Windows в процессе lsm.exe, а приложения интеллектуальной карта могут отображать ошибки «SCARD_E_NO_SERVICE»
  - Windows Server 2012 R2: KB 4103724, 17 мая 2018 г. KB4103724 г. (предварительная версия ежемесячного накопительного пакета)
  - Windows Server 2016 и Windows 10 версии 1607: KB 4103720, 17 мая 2018 г. KB4103720 г. (сборка ОС 14393.2273)
  Если удаленный компьютер заблокирован, пользователю необходимо ввести пароль дважды.
  
  Эта проблема может возникнуть, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, в котором подключения RDP не требуют NLA. В этих условиях, если удаленный рабочий стол заблокирован, пользователю необходимо дважды ввести свои учетные данные при подключении.
  
  Чтобы устранить эту проблему, обновите компьютер Windows 10 версии 1709 с 4343893 кб, 30 августа 2018 г. по KB4343893 г. (сборка ОС 16299.637).
  
  Пользователь не может войти в систему и получает сообщения об ошибке проверки подлинности и исправлении шифрования CredSSP
  
  Когда пользователи пытаются войти в систему с помощью любой версии Windows из Windows Vista с пакетом обновления 2 (SP2) и более поздних версий или Windows Server 2008 с пакетом обновления 2 (SP2) и более поздних версий, им отказано в доступе и получать такие сообщения:
  
  Произошла ошибка определения подлинности. Указанная функция не поддерживается. . Это может быть связано с исправлением оракула шифрования CredSSP .
  
  «Исправление oracle шифрования CredSSP» относится к набору обновлений для системы безопасности, выпущенных в марте, апреле и мае 2018 года. CredSSP — это поставщик проверки подлинности, обрабатывающий запросы проверки подлинности для других приложений. 13 марта 2018 г., «3B» и последующие обновления касались эксплойтов, при которых злоумышленник мог ретранслировать учетные данные пользователя для выполнения кода в целевой системе.
  
  В первоначальных обновлениях добавлена поддержка нового объекта групповая политика , Encryption Oracle Remediation, который имеет следующие возможные параметры:
  - Уязвимые. Клиентские приложения, использующие CredSSP, могут вернуться к небезопасным версиям, но это поведение подвергает удаленные рабочие столы атакам. Службы, использующие CredSSP, принимают клиенты, которые не были обновлены.
  - Исправлено. Клиентские приложения, использующие CredSSP, не могут вернуться к небезопасным версиям, но службы, использующие CredSSP, принимают клиенты, которые не были обновлены.
  - Принудительное обновление клиентов. Клиентские приложения, использующие CredSSP, не могут вернуться к небезопасным версиям, а службы, использующие CredSSP, не будут принимать непатшированные клиенты.
  Примечание. Этот параметр не следует развертывать до тех пор, пока все удаленные узлы не поддерживают последнюю версию.
  
  В обновлении от 8 мая 2018 г. значение по умолчанию Для шифрования Oracle исправление было изменено с Уязвимый на Смягчаемая. После этого изменения клиенты удаленного рабочего стола с обновлениями не могут подключаться к серверам, на которых их нет (или к обновленным серверам, которые не были перезапущены). Дополнительные сведения об обновлениях CredSSP см. в 4093492 базы знаний.
  
  Чтобы устранить эту проблему, обновите и перезапустите все системы. Полный список обновлений и дополнительные сведения об уязвимостях см. в разделе CVE-2018-0886 | Уязвимость credSSP, связанная с удаленным выполнением кода.
  
  Чтобы обойти эту проблему до завершения обновлений, проверка КБ 4093492 для разрешенных типов подключений. Если альтернативных вариантов нет, можно рассмотреть один из следующих методов:
  - Для затронутых клиентских компьютеров задайте для политики исправления Oracle шифрование значение Уязвимое.
  - Измените следующие политики в папке групповой политикибезопасности узласеансов удаленных рабочих столов Службы удаленных рабочих столов впапке «Административные шаблоны\конфигурации\ компьютера» Windows Components \Remote Desktop Services\ \:
    - Требовать использования определенного уровня безопасности для удаленных подключений (RDP): установите значение Включено и выберите RDP.
    - Требовать проверку подлинности пользователя для удаленных подключений с помощью проверки подлинности на уровне сети: установите значение Отключено.
    Важно! Изменение этих групповых политик снижает безопасность развертывания. Мы рекомендуем использовать их только временно, если они вообще.
    
    Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики.
    
    После обновления клиентских компьютеров некоторые пользователи должны дважды войти в систему.
    
    Когда пользователи входят в удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, они сразу же увидят второй запрос на вход. Эта проблема возникает, если на клиентском компьютере имеются следующие обновления:
    - Windows 7: KB 4103718, 8 мая 2018 г. KB4103718 г. (ежемесячный накопительный пакет)
    - Windows 10 1709: KB 4103727, 8 мая 2018 г. KB4103727 г. (сборка ОС 16299.431)
    Чтобы устранить эту проблему, убедитесь, что компьютеры, к которым пользователи хотят подключиться (а также серверы RDSH или RDVI), полностью обновлены до июня 2018 г. Сюда входят следующие обновления:
    - Windows Server 2016: KB 4284880, 12 июня 2018 г. KB4284880 г. (сборка ОС 14393.2312)
    - Windows Server 2012 R2: KB 4284815, 12 июня 2018 г. KB4284815 г. (ежемесячный накопительный пакет)
    - Windows Server 2012: KB 4284855, 12 июня 2018 г. KB4284855 г. (ежемесячный накопительный пакет)
    - Windows Server 2008 R2: kb 4284826, 12 июня 2018 г. KB4284826 г. (ежемесячный накопительный пакет)
    - Windows Server 2008 с пакетом обновления 2 (SP2): KB4056564, описание обновления для системы безопасности для уязвимости удаленного выполнения кода CredSSP в Windows Server 2008, Windows Embedded POSReady 2009 и Windows Embedded Standard 2009: 13 марта 2018 г.
    Пользователям отказано в доступе в развертывании, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу
    
    Эта проблема возникает в развертываниях с высоким уровнем доступности, использующих два или более брокера подключения к удаленному рабочему столу, если используется Защитник Windows Remote Credential Guard. Пользователи не могут войти на удаленные рабочие столы.
    
    Эта проблема возникает из-за того, что Remote Credential Guard использует Kerberos для проверки подлинности и ограничивает NTLM. Однако в конфигурации с высоким уровнем доступности с балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.
    
    Если вам нужно использовать конфигурацию высокого уровня доступности с брокерами подключений к удаленному рабочему столу с балансировкой нагрузки, вы можете обойти эту проблему, отключив Remote Credential Guard. Дополнительные сведения об управлении Защитник Windows Remote Credential Guard см. в статье Защита учетных данных удаленного рабочего стола с помощью Защитник Windows Remote Credential Guard.
    
    Обратная связь
    
    Были ли сведения на этой странице полезными?
    Похожие публикации: