Как сделать учетную запись на компьютере с ограниченным доступом

Обновлено: 07.07.2024

Вам также может быть интересно:

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

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

Как изменить права пользователя на Windows 10

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

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

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

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

Способ №3. При помощи командной строки (cmd)

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

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

Для русскоязычных Windows — net localgroup Администраторы Имя пользователя /add
Для англоязычных Windows — net localgroup Administrators Имя пользователя /add

После набора команды, нажмите на кнопку Enter. В результате этого вы увидите уведомление о том, что команда выполнена успешно. На этом закрывайте командную строку.

Ну что же, сегодня мы рассмотрели разные способы, которые позволяют изменить учетную запись на Windows 10. Надеемся, что один из способов помог вам в этом не простом деле!

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

Как создать учетную запись с ограниченными правами?

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

Настройка учетной записи с ограниченными правами

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

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

Следует заметить, что настраивать учетную запись с ограниченными правами нужно только из-под учетной записи администратора, иначе вы ничего не сможете сделать.

Помогите членам семьи сбалансировать свое время в сети, установив ограничения для приложений и игр. Ограничения распространяются на все устройства Windows, Xbox и Android, подключенные через приложение Microsoft Family Safety.

Чтобы установить ограничения для приложений и игр, выполните следующие действия.

Откройте приложение "Семейная безопасность" (Майкрософт).

Найдите члена семьи и коснитесь его имени. Нажмите Установите временные ограничения > Приложения и игры.

Включите Ограничения для приложений и игр.

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

Задайте продолжительность использования приложения или игры членом семьи в день и время, когда ими можно пользоваться. Используйте одинаковые ограничения каждый день или составьте отдельное расписание для каждого дня недели.

Перейдите на сайт family.microsoft.com. Войдите в учетную запись "Семейной безопасности".

Найдите имя члена семьи и нажмите Дополнительные параметры > Время работы экрана.

Выберите вкладку Приложения и игры. Включите Ограничения для приложений и игр.

Щелкните приложение или игру, для которых требуется задать ограничения.

Ограничения для веб-сайтов

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

В веб-браузере откройте страницу family.microsoft.com. Войдите в учетную запись "Семейной безопасности".

Найдите члена семьи и нажмите Дополнительные параметры > Время работы экрана > Приложения и игры.

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

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

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

На компьютере установлен 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 вместо нескольких килобайт в случае группы.

С чего Вы это взяли? Политика 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 за очередной флейм.

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

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

Расположение политик Restricted groups.

Вторым способом является настройка Предпочтения Групповых Политик (Group Policy Preference, далее – GPP). Искать следует в Конфигурации компьютера – Настройка – Локальные пользователи и группы.

Настройка группы безопасности через GPP.

Как и все настройки в GPP, эта проще в понимании и с более дружелюбным интерфейсом. Но если у вас в инфраструктуре присутствуют не обновленные Windows XP или даже Windows 2000, то остается только первый вариант.

Таким же способом можно дать права и на определенные серверы нужным сотрудникам. Например, дать права группе разработчиков на тестовый стенд.

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

Группа	Описание
Администраторы	Полные права на систему.
Пользователи	Возможность пользоваться без изменения системных параметров и без записи в системные разделы. Фактически пользователь – полноценный хозяин только в папке своего профиля.
Операторы архива	Группа, предназначенная для выполнения резервного копирования и восстановления. Участники группы могут завершать работу системы на серверах и переопределять права доступа в целях резервного копирования.
Опытные пользователи	Участники этой группы могут администрировать локальные учетные записи и группы (кроме администраторов), создавать сетевые ресурсы и управлять доступом на них, менять NTFS ACL (кроме смены владельца папки).
Пользователи удаленного рабочего стола	Членство дает возможность подключаться к компьютеру по RDP
Операторы печати	Операторы могут устанавливать и удалять принтеры, изменять их драйвера и настройки, останавливать и чистить очередь печати.
Операторы настройки сети	Могут менять настройки сетевых интерфейсов. Это полезная группа на случай если нужно переназначать получение адреса сетевой картой с автоматического на статическое. Мобильные пользователи скажут спасибо, если добавить их в эту группу.
Операторы учета	Пользователи в этой группе могут создавать/удалять/редактировать/перемещать учетные записи в Active Directory. Удобно дать эти права для сервиса, автоматически заводящего учетки сотрудников после приема на работу.

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

Настройка прав доступа через групповые политики.

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

Вообще лучше всегда все документировать. Представьте ситуацию, что вы уволились из организации и вместо вас пришел человек с улицы. Поставьте себя на место этого человека. Если начал дергаться глаз или зашевелились волосы – посвятите время написанию документации. Пожалуйста!

Существует еще один хороший метод ограничения доступа к объектам – делегирование. Про эту технологию на Хабре уже писали, поэтому я лишь добавлю, что с помощью делегирования удобно выдаются права для ввода нового компьютера в домен.

Все эти технологии довольно давно существуют в системах Windows. С появлением Windows 10\2016 появилась еще одна интересная возможность ограничить учетные записи – речь о ней пойдет далее.

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

Сначала нам нужно разрешить удаленное подключение к серверу с помощью командлета Enable-PSRemoting, а заодно убедимся, что у нас Windows Management Framework нужной версии при помощи командлета $PSVersionTable.PSVersion.

Проверка версии и разрешение удаленных подключений при помощи PS.

Создадим группу безопасности и специального пользователя:

Теперь создадим нужные для работы конфигурационные файлы и папки. Сначала общие:

А затем создадим конкретный файл конфигурации для нашего оператора виртуальной машины с именем win. Для примера разрешим запуск и остановку виртуальной машины:

Теперь необходимо подготовить файл сессии PowerShell:

Зарегистрируем файл сессии:

Теперь все готово для проверки. Попробуем подключиться к серверу с учетными данными созданного пользователя командлетом:

Проверим список доступных команд командой get-command и попробуем остановить нашу виртуальную машину win, а затем другую машину win2.

Доступ к серверу ограничен управлением одной виртуальной машиной.

Для облегчения создания файлов конфигурации сообществом была создана утилита под названием JEA Toolkit Helper, где графический интерфейс поможет создать файлы с необходимыми параметрами.

Интерфейс JEA Toolkit Helper.

При необходимости есть возможность через групповые политики включить аудит выполнения модулей по адресу Конфигурация компьютера – Административные шаблоны – Windows Powershell – Включить ведение журнала модулей. Тогда в журнале Windows будут отображаться записи о том что, где и когда.

Журнал выполнения PowerShell.

Файловый журнал JEA.

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