Ограничение доступа к компьютеру в домене

Обновлено: 07.07.2024

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

Запретить вход в систему для определенных учетных записей можно с помощью групповых политик. Для этого откроем оснастку управления групповыми политиками и создадим новый GPO.

Затем откроем созданный GPO для редактирования и перейдем в раздел Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Здесь нас интересуют два параметра:

Для активации политики необходимо включить (define) ее и указать пользователей или группы, для которых необходимо запретить вход. Использовать группы более удобно, чем добавлять пользователей по одному, поэтому я создал группу DenyInteractiveLogon, которую и добавлю в данные политики.

В результате должна получиться такая картина.

Политика готова, надо проверить ее действие. Для этого в оснастке ADUC находим группу DenyInteractiveLogon, добавляем в нее специально созданную сервисную учетку service_user

В заключение пара важных моментов, о которых надо помнить при использовании запретов:

• Политика предназначена для компьютеров, поэтому назначать ее надо на подразделения, в которых находятся компьютеры, а не пользователи. В принципе можно особо не заморачиваться и назначить политику на весь домен, все равно запрет будет действовать только на указанные в политике группы;
• Данная политика довольно опасна в неумелых руках. К примеру, если указать в ней группу Domain Users, то никто из доменных пользователей не сможет войти на свой компьютер, а если добавить группу Everyone, то запрет подействует на все без исключения учетные записи. Поэтому, выбирая объекты для запрета будьте внимательны, чтобы не запретить вход обычным пользователям;
• По возможности для технических целей старайтесь использовать управляемые учетные записи служб (managed service accounts), они более безопасны в использовании.

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

Применяется к: Windows Server 2012 R2, Windows 10 — все выпуски
Исходный номер КБ: 555317

Эта статья была написана Yuval Sinay, MVP Майкрософт.

Симптомы

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

Причина

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

Решение

Вариант A: Domain-Wide политика

С помощью возможностей групповой политики в Windows домене 2000/2003 можно запретить пользователю/s войти в другой домен/s, чем его домашний домен.

Создайте новое GPO для всей области домена и введете пользователю "Запретить логоун локально" право пользователя на учетную запись пользователя домена или sIn целевого домена.

Некоторые службы (например, службы резервного копирования) могут действовать этой политикой и не будут функционировать. Чтобы устранить проблемы в будущем, применяем эту политику и используйте перо фильтра безопасности GPO.

Запретить локализованный логотип

Фильтрация с помощью групп безопасности

Запустите Gpupdate /force на контроллере домена.

Вариант B. Удаление использования "NT AUTHORITY\Authenticated Users" из списка группы пользователей

Чтобы исключить возможность ведения журнала на одном или нескольких компьютерах, выполните инструкции:

Щелкните правой кнопкой мыши значок "Мой компьютер" на рабочем столе.

Выберите "Управление".

Извлечение "Локальные пользователи и группы".

Выберите в "Группы".

В правой части экрана дважды щелкните группу "Пользователи".

Удаление:"NT AUTHORITY\Authenticated Users" из списка.

Добавьте требуемую пользователь/s или группу/s в локализованную группу "Пользователи".

Параметр C. Настройка пользователя "Запретить логонс локально" прямо на локальном компьютере/s

Чтобы исключить возможность ведения журнала на одном или нескольких компьютерах, выполните инструкции:

Перейдите к "Start" -> "Run".

Напишите "Gpedit.msc"

Включить "Запретить логос локально" пользователю право на исходные учетные записи пользователей домена.

Некоторые службы (например, службы резервного копирования) могут действовать этой политикой и не будут функционировать.

Запретить локализованный логотип

Запуск Gpupdate /force на локальном компьютере.

Вариант D. Использование выборочной проверки подлинности при использовании Forest Trust

Создание лесных трастов

Дополнительная информация

Community Отказ от контента решений

Корпорация Майкрософт и/или соответствующие поставщики не делают представлений о пригодности, надежности или точности сведений и связанных с ними графических данных, содержащихся в этой записи. Вся такая информация и связанная графика предоставляются "как есть" без какой-либо гарантии. Корпорация Майкрософт и/или соответствующие поставщики тем самым отключили все гарантии и условия в отношении этой информации и связанной графики, включая все подразумеваемые гарантии и условия торговой доступности, пригодность для определенной цели, рабочий труд, название и неущемление. Вы соглашаетесь, что ни в каких событиях корпорация Майкрософт и/или ее поставщики не несут ответственности за любые прямые, косвенные, штрафные, случайные, специальные, сопутствующие повреждения или любые повреждения, включая без ограничений убытки за потерю использования, данных или прибыли, возникающие из-за использования или невозможности использования сведений и связанных с ними графических элементов, содержащихся в этом деле, независимо от того, были ли они связаны с контрактом, тортом, халатностью, строгой ответственностью или иным образом, даже если корпорации Майкрософт или любому из ее поставщиков было рекомендовано о возможности ущерба.

На компьютере установлен Windows XP SP3, сам комп. в домене Windows 2003. Нужно, чтобы на этот компьютер можно было заходить только под отпределенной учетной записью. Это необходимо сделать только для 1-го компьютера, а не для всех в OU. То, что это делается через групповые политики я знаю, нужно конкретное решение.

Все ответы

На компьютере установлен Windows XP SP3, сам комп. в домене Windows 2003. Нужно, чтобы на этот компьютер можно было заходить только под отпределенной учетной записью. Это необходимо сделать только для 1-го компьютера, а не для всех в OU. То, что это делается через групповые политики я знаю, нужно конкретное решение.

Вам именно последовательность действий?

1. mmc
2. Редактор групповой политики - Локальный компьютер
3. Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики
4. Локальный вход в систему - наполняете список как вам угодно.

Артем привел решение, которе изменяет локальные политики безопасности, но не учел, что компьютер находится под воздействием групповых политик.
Создайте отдельный ОГП, установите параметры безопасности ("Allow logon locally"), назначьте "Security Filtering" для учетной записи целевого компьютера (Allow "Read" и "Apply"), после чего слинкуйте его с OU этого компьютера.

Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)

Артем привел решение, которе изменяет локальные политики безопасности, но не учел, что компьютер находится под воздействием групповых политик.
Создайте отдельный ОГП, установите параметры безопасности ("Allow logon locally"), назначьте "Security Filtering" для учетной записи целевого компьютера (Allow "Read" и "Apply"), после чего слинкуйте его с OU этого компьютера.
Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)

все компьютеры находятся в OU - SUS (не computers, думаю понимаете зачем), пользователи отдела продаж находятся в OU - Sales, пользователи отдела комиссии находятся в OU - Comission. Нужно чтобы пользователи отдела продаж не могли зайти на компьютеры пользователей отдела комиссии. Для какого OU мне нужно создавать GPO? Для какого объекта GPO мне нужно устанаваливать запрет на локальный вход, для компьютера или пользователя?

Мде. меняет задачи "на ходу".

1. Привязка определенного пользователя к определенному(ым) компьютеру осуществляется следующим образом:
Открываем Active Directory Users and Computers выбираем нужного пользователя, открываем его Propirties идем на вкладку Account жмем кнопочку Log On To и указываем необходимые компьютеры (Примечание: NetBios нужен для этого вроде).

2. Разрешение определенным пользователям для доступа к определенному компьютеру:
Открываем или создаем Group Policy в Active Directory, идем в раздел Computer Configuration - Windows Settings - Security Settings - Local Policies - User Rights Assigment и тут в нужных параметрах (Allow log on locally or Deny log on locally) указываем нужных пользователей или группы и привязываем GP к необходимым компьютерамм.

А все могло быть и лучше.

Мне кажется, что в данной ситуации может сработать такой рецепт: необходимо создать две группы, назовем их PCComission и UserComission.
Включить в их состав компьютеры и пользователей отдела комиссии соответственно.
Далее создать объект групповой политики и прилинковать к OU SUS, отняв право apply policy у группы Auth Users, добавив его вместо этого группе PCComission. После этого в свойствах политики, используя механизм ограничения членства в группах, исключить из локальной группы Users доменную группу Domain Users, но добавить группу UserComission

VadimP, Вы вводите автора обсуждения в заблуждение о достаточных и необходимых действиях для решения его задачи.

Георгий, я Вам рекомендую следующий сценарий:
Создайте локальные доменные группы безопасности, например "dl-ac-AllowLogon-ComputerGroup1" и "dl-ac-AllowLogon-ComputerGroup2".
Включите в эти группы те группы, которым необходимо иметь право локального входа на соответствующие группы компьютеров.
Создайте локальные доменные группы безопасности, например "dl-md-ComputerGroup1" и "dl-md-ComputerGroup1", включите в них компьютеры.
Создайте два объекта групповой политики, например "Restrict Logon Locally on ComputerGroup1" и "Restrict Logon Locally on ComputerGroup2".
На кажый из объектов групповой политики установите "Security Filtering" с разрешением "Read" и "Apply" только для соответствующих групп компьютеров.
В настройках безопасности объектов групповой политики установите "Allow Log on Locally" только для соответствующих групп "dl-ac-AllowLogon-<. >" и встроенной "Administrators".
Слинкуйте объекты групповой политики на контейнер, содержащий компьютеры, которые Вы хотите подвергнуть ограничениям локального входа.

P.S. Перед применением политик, обязательно тестируйте их влияние!

VadimP, Вы вводите автора обсуждения в заблуждение о достаточных и необходимых действиях для решения его задачи.

Дмитрий, если Вы сможете объяснить, в чем я ошибаюсь, - я Вам буду благодарен.

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

Вадим, Ваш сценарий к сожалению не сработает. Так как политика "Компьютер" применяется до входа пользователя в систему. Соответственно необходимо либо линковать политики на разные OU (разделять компьютеры), либо создавать группы безопасности для компьютеров и фильтровать применение политик на основе членства компьютеров в этих группах.

А причем здесь время входа пользователя? На этапе применения компьютерной части политики компьютером из OU SUS будет считаны настройки политики. Если компьютер не входит в группу PCComission, то на этом всё и закончится. А если он входит в неё, то к нему применятся настройки. Конкретно - будет отредактирован состав группы Users, в состав которой после включения компьютера в домен включается группа Domain User: состав группы будет очищен, после чего в группу будет добавлена группа UserComission. Если Вы посмотрите, кому в локальной политике предоставлено по умолчанию право Logon locally, то увидите группу Users, состав которой только что был сформирован в соответствии с поставленной задачей.
Если на такой компьютер попытается залогиниться пользователь из отдела Sales, то ему это не удастся, поскольку его нет в группе UserComission и, соответственно, в группе Users.
Так что сценарий сработает. А создавать для решения конкретно этой задачи две политики - не самое простое решение, согласитесь, если можно обойтись одной.

А причем здесь время входа пользователя? На этапе применения компьютерной части политики компьютером из OU SUS будет считаны настройки политики. Если компьютер не входит в группу PCComission, то на этом всё и закончится. А если он входит в неё, то к нему применятся настройки. Конкретно - будет отредактирован состав группы Users, в состав которой после включения компьютера в домен включается группа Domain User: состав группы будет очищен, после чего в группу будет добавлена группа UserComission.
.
Так что сценарий сработает.

Да, Вы правы. Я просто не внимательно прочитал. Такое решение сработает. Просто Дмитрий имел ввиду, что оно очень громоздкое.

А создавать для решения конкретно этой задачи две политики - не самое простое решение, согласитесь, если можно обойтись одной.

Ну почему же не самое простое - зато сразу видно какая политика применяется, не нужно создавать группы для компьютеров и применение политик будет регулироваться перемещением компьютера между OU.
Кстати, если реализовывать только конкретное требование автора вопроса - то OU и политика нужна только одна.

Ну, если ему (или Вам ;) моё решение кажется громоздким, то мне таким кажется его (с двумя политиками и четырьмя группами)

Использовать фильтацию политик через членство в группах или путем создания дополнительных OU - дело, как говорится, вкуса.
На мой вкус, - группы оптимальнее, чем OU: в первом случае можно использовать и пересекающиеся множества объектов в отличие от второго.
Кроме того, каждый новый объект политики, - это новые три мегабайта в SYSVOL вместо нескольких килобайт в случае группы.

Кроме того, каждый новый объект политики, - это новые три мегабайта в SYSVOL

С чего Вы это взяли? Политика Computer, без дополнительных шаблонов будет не более 10 Кб.
З.Ы. Предлагаю прекратить неконструктивный флуд.
Я взял из результатов команды DIR /s?, выполненной в каталоге одной из политик. Ответ получился 7 файлов и 3666010 байт.
А вот с чего Вы взяли, что она будет без дополнительных шаблонов ? У автора про это ни слова ;)
З.Ы. Насчет неконструктивного флуда: сначала было заявлено, что я ввожу автора в заблуждение, затем - что моё решение не сработает, наконец - что оно слишком громоздкое. В ответных постах мне пришлось аргументировано доказывать, что это не так. В итоге оказалось, что я неконструктивно зафлудил тему.

Мне кажется, что в данной ситуации может сработать такой рецепт: необходимо создать две группы, назовем их PCComission и UserComission.
Включить в их состав компьютеры и пользователей отдела комиссии соответственно.
Далее создать объект групповой политики и прилинковать к OU SUS, отняв право apply policy у группы Auth Users, добавив его вместо этого группе PCComission. После этого в свойствах политики, используя механизм ограничения членства в группах, исключить из локальной группы Users доменную группу Domain Users, но добавить группу UserComission

Вадим, я указал, что Вы заблуждаетесь потому, что Ваш рецепт не сработает: исключение доменных пользователей из встроенной группы пользователей компьютера не ограничит доменных пользователей в локальном входе на этот компьютер. Вот и все. Не обижайтесь, но Ваше "мне кажется, что. " нужно проверять прежде, предлагая в качестве рецепта. Вспомните/ознакомьтесь, с состоянием типичного членства "Builtin\Users" на рядовом компьютере в составе домена AD, о привилегиях, наконец.

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

Вадим, если Вы сможете объяснить, в чем я ошибаюсь - я Вам буду благодарен. :)

Add: Вадим, и по поводу объекта политики. Ну, пусть бы ОГП хоть 10 мегабайт в SYSVOL и столько же в контейнере AD занимал - и что? Репликация - оптимизирована, клиент не по пять раз на дню ОГП заново загружает, а администратор не меняет его от нечего делать - так ведь? В общем, лучше создать побольше ОГП, а часто - только так и возможно, чем в винегрете ковыряться.

Мне кажется, что в данной ситуации может сработать такой рецепт: необходимо создать две группы, назовем их PCComission и UserComission.
Включить в их состав компьютеры и пользователей отдела комиссии соответственно.
Далее создать объект групповой политики и прилинковать к OU SUS, отняв право apply policy у группы Auth Users, добавив его вместо этого группе PCComission. После этого в свойствах политики, используя механизм ограничения членства в группах, исключить из локальной группы Users доменную группу Domain Users, но добавить группу UserComission

Вадим, если Вы сможете объяснить, в чем я ошибаюсь - я Вам буду благодарен. :)

Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
Дмитрий, вообще-то я объяснил уже в одном из предыдущих постов этой ветки: 21 августа 2009 г. 10:26.
Ну давайте ещё раз. Моё предложение состояло из идеи изменить, используя механизм "Restricted Groups", состав локальной группы Users/Пользователи на компьютерах отдела комиссии, чтобы пользователи отдела продаж не могли на них логиниться (ведь именно через членство в этой группе они имеют такое право). Я, правда, небрежно сформулировал эту мысль, правильно было сказать не " исключить из локальной группы Users доменную группу Domain Users", а " очистить локальную группу Users", но сути это не меняет , поскольку политика при её применении именно чистит группу перед добавлением явно указанной в разделе Restricted Groups. Так что в данном случае помнить дефолтный состав группы не обязательно. Хотя и не помешает ;) А привилегии я не только помню, но и как раз предлагаю использовать, а именно Allow Logon Locally.
Если Вам ещё что-то непонятно, спросите конкретно - постараюсь объяснить доходчивее.
Дмитрий, кое-какие бонусы я и сам вижу. А от каких конкретно проблем Вы меня и других неопытных администраторов предостерегаете в связи с изменением состава группы Users?
И объясните мне ради бога, как это может повлиять на техническую поддержку? И чью?
Ну, и по поводу размера объекта политики. Если Вам не доводилось при обследовании инфраструктуры заказчика обнаруживать контроллер, находящийся за каналом 128к и не реплицировавшийся почти весь срок жизни tombstone объектов, то Вам нелегко будет понять моё беспокойство ;) Это при том, что количество объектов GPO было более 100.
И Ваше утверждение о том, что "лучше создать побольше ОГП, а часто - только так и возможно", мне, например, неочевидно.
Я сторонник противоположной точки зрения: если есть два варианта решения задачи, путём создания группы или ГПО, выбираю первый.
Мне так удобнее реализовывать делегирование полномочий. Да и продолжительность процесса загрузки\логина напрямую зависит от числа применяемых ГПО. Но, повторюсь, это дело вкуса.

Надеюсь, с технической частью вопрос прояснен.
Тогда, Дмитрий, несколько слов об этике дискуссии.
1. Если уж Вы высказали своё мнение о моей неправоте, то хотелось бы в том же посте увидеть и аргументацию такого мнения.
2. " Не обижайтесь, но Ваше "мне кажется, что. " нужно проверять прежде, предлагая в качестве рецепта. " Так вот, я не поленился и ещё раз проверил - рецепт работает. А Вы-то сами проверяли, прежде, чем утверждать, что "рецепт не сработает"? Так что возвращаю Вам Ваши же слова: прежде, чем что-либо безапелляционно заявлять, неплохо бы свое заявление проверить экспериментом.
3. Спасибо Вам за Ваши мне советы, но я о них Вас не просил. Хотя не исключаю, что когда-нибудь и обращусь :)
Да простит меня Vitaliy Shestakov за очередной флейм.

Для чего нужно запрещать вход на удаленный рабочий стол

Ранее мы с вами изучали, как подключаться к удаленному рабочему столу и познакомились с рядом клиентов RDP. Теперь у нас обратная задача, сделать все наоборот. Приведу несколько ситуацию в которых будет полезно запретить интерактивный и RDP вход:

Как запретить RDP подключение через групповую политику

Первый метод будет рассчитан на инфраструктуру построенную на Active Directory, где централизация является важным фактором управления. Тут мы с вами создадим отдельную групповую политику рассчитанную на группу RDSH хостов. Открываем редактор "Управление групповой политикой" и создаем новый объект GPO на нужном организационном подразделении.

Переходим в раздел:

Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Локальные политики - Назначение прав пользователя (Computer Configuration - Policies\Windows Settings - Security Settings - Local Policies - User Rights Assignment)

Там есть политика "Запретить вход в систему через службы удаленных рабочих столов (Deny log on through Remote Desktop Services)". Именно данная политика позволяет внести в нее пользователей или группы, у которых нужно отнять возможность входа по RDP.

Откроем оснастку ADUC и создадим новую группу безопасности "RDP-Deny"

Я включу в нее тестовую учетную запись Барбоскина Геннадия Викторовича, обратите внимание, что он является администратором домена и по умолчанию имеет доступ на все компьютеры в домене.

Активируем галку "Определить следующие параметры политики", после чего у вас станет доступна кнопка "Добавить пользователей или группу". Через кнопку обзор производим поиск нашей группы "RDP-Deny".

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

Теперь даже обладая административными правами на сервер с Windows Server 2019, вы получите вот такое уведомление:

Чтобы войти в систему, вам нужно право на вход через службу удаленных рабочих столов. По умолчанию такое право имеют члены группы "Пользователи удаленного рабочего стола". Если у вашей группы нет этого права или оно было удалено для группы "Пользователи удаленного рабочего стола", попросите предоставить его вам вручную. (the sign-in method you're trying to use isn't allowed. For more info, contact your network administrator)

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

Переходим в раздел:

Там есть политика "Запретить вход в систему через службы удаленных рабочих столов (Deny log on through Remote Desktop Services)".

Как запретить локальный вход

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

Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Локальные политики - Назначение прав пользователя - Запретить локальный вход (Computer Configuration - Policies\Windows Settings - Security Settings - Local Policies - User Rights Assignment - Deny log on locally)

Читайте также: