Пользователи домена права - IT Журнал
Light-electric.com

IT Журнал
6 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Пользователи домена права

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Пошаговый ввод в домен Windows 10

Погружение в Iptables – теория и настройка

Система мониторинга Nagios

Что делать? This host supports Intel VT-x

Создание доменного пользователя и ввод компьютера в домен

4 минуты чтения

В прошлой статье мы создали и настроили контроллер домена (DC), настало время наполнить наш домен пользователями и рабочими станциями.

Конфигурация

Открываем Server Manager и выбираем опцию Roles.

Из доступных ролей выбираем недавно установленную — Active Directory Domain Services, далее Active Directory Users and Computers и находим созданный нами домен (в нашем случае — merionet.loc). В выпадающем списке объектов находим Users и кликаем по данной опции правой кнопкой мыши и выбираем NewUser.

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

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

Далее, нас просят ввести пароль для новой учетной записи и выбрать дополнительные опции:

  • User must change password at next logon — при включении данной опции, пользователя попросят сменить пароль при следующем логине;
  • User cannot change password — пользователь не сможет самостоятельно изменить свой пароль;
  • Password never expires — срок действия пароля пользователя никогда не истечет;
  • Account is disabled — учетная запись пользователя будем отключена и он не сможет залогиниться с доменными учетными данными, даже если они будут введены верно.

После того, как все данные будут заполнены, нас попросят подтвердить создание нового объекта.

Отлично, новый пользователь домена создан. Теперь нам нужно зайти на компьютер пользователя и ввести его в домен. Для этого логинимся на компьютер пользователя с локальными учетными данными и открываем Свойства компьютера. Как видите, наш компьютер пока еще не стал частью домена, он ещё является частью рабочей группы WORKGROUP/. Убедитесь, что компьютер пользователя имеет версию Windows не ниже Professional. Чтобы ввести его в домен выбираем Change Settings

Важно! Поддержка доменной инфраструктуры начинается только с версии Windows Professional. На версиях Starter, Home Basic, Home Premium подключиться к домену не получится!

Далее напротив опции «To rename this computer or change its domain or workgroup, click Change» нажимаем собственно Change

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

Далее в открывшемся окне в опции «Member of» вместо Workgroup выбираем Domain и вводим имя нашего домена (в нашем случае – merionet.loc)

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

Если все было сделано корректно, то мы увидим сообщение, свидетельствующее о том, что наш компьютер теперь является частью домена (в нашем случае — merionet.loc)

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

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

Теперь, если мы откроем свойства компьютера, то увидим, что наш компьютер принадлежит домену (в нашем случае – merionet.loc)

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Предоставление прав локального администратора на машинах домена пользователю

Поставили задачу: обеспечить нескольким пользователям домена права локальных администраторов на ряде компьютеров домена, для возможности установки программ, оборудования, например, локальных принтеров. По-умолчанию, администратор домена является и локальным администратором компьютеров, включенных в домен. Но давать права или пароль от учетной записи администратора домена, пусть даже продвинутому пользователю, пожалуй, худший из возможных вариантов. Ходить, и в ручную добавлять выбранных пользователей на каждую рабочую станцию, тоже не вариант.

В итоге остановился на достаточно гибком решении при помощи групповых политик.

Запускаем оснастку «Active Directory — пользователи и компьютеры» и создаем глобальную группу безопасности. Для ясности назовем ее «Администраторы локальных машин»

Далее, запускаем оснастку «Управление групповой политикой» и создаем новый объект групповой политики. Для ясности, назовем политику «Локальные администраторы (PC)» /я обычно помечаю, на что действует та или иная политика. В данном случае PC — на компьютер/

Далее, изменяем созданную политику. Выбираем ветку: «Конфигурация компьютера» → «Конфигурация Windows» → «Параметры безопасности» → Группы с ограниченным доступом

И выбираем Добавить группу…

При добавлении группы указываем ранее созданную группу «Администраторы локальных машин»

Далее добавляем запись в нижней части «Эта группа входит в:»

Указываем группу «Администраторы»

Жмем Ок. Политика создана.

Можно посмотреть политику перейдя на вкладку «Параметры»

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

Теперь, можно создать подразделение, например, «Рабочие станции», поместить туда компьютеры, для которых необходимо применить политику

После этого следует назначить подразделению созданную нами политику.

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

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

Как видно из примера, все достаточно просто и, надеюсь, понятно.

ВАЖНО. Используя данный метод, появляется возможность входа на сервера с такой учетной записью.
Данный вопрос изучается.

Пользователи домена права

Вопрос

В чем разница в домене мужде Users и Domain Users?

Ответы

В чем разница в домене мужде Users и Domain Users?

Вот тут даны описания для всех дефолтовых групп.

  • Помечено в качестве ответа Vinokurov Yuriy Moderator 30 июня 2009 г. 12:51

Все ответы

Ну Users — локальная группа пользователей, а D omain Users — доменная. В домене любой пользователь является членом группы Domain Users. Локально же пользователь может и не состоять в группе Users. На каждой машине группа Domain Users входит в группу Users, что нивелирует разницу между группами.

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

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

Если у вас один домен, то этот момент абсолютно непринципиален ).

В чем разница в домене мужде Users и Domain Users?

Вот тут даны описания для всех дефолтовых групп.

  • Помечено в качестве ответа Vinokurov Yuriy Moderator 30 июня 2009 г. 12:51

Нибоже мой, стратегии AGLP/AGDLP принципиальны и в одном домене. В многодоменной структуре обсуждаема только роль Универсальных групп.

Нибоже мой, стратегии AGLP/AGDLP принципиальны и в одном домене. В многодоменной структуре обсуждаема только роль Универсальных групп.

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

Читать еще:  Как ввести mac в домен

Нибоже мой, стратегии AGLP/AGDLP принципиальны и в одном домене. В многодоменной структуре обсуждаема только роль Универсальных групп.

Простите, но такое впечатление, что вы перечитали книжек )

Нибоже мой, стратегии AGLP/AGDLP принципиальны и в одном домене. В многодоменной структуре обсуждаема только роль Универсальных групп.

Простите, но такое впечатление, что вы перечитали книжек )

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

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

Это я к тому, что возводить ничегов абсолют не нужно. Не сотвори себе кумира ).

В однодоменной структуре та же проблематика, что и в многодоменной:

В: «Как дать Менеджерам доступ к Цветному лазерному принтеру, к которому уже имеют доступ Бухгалтеры?»

О: «Внесите Глобальную группу Менеджеры в Локальную группу Цветной лазерный принтер», одно действие

В: «Как правильно и быстро дать доступ Операторам московского офиса к программе Консультант+ ?»

О: «Внесите Глобальную группу Операторы московского офиса в Локальную Пользователи Консультант. На эту группу уже назначены все детальные права на все необходимые файлы и каталоги, поэтому операция будет выполнена быстро (два клика) и гарантированно (вы не ошибётесь, забыв про специальные права на один-два файла)»

Ценность быстрой и точной ПЕРЕконфигурации системы в домене любого масштаба.

MCSE NT4, MCSE 2000, MCSE 2003

Microsoft IT Academy trainer for MCSE 2003 track

В однодоменной структуре та же проблематика, что и в многодоменной:

В: «Как дать Менеджерам доступ к Цветному лазерному принтеру, к которому уже имеют доступ Бухгалтеры?»

О: «Внесите Глобальную группу Менеджеры в Локальную группу Цветной лазерный принтер», одно действие

MCSE NT4, MCSE 2000, MCSE 2003

Microsoft IT Academy trainer for MCSE 2003 track

В: «Как дать Менеджерам доступ к Цветному лазерному принтеру, к которому уже имеют доступ Бухгалтеры?»

О: «Внесите Глобальную группу Менеджеры в Глобальную группу Цветной лазерный принтер», одно действие

Понимаете, что я хочу сказать?

vanchello: когда я тут назвал глобальные, локальные и универсальные группы «типом», а не «областью действия, scope», ув. коллега Alager быстро меня одёрнул — «давайте придерживаться принятой Microsoft терминологии». И я, безусловно, поддерживаю его устремление следовать хорошим практикам, чёткой терминологии. Так что, дорогой коллега, давайте придерживаться принятой Microsoft идеологии — для назначения прав доступа использовать Локальные (или ДоменЛокальные) группы; для объединения пользователей — Глобальные.

Мы можем объединить глобальные Операторы Москвы, Операторы Риги и Операторы Киева в единой глобальной Операторы Холдинга, но группа «Пользователи цветного лазерного принтера» останется Локальной либо ДоменЛокальной. И стратегия AGLP / AGDLP тоже останется. Я понимаю, что права доступа, назначенные на Глобальные группы, работают. Права, назначенные напрямую на аккаунты, тоже работают, но это неправильно.

Как дать пользователям домена права локального администратора через групповые политики (GPO)

Вы, вероятно, уже знаете, как на дать права локального администратора доменным пользователям на отдельном компьютере (просто добавьте доменные учетки в группу локальных администраторов).
А когда таких компьютеров 10? 100? 1000? Как добавить доменных юзеров в локальную группу (администраторов) через групповую политику?

А когда у Вас разные версии Windows? Разные языки: английская, русская, украинская, испанская версия windows? В этом случае главное — добавлять доменных пользователей в локальные группы, используя SID локальных групп, а не их имена. О том, что такое SID, зачем он здесь нужен и главное — как указать SID группы там, где можно вписать только имя — читайте в этой статье.

Настройка прав через GPO: Restricted Groups

  1. Подключитесь к контроллеру домена.
  2. Создайте новую групповую политику (например, с помощью gpmc.msc => Group Policy Objects => New).
  3. Откройте созданную групповую политику на редактирование.
  4. Выберите пункт «Computer Configuration» => «Policies» => «Windows Settings» => «Security Settings» => «Restricted Groups».
  5. Нажмите правой кнопкой мыши на «Restricted Groups» и выберите «Add Group. «
  6. Выполните один из 2 вариантов (обратите внимание — важно сделать правильный выбор, почему — см. ниже):
    1. Впишите имя группы доменных юзеров (это может быть имя пользователя, но обычно это все-таки группа).
    2. Нажмите «Browse. » и выберите группу пользователей домена.
  7. После добавления группы пользователей домена откроются свойства добавленной Вами группы (Вы также можете открыть свойства самостоятельно двойным щелчком мыши на добавленной группе).
  8. В окне свойств добавленной группы Вы можете задать членов этой доменной группы, либо (что используется намного чаще) указать, в какие локальные группы на компьютере должна входить данная группа доменных пользователей.
  9. Для указания того, в какие локальные группы компьютеров должна входить добавленная группа пользователей домена, в части окна «This group is a member of» нажмите кнопку «Add. » и выполните один из двух вариантов (обратите внимание — важно сделать правильный выбор, почему — см. ниже):
    1. Впишите имя локальной группы, в которую должна входить добавленная Вами группа доменных пользователей.
    2. Нажмите «Browse. » и выберите группу пользователей (да, локальную группу из AD).
  10. Обратите внимание, что Вы можете указать несколько локальных групп, членом которых Вы хотите сделать доменную группу. Для этого каждый раз необходимо нажимать кнопку «Add..» (и выполнять пункт 9).
  11. После внесения всех необходимых доменнных (и локальных) групп закройте групповую политику и назначьте (link) её к нужной Вам организационной единице (Organizational Unit).
  12. Переместите в эту организационную единицу компьютеры, при необходимости сделайте на компьютерах принудительное обновление групповой политики:
    gpupdate /force
  13. Для того, чтобы узнать, применилась ли (и каким образом применилась) созданная Вами групповая политика, Вы можете посмотреть в логи на клиентских компьютерах:
    %SYSTEMROOT%SecurityLogswinlogon.log
    %SYSTEMROOT%DebugUserModeUserenv.log
    А также в журнал событий Event Viewer (eventvwr) в разделе «Applications and Services Logs» => «Microsoft» => «Windows» => «Applications and Services Logs» => «Group Policy» => «Operational».

Новая группа доменных пользователей в Restricted Groups (пункт 6): ввод имени группы или выбор через поиск?

При добавлении новой группы доменных пользователей в «Restricted Groups» в Windows работают 2 разных механизма: ввод имени группы вручную или выбор ее из имеющегося списка доменных групп. Если совсем кратко, то при вводе имени группы вручную в конфигурацию групповой политики попадет (как правило) имя группы, а при выборе из списка доменных групп (через поиск в AD) — будет использован SID.

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

Что такое SID?
У каждой группы (и пользователя) как доменных, так и локальных, есть уникальный идентификатор — SID (иначе мы не смогли бы переименовывать группы, при этом терялись бы все права на папки, принадлежащие этой группе). Так вот, при сопоставлении имён Windows понимает, что эта группа — не «Друзья Васи», а SID S-123-456-7890-49439535. И даже переименовав группу, мы не потеряем групповых политик, связанных с ней.

Если же название группы введено вручную, то скорее всего, Windows запишет группу по её названию. И если мы (например) дали группе «Друзья Васи» админские права на всех компьютерах, мы потеряем эти права, если переименуем группу, например в «Лучшие друзья Васи». Более того: поскольку сопоставление будет выполняться по имени группы, то переименовав группу «Друзья Васи» в «Лучшие друзья Васи», и создав (новую, никак с предыдущей группой не связанную) группу «Друзья Васи» (может, уже другого Васи) — мы дадим этим новым друзьям нового Васи админские права на компах!

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

Читать еще:  Настройка репликации между контроллерами домена

Вывод: всегда добавляйте группы, делая выбор из имеющихся доменных групп (через поиск в AD), чтобы использовался SID группы.

Добавление доменной группы в локальные группы пользователей (пункт 9):
ввод имён групп вручную или выбор через поиск в AD?

При указании того, членом каких локальных групп компьютера должна быть нужная Вам доменная группа обратите внимание: в Windows работают 2 разных механизма: ввод имён групп вручную или выбор их из имеющегося списка. Если совсем кратко, то при вводе имени группы вручную в конфигурацию групповой политики попадет (как правило) имя группы, а при выборе из списка доменных групп (через поиск в AD) — будет использован SID. О том, почему это так важно — читайте ниже.

С SID мы разберемся чуть позже, но еще вопрос в том, как выбрать локальную группу там, где отображается только Active Directory (AD). Об этом также читайте далее.

Обратите внимание, что через интерфейс редактирования групповых политик мы (скорее всего) никак не сможем установить, введено ли название группы вручную — или выбрано из имеющихся групп (и вместо имени там фактически используется SID).

Настройка Restricted Groups для предоставления доменным пользователям прав локального администратора: как указывать локальные группы пользователей

Рассмотрим, в чем у нас состоит задача: добавить доменного пользователя (а правильнее — группу доменных пользователей, даже если в этой группе только 1 пользователь) в локальные администраторы на всех компьютерах (можно — домена, можно — организационной единицы).

Механизм добавления ясен: берем имеющуюся доменную группу (например domainIT) и нам необходимо её добавить в локальные администраторы. Казалось бы, всё просто? Ан нет.

Добавление группы доменных пользователей в группу локальных администраторов на АНГЛОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Administrators». Всё просто, но в русскоязычных версиях Windows это не работает: группа IT не становится администраторами компьютеров, а в логах русской винды — ошибки применения нашей групповой политики.

Добавление группы доменных пользователей в группу локальных администраторов на РУССКОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Администраторы». Всё просто, но в англоязычных версиях Windows это не работает: группа IT не становится администраторами компьютеров, а в логах английской винды — ошибки применения нашей групповой политики.

Добавление группы доменных пользователей в группу локальных администраторов на АНГЛОязычной и РУССКОязычной версии Windows

Для этого добавляем в Restricted Groups новую группу: domainIT, а в её свойствах, в разделе «This group is a member of» вписываем группу «Администраторы», а также группу «Administrators». Всё просто, группа IT становится администраторами русской и английской версий Windows, но в логах на всех windows — ошибки применения нашей групповой политики (потому что где-то нет группы «Администраторы», а где-то — «Administrators»).

А что, если (вдруг) у Вас украинская версия Windows? Испанская версия Windows? А если злобные администраторы переименовали на компьютере группу локальных администраторов, назвав ее например. «Админы»?

Права локального администратора группе доменных пользователей в любой версии Windows (для любого языка): используем SID для локальных групп

Способ очень простой: для локальных групп, членом которых будет наша доменная группа, необходимо указывать SID. Разумеется, Вы не можете указать SID напрямую (это будет воспринято как имя группы), но есть целых 2 способа заставить Windows подставить SID вместо имен локальных групп.

Прежде всего: почему SID? Это будет работать?
Да! Потому что независимо от версии, разрядности, языка(!) и других параметров Windows, у стандартных групп (таких как «Пользователи» — «Users», «Администраторы» — «Administrators» и так далее) есть заранее зарезервированные (так сказать «широко известные идентификаторы безопасности SID» — «well-known SIDs»). Для группы локальных администраторов SID всегда один и тот же, независимо от языка: S-1-5-32-544.

Способ 1. Выбор локальных групп из AD

Итак, Вы уже добавили в Restricted Groups доменную группу, открыли её свойства, нажали кнопку «Add..» и думаете, как вписать название группы локальных администраторов, чтобы Windows подставила её SID? Всё просто: нажимаете «Browse. » и ищете (в зависимости от языка Вашей AD — именно самой AD!) либо «Administrators», либо «Администраторы» (либо другое название — зависит от языка самой AD!). Эта группа располагается в AD в разделе (это не совсем OU, хотя выглядит так же) под названием «Builtin». При поиске можно также открыть настройки поиска: «Object types. » и оставить отмеченным только пункт «Built-in security principials».

Если Вы выберете локальную группу таким образом (т.е. через поиск в домене, раздел builtin), то хотя после поиска будет отображено только название группы («Administrators», «Администраторы», . ), в Windows будет записан SID группы локальных администраторов, независимо от текстового названия группы локальных админов!

Способ 2. Правка конфига групповой политики

Итак, Вы уже добавили в Restricted Groups доменную группу, открыли её свойства, нажали кнопку «Add..» и думаете, как вписать название группы локальных администраторов, чтобы Windows подставила её SID? Всё просто:

  1. Впишите любое уникальное название: например «testtesttest».
  2. Теперь откройте свойства групповой политики (правой кнопкой по имени политики) и скопируйте/запишите/запомните ее «Unique name» (т.е. GUID).
  3. Не забудьте закрыть групповую политику!
  4. Откройте папку групповой политики.
    Для этого откройте шару:
    \domain.localsysvolPolicies
  5. Перейдите в папку:
    MachineMicrosoftWindows NTSecEdit
  6. Откройте файл:
    GptTmpl.inf
  7. В разделе [Group Membership]
    В одной из строчек Вы увидите Ваше уникальное название, перед которым стоит какой-то длинный текст из букв и цифр:
    *S-1-5-21-488169584-1945689841-2750668826-1126__Memberof = testtesttest
  8. Удалите Ваше уникальное название и впишите SID группы локальных администраторов. Звездочка (программисты на С/С++ знают, что это вызов значения по указателю) указывает, что нужно использовать не само название, а содержимое того, что стоит за этим названием, так что пишем:
    *S-1-5-21-488169584-1945689841-2750668826-1126__Memberof = *S-1-5-32-544
    Итак, алгоритм действий:
    1. Находите в файле GptTmpl.inf строку с уникальным текстом, который Вы вписали в качестве имени локальной группы
    2. Удаляете в этой строке всё СПРАВА от знака «=» (т.е. Ваш текст)
    3. Вписываете СПРАВА от знака «=» (не забудьте после «=» поставить пробел!):
      . = *S-1-5-32-544
    4. Сохраняете файл GptTmpl.inf
  9. Всё.

Обязательно проверьте, как работает эта схема, применив групповую политику к одному или нескольким компьютерам, и проанализировав результат! Ищите добавленную Вами группу доменных пользователей не только в панели управления => учетные записи пользователей, но и в управлении компьютером, просмотрев членов локальной группы администраторов!

При подготовке статьи использовались следующие материалы:

Статья опубликована: 26.07.2017, обновлена: 16.08.2017

Учетные записи пользователей

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

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

Локальные учетные записи против доменных

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

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

Читать еще:  Проверка работы домена

Но доменные учетные записи имеют не только пользователи. В домене учетные записи представляют физические записи, которые могут соответствовать компьютеру, пользователю или группе. Пользовательские учетные записи, учетные записи компьютеров и учетные записи групп являются принципалами (элементами доступа) — объектами службы каталогов, автоматически получающими идентификаторы SID, которые и определяют доступ к ресурсам домена.

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

Встроенные доменные учетные записи

Когда создается домен, Windows автоматически генерирует несколько пользовательских учетных записей. В Windows 2000 встроенными являются учетные записи Administrator и Guest. Домены Windows Server 2003 имеют третью встроенную учетную запись с именем HelpAssistant, которая автоматически создается при первом запуске функции Remote Assistance. Каждая из этих встроенных учетных записей имеет разный набор разрешений.

Учетная запись Administrator имеет набор разрешений Full Control на все ресурсы домена и может назначать разрешения пользователям в домене. По умолчанию учетная запись Administrator является членом следующих групп:

  • Administrators
  • Domain Admins
  • Domain Users
  • Enterprise Admins
  • Group Policy Creator Owners
  • Schema Admins

Некоторые администраторы переименовывают или отключают учетную запись Administrator, чтобы усложнить пользователям доступ к контроллеру домена (DC). Вместо этого администраторы могли бы регистрироваться с учетными записями, которые являются членами тех же групп, что давало бы им достаточно прав для администрирования домена. Если учетную запись Administrator отключить, при необходимости получение доступа к DC можно будет пользоваться этой учетной записью, загружая DC в режиме Safe Mode (учетная запись Administrator всегда доступна в режиме Safe Mode).

Учетная запись Guest позволяет регистрироваться в домене пользователям, не имеющим учетной записи. Учетная запись Guest не требует пароля, но можно установить для нее разрешения точно так же, как для любой пользовательской учетной записи. Учетная запись Guest является членом групп Guests и Domain Guests. Понятно, что возможность регистрироваться в домене любому лицу, не имеющему реальной учетной записи, создает определенный риск, поэтому большинство администраторов эту учетную запись не используют. В Windows 2003 учетная запись Guest по умолчанию отключена. Для того чтобы отключить учетную запись Guest в Windows 2000, нужно щелкнуть по ней правой кнопкой в оснастке Microsoft Management Console (MMC) Active Directory Users and Computers, затем в меню выбрать Disable.

Учетная запись HelpAssistant появилась только в Windows 2003. Служба Remote Desktop Help Session Manager создает эту учетную запись и управляет ею, когда пользователь запрашивает сеанс Remote Assistance.

Создаем учетные записи пользователя домена

Учетные записи пользователей домена создаются на DC как функция AD. Необходимо открыть оснастку Active Directory Users and Computers, затем раскрыть подходящий домен (если их несколько). В отличие от Windows NT 4.0, в Windows 2000 и Windows 2003 процессы создания и настройки учетных записей разделены: сначала администратор создает пользователя и соответствующий пароль, затем выполняет настройку, задавая членство в группах.

Чтобы создать нового пользователя домена, следует щелкнуть правой кнопкой по контейнеру Users, затем выбрать New, User, чтобы открыть диалоговое окно New Object — User, изображенное на экране 1. Далее требуется ввести имя пользователя и регистрационное имя. Windows автоматически добавляет к регистрационному имени суффикс текущего домена, который называется суффиксом принципала пользователя (UPN-суффиксом). Можно создать дополнительные UPN-суффиксы и выбрать суффикс для нового пользователя в поле со списком. Можно также ввести другое имя пользователя для регистрации в домене с компьютеров NT 4.0 и Windows 9.x (по умолчанию подставляется предыдущее имя).

Далее следует щелкнуть Next, чтобы выполнить настройку пароля пользователя, как показано на экране 2. По умолчанию Windows вынуждает пользователей менять пароль при следующей регистрации, поэтому для каждого нового пользователя можно брать некий стандартный пароль компании, а затем дать пользователям возможность ввести новый пароль после первой самостоятельной регистрации. Далее следует выбрать параметры пароля, которые нужно задать для этого пользователя. Наконец, требуется щелкнуть Next, чтобы увидеть общую картину выбранных настроек, затем щелкнуть Finish, чтобы создать учетную запись пользователя в AD.

Свойства учетной записи пользователя

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

Вкладка Member Of управляет членством пользователя в группах (и, следовательно, разрешениями и правами пользователя в домене). По умолчанию Windows помещает учетную запись нового пользователя в группу Domain Users. Для одних пользователей этого достаточно, и больше ничего делать не нужно. Другим пользователям, например руководителям отделов или ИT-персоналу, нужно обеспечить такое членство в группах, которое позволило бы им выполнять необходимые задачи. Чтобы установить членство в группе, следует щелкнуть Add, затем выбрать для пользователя, учетная запись которого редактируется, подходящую группу. Если встроенные группы не обеспечивают точно соответствующего имеющимся требованиям набора разрешений, следует сформировать собственные группы.

Создаем шаблоны

Windows позволяет копировать учетные записи пользователей, что делает процесс создания шаблонов более быстрым и эффективным. Наилучший способ воспользоваться преимуществами этой функции — создать ряд шаблонов учетных записей пользователей, а потом превращать эти учетные записи в реальные. Поскольку разрешения и права являются наиболее важными (и потенциально опасными) свойствами, следует создавать шаблоны в категориях в соответствии с членством в группах. Начать нужно с шаблона для стандартного пользователя (т. е. члена только группы Domain Users), затем следует создать шаблоны, имеющие конкретные комбинации принадлежности к группам. Например, можно создать шаблон пользователя под именем Power с принадлежностью к группе Power Users без ограничений часов регистрации или шаблон пользователя под именем DialUp с заранее установленными параметрами коммутируемого доступа. Впоследствии, по мере создания новых учетных записей, можно выбирать подходящий шаблон и модифицировать его.

Я обнаружила несколько полезных приемов создания и копирования шаблонов:

  • присваивать шаблонам имена, которые начинаются с 0, чтобы они все вместе появлялись поверх списка пользовательских файлов;
  • назначать всем шаблонам один и тот же пароль;
  • отключать все учетные записи шаблонов (щелкнуть правой кнопкой файл, затем выбрать Disable).

Для того чтобы создать учетную запись для нового пользователя из шаблона, следует щелкнуть правой кнопкой по списку шаблонов, затем выбрать Copy. В диалоговом окне Copy Object — User нужно ввести имя пользователя и регистрационное имя для вновь создаваемой записи, затем щелкнуть Next, чтобы задать пароль нового пользователя, как описано ниже.

  1. Введите стандартный пароль компании и назначьте его новому пользователю.
  2. Очистите ячейки Password never expires (срок действия не ограничен) и Account is disabled (учетная запись отключена).
  3. Поставьте флажок User must change password at next logon.
  4. Щелкните Next, затем Finish.

Не стоит возиться с вкладкой Member Of, поскольку система уже скопировала членство в группах из шаблона пользователя. По сути, если нет необходимости записывать телефон и адрес пользователя, на оставшихся вкладках можно ничего не делать. Система копирует все общие атрибуты. Однако можно добавить для автоматического копирования другие атрибуты или сделать так, чтобы определенные атрибуты не копировались, модифицируя схему AD.

Кэти Ивенс — редактор Windows 2000 Magazine. Участвовала в написании более 40 книг по компьютерной тематике, включая «Windows 2000: The Complete Reference» (Osborne/McGraw-Hill). С ней можно связаться по адресу: kivens@win2000mag.com

Поделитесь материалом с коллегами и друзьями

голоса
Рейтинг статьи
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector