Системный администратор ограничил количество компьютеров с которых вы можете войти в систему
В этой статье описаны некоторые причины проблем с аутентификацией пользователей.
Пользователю не удается выполнить вход с помощью смарт-карты
В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты.
Изменяем атрибут LogonWorkstations с помощью PowerShell
Вручную заполнять список компьютеров, на которые разрешено входить пользователю домена довольно утомительно. С помощью PowerShell можно автоматизировать это действие. Список компьютеров, на которые разрешено входить пользователю хранится в атрибуте пользователя в AD – LogonWorkstations. Например, наша задача разрешить определенному пользователю входить только на компьютеры, чьи имена содержатся в текстовом файле computers.csv (в этом примере в первой строке файла должно содержаться имя столбца – NetBIOSName).
Скрипт может выглядеть так (сначала загружаем модуль AD для Powershell):
Import-Module ActiveDirectory
$ADusername = ‘aapetrov’
$complist = Import-Csv -Path "C:\PS\computers.csv" | ForEach-Object
$comparray = $complist -join ","
Set-ADUser -Identity $ADusername -LogonWorkstations $comparray
Clear-Variable comparray
С помощью командлета Get-ADUser команды можно вывести список компьютеров, на которые разрешено входить пользователю:
Get-ADUser $ADusername -Properties LogonWorkstations | Format-List Name, LogonWorkstations
Либо можно посмотреть список компьютеров в консоли ADUC.
Чтобы добавить в список новый компьютер, воспользуйтесь такой командой:
$Wks = (Get-ADUser dvivannikov -Properties LogonWorkstations).LogonWorkstations
$Wks += ",newpc"
Set-ADUser aapetrov -LogonWorkstations $Wks
После обновления клиентских компьютеров некоторым пользователям приходится выполнять вход дважды
Если пользователи входят на Удаленный рабочий стол с помощью компьютера под управлением Windows 7 или Windows 10 версии 1709, им сразу же отображается запрос на повторный вход. Эта проблема возникает, если на клиентском компьютере установлены следующие обновления:
Чтобы устранить эту проблему, убедитесь, что на компьютерах, к которым подключаются пользователи, (а также серверы RDSH или RDVI) установлены все обновления в том числе за июнь 2018 г. К ним относятся следующие обновления:
- Windows Server 2016: 12 июня 2018 г. — KB4284880 (сборка ОС 14393.2312);
- Windows Server 2012 R2: 12 июня 2018 г. — KB4284815 (ежемесячный накопительный пакет);
- Windows Server 2012: 12 июня 2018 г. — KB4284855 (ежемесячный накопительный пакет);
- Приложение. 12 июня 2018 г. — KB4284826 (ежемесячный накопительный пакет);
- Windows Server 2008 с пакетом обновления 2 (SP2): обновление KB4056564, Description of the security update for the CredSSP remote code execution vulnerability in Windows Server 2008, Windows Embedded POSReady 2009, and Windows Embedded Standard 2009: March 13, 2018 (Описание обновления системы безопасности для устранения уязвимости CredSSP, допускающей удаленное выполнение кода, в Windows Server 2008, Windows Embedded POSReady 2009 и Windows Embedded Standard 2009: 13 марта 2018 г.).
Пользователь не может войти на компьютер с Windows Server 2008 с пакетом обновления 2 (SP2) с помощью смарт-карты
Чтобы устранить эту проблему, обновите на компьютере ОС 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 г.).
Пользователям запрещается доступ к развертыванию, которое использует Remote Credential Guard с несколькими брокерами подключений к удаленному рабочему столу
Эта проблема возникает в развертываниях с высоким уровнем доступности, в которых используются не менее двух брокеров подключений к удаленному рабочему столу и Remote Credential Guard в Защитнике Windows. Пользователям не удается войти на удаленные рабочие столы.
Эта проблема связана с тем, что Remote Credential Guard использует Kerberos для проверки подлинности, а также запрещает использовать NTLM. Но в конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеры подключений к удаленному рабочему столу не могут поддерживать операции Kerberos.
Если нужно использовать конфигурации с высоким уровнем доступности и балансировкой нагрузки брокеров подключений к удаленному рабочему столу, эту проблему можно устранить, отключив Remote Credential Guard. Дополнительные сведения об управлении Remote Credential Guard в Защитнике Windows см. в статье Protect Remote Desktop credentials with Windows Defender Remote Credential Guard (Защита учетных данных удаленного рабочего стола с помощью Remote Credential Guard в Защитнике Windows).
Собственно, название темы и есть проблема. И проблема эта существует только между 8.1 и 2012 R2.
При подключении выскакивает такая ошибка: "Системный администратор ограничил количество компьютеров, с которых вы можете войти в систему. Попробуйте войти в систему с другого компьютера."
С не доменными машинами такой проблемы нет.
Предмет:
Идентификатор безопасности: DOMAIN\User
Имя учетной записи: User
Домен учетной записи: DOMAIN
Идентификатор входа: 0x12927B4A
В локальной групповой политике в разделе Административные шаблоны -> Система -> Передача учетных данных есть что-то по этой теме, как мне казалось. Но ничего не помогает.
Конфигурация компьютера | |
Процессор: Intel Core i7-9700K 3600/4900 MHz Coffee Lake R | |
Материнская плата: ASRock Z390 Extreme4 | |
Память: Kingston HyperX HX434C16FB3K2/32 DDR4 32Gb | |
HDD: WDC WD8002FRYZ-01FF2B0 8Tb SATA, Patriot Viper VPN100 512Gb NVME | |
Видеокарта: AMD Radeon RX 560(Polaris 21) 4Gb | |
Звук: Realtek ALC1220 | |
Блок питания: Thermaltake 1000 | |
CD/DVD: HL-DT-ST DVDRAM GH24NSC0 | |
Монитор: Iiyama ProLite X2483HSU, LG L193ST | |
Ноутбук/нетбук: ASUS ZenBook UX32A | |
ОС: Windows 10 Pro x64 |
obid13
Это параметры:
"Разрешить передачу сохраненных учетных данных"
"Разрешить передачу учетных данных, установленных по умолчанию"
"Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера "только NTLM""
"Разрешить делегирование учетных данных, установленных по умолчанию, с проверкой подлинности сервера "только NTLM""
Они предполагают, помимо включения, заполнения списка ресурсов для применения.
В твоей ситуации это будет TERMSRV//172.16.0.200
Но на всякий случай я бы добавил еще NETBIOS и FDQN имена, кроме IP.
Практически наверняка тебя интересуют(для 8.1) первые два - притом первый это через "Диспетчер учетных данных"(так как настроено у тебя сейчас), а второй - это прозрачная авторизация в домене с использованием текущей учетки пользователя.
Ну и это - "gpupdate /force" никто не отменял. И потом нелишне результирующую политику проверить по выбранному пользователю на определенном компе.
Собственно, название темы и есть проблема. И проблема эта существует только между 8.1 и 2012 R2.
При подключении выскакивает такая ошибка: "Системный администратор ограничил количество компьютеров, с которых вы можете войти в систему. Попробуйте войти в систему с другого компьютера."
С не доменными машинами такой проблемы нет.
Предмет:
Идентификатор безопасности: DOMAIN\User
Имя учетной записи: User
Домен учетной записи: DOMAIN
Идентификатор входа: 0x12927B4A
В локальной групповой политике в разделе Административные шаблоны -> Система -> Передача учетных данных есть что-то по этой теме, как мне казалось. Но ничего не помогает.
Конфигурация компьютера | |
Процессор: Intel Core i7-9700K 3600/4900 MHz Coffee Lake R | |
Материнская плата: ASRock Z390 Extreme4 | |
Память: Kingston HyperX HX434C16FB3K2/32 DDR4 32Gb | |
HDD: WDC WD8002FRYZ-01FF2B0 8Tb SATA, Patriot Viper VPN100 512Gb NVME | |
Видеокарта: AMD Radeon RX 560(Polaris 21) 4Gb | |
Звук: Realtek ALC1220 | |
Блок питания: Thermaltake 1000 | |
CD/DVD: HL-DT-ST DVDRAM GH24NSC0 | |
Монитор: Iiyama ProLite X2483HSU, LG L193ST | |
Ноутбук/нетбук: ASUS ZenBook UX32A | |
ОС: Windows 10 Pro x64 |
obid13
Это параметры:
"Разрешить передачу сохраненных учетных данных"
"Разрешить передачу учетных данных, установленных по умолчанию"
"Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера "только NTLM""
"Разрешить делегирование учетных данных, установленных по умолчанию, с проверкой подлинности сервера "только NTLM""
Они предполагают, помимо включения, заполнения списка ресурсов для применения.
В твоей ситуации это будет TERMSRV//172.16.0.200
Но на всякий случай я бы добавил еще NETBIOS и FDQN имена, кроме IP.
Практически наверняка тебя интересуют(для 8.1) первые два - притом первый это через "Диспетчер учетных данных"(так как настроено у тебя сейчас), а второй - это прозрачная авторизация в домене с использованием текущей учетки пользователя.
Ну и это - "gpupdate /force" никто не отменял. И потом нелишне результирующую политику проверить по выбранному пользователю на определенном компе.
Собственно, название темы и есть проблема. И проблема эта существует только между 8.1 и 2012 R2.
При подключении выскакивает такая ошибка: "Системный администратор ограничил количество компьютеров, с которых вы можете войти в систему. Попробуйте войти в систему с другого компьютера."
С не доменными машинами такой проблемы нет.
Предмет:
Идентификатор безопасности: DOMAIN\User
Имя учетной записи: User
Домен учетной записи: DOMAIN
Идентификатор входа: 0x12927B4A
В локальной групповой политике в разделе Административные шаблоны -> Система -> Передача учетных данных есть что-то по этой теме, как мне казалось. Но ничего не помогает.
Конфигурация компьютера | |
Процессор: Intel Core i7-9700K 3600/4900 MHz Coffee Lake R | |
Материнская плата: ASRock Z390 Extreme4 | |
Память: Kingston HyperX HX434C16FB3K2/32 DDR4 32Gb | |
HDD: WDC WD8002FRYZ-01FF2B0 8Tb SATA, Patriot Viper VPN100 512Gb NVME | |
Видеокарта: AMD Radeon RX 560(Polaris 21) 4Gb | |
Звук: Realtek ALC1220 | |
Блок питания: Thermaltake 1000 | |
CD/DVD: HL-DT-ST DVDRAM GH24NSC0 | |
Монитор: Iiyama ProLite X2483HSU, LG L193ST | |
Ноутбук/нетбук: ASUS ZenBook UX32A | |
ОС: Windows 10 Pro x64 |
obid13
Это параметры:
"Разрешить передачу сохраненных учетных данных"
"Разрешить передачу учетных данных, установленных по умолчанию"
"Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера "только NTLM""
"Разрешить делегирование учетных данных, установленных по умолчанию, с проверкой подлинности сервера "только NTLM""
Они предполагают, помимо включения, заполнения списка ресурсов для применения.
В твоей ситуации это будет TERMSRV//172.16.0.200
Но на всякий случай я бы добавил еще NETBIOS и FDQN имена, кроме IP.
Практически наверняка тебя интересуют(для 8.1) первые два - притом первый это через "Диспетчер учетных данных"(так как настроено у тебя сейчас), а второй - это прозрачная авторизация в домене с использованием текущей учетки пользователя.
Ну и это - "gpupdate /force" никто не отменял. И потом нелишне результирующую политику проверить по выбранному пользователю на определенном компе.
06.04.2022
itpro
Active Directory, PowerShell, Windows Server 2019, Групповые политики
комментария 24
Когда вы создаёте нового пользователя в Active Directory, он автоматически добавляется в группу Domain Users. Группа Domain Users в свою очередь по умолчанию добавляется в локальную группу Users на компьютере при добавлении его в домен AD. Это означает что любой пользователь домена может войти на любой компьютер в вашей сети. В этой статье мы рассмотрим, как ограничить вход пользователей на компьютеры домена и ограничить разрешенное время входа.
Не удается оставаться в системе, вход в которую выполнен с помощью смарт-карты, и служба удаленных рабочих столов зависает
Чтобы устранить эту проблему, перезапустите удаленный компьютер.
Чтобы устранить эту проблему, обновите систему на удаленном компьютере, установив соответствующее исправление:
Ограничить часы входа пользователя в Active Directory
В свойствах учетной записи пользователя вы можете ограничить время входа учетной записи. Например, вы можете разрешить пользователю входить на компьютеры домена только в рабочие часы с 8:00 до 19:00.
Если вам нужно применить одинаковы ограничения Logon Hours для нескольких пользователей, проще всего использовать PowerShell. Сначала вручную настройте ограничения для одного пользователя, а затем используете значение его атрибута logonHours в качестве шаблона для других пользователей. Например, вы хотите ограничить время входа для группы удаленных пользователей:
$templateuser='a.khramov'
$templatehours= Get-ADUser -Identity $templateuser -properties logonHours
Get-ADGroupmember "msk-VPN_Users" |foreach >
Если пользователь попытайся войти в компьютер за пределами разрешенных logonhours, он получит ошибку:
В Windows нет встроенного функционала по принудительному завершению сессии пользователе, если его рабочее время закончено. Для гарантированного выполнения logoff можно создать простое задание планировщика и распространить его через GPO.
Также обратите внимание на два параметра GPO в разделе to Computer configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
- Network security: Force logoff when logon hours expire
- Microsoft network server: Disconnect clients when logon hours expire
При включении этих политик SMB сервера будут отключать подключения пользователей, чьи часы работы просрочены.
Ограничить вход на компьютеры в Active Directory с помощью GPO
В больших доменах использовать свойство пользователя LogonWorkstations для ограничения доступа пользователей к компьютерам нецелесообразно из-за ограничений и недостаточной гибкости. Для более гибкого управления правилами запрета/разрешения входа на компьютеры используют групповые политики.
Можно ограничить список пользователей в локальной группе Users с помощью политики Restricted Groups (см. пример использования политик Restricted Groups из раздела Windows Settings -> Security Settings для добавления пользователей в локальную группу администраторов). Но мы рассмотрим другой вариант.
Есть две групповые политики, которые находятся в разделе Computer Configuration -> Policies -> Security Settings -> Local Policies -> User Rights Assignment (Конфигурация пользователя -> Политики -> Параметры безопасности -> Локальные политики -> Назначение прав пользователя):
- Deny log on locally (Запретить локальный вход) – позволяет запретить локальный вход на компьютеры для определенных пользователей или групп. ;
- Allow log on locally (Локальный вход в систему) – содержит список пользователей и групп, которым разрешено входить на компьютер локально.
Например, чтобы запретить пользователям определенной группы входить на компьютеры в определенной Organizational Unit (OU), вы можете создать отдельную группу пользователей, добавить ее в политику Deny log on locally и назначить ее на OU с компьютерами, доступ к которым вы хотите ограничить.
В больших доменах можно использовать комбинацию этих политик. Например, вы хотите запретить пользователям входить на компьютеры других OU.
Для этого в каждой OU нужно создать группу безопасности, куда нужно включить всех пользователей OU.
Совет. Группы можно автоматически наполнять пользователями из OU с помощью PowerShell командлетов Get-ADUser и Add-ADGroupMember таким скриптом:
Import-module ActiveDirectory
$rootOU = “OU= Users,OU=MSK,DC=winitpro,DC=ru”
$group = “corp\msk-users”
Get-ADUser -SearchBase $rootOu -Filter * | ForEach-Object
Затем нужно включить параметр GPO Allow log on locally, добавить в него эту группу (+ различные администраторские группы: Domain Admins, администраторы рабочих станций и прочее) и назначить политику на OU с компьютерами. Таким образом вы разрешите входить на компьютеры только пользователям конкретного OU.
Обновите настройки GPO на клиентах. Теперь при попытке входа пользователя, которому не разрешен локальный метод входа, появится окно с предупреждением:
Несколько важных моментов касательно данных политик:
-
Не стоит применять данные политики, для ограничения доступа к серверам и тем более к контроллерам домена;
Отказано в доступе (удаленный вызов к базе данных SAM отклонен)
Такое поведение обычно возникает, если контроллеры домена работают под управлением Windows Server 2016 или более поздней версии, а пользователи пытаются подключиться с помощью настраиваемого приложения для подключения. В частности, отказ в доступе получат приложения, которым требуется доступ к сведениям профиля пользователя в Active Directory.
Такое поведение обусловлено изменением в Windows. В Windows Server 2012 R2 и более ранних версиях, когда пользователь выполняет вход на удаленный рабочий стол, диспетчер удаленных подключений (RCM) обращается к контроллеру домена (DC), чтобы запросить конфигурацию, относящуюся к удаленному рабочему столу, в объекте пользователя в доменных службах Active Directory (AD DS). Эта информация отображается на вкладке "Профиль служб удаленных рабочих столов" в окне свойств объекта пользователя в оснастке MMC "Пользователи и компьютеры Active Directory".
Начиная с Windows Server 2016 RCM больше не запрашивает объект пользователя в AD DS. Если требуется, чтобы RCM обращался к AD DS из-за того, что вы используете атрибуты служб удаленных рабочих столов, вам нужно вручную разрешить отправку запросов.
Внимательно выполните действия, описанные в этом разделе. Неправильное изменение реестра может привести к серьезным проблемам. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем.
Чтобы разрешить прежнее поведение RCM на сервере узла сеансов удаленных рабочих столов, настройте следующие записи реестра и перезапустите службу Службы удаленных рабочих столов:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ Winstation name>\
- Имя: fQueryUserConfigFromDC.
- Тип: Reg_DWORD
- Значение: 1 (десятичное число).
Чтобы разрешить устаревшее поведение RCM на сервере, отличающемся от сервера RDSH, настройте эти записи реестра и следующую дополнительную запись (затем перезапустите службу).
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Дополнительные сведения об этом поведении см. в статье базы знаний № 3200967 Changes to Remote Connection Manager in Windows Server (Внесение изменений в диспетчер удаленных подключений в Windows Server).
Не удается войти в систему с помощью смарт-карты в филиале с контроллером домена только для чтения (RODC)
Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту. Если пользователь получает ошибку "Недопустимо", значит два ключа не совпадают.
Чтобы решить эту проблему, выполните одно из указанных ниже действий:
- измените топологию контроллера домена, отключив кэширование паролей на RODC, или разверните на сайте филиала контроллер домена с доступом на запись;
- переместите сервер RDSH в тот же дочерний домен, где находятся пользователи;
- разрешите пользователям выполнять вход без смарт-карты.
Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности.
Если удаленный компьютер заблокирован, пользователю нужно дважды ввести пароль
Эта проблема может возникать, когда пользователь пытается подключиться к удаленному рабочему столу под управлением Windows 10 версии 1709 в развертывании, где для подключений по протоколу RDP не требуется использовать NLA. Если в таком случае удаленный рабочий стол оказался заблокированным, пользователю нужно ввести свои учетные данные дважды при подключении.
Чтобы устранить эту проблему, обновите Windows 10 версии 1709 на соответствующем компьютере с использованием обновления за 30 августа 2018 г. — KB4343893 (ОС сборки 16299.637).
Ошибка "Исправление шифрования CredSSP" ссылается на набор обновлений системы безопасности, выпущенный в марте, апреле и мае 2018 г. CredSSP — это поставщик проверки подлинности, который обрабатывает запросы проверки подлинности для других приложений. Обновление за 13 марта 2018 г., 3B и все последующие обновления подверглись эксплойту, когда злоумышленник мог передать учетные данные пользователя для выполнения кода в целевой системе.
В исходные обновления была добавлена поддержка нового объекта групповой политики "Защита от атак с использованием криптографического оракула", который может иметь следующие настройки:
- Уязвимо. Клиентские приложения, использующие CredSSP, могли переключиться на небезопасные версии, но из-за этого удаленные рабочие столы могли подвергаться атакам. Службы, использующие CredSSP, принимали клиенты, которые не были обновлены.
- Устранено. Клиентские приложения, использующие CredSSP, не могут переключиться на небезопасные версии, но службы, использующие CredSSP, принимают клиенты, которые не были обновлены.
- Принудительно обновленные клиенты. Клиентские приложения, использующие CredSSP, не могут переключиться на небезопасные версии, и службы, использующие CredSSP, не принимают клиенты без установленных обновлений.
Этот параметр не следует развертывать, пока все узлы поддержки в удаленном расположении не будут поддерживать последнюю версию.
В обновлении за 8 мая 2018 г. значение для параметра по умолчанию "Защита от атак с использованием криптографического оракула" изменилось с "Уязвимо" на "Устранено". После реализации этого изменения клиенты Удаленного рабочего стола, на которых были установлены обновления, не могут подключаться к серверам без этого обновления (или к обновленным серверам, которые еще не были перезапущены). Подробные сведения об обновлениях CredSSP см. в статье базы знаний KB4093492.
Чтобы устранить эту проблему до завершения обновления, просмотрите список допустимых типов подключений в обновлении KB4093492. Если нет других осуществимых альтернатив, можете попробовать один из следующих методов:
- На затронутых клиентских компьютерах верните для политики "Защита от атак с использованием криптографического оракула" значение Уязвимо.
- Измените следующие политики в папке групповой политики, выбрав Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Безопасность:
- для политики Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP задайте значение Включено и выберите RDP.
- для политики Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети задайте значение Отключено.
Изменение этих групповых политик делает развертывание менее защищенным. Мы рекомендуем использовать их только временно (или вообще не использовать).
Дополнительные сведения о работе с групповой политикой см. в разделе Изменение блокирующего объекта групповой политики.
Изменение членства пользователя в группах или назначенных ему прав
Если эта проблема затрагивает одного пользователя, наиболее простым решением будет добавить этого пользователя в группу Пользователи удаленного рабочего стола.
Если пользователь уже является членом этой группы (или если проблема возникает у нескольких членов группы), проверьте конфигурацию прав пользователей на удаленном компьютере Windows 10 или Windows Server 2016.
- Откройте редактор объектов групповой политики (GPE) и подключитесь к локальной политике удаленного компьютера.
- Выберите Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя, щелкните правой кнопкой мыши элемент Доступ к компьютеру из сети и выберите Свойства.
- Просмотрите список пользователей и групп для группы Пользователи удаленного рабочего стола (или родительской группы).
- Если список не включает группу Пользователи удаленного рабочего стола или родительскую группу, например Все, добавьте их. Если развертывание включает больше одного компьютера, используйте объект групповой политики.
Например, членством по умолчанию для политики Доступ к компьютеру из сети будет Все. Если в развертывании используется объект групповой политики для удаления Все, может потребоваться восстановить доступ, обновив объект групповой политики, чтобы добавить группу Пользователи удаленного рабочего стола.
Отказано в доступе (ограничение по типу входа в систему)
Подключение к удаленному рабочему столу
Системный администратор ограничил типы входа в систему (сетевой или интерактивный), которые можно использовать. Обратитесь за помощью к системному администратору или в службу технической поддержки.Эта проблема возникает, если для подключения к удаленному рабочему столу требуется пройти проверку подлинности на уровне сети (NLA), но пользователь не является членом группы Пользователи удаленного рабочего стола. Она также может возникать, если группе Пользователи удаленного рабочего стола не назначено право пользователя Доступ к компьютеру из сети.
Чтобы решить эту проблему, выполните одно из указанных ниже действий.
-
.
- Отключите NLA (не рекомендуется).
- Используйте клиенты удаленного рабочего стола, отличающиеся от Windows 10. Например, в клиентах Windows 7 нет такой проблемы.
Разрешить вход на определенные компьютеры в свойствах пользователя AD
В свойствах (атрибутах) учетной записи пользователя Active Directory можно задать список компьютеров, на которые ему разрешено входить. Например, вы хотите, чтобы определенный пользователь мог войти только на свой компьютер. Для этого:
- Запустите оснастку ADUC (Active Directory Users and Computers), выполнив команду dsa.msc ;
- С помощью поиска найдите учетную запись пользователя, которому нужно ограничить вход только на компьютеры домена и откройте его свойства;
- Перейдите на вкладку Account и нажмите кнопку Log On To;
- Как вы видите, пользователю разрешено входить на все компьютеры (The user can log on to: All computer). Чтобы разрешить пользователю аутентифицироваться только на определенных компьютерах, выберите опцию The following computers и добавьте в список имена компьютеров, но которые ему разрешено входить;
Примечание. Нужно указывать полное NetBIOS или DNS имя компьютера (нельзя знаки подстановки использовать), параметр регистронезависимый.
С помощью оснастки Active Directory Administrative Center ( dsac.msc ) и с помощью PowerShell вы можете разрешить пользователю входить более чем на 65 компьютер. Однако максимальное значение ограничивается типом данных атрибута Logon-Workstation в схема Active Directory (Octet String). В Windows Server 2016 + в этом атрибуте может содержаться до 8192 символов (в предыдущих версиях Windows Server 2003-2012 использовалось ограничение 1024 символов).
Еще одна интересная особенность появляется, если вы ограничили пользователю список компьютеров разрешенных для входа с помощью атрибута LogonWorkstation.
При попытке подключится к удаленному компьютеру (RDS ферме) по RDP, вы можете получить ошибку:Для решения этой проблемы нужно добавить в список LogonWorkstation компьютер с которого (. ) осуществляется RDP вход.
Читайте также: