Привязать пользователя к компьютеру в домене
Пользовательские учетные записи одни из самых популярных объектов в AD. Они нужны для аутентификации и авторизации на рабочих компьютерах и во многих сервисах, интегрированных с AD. Решение различных проблем связанных с УЗ пользователей, а также управление ими является одной из главных рутин для администраторов и специалистов хелпдеска. Данное руководство поможет вам сделать это несколькими способами. Чтобы управлять УЗ пользователей, необходимо войти на контроллер домена или сервер или устройство с установленными средствами удаленного администрирования сервера (RSAT) для Active Directory Domain Services.
Для того, чтобы не было ошибок доступа нам нужен аккаунт администратора домена или группы операторов учетных записей (Account Operators group) или нам нужна УЗ, которая делегирована на создание пользовательских объектов в домене или в нужной нам организационной единице (OU), которую мы будем использовать для хранения аккаунтов.
Как переместить учетную запись пользователя
После создания пользователя вы можете захотеть переместить его в другую 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
Вадим, я указал, что Вы заблуждаетесь потому, что Ваш рецепт не сработает: исключение доменных пользователей из встроенной группы пользователей компьютера не ограничит доменных пользователей в локальном входе на этот компьютер. Вот и все. Не обижайтесь, но Ваше "мне кажется, что. " нужно проверять прежде, предлагая в качестве рецепта. Вспомните/ознакомьтесь, с состоянием типичного членства "Builtin\Users" на рядовом компьютере в составе домена AD, о привилегиях, наконец.
Да, и вот еще что, не надо самому практиковать, а тем более - советовать неопытному администратору, менять эталонную модель безопасности без весомых причин. Во-первых, этим Вы навлечете больше проблем, чем получите бонусов, а во-вторых - это может лишить Вас технической поддержки!
Вадим, если Вы сможете объяснить, в чем я ошибаюсь - я Вам буду благодарен. :)
Add: Вадим, и по поводу объекта политики. Ну, пусть бы ОГП хоть 10 мегабайт в SYSVOL и столько же в контейнере AD занимал - и что? Репликация - оптимизирована, клиент не по пять раз на дню ОГП заново загружает, а администратор не меняет его от нечего делать - так ведь? В общем, лучше создать побольше ОГП, а часто - только так и возможно, чем в винегрете ковыряться.
Спасибо моей жене Кате, Клевогину С.П., Козлову С.В., Муравлянникову Н.А., Никитину И.Г., Шапиро Л.В. за мои знания! :)
Дмитрий, вообще-то я объяснил уже в одном из предыдущих постов этой ветки: 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 за очередной флейм.
Доброго времени суток!
Как можно автоматизировать это процесс, чтобы не добавлять рабочую станцию каждому пользователю вручную?
В идеале хотелось бы, чтобы каждому новому доменному юзеру, данный комп прописывался автоматически.
Возможно ли решить это групповой политикой доменной?
Создание учетной записи компьютера с помощью ADUC
Запустите ADUC (dsa.msc).
Перейдите к OU, в которой вы хотите хранить такие объекты, щелкните правой кнопкой мыши на этой OU -> New-> Computer:
Или вы можете сделать это, нажав на Action -> New -> Computer.
В окне New Object – Computer введите имя компьютера и имя pre Windows 2000 в соответствии с вашей политикой именования. Выберите, какая группа может ввести эту машину в домен и нажмите OK.
Поздравляю учетная запись компьютера создана!
Удаление учетной записи пользователя с помощью Active Directory Users and Computers
Чтобы удалить пользователя из домена, откройте Active Directory Users and Computers (dsa.msc).
Нажмите на меню View, включите Advanced Features. Перейдите в OU или контейнер, где находится объект пользователя, который вы собираетесь удалить. В меню Action выберите Find.
В поле Name введите имя пользователя, которого вы хотите удалить, и нажмите кнопку "Find now". В списке результатов поиска выберите нужного пользователя.
Щелкните правой кнопкой мыши на пользователя и выберите из списка пункт "Delete", а затем "Yes".
Как создать учетную запись пользователя
Давайте создадим учетную запись пользователя AD несколькими способами.
Перемещение учетной записи пользователя с помощью Windows PowerShell
Используйте следующий код Powershell для перемещения учетной записи пользователя (GSoul в нашем примере) в OU "Employees".
Import-Module ActiveDirectory
Move-ADObject -Identity:"CN=GSoul,CN=Users,DC=office,DC=local" -TargetPath:"OU=Employees,DC=office,DC=local"
Перемещение учетной записи пользователя через командную строку
Чтобы переместить объект пользователя (в нашем случае GSoul) в OU "Employees", запустите dsmove.exe в cmd со следующими параметрами:
dsmove.exe "CN=GSoul,CN=Users,DC=office,DC=local" -newparent "OU=Employees,DC=office,DC=local"
В этом окне перейдите к OU или контейнеру, в который вы хотите переместить пользователя, выберите его и нажмите OK.
Как переименовать учетную запись пользователя в Active Directory
Для того чтобы переименовать учетную запись пользователя, выполните следующие инструкции.
Переименование учетной записи пользователя с помощью PowerShell
Чтобы переименовать пользователя в AD, введите этот код в Windows PowerShell:
Import-Module ActiveDirectory
Rename-ADObject -Identity "CN=GSoul,CN=Users,DC=office,DC=local" -NewName "Gordon Gates"
На компьютере установлен Windows XP SP3, сам комп. в домене Windows 2003. Нужно, чтобы на этот компьютер можно было заходить только под отпределенной учетной записью. Это необходимо сделать только для 1-го компьютера, а не для всех в OU. То, что это делается через групповые политики я знаю, нужно конкретное решение.
Удаление учетной записи компьютера из AD с помощью Windows PowerShell
Эту задачу также можно легко выполнить с помощью Powershell, вот код для удаления учетной записи компьютера. В нашем примере имя компьютера WKS033
Import-Module ActiveDirectory
Remove-ADComputer -Identity "CN=WKS033,CN=Computers,DC=office,DC=local"
Пользовательские учетные записи одни из самых популярных объектов в AD. Они нужны для аутентификации и авторизации на рабочих компьютерах и во многих сервисах, интегрированных с AD. Решение различных проблем связанных с УЗ пользователей, а так же управление ими является одной из главных рутин для администраторов и специалистов хелпдеска. Данное руководство поможет вам сделать это несколькими способами. Чтобы управлять УЗ пользователей, необходимо войти на контроллер домена или сервер или устройство с установленными средствами удаленного администрирования сервера (RSAT) для Active Directory Domain Services.
Для того чтобы не было ошибок доступа, нам нужен аккаунт администратора домена или группы операторов учетных записей (Account Operators group), либо УЗ, которая делегирована на создание пользовательских объектов в домене или в нужной нам организационной единице (OU), которую мы будем использовать для хранения аккаунтов.
Удаление учетной записи компьютера из AD с помощью ADAC
Запустите ADAC (dsac.exe). Переключите левую панель в Tree view и выделите нужную OU. Введите имя компьютера в панели Filter и нажмите Enter. Выберите компьютер для удаления в результатах поиска, щелкните его правой кнопкой мыши и выберите Delete. Нажмите Yes для подтверждения.
Щелкните правой кнопкой мыши на учетную запись компьютера ->Properties и снимите флажок " Protect from accidental deletion".
После этого повторите процесс удаления.
Удаление учетной записи пользователя с помощью командной строки
Следующая команда удаляет пользователя "GSoul" из контейнера “Users” из домена office.local:
dsrm.exe "CN=Gregory Soul,CN=Users,DC=office,DC=local"
Создание учетной записи пользователя с помощью Windows PowerShell
Запустите следующий код PowerShell с правами администратора:
Import-Module ActiveDirectory
New-ADUser -Name FRobinson -Path "CN=Users,DC=office,DC=local" -GivenName "Frank" -Surname "Robinson" -sAMAccountName FRobinson
Как создать учетную запись компьютера в AD
Давайте создадим учетную запись компьютера, используя несколько методов. Эта учетная запись может быть использована для присоединения к ней устройства.
Удаление учетной записи компьютера из AD с помощью ADUC
Запустите ADUC (dsa.msc).
Перейдите в OU, содержащую нужные компьютеры, в меню Action выберите Find. Введите имя компьютера в поле Name и нажмите Find now. В результате поиска, щелкните правой кнопкой мыши на компьютере, который вы хотите удалить и выберете опцию Delete.
Нажмите Yes в окне подтверждения. Если после этого вы получите следующую ошибку:
Снова щелкните на компьютер правой кнопкой мыши, перейдите в Properties -> Object снимите флажок "“Protect object from accidental deletion" и выполните операцию удаления снова.
Создание учетной записи компьютера с помощью Cmd.exe
Для этой задачи нам необходимо использовать dsadd.exe. Используйте следующую команду для создания объекта компьютера в Active Directory:
dsadd.exe computer "CN=WKS033,CN=Computers,DC=office,DC=local"
Перемещение учетной записи пользователя через Active Directory Users and Computers
В Active Directory Users and Computers (dsa.msc) включите "Advanced Features" в меню "View".
Перейдите к OU или контейнеру с нужной учетной записью пользователя. В меню "Actions" выберите "Find. ”. В поле “Name” введите имя учетной записи пользователя и нажмите кнопку “Find now. ” В списке результатов поиска выберите нужный объект пользователя.
Щелкните правой кнопкой мыши на учетной записи пользователя. В меню выберите Move.
Откроется окно Перемещения:
Создание учетной записи компьютера с помощью ADAC
Запустите ADAC(dsac.exe), щелкните правой кнопкой мыши на имени домена, выберите New->Computer. Появится окно Create Computer, где вам нужно ввести имя компьютера, имя NetBIOS, в соответствии с вашей политикой именования. Укажите OU, где вы хотите хранить компьютер, нажав на Change. Вы также можете указать, какая группа может ввести этот компьютер в домен и защитить его от удаления. В конце нажмите OK.
Как удалить учетную запись компьютера в AD
Важно периодически удалять старые компьютеры из домена, чтобы избежать беспорядка в отчетах WSUS и применения политик GPO. Существует несколько способов добиться этого.
Удаление учетной записи пользователя с помощью Windows PowerShell
Используйте следующий PowerShell код для удаления пользователя из AD, синтаксис для примера использован такой же, как и в примере выше:
Import-Module ActiveDirectory
Remove-ADUser -Identity "CN=GSoul,CN=Users,DC=office,DC=local"
Переименование учетной записи пользователя в Active Directory Users and Computers
В Active Directory Users and Computers (dsa.msc) в меню View включите Advanced Features.
Перейдите к OU или контейнеру, в котором находится нужный объект пользователя. Щелкните его правой кнопкой мыши и выберите Find. В поле Name введите имя пользователя и нажмите "Find now". В результатах поиска щелкните правой кнопкой мыши нужную учетную запись пользователя и выберите Rename. Введите новое имя и нажмите Enter.
В появившемся окне введите новые данные для других атрибутов и нажмите OK.
Создание учетной записи компьютера с помощью PowerShell
Используйте следующие строки кода PowerShell для создания учетной записи компьютера с именем "WKS033" в домене office.local.
Import-Module ActiveDirectory
New-ADComputer -Name "WKS033" -sAMAccountName " WKS033" -Path "CN=Computers,DC=office,DC=local"
Создание учетной записи пользователя с помощью ADUC
- Бесплатное тестирование
- Лицензия Windows Server в подарок
- ЦОД в Амстердаме
Запустите Active Directory Users and Computers (dsa.msc).
Перейдите в нужную вам OU (organizational unit) или контейнер. На панели задач нажмите на значок New User, или щелкните правой кнопкой мыши пустое место в главном окне и выберите New -> User из меню, или щелкните правой кнопкой по выбранному вами OU или контейнеру и выберите New -> User.
Появится окно New Object - User, укажите параметры для вашего пользователя:
- Full Name, введите полное имя в поле Full Name или введите отдельно фамилию и имя в поля First Name и Last Name.
- User logon name - Имя логина пользователя, данный параметр создаст атрибут userPrincipalName и атрибут sAMAccountName, которые пользователь будет вводить при входе в систему.
Нажмите Next и укажите Пароль, затем наберите его во втором поле и отметьте нужные настройки, обычно для нового пользователя нужно отметить "User must change password at next logon"(Пользователь должен сменить пароль при следующем входе).
Нажмите Next и Finish. Поздравляем, учетная запись пользователя успешно создана!
Как удалить учетную запись пользователя
Для того чтобы удалить пользователя из Active Directory, используйте один из следующих методов. Обратите внимание, что это не приведет к полному удалению УЗ, если у вас настроена корзина AD Recycle Bin.
Удаление учетной записи компьютера из AD с помощью cmd.exe
Для этой задачи нам понадобится dsrm.exe. Используйте его со следующими параметрами для удаления учетной записи компьютера, в нашем случае это WKS033.
Создание УЗ пользователя с помощью cmd.exe
Используйте следующую команду с необходимыми параметрами для создания объекта пользователя в контейнере "Users", имя пользователя в примере будет GSoul:
dsadd.exe user "CN=GSoul,CN=Users,DC=office,DC=local" -upn GSoul@office.local -fn "Gordon" -ln "Soul" -display "Gordon Soul" -pwd "P@&&W0rd"
Все ответы
Политикой однозначно нельзя: она предназначена для конфигурирования компьютеров-членов домена и среды для пользователей на них, на отдельные учетные записи она не действует.
Если хотите автоматизировать - придется сделать скрипт.
А список рабочих станций одинаковый для всех пользователей, или существует несколько списков для разных категорий пользователей, или список индивидуальный для каждого пользователя?
Вообще предложил бы отказаться от настройки "Log on to. " и настроить по-другому, через политики безопасности. Cоздайте необходимое число доменных групп пользователей. Для каждого списка одинаковых компьютеров определите только одну доменную группу пользователей, которая будет иметь право заходить на них в систему, а вот каждый пользователь может быть членом одной или нескольких групп. Далее на каждой рабочей станции настройте политику безопасности, а именно привилегию Log On Locally (Локальный вход в систему), удалив все существующие группы и добавляя только группы Администраторы и одну из созданных вами доменных групп. Это можно сделать централизованно групповыми политиками, особенно если распределить списки одинаковых компьютеров по отдельным OU.
- Изменено osr_ MVP 12 ноября 2014 г. 16:24
- Предложено в качестве ответа Alexander Rusinov 12 ноября 2014 г. 16:46
Последний описанный вариант может делать не совсем то, что изначально описано. Поскольку любой пользователь будет иметь возможность залогиниться на любом новом компьютере в домене, который ещё не подвергся дополнительному конфигурированию (например, размещением в соответствующем OU). Тогда как вариант "Log on to. " будет работать всегда.
Но порождение соответствующего скрипта для произвольно именованных эккаунтов компьютеров и пользователей (без использования регулярных выражений), по трудоёмкости может оказаться сравнимым с рукопашными настройками :).
P.S. Сорри, пока писал, вариант (про который речь) стал предпоследним :)
Новый компьютер, также как и старые, применит политику в которой определены группы, имеющие право локального входа.
Новый компьютер, также как и старые, применит политику в которой определены группы, имеющие право локального входа.
Ещё раз попробую :). Для того, чтобы к разным компьютерам применялись разные (или по разному) политики, компьютеры должна принадлежать разным OU (или быть включены в разные группы). Для этого требуются дополнительные действия с учёткой компьютера. Поскольку после включения в домен, по умолчанию оно всегда Computers (и Domain Computers), и любая применяющаяся политика будет работать одинаково.
При использовании "Log on to. " действия производится только с учёткой пользователя. И для правильного эффекта, достаточно "правильного" имени компьютера, оно даже не завязано на учётки компьютеров в AD (то есть, компьютер не как конкретный объект AD, а как объект AD с конкретным именем системы).
Собственно, у нас используется и то, и другое, но с несколько разными "целями": или "этот пользователь может логиниться только на этих компьютерах", или "на этих компьютерах разрешено логиниться только этим пользователям". Различия, на самом деле, таки есть.
Учетные записи компьютеров представляют собой устройства, подключенные к AD. Они хранятся в базе данных AD после того, как их подключат к домену. Это необходимо для применения к ним различных GPO и отслеживания их обновлений, если у вас установлен WSUS. И что еще более важно, это нужно для установки безопасной аутентификации для пользователей, входящих в Windows.
Чтобы управлять компьютерами, вам нужны права администратора домена, оператора учетной записи (Account Operators) или делегированные права на OU в котором хранятся компьютеры. Управлять можно с рабочей станции с установленными инструментами RSAT или на контроллере домена.
Переименование учетной записи пользователя через командную строку
Для переименования пользователя используйте команду dsmove.exe со следующими параметрами:
dsmove.exe "CN=GSoul,CN=Users,DC=office,DC=local" -NewName "Gordon Gates"
Читайте также: