Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Описание проблемы

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

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

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

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: «Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя»

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 — именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

04:45.940011-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: SrcUserName1: svc-1c@DOMAIN701.COM
04:45.940012-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
04:45.971001-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName2: DOMAIN701\testuser2(DOMAIN701\testuser2)
04:46.205021-0,EXCP,2,process=rphost,p:processName=trade,t:clientID=60,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=19,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

Заменить значение свойства «Пользователь» пользователя информационной базы согласно следующему формату «\\» + [Имя пользователя из свойства DstUserName2 без скобок].

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

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

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

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: winserver1c$@DOMAIN701.COM
56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON )
56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

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

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

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Пользователь не может выполнить аутентификацию или должен выполнить ее дважды User can’t authenticate or must authenticate twice

В этой статье описаны некоторые причины проблем с аутентификацией пользователей. This article addresses several issues that can cause problems that affect user authentication.

Отказано в доступе (ограничение по типу входа в систему) Access denied, restricted type of logon

В этом случае пользователь Windows 10, который пытается подключиться к компьютерам с Windows 10 или Windows Server 2016, получит отказ в доступе со следующим сообщением: In this situation, a Windows 10 user attempting to connect to Windows 10 or Windows Server 2016 computers is denied access with the following message:

Подключение к удаленному рабочему столу Remote Desktop Connection:
Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. The system administrator has restricted the type of logon (network or interactive) that you may use. Обратитесь за помощью к системному администратору или в службу технической поддержки. For assistance, contact your system administrator or technical support.

Эта проблема возникает, если для подключения к удаленному рабочему столу требуется пройти проверку подлинности на уровне сети (NLA), но пользователь не является членом группы Пользователи удаленного рабочего стола. This issue occurs when Network Level Authentication (NLA) is required for RDP connections, and the user is not a member of the Remote Desktop Users group. Она также может возникать, если группе Пользователи удаленного рабочего стола не назначено право пользователя Доступ к компьютеру из сети. It can also occur if the Remote Desktop Users group has not been assigned to the Access this computer from the network user right.

Чтобы решить эту проблему, выполните одно из указанных ниже действий. To solve this issue, do one of the following things:

• Измените членство пользователя в группах или назначенные ему права. Modify the user’s group membership or user rights assignment.
• Отключите NLA (не рекомендуется). Turn off NLA (not recommended).
• Используйте клиенты удаленного рабочего стола, отличающиеся от Windows 10. Use remote desktop clients other than Windows 10. Например, в клиентах Windows 7 нет такой проблемы. For example, Windows 7 clients do not have this issue.

Изменение членства пользователя в группах или назначенных ему прав Modify the user’s group membership or user rights assignment

Если эта проблема затрагивает одного пользователя, наиболее простым решением будет добавить этого пользователя в группу Пользователи удаленного рабочего стола. If this issue affects a single user, the most straightforward solution to this issue is to add the user to the Remote Desktop Users group.

Если пользователь уже является членом этой группы (или если проблема возникает у нескольких членов группы), проверьте конфигурацию прав пользователей на удаленном компьютере Windows 10 или Windows Server 2016. If the user is already a member of this group (or if multiple group members have the same problem), check the user rights configuration on the remote Windows 10 or Windows Server 2016 computer.

1. Откройте редактор объектов групповой политики (GPE) и подключитесь к локальной политике удаленного компьютера. Open Group Policy Object Editor (GPE) and connect to the local policy of the remote computer.
2. Выберите Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя, щелкните правой кнопкой мыши элемент Доступ к компьютеру из сети и выберите Свойства. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment, right-click Access this computer from the network, and then select Properties.
3. Просмотрите список пользователей и групп для группы Пользователи удаленного рабочего стола (или родительской группы). Check the list of users and groups for Remote Desktop Users (or a parent group).
4. Если список не включает группу Пользователи удаленного рабочего стола или родительскую группу, например Все, добавьте их. If the list doesn’t include either Remote Desktop Users or a parent group like Everyone, you must add it to the list. Если развертывание включает больше одного компьютера, используйте объект групповой политики. If you have more than one computer in your deployment, use a group policy object.
   Например, членством по умолчанию для политики Доступ к компьютеру из сети будет Все. For example, the default membership for Access this computer from the network includes Everyone. Если в развертывании используется объект групповой политики для удаления Все, может потребоваться восстановить доступ, обновив объект групповой политики, чтобы добавить группу Пользователи удаленного рабочего стола. If your deployment uses a group policy object to remove Everyone, you may need to restore access by updating the group policy object to add Remote Desktop Users.

Отказано в доступе (удаленный вызов к базе данных SAM отклонен) Access denied, A remote call to the SAM database has been denied

Такое поведение обычно возникает, если контроллеры домена работают под управлением Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настраиваемого приложения для подключения. This behavior is most likely to occur if your domain controllers are running Windows Server 2016 or later, and users attempt to connect by using a customized connection app. В частности, отказ в доступе получат приложения, которым требуется доступ к сведениям профиля пользователя в Active Directory. In particular, applications that access the user’s profile information in Active Directory will be denied access.

Такое поведение обусловлено изменением в Windows. This behavior results from a change to Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь выполняет вход на удаленный рабочий стол, диспетчер удаленных подключений (RCM) обращается к контроллеру домена (DC), чтобы запросить конфигурацию, относящуюся к удаленному рабочему столу, в объекте пользователя в доменных службах Active Directory (AD DS). In Windows Server 2012 R2 and earlier versions, when a user signs in to a remote desktop, the Remote Connection Manager (RCM) contacts the domain controller (DC) to query the configurations that are specific to Remote Desktop on the user object in Active Directory Domain Services (AD DS). Эта информация отображается на вкладке «Профиль служб удаленных рабочих столов» в окне свойств объекта пользователя в оснастке MMC «Пользователи и компьютеры Active Directory». This information is displayed in the Remote Desktop Services Profile tab of a user’s object properties in the Active Directory Users and Computers MMC snap-in.

Начиная с Windows Server 2016 RCM больше не запрашивает объект пользователя в AD DS. Starting in Windows Server 2016, RCM no longer queries the user’s object in AD DS. Если требуется, чтобы RCM обращался к AD DS из-за того, что вы используете атрибуты служб удаленных рабочих столов, вам нужно вручную разрешить отправку запросов. If you need RCM to query AD DS because you’re using Remote Desktop Services attributes, you must manually enable the query.

Внимательно выполните действия, описанные в этом разделе. Follow the steps in this section carefully. Неправильное изменение реестра может привести к серьезным проблемам. Serious problems might occur if you modify the registry incorrectly. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем. Before you modify it, back up the registry for restoration in case problems occur.

Чтобы разрешить прежнее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра и перезапустите службу Службы удаленных рабочих столов: To enable the legacy RCM behavior on a RD Session Host server, configure the following registry entries, and then restart the Remote Desktop Services service:

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ \
  • Имя: fQueryUserConfigFromDC. Name: fQueryUserConfigFromDC
  • Введите команду: Reg_DWORD. Type: Reg_DWORD
  • Значение: 1 (десятичное число). Value: 1 (Decimal)

Чтобы разрешить устаревшее поведение RCM на сервере, отличающемся от сервера RDSH, настройте эти записи реестра и следующую дополнительную запись (затем перезапустите службу). To enable the legacy RCM behavior on a server other than a RD Session Host server, configure these registry entries and the following additional registry entry (and then restart the service):

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal ServerHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

Дополнительные сведения об этом поведении см. в статье базы знаний № 3200967 Changes to Remote Connection Manager in Windows Server (Внесение изменений в диспетчер удаленных подключений в Windows Server). For more information about this behavior, see KB 3200967 Changes to Remote Connection Manager in Windows Server.

Пользователю не удается выполнить вход с помощью смарт-карты User can’t sign in using a smart card

В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты. This section addresses three common scenarios where a user can’t sign in to a remote desktop using a smart card.

Не удается войти в систему с помощью смарт-карты в филиале с контроллером домена только для чтения (RODC) Can’t sign in with a smart card in a branch office with a read-only domain controller (RODC)

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC. This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. Сервер RDSH размещен в корневом домене. The RDSH server is hosted in the root domain. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности. Users at the branch site belong to a child domain, and use smart cards for authentication. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC. The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему. When users try to sign in to sessions on the RDSH server, they receive messages such as «The attempted logon is invalid. Указано неверное имя пользователя или другие неверные личные данные.» This is either due to a bad username or authentication information.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей. This issue is caused by how the root DC and the RDOC manage user credential encryption. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту. The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают. When a user receives the «invalid» error, that means the two keys don’t match.

Чтобы решить эту проблему, выполните одно из указанных ниже действий: To work around this issue, try one of the following things:

• измените топологию контроллера домена, отключив кэширование паролей на RODC, или разверните на сайте филиала контроллер домена с доступом на запись; Change your DC topology by turning off password caching on the RODC or deploy a writeable DC to teh branch site.
• переместите сервер RDSH в тот же дочерний домен, где находятся пользователи; Move the RDSH server to the same child domain as the users.
• разрешите пользователям выполнять вход без смарт-карты. Allow users to sign in without smart cards.

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности. Be advised that all of these solutions require compromises in either performance or security level.

Пользователь не может войти на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2) с помощью смарт-карты User can’t sign in to a Windows Server 2008 SP2 computer using a smart card

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B). This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены. When users attempt to sign in using a smart card, they are denied access with messages such as «No valid certificates found. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме». Check that the card is inserted correctly and fits tightly.» В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка: At the same time, the Windows Server computer records the Application event «An error occurred while retrieving a digital certificate from the inserted smart card. неправильная подпись.» Invalid Signature.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.). To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Не удается оставаться в системе, вход в которую выполнен с помощью смарт-карты, и служба удаленных рабочих столов зависает Can’t stay signed in with a smart card and Remote Desktop Services service hangs

Эта проблема возникает, когда пользователи входят в систему компьютера Windows или Windows Server с обновлением KB4056446. This issue occurs when users sign in to a Windows or Windows Server computer that has been updated with KB 4056446. Возможно, сначала пользователю удается войти в систему с помощью смарт-карты, но потом он получает сообщение об ошибке SCARD_E_NO_SERVICE. At first, the user may be able to sign in to the system by using a smart card, but then receives a «SCARD_E_NO_SERVICE» error message. Удаленный компьютер может перестать отвечать. The remote computer may become unresponsive.

Чтобы устранить эту проблему, перезапустите удаленный компьютер. To work around this issue, restart the remote computer.

Чтобы устранить эту проблему, обновите систему на удаленном компьютере, установив соответствующее исправление: To resolve this issue, update the remote computer with the appropriate fix:

• Windows Server 2008 с пакетом обновления 2 (SP2): KB4090928 Windows leaks handles in the lsm.exe process and smart card applications may display SCARD_E_NO_SERVICE errors (Windows зависает на процессе lsm.exe, а в приложениях, для которых используются смарт-карты, может отображаться сообщение SCARD_E_NO_SERVICE). Windows Server 2008 SP2: KB 4090928, Windows leaks handles in the lsm.exe process and smart card applications may display «SCARD_E_NO_SERVICE» errors
• Windows Server 2012 R2: 17 мая 2018 г. — KB4103724 (ознакомительная версия ежемесячного накопительного пакета). Windows Server 2012 R2: KB 4103724, May 17, 2018—KB4103724 (Preview of Monthly Rollup)
• Windows Server 2016 и Windows 10 версии 1607: 17 мая 2018 г. — KB4103720 (сборка ОС 14393.2273). Windows Server 2016 and Windows 10, version 1607: KB 4103720, May 17, 2018—KB4103720 (OS Build 14393.2273)

Если удаленный компьютер заблокирован, пользователю нужно дважды ввести пароль If the remote PC is locked, the user needs to enter a password twice

Эта проблема может возникать, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, где для подключений по протоколу RDP не требуется использовать NLA. This issue may occur when a user attempts to connect to a remote desktop running Windows 10 version 1709 in a deployment in which RDP connections don’t require NLA. Если в таком случае удаленный рабочий стол оказался заблокированным, пользователю нужно ввести свои учетные данные дважды при подключении. Under these conditions, if the remote desktop has been locked, the user needs to enter their credentials twice when connecting.

Чтобы устранить эту проблему, обновите Windows 10 версии 1709 на соответствующем компьютере с использованием обновления за 30 августа 2018 г. — KB4343893 (ОС сборки 16299.637). To resolve this issue, update the Windows 10 version 1709 computer with KB 4343893, August 30, 2018—KB4343893 (OS Build 16299.637).

Пользователю не удается войти, при этом отображаются сообщения «Ошибка аутентификации» и «Защита CredSSP от атак с использованием криптографического оракула» User can’t sign in and receives «authentication error» and «CredSSP encryption oracle remediation» messages

Когда пользователи пытаются войти с использованием любой версии Windows (начиная с Windows Vista с пакетом обновления 2 (SP2) или Windows Server 2008 с пакетом обновления 2 (SP2)), они получают отказ в доступе и такие сообщения: When users try to sign in using any version of Windows from Windows Vista SP2 and later versions or Windows Server 2008 SP2 and later versions, they’re denied access and recieve messages like these:

Ошибка «Исправление шифрования CredSSP» ссылается на набор обновлений системы безопасности, выпущенный в марте, апреле и мае 2018 г. «CredSSP encryption oracle remediation» refers to a set of security updates released in March, April, and May of 2018. CredSSP — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. CredSSP is an authentication provider that processes authentication requests for other applications. Обновление за 13 марта 2018 г., 3B и все последующие обновления подверглись эксплойту, когда злоумышленник мог передать учетные данные пользователя для выполнения кода в целевой системе. The March 13, 2018, «3B» and subsequent updates addressed an exploit in which an attacker could relay user credentials to execute code on the target system.

В исходные обновления была добавлена поддержка нового объекта групповой политики «Защита от атак с использованием криптографического оракула», который может иметь следующие настройки: The initial updates added support for a new Group Policy Object, Encryption Oracle Remediation, that has the following possible settings:

• Уязвимо. Клиентские приложения, использующие CredSSP, могли переключиться на небезопасные версии, но из-за этого удаленные рабочие столы могли подвергаться атакам. Vulnerable: Client applications that use CredSSP can fall back to insecure versions, but this behavior exposes the remote desktops to attacks. Службы, использующие CredSSP, принимали клиенты, которые не были обновлены. Services that use CredSSP accept clients that have not been updated.
• Устранено. Клиентские приложения, использующие CredSSP, не могут переключиться на небезопасные версии, но службы, использующие CredSSP, принимают клиенты, которые не были обновлены. Mitigated: Client applications that use CredSSP can’t fall back to insecure versions, but services that use CredSSP accept clients that have not been updated.
• Принудительно обновленные клиенты. Клиентские приложения, использующие CredSSP, не могут переключиться на небезопасные версии, и службы, использующие CredSSP, не принимают клиенты без установленных обновлений. Force Updated Clients: Client applications that use CredSSP can’t fall back to insecure versions, and services that use CredSSP will not accept unpatched clients.

Этот параметр не следует развертывать, пока все узлы поддержки в удаленном расположении не будут поддерживать последнюю версию. This setting should not be deployed until all remote hosts support the newest version.

В обновлении за 8 мая 2018 г. значение для параметра по умолчанию «Защита от атак с использованием криптографического оракула» изменилось с «Уязвимо» на «Устранено». The May 8, 2018 update changed the default Encryption Oracle Remediation setting from Vulnerable to Mitigated. После реализации этого изменения клиенты Удаленного рабочего стола, на которых были установлены обновления, не могут подключаться к серверам без этого обновления (или к обновленным серверам, которые еще не были перезапущены). With this change in place, Remote Desktop clients that have the updates can’t connect to servers that don’t have them (or updated servers that have not been restarted). Подробные сведения об обновлениях CredSSP см. в статье базы знаний KB4093492. For more information about the CredSSP updates, see KB 4093492.

Чтобы устранить эту проблему, обновите и перезапустите все системы. To resolve this issue, update and restart all systems. Полный список обновлений и дополнительные сведения об уязвимостях см. в разделе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability (CVE-2018-0886 | Уязвимость CredSSP, допускающая удаленное выполнение кода). For a full list of updates and more information about the vulnerabilities, see CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability.

Чтобы устранить эту проблему до завершения обновления, просмотрите список допустимых типов подключений в обновлении KB4093492. To work around this issue until the updates are complete, check KB 4093492 for allowed types of connections. Если нет других осуществимых альтернатив, можете попробовать один из следующих методов: If there are no feasible alternatives you may consider one of the following methods:

• На затронутых клиентских компьютерах верните для политики «Защита от атак с использованием криптографического оракула» значение Уязвимо. For the affected client computers, set the Encryption Oracle Remediation policy back to Vulnerable.
• Измените следующие политики в папке групповой политики, выбрав Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Безопасность: Modify the following policies in the Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security group policy folder:
  • для политики Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP задайте значение Включено и выберите RDP. Require use of specific security layer for remote (RDP) connections: set to Enabled and select RDP.
  • для политики Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети задайте значение Отключено. Require user authentication for remote connections by using Network Level authentication: set to Disabled.

  Изменение этих групповых политик делает развертывание менее защищенным. Changing these group policies reduces your deployment’s security. Мы рекомендуем использовать их только временно (или вообще не использовать). We recommend you only use them temporarily, if at all.

  Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики. For more information about working with group policy, see Modifying a blocking GPO.

  После обновления клиентских компьютеров некоторым пользователям приходится выполнять вход дважды After you update client computers, some users need to sign in twice

  Если пользователи входят на Удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, им сразу же отображается запрос на повторный вход. When users sign in to Remote Desktop using a computer running Windows 7 or Windows 10, version 1709, they immediately see a second sign-in prompt. Эта проблема возникает, если на клиентском компьютере установлены следующие обновления: This issue happens if the client computer has the following updates:

  Чтобы устранить эту проблему, убедитесь, что на компьютерах, к которым подключаются пользователи, (а также серверы RDSH или RDVI) установлены все обновления в том числе за июнь 2018 г. To resolve this issue, ensure that the computers that the users want to connect to (as well as RDSH or RDVI servers) are fully updated through June, 2018. К ним относятся следующие обновления: This includes the following updates:

  Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу Users are denied access on a deployment that uses Remote Credential Guard with multiple RD Connection Brokers

  Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. This issue occurs in high-availability deployments that use two or more Remote Desktop Connection Brokers, if Windows Defender Remote Credential Guard is in use. Пользователям не удается войти на удаленные рабочие столы. Users can’t sign in to remote desktops.

  Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. This issue occurs because Remote Credential Guard uses Kerberos for authentication, and restricts NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos. However, in a high-availability configuration with load balancing, the RD Connection Brokers can’t support Kerberos operations.

  Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. If you need to use a high-availability configuration with load-balanced RD Connection Brokers, you can work around this issue by disabling Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows). For more information about how to manage Windows Defender Remote Credential Guard, see Protect Remote Desktop credentials with Windows Defender Remote Credential Guard.