HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Полное руководство по Active Directory, от установки и настройки до аудита безопасности. Ч. 1: Введение в Active Directory (понятия, применение, отличие от Workgroup)
Оглавление
8. Групповые политики
9. Управление пользователями и компьютерами Active Directory. Группы. Организационные единицы
10. Настройка траста и сайта доменов
11. Другие службы и роли Active Directory
12. Настройка Samba (Active Directory для Linux)
13. Инструменты для аудита безопасности Active Directory
Что такое Active Directory
Active Directory — это технология Microsoft, которая представляет собой распределенную базу данных, в которой хранятся объекты в иерархическом, структурированном и безопасном формате. Объекты AD обычно представляют пользователей, компьютеры, периферийные устройства и сетевые службы. Каждый объект уникально идентифицируется своим именем и атрибутами. Домен, лес и дерево представляют собой логические подразделения инфраструктуры AD.
Домены Windows обычно используются в больших сетях — корпоративных сетях, школьных сетях и государственных сетях. Они не то, с чем вы столкнётесь дома, если у вас нет ноутбука, предоставленного вашим работодателем или учебным заведением.
Типичный домашний компьютер — обособленный объект. Вы управляете настройками и учётными записями пользователей на компьютере. Компьютер, присоединённый к домену, отличается — этими настройками управляет контроллер домена.
Что такое домен?
Домены Windows предоставляют сетевым администраторам возможность управлять большим количеством компьютеров и контролировать их из одного места. Один или несколько серверов, известных как контроллеры домена, контролируют домен и компьютеры на нём.
Домены обычно состоят из компьютеров в одной локальной сети. Однако компьютеры, присоединённые к домену, могут продолжать обмениваться данными со своим контроллером домена через VPN или подключение к Интернету. Это позволяет предприятиям и учебным заведениям удалённо управлять ноутбуками, которые они предоставляют своим сотрудникам и учащимся.
Когда компьютер присоединён к домену, он не использует свои собственные локальные учётные записи пользователей. Учётные записи пользователей и пароли устанавливаются на контроллере домена. Когда вы входите в систему в этом домене, компьютер аутентифицирует имя вашей учётной записи и пароль с помощью контроллера домена. Это означает, что вы можете войти в систему с одним и тем же именем пользователя и паролем на любом компьютере, присоединённом к домену.
Сетевые администраторы могут изменять параметры групповой политики на контроллере домена. Каждый компьютер в домене получит эти настройки от контроллера домена, и они переопределят любые локальные настройки, указанные пользователями на своих компьютерах. Все настройки контролируются из одного места. Это также «блокирует» компьютеры. Вероятно, вам не будет разрешено изменять многие системные настройки на компьютере, присоединённом к домену.
Другими словами, когда компьютер является частью домена, организация, предоставляющая этот компьютер, управляет и настраивает его удалённо. Они контролируют ПК, а не тот, кто им пользуется.
Поскольку домены не предназначены для домашних пользователей, к домену можно присоединить только компьютер с версией Windows Professional или Enterprise. Устройства под управлением Windows RT также не могут присоединяться к доменам.
Для чего нужна Active Directory
Если в вашем офисе используется Active Directory, все машины будут подключены к домену, что означает, что вся информация хранится в централизованном месте, а не локально на жёстких дисках отдельных компьютеров. Домен управляется глобальным каталогом, который отслеживает все устройства, зарегистрированные в сети. В глобальном каталоге хранятся IP-адреса, имена компьютеров и пользователей, поэтому глобальный администратор может контролировать всё, что происходит в домене. Чтобы управлять компьютерами, администратору просто понадобится имя этого компьютера, потому что всё уже связано с серверной частью.
Когда вы используете Active Directory, все разрешения устанавливаются контроллером домена. Это означает, что сетевой администратор уже сообщил контроллеру домена, какие разрешения назначить каждому пользователю. Это делает всю цифровую коммуникацию более эффективной.
Что может администратор сети через Active Directory?
Не всем в вашей организации обязательно нужен доступ ко всем файлам/документам, имеющим отношение к вашей компании. С помощью Active Directory вы можете предоставить отдельным пользователям разрешение на доступ к любым файлам/дискам, подключённым к сети, чтобы все участвующие стороны могли использовать ресурсы по мере необходимости. Кроме того, вы можете указать ещё более точные разрешения. Чтобы проиллюстрировать это, давайте рассмотрим пример: предположим, у вашей компании есть каталог в сети для всех документов, относящихся к кадрам. Сюда могут входить любые формы, которые нужны сотрудникам для подачи в отдел кадров (официальные запросы, официальные жалобы и так далее). Предположим также, что в каталоге есть таблица, в которой указано, когда сотрудники будут в отпуске и отсутствовать в офисе. Ваш сетевой администратор может предоставить всем пользователям доступ к этому каталогу только для чтения, что означает, что они могут просматривать документы и даже распечатывать их, но они не могут вносить какие-либо изменения или удалять документы. Затем администратор может предоставить расширенные права вашему менеджеру/директору по персоналу или любому другому сотруднику отдела кадров, которому потребуется редактировать файлы, хранящиеся в каталоге.
Ещё одним огромным плюсом для сетевых администраторов, использующих Active Directory, является то, что они могут выполнять обновления в масштабе всей сети одновременно. Когда все ваши машины автономны и действуют независимо друг от друга, вашим сетевым администраторам придётся переходить от машины к машине каждый раз, когда необходимо выполнить обновления. Без Active Directory им пришлось бы надеяться, что все сотрудники обновят свои машины самостоятельно.
AD позволяет централизовать управление пользователями и компьютерами, а также централизовать доступ к ресурсам и их использование.
Вы также получаете возможность использовать групповую политику, когда у вас настроена AD. Групповая политика — это набор объектов, связанных с подразделениями, которые определяют параметры для пользователей и/или компьютеров в этих подразделениях. Например, если вы хотите сделать так, чтобы в меню «Пуск» не было опции «Завершение работы» для 500 лабораторных ПК, вы можете сделать это с помощью одного параметра в групповой политике. Вместо того, чтобы тратить часы или дни на настройку правильных записей реестра вручную, вы создаёте объект групповой политики один раз, связываете его с правильным OU (organizational units, организационные единицы) или несколькими OU, и вам больше никогда не придётся об этом думать. Существуют сотни объектов групповой политики, которые можно настроить, и гибкость групповой политики является одной из основных причин доминирования Microsoft на корпоративном рынке.
Что нужно для Active Directory
Active Directory можно включить на компьютерах с Windows Server. На не серверных компьютерах (например, с Windows 10), можно установить и включить Active Directory Lightweight Directory Services, то есть средства удалённого администрирования сервера: средства доменных служб Active Directory и служб облегчённого доступа к каталогам. Они предоставляют сервер LDAP (Lightweight Directory Access Protocol, облегчённый протокол доступа к каталогам). Он работает как служба Windows и предоставляет каталог для аутентификации пользователей в сети. Это лёгкая альтернатива полноценному серверу Active Directory, которая будет полезна только в определённых бизнес-сетях.
Active Directory Domain Services
Когда люди говорят «Active Directory», они обычно имеют в виду «доменные службы Active Directory» (Active Directory Domain Services, AD DS). Важно отметить, что существуют другие роли/продукты Active Directory, такие как службы сертификации, службы федерации, службы облегчённого доступа к каталогам, службы управления правами и так далее.
Доменные службы Active Directory — это сервер каталогов Microsoft. Он предоставляет механизмы аутентификации и авторизации, а также структуру, в которой могут быть развёрнуты другие связанные службы (службы сертификации AD, федеративные службы AD и так далее). Это совместимая с LDAP база данных, содержащая объекты. Наиболее часто используемые объекты — это пользователи, компьютеры и группы. Эти объекты могут быть организованы в организационные единицы (OU) по любому количеству логических или бизнес-потребностей. Затем объекты групповой политики (GPO) можно связать с подразделениями, чтобы централизовать настройки для различных пользователей или компьютеров в организации.
Контроллер домена
Сервер, который хостит AD DS — это Контроллер домена (Domain Controller (DC)).
Диспетчер серверов и Windows Admin Center
Управлять всем этим можно через различные программы. Более старым вариантом является Диспетчер серверов (Server Manager). Он позволяет установить Active Directory Domain Services (AD DS) и назначить компьютеру роль Domain Controller (DC).
Новым ПО для управления компьютерами является Windows Admin Center. Данное программное обеспечение является облегчённым с технической точки зрения (работает в веб браузерах), но при этом более функциональное с точки зрения возможностей. Microsoft активно продвигает Windows Admin Center как приложение которое включает в себя функциональность Диспетчера серверов (Server Manager), а также превосходит её, предлагая множество дополнительных функций и удобные интерфейсы для управления и мониторинга компьютерами.
На самом деле, Windows Admin Center не является полноценной заменой ни для Server Manager, ни для другой оснастки. Это программное обеспечение сильно облегчает выполнение многих популярных действий по администрированию компьютеров и серверов, но для некоторых узкоспециализированных настроек требуется другое ПО.
Мы рассмотрим работу с Active Directory в каждом из этих приложений. Также мы рассмотрим развёртывание и управление Active Directory в PowerShell.
Диспетчер серверов уже предустановлен на Windows Server 2022 и автоматически открывается при включении компьютера. Для установки Windows Admin Center перейдите по ссылке https://aka.ms/WindowsAdminCenter. Более подробные инструкции по установке и использованию Windows Admin Center будут даны в третьей части данного цикла статей.
Чем рабочие группы отличаются от доменов
Рабочая группа — это термин Microsoft для компьютеров Windows, подключённых через одноранговую сеть. Рабочие группы — это ещё одна организационная единица для компьютеров Windows в сети. Рабочие группы позволяют этим машинам обмениваться файлами, доступом в Интернет, принтерами и другими ресурсами по сети. Одноранговая сеть устраняет необходимость в сервере для аутентификации.
Каждый компьютер Windows, не присоединённый к домену, является частью рабочей группы. Рабочая группа — это группа компьютеров в одной локальной сети. В отличие от домена, ни один компьютер в рабочей группе не контролирует другие компьютеры — все они объединены на равных. Для рабочей группы пароль также не требуется.
Рабочие группы использовались для общего доступа к домашним файлам и принтерам в предыдущих версиях Windows. Теперь вы можете использовать домашнюю группу чтобы легко обмениваться файлами и принтерами между домашними ПК. Рабочие группы теперь переведены в фоновый режим, поэтому вам не нужно о них беспокоиться — просто оставьте имя рабочей группы по умолчанию WORKGROUP и настройте общий доступ к файлам домашней группы.
Есть несколько различий между доменами и рабочими группами:
- В доменах, в отличие от рабочих групп, могут размещаться компьютеры из разных локальных сетей.
- Домены могут использоваться для размещения гораздо большего числа компьютеров, чем рабочие группы. Домены могут включать тысячи компьютеров, в отличие от рабочих групп, у которых обычно есть верхний предел, близкий к 20.
- В доменах имеется по крайней мере один сервер — это компьютер, который используется для управления разрешениями и функциями безопасности для каждого компьютера в домене. В рабочих группах нет сервера, и все компьютеры равноправны.
- Пользователям домена обычно требуются идентификаторы безопасности, такие как логины и пароли, в отличие от рабочих групп.
Является ли мой компьютер частью домена?
Если у вас есть домашний компьютер, он почти наверняка не является частью домена. Вы можете настроить контроллер домена дома, но нет причин для этого, если вам действительно это не нужно для чего-то. Если вы используете компьютер на работе или в школе, скорее всего, ваш компьютер является частью домена. Если у вас есть портативный компьютер, предоставленный вам на работе или в школе, он также может быть частью домена.
Вы можете быстро проверить, является ли ваш компьютер частью домена. Откройте приложение «Параметры» (Win+x).
Нажмите «Система».
Перейдите на вкладку «О программе» и найдите пункт «Переименовать этот ПК (для опытных пользователей)»:
Если вы видите «Домен»: за которым следует имя домена, ваш компьютер присоединён к домену.
Если вы видите «Рабочая группа»: за которым следует имя рабочей группы, ваш компьютер присоединён к рабочей группе, а не к домену.
В англоязычной версии это соответственно «Settings» → «System» → «About» → «Rename this PC (advanced)».
Используя командную строку (PowerShell) вы также можете узнать, прикреплён ли компьютер к домену или входит в рабочую группу.
Для этого выполните команду (можно за один раз всё скопировать-вставить в окно терминала):
Глава 8. Управление пользователями, группами и устройствами
В своей предыдущей главе мы изучили основные типы объектов AD ( Active Directory ), а также как мы можем добавлять, изменять и удалять их. Мы также изучили различные инструменты управления, которые помогают нам в этих задачах. Последнее, но не по значимости, мы изучили как определять местоположение объектов AD или установленное значение атрибута, когда это это требуется, с помощью разнообразных инструментов и методов. Данная глава является неким расширением этого, так как она намерена дополнительно обсудить объекты и атрибуты.
Основные характеристики объектов описываются при помощи атрибутов. Некоторые из этих атрибутов являются общими для различных типов объектов, а другие уникальны. Когда то необходимо, мы также можем добавлять свои собственные атрибуты. В этой главе мы изучим атрибуты объектов и то как ими управлять. Также мы изучим как добавлять индивидуальные атрибуты. В своей предыдущей главе мы изучили как добавлять/ удалять объекты пользователей. Как правило, объекты пользователей представляют людей. Однако в некой среде AD мы также можем добавлять объекты пользователей для представления учётных записей служб. Microsoft рекомендует вам применять для служб и приложений MSA ( Managed Service Accounts , Управляемые учётные записи служб) и gMSA ( Group Managed Service Accounts , Групповые управляемые учётные записи служб) вместо обычных учётных записей пользователей. В этой главе мы изучим эти различные типы учётных записей служб и как использовать их. В некой среде AD мы группируем объекты с помощью групп AD. Такие группы имеют различные категории. В этой главе мы изучим различные виду групп AD и как их действенно использовать. Помимо пользователей, компьютеров и групп, AD также поддерживает регистрацию устройств в качестве объектов, например, принтеров. Позднее в этой главе мы также рассмотрим и их. И последнее, но не менее важное, мы рассмотрим рекомендации, которые помогут вам улучшить ваши навыки работы с объектами.
В данной главе мы рассмотрим такие области:
Различные типы учётных записей пользователей и их действия
Различные типы групп и их действия
Различные типы устройств и прочих объектов, которыми можно управлять через AD
Рекомендации по управлению объектами
Атрибуты объекта
Моя дочь, Селена, любит книжки Джулии Дональдсон, в особенности книжки про Груффало. Поэтому всякий раз, когда я беру её в библиотеку, она прихватывает с собой по крайней мере одну книгу. Несколько лет назад я прочёл одну книгу из общей серии книг про Груффало, а именно Дочурка Груффало . В этой книге дочка Груффало спрашивает о большой плохой мыши, живущей в заснеженном лесу. Груффало описывает эту мышь, говоря что она сильная, её глаза громадные, её хвост очень длинный, а её усы толще проводов. После этого дочка Груффало уходит на поиски мыши снежной ночью.
В процессе своего путешествия она отыскивает животных, которые соответствуют одной или нескольким характеристикам, котрые описал её отец, однако никто из них не соответствует им всем. В конце концов, лишь тень маленькой мышки совпадает тому описанию, которое она разыскивала. Но не настоящее живое существо. Перенося эту мысль в мир объектов, большая плохая мышь является неким объектом. Груфалло описывает его своей дочурке, применяя характеристики, которые схожи с атрибутами некого объекта. Когда дочурка Груффало отправляется на его поиски, она также обнаруживает животных, которые имеют сходные свойства. Точно также и объекты могут иметь атрибуты, которые применяются и к прочим объектам в том же самом классе. В конце концов она обнаруживает наилучшее совпадение по всем характеристикам, так как некоторые из них не совпадают для любых прочих животных. Аналогично, некоторые атрибуты имеют уникальные значения, которые превращают их в уникальные даже в одном и том же классе.
На нашем следующем снимке экрана я открыл некий объект пользователя при помощи Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) . Здесь, в Attribute Editor , мы можем видеть все те атрибуты, которые ассоциированы с данным объектом, включая их значения:
Рисунок 8-1
Воспользовавшись этим окном, мы можем добавлять, изменять или удалять значения для некоторых атрибутов. Большинство из названий этих атрибутов не соответствуют названиям в том мастере, в котором вы создавали данный объект. В качестве примера, атрибут givenName (имя из LDAP или Lightweight Directory Access Protocol ) соответствует самому первому имени (отображаемому названию) в мастере создания учётной записи пользователя.
Все прочие учётные записи в AD будут иметь в точности те же наборы атрибутов. Они задаются неким классом в установленной схеме AD:
Рисунок 8-2
Чтобы открыть имеющуюся оснастку схемы AD, вам требуется запустить команду regsvr32 schmmgmt.dll в своём контроллере домена. После этого вы можете применять MMC и добавлять имеющуюся схему AD в качестве оснастки.
В нашем предыдущем снимке экрана я открыл некую оснастку схемы AD, а в ней раскрыл класс user . Чтобы открыть некую оснастку, перейдите в Run | MMC | File | Add/Remove Snap-in , а затем выберите из списка Active Directory Schema . Затем кликните Add и потом OK для завершения данного мастера. В окне свойств рассматриваемого объекта мы можем видеть список атрибутов, которые ассоциируются с выбранным классом user . Те же самые атрибуты могут быть также частью иных классов. например, атрибут mail является частью классов user и group :
Рисунок 8-3
Открывая атрибуты в контейнере Attributes , мы можем просматривать подробности необходимых нам атрибутов:
Рисунок 8-4
В нашем предыдущем снимке экрана с открыл атрибут cn и это отобразило в данном окне такие подробности как Common Name Syntax и допустимые значения.
Индивидуальные атрибуты
В некой схеме AD вам дозволяется добавлять индивидуальные атрибуты. В организациях случаются ситуации, в которых такие возможности полезны. В большинстве случаев это относится к требованиям интеграции приложений с инфраструктурой AD. В современных инфраструктурах приложения децентрализуют управление идентичностью. Персоны организации могут располагаться как в AD, так и в приложениях. Если такое приложение интегрировано с AD, это всё ещё предоставляет централизованное управление идентичностью, но это присутствует не всегда. Некоторые приложения обладают своими собственными способами обработки учётных записей и полномочий собственных пользователей. Аналогично с ситуацией атрибутов, такие приложения могут также обладать своими собственными атрибутами, задаваемыми в их системах баз данных для хранения сведений. Порой такие атрибуты приложений могут не совпадать с атрибутами AD.
В качестве примера давайте рассмотрим некую систему Кадров (HR), применяющую идентификаторы работников для идентификации записей сотрудников. Однако AD применяет имена пользователей для идентификации уникальных записей. Каждый из атрибутов системы содержит некие сведения относительно имеющихся объектов, даже когда атрибуты ссылаются на того же самого пользователя или устройство. Когда имеется некое иное приложение, которое требуется вам для выборки информации из атрибутов обеих систем, как мы можем выполнить это без дублирования?
Однажды я работал в подобном проекте. Потребитель уже имел у себя некую инфраструктуру AD. У них также поддерживалась некая система Кадров, которая не была интегрирована с AD. У них появилось новое требование для приложения совместной работы пользователей, которое требовало ввода данных неким особым образом. Они определили свои поля в имеющейся базе данных, а нам требовалось установить соответствие своих данных в порядке с выделенными полями. Некоторые из этих полей требовали сведений о пользователях, которые можно было получать из AD, а некоторые пользовательские данные можно было выбирать из имеющейся системы Кадров. Вместо того чтобы применять наполнение двумя наборами сведений, мы приняли решение рассматривать AD как целиком доверенный источник сведений для такой новой системы. Раз AD требовалось содержать все необходимые данные, нам также потребовалось хранить и данные, которые поступают из имеющейся системы Кадров. Решение состояло в добавлении индивидуальных атрибутов в установленную схему AD и их ассоциации с классом user . Вместо того чтобы работать с двумя системами в качестве каналов данных, теперь имеющаяся система Кадров могла передавать фильтрованные значения в AD, которая экспортировала бы все необходимые сведения в формате CSV в соответствующее приложение.
Для создания индивидуальных атрибутов проследуйте в оснастку Active Directory Schema , кликните правой кнопкой по контейнеру Attributes и выберите возможность Create Attribute. .
Затем ваша система выдаст предупредительное сообщение о создании объекта схемы. Кликните OK для продолжения и появится такое окно:
Рисунок 8-5
Как показано на предыдущем снимке экрана, откроется некая форма и она будет именно тем местом, в которым вы задаёте подробности относительно индивидуальных атрибутов:
Общее название : Это само название данного объекта. Для CN ( Common Name ) вы можете применять только символы, числа и знаки тире.
Отображаемое название LDAP : Когда некий объект ссылается на какие- то сценарий, программу или утилиту командной строки, требуется именовать его с помощью отображаемого названия LDAP вместо значения CN. При задании вами значения CN будет автоматически создаваться и LDAP Display Name.
Уникальный идентификатор объекта X500 : Абсолютно все атрибуты в некой схеме имеют уникальное значение OID object ID , Идентификатора объекта). Имеется некий разработаны Microsoft сценарий для выработки таких уникальных значений OID. Его можно найти по ссылке https://gallery.technet.microsoft.com/scriptcenter/Generate-an-Object-4c9be66a#content. Она содержит следующий сценарий, который будет вырабатывать необходимый OID:
Синтаксис : Это поле задаёт представление для хранения самого объекта. Вам разрешается применять только определённый Microsoft синтаксис. Один атрибут может быть ассоциирован лишь с одним синтаксисом. В приводимой ниже таблице перечисляется ряд обычно применяемых синтаксисов:
Boolean
Строка Unicode
Некая большая строка
Строка Numeric
Integer
32- битное целое значение
Large Integer
64- битное целое значение
SID
Значение идентификатора безопасности (Security identifier value)
Отличительное имя (Distinguished Name)
Строковое значение для уникальной идентификации объекта в AD
Помимо данного синтаксиса мы также можем задавать минимальное и максимально число значений. Когда оно не определено, значение индивидуального атрибута получает устанавливаемое по умолчанию значение.
В качестве некого примера я пожелал добавить некий новый атрибут с названием nINumber и добавил его в класс user :
Рисунок 8-6
На своём следующем шаге мы добавляем его в имеющийся класс user . Для этого перейдите в контейнер Classes , дважды кликните по классу user и кликните по закладке Attributes . Там, кликнув по кнопке Add , мы можем просматривать и добавлять вновь добавленные атрибуты из отображаемого списка:
Рисунок 8-7
Теперь, когда мы открываем некую учётную запись пользователя, мы можем обнаружить этот новый атрибут:
Рисунок 8-8
После добавления необходимых сведений, мы можем выполнять фильтрацию необходимой информации:
Здесь мы изучили как добавлять вручную некий индивидуальный атрибут. Иногда интегрированные с AD приложения также требуют размещения каких -то атрибутов для хранения дополнительных сведений. Обычно это выполняется через какой- то автоматический процесс расширения схемы. Отличным примером некого приложения, которое требует какого- то расширения схемы является Exchange Server Microsoft. В процессе установки Exchange Server, имеющаяся схема AD будет расширена новыми классами. Дополнительные сведения относительно изменений схемы AD для Microsoft Exchange Server можно найти по ссылке https://docs.microsoft.com/en-us/exchange/plan-and-deploy/active-directory/ad-schema-changes?view=exchserver-2016.
Для добавления в схему атрибутов вам требуется иметь полномочия Администратора схемы или Администратора предприятия. После добавления новых атрибутов вам рекомендуется перегрузить свою систему чтобы отразить такие новые изменения в установленной схеме.
Учётные записи пользователя
Что является наиболее распространённой задачей администрирования в AD? Очевидно, создание учётных записей пользователей и администрирование ими. Некая учётная запись пользователя не просто хранит некое имя пользователя; она также содержит такие сведения, как участие в группах, путь удалённого профиля, значение пути домашней папки, сведения о сценарии регистрации, полномочия удалённого дозвона и многое иное. Всякий раз когда мы настраиваем какую- то новую учётную запись, нам требуется задавать значения этих атрибутов. Когда общее число атрибутов растёт, также возрастает и общее число ошибок, которое может происходить в процессе создания конкретной учётной записи. Здесь на кону идентичность некой организации; даже небольшая ошибка может оказаться дорогостоящей для организации. Например, если вы случайно добавите пользователя в неправильную группу, он/ она получит доступ к некоторым ресурсам, к которым он не должен иметь доступа.
Когда я создаю некую Заявку на работу ( SoW , Statement of Work ) или план реализации для заказчика, я всегда начинаю с какого- то шаблона. Этот шаблон содержит разделы, которые создают контур того что мне требуется изменять в соответствии с каждым из требований заказчика. Когда я применяю некий шаблон, это не просто сберегает моё время, но также исключает какой бы то ни было риск того что может произойти в процессе форматирования документа. Аналогично, а некой среде AD учётные записи пользователя могут обладать общими атрибутами и уровнями привилегий. В качестве примера, все пользователи подразделения продаж будут участниками одной и той же группы безопасности. Они также будут иметь тот же самый сценарий регистрации в системе для установки соответствий совместным ресурсам. Тем самым, вместо того чтобы создавать некую учётную запись пользователя продавца с нуля, я могу создать некий шаблон со всеми значениями общих атрибутов и применять его для создания новой учётной записи пользователя. Microsoft поддерживает такое создание шаблонов учётных записей пользователей начиная с Windows NT.
Даже несмотря на то, что имеются значения атрибутов, которые являются общими среди учётных записей пользователей, некоторым атрибутам всё ещё требуется иметь уникальные или не нулевые значения.
Имеется несколько моментов, которые следует учитывать при создании шаблонов пользователей:
Не копируйте учётные записи пользователей в качестве шаблона : Я наблюдал как многие инженеры просто случайным образом выбирают какого- то пользователя из OU ( Organizational Unit ) и применяют его в качестве какого- шаблона для новой учётной записи пользователя. Шаблоны должны создавать некий базовый уровень. Прочие учётные записи пользователей могут обладать уникальными полномочиями и значениями атрибутов, даже когда они расположены в одном и том же OU. Следовательно, всегда удерживайте учётные записи пользователей обособленно от шаблонов.
Отключённые учётные записи : Никто не должен применять учётные записи шаблона для аутентификации. При создании некого шаблона убедитесь что вы настроили его в качестве отключённой учётной записи. В процессе создания соответствующей новой учётной записи пользователя данное состояние создаваемой учётной записи может быть изменено.
Для демонстрации всего этого я намерен создать некий шаблон пользователя для пользователей Technical Department . Я применяю такую команду:
Наша предыдущая команда создаёт некую учётную запись пользователя с названием _TechSupport_Template . Она также устанавливает эту учётную запись пользователя в отключённое состояние.
Я также намерен добавлять такую учётную запись в имеющуюся группу безопасности Technical Department :
Теперь, когда мы заходим в ADUC, мы можем наблюдать этот новый шаблон. Чтобы создать из него какую- то новую учётную запись, кликните правой кнопкой по Copy. :
Рисунок 8-9
Затем пройдите и заполните все сведения в соответствующем мастере и завершите этот процесс создания учётной записи пользователя.
В данном разделе мы изучили как создавать шаблоны пользователя и применять их в некой среде AD. Применение шаблонов пользователей это отличный способ сопровождения согласованности полномочий в некой среде AD. В своём следующем разделе мы намерены изучить различные виды учётных записей служб и то как мы можем верно использовать их в некой среде AD.
При установке приложений или служб в некой инфраструктуре рекомендуется применять учётные записи служб. Некая учётная запись службы представляет собой какую- то выделенную учётную запись с особыми привилегиями, которые применяются запускаемыми службами, пакетными заданиями и задачами управления. В большинстве инфраструктур учётные записи служб это обычные учётные записи пользователей с вариантом Password never expire (никогда не истекающего срока действия пароля). Так как учётные записи службы не используются постоянно, администраторам приходится отслеживать эти учётные записи и их полномочия. Я был свидетелем множества ситуаций, при которых инженеры сталкивались с проблемами из- за устаревших или неуместных сведений учётной записи службы. Основная проблема состоит в том, что когда вы сбрасываете пароль учётных записей служб, вам придётся обновлять службы, базы данных и настройки приложения с таким новым паролем. Кроме того, инженерам также приходится управлять SPN ( service principal name , именем главы службы), которая помогает уникально идентифицировать экземпляры служб.
После рассмотрения всех этих вызовов Microsoft ввёл в Windows Server 2008 R2 MSA. MSA Microsoft обладают следующим:
Больше нет необходимости управления паролем. MSA используют некий сложный и случайный пароль из 240 символов, который изменяется автоматически когда истекает срок действия пароля соответствующего домена или компьютера.
MSA не может блокироваться или использоваться для интерактивной регистрации.
Для одного компьютера может применяться лишь один MSA. Он не может совместно применяться множеством компьютеров.
MSA предоставляет упрощённое управление SPN; система будет автоматически изменять необходимое значение SPN когда изменяются подробности SamAccountName данного компьютера или соответствующим образом меняется имя DNS.
Чтобы создать некий MSA, мы можем воспользоваться приводимой ниже командой. Я запускаю её в своём контроллере домена.
В своей предыдущей команде я создал некую учётную запись службы с названием MyAcc1 и я ограничил её одним компьютером.
Своим следующим шагом я ассоциирую эту учётную запись службы с сервером хоста REBEL-SRV01 , в котором я намерен применять данную учётную запись службы:
Наш следующий шаг состоит в установке учётной записи службы в своём сервере REBEL-SRV01 . Для этого нам потребуется модуль AD PowerShell. Мы можем установить его воспользовавшись RSAT ( Remote Server Administration Tools , Инструментами удалённого администрирования серверами). Это можно сделать запустив команду Install-WindowsFeature RSAT-AD-Tools . Когда всё готово, выполните такую команду:
Мы можем проверить свою учётную запись службы воспользовавшись следующей командой:
Она возвращает True , что означает что проверка прошла успешно.
Из соответствующего сервера AD мы можем проверить созданную учётную запись службы выполнив такую команду:
При настройке MSA в службе, убедитесь что вы оставили пароль пустым. Вам не требуется задавать некий пароль, так как сама система автоматически его создаст.
В своём предыдущем разделе мы обсудили MSA. Один MSA может применяться лишь с единственным компьютером. Однако имеются рабочие требования, при которых необходимо разделять одну и ту же учётную запись службы во множестве хостов. Хорошими примерами этого служат функциональность NLB ( Network Load Balancing , балансировки сетевой нагрузки) Microsoft и фермы серверов IIS ( Internet Information Services ). Все имеющиеся в таких группах серверы требуют применения для аутентификации одного и того же главу службы. gMSA предоставляют ту же самую функциональность, что и MSA, но они расширяют самый высокий уровень леса AD. Они впервые было введены в Windows Server 2012.
Такие gMSA обладают следующими возможностями:
Не требуют управления паролями
Поддерживают совместное использование во множестве хостов
Могут применяться для запуска планируемых по расписанию задач (MSA не поддерживают запуск планируемых по расписанию задач)
Применяют KDC ( Key Distribution Center , Центр распределения ключей) Microsoft для создания паролей gMSA и управления ими.
KDC ( Key Distribution Center , Центр распределения ключей) был введён в Windows Server 2012. KDS разделяет некий секрет (идентификатор ключа корня — root key ID) среди всех имеющихся экземпляров KDS в этом домене. Его значение периодически изменяется. Когда для gMSA требуется некий пароль, контроллер домена Windows Server 2012 вырабатывает некий пароль на основании общего алгоритма, который содержит идентификатор ключа корня. Затем все имеющиеся хосты, которые совместно используют такие gMSA запросят у контроллеров домена получение самого последнего пароля.
Вот необходимые требования для gMSA:
Уровень леса AD Windows Server 2012 или выше
Серверы участники домена Windows Server 2012 (также поддерживаются подключённые к домену компьютеры Windows 8 и выше)
64- битная архитектура для запуска команд PowerShell управления такими gMSA
gMSA не поддерживаются для установок отказоустойчивых кластеров. Однако gMSA поддерживаются для служб, которые запускаются в неких отказоустойчивых кластерах.
Для запуска самого процесса настройки нам требуется создать некий ключ корня KDS. Это требуется выполнять в контроллере домена с полномочиями Администратора домена или Администратора предприятия:
После выполнения этого имеется установленный по умолчанию предел в 10 часов для репликации этого ключа корня во все контроллеры домена и запуска обработки запросов gMSA. В некой тестовой среде с единственным контроллером домена вы можете принудительно удалить такое время ожидания и запускать отклики на запросы gMSA немедленно. Это не рекомендуется для промышленных сред. Мы можем удалить такой предел времени репликации в 10 часов воспользовавшись следующей командой:
После этого мы можем создать самую первую учётную запись gMSA. Я создал некую группу, IISFARM , и добавил в неё все свои серверы IIS. Эта ферма будет применять вновь создаваемый gMSA:
В нашей предыдущей команде Mygmsa1 это создаваемая учётная запись службы, а web.rebeladmin.com это FQDN ( fully qualified domain name ) данной службы. После её выполнения мы можем проверить такую новую учётную запись при помощи следующей команды:
Наш следующий шаг состоит в установке Mygmsa1 в определённом сервере из имеющейся фермы IIS. Mygmsa1 требует для запуска модуль AD PowerShell/ Mygmsa1 можно установить при помощи RSAT:
Если вы только что создали соответствующую группу серверов и добавили этот хост, вам требуется перезапустить данный компьютер хоста чтобы отобразить его участие в группе. В противном случае приведённая выше команда завершится отказом.
После её выполнения мы можем проверить созданную учётную запись службы исполнив такую команду:
Аналогично случаю с MSA, когда вы настраиваете gMSA с любой из служб, оставляйте значение пароля пустым.
Деинсталляция MSA
Иногда вам требуется удалять MSA. Это можно выполнить при помощи такой команды:
Наша предыдущая команда удалит Mygmsa1 . Это применимо к обоим видам MSA.
Группы
В целом, группа является коллекцией лиц или ресурсов, которые совместно используют одни и те же свойства и обязанности. В некой организации идентичности личностей добавляются и удаляются, однако роли и обязанности сильно не изменяются. Таким образом, наилучший способ управления привилегиями в организациях основывается на ролях и обязанностях вместо личностей. К примеру, в неком подразделении продаж, продавцы меняются часто, однако их рабочие требования не меняются также часто. Все они будут иметь доступ к одним и тем же совместным файлам, те же самые полномочия к CRM ( customer relationship management , управлению взаимоотношений с клиентами) и иметь те же самые права доступа к календарям друг друга. Группы AD позволяют вам изолировать персонализацию на основании требований привилегий.
В среде AD имеются две категории групп:
Группы безопасности : Этот тип применяется для назначения прав к ресурсам. В качестве примера, Rebeladmin Corp. имеет команду из 10 продавцов. Они используют некую совместную папку с названием Sales . Все в этой команде продавцов имеют одни и те же полномочия доступа к ней. Когда эти права управлялись на уровне пользователя, его ACL ( Access Control List , Список управления доступом) для папки Sales приходилось иметь 10 записей для представления этих пользователей. Если некий новый продавец присоединяется к этой команде, его учётную запись необходимо добавлять в этот ACL и устанавливать вручную соответствия по сравнению с уже имеющимися пользователями в данном ACL. Так как это ручной процесс, имеется вероятность, применения неверных прав по ошибке. Когда же они основываются на группах безопасности, мы можем создать некую группу для подразделения продаж, а затем добавить её для ACL папки Sales с надлежащими правами. После этого мы можем удалить индивидуальные записи для каждого из продавцов из этого ACL. Тем самым, решение о доступе к рассматриваемой папке Sales будет приниматься на основе участия в группе.
Группы распространения : Они используются в некой системе электронной почты, например, в Microsoft Exchange. Они применяются для распространения одного электронного письма в какую- то группу. В этих группах не включена безопасность, поэтому вы не можете применять их для назначения прав.
Область действия группы
Сферы групп помогают определять границы определённой операции внутри имеющегося леса AD. Имеются три предварительно определённых областей действия для их выбора при создании групп AD:
Domain Local (Локально в домене): Локальные в домене группы могут применяться для управления правами для ресурсов в неком отдельном домене. Это не означает, что данная группа будет иметь только участников внутри одного и того же самого домена. Они могут иметь такие типы участников:
Учётные записи пользователей для всех доверенных доменов
Учётные записи компьютеров для всех доверенных доменов
Универсальные группы для всех доверенных доменов
Локальные в домене группы из того же самого домена
Глобальные группы для всех доверенных доменов
Объекты Локальных в домене групп и данные их участников будут реплицироваться во все контроллеры домена в том же самом домене.
Global (Глобальные): Глобальные группы могут применяться для управления правами к ресурсам в любом домене из одного и того же леса. Глобальные группы могут содержать следующие типы участников:
Учётные записи пользователей из одного и того же домена
Учётные записи компьютеров из одного и того же домена
Глобальные группы из одного и того же домена
Объекты Глобальной группы и данные участников будут реплицироваться во все контроллеры домена в одном и том же домене. Эта группа имеет ограниченное членство и никакой высокой доступности, так как группа не будет доступна для прочих доменов в этом лесу. Это идеально подходит для создания категорий прав на основе ролей и обязанностей.
Universal (Универсальные): Аналогично Глобальным группам, Универсальные группы могут использоваться для управления привилегиями в любом домене определённого леса. Однако, они позволяют вам иметь участников из любого из доменов. Например домены rebeladmin.com и rebeladmin.net из одного и того же леса могут обладать некой Универсальной группой с названием Sales Managers с участниками из обоих доменов. Затем, я могу назначить её полномочия для соответствующей папки в rebeladmin.org из того же самого леса. Универсальная группа может обладать такими типами участников:
Учётные записи пользователей из всех доверенных доменов
Учётные записи компьютеров из всех доверенных доменов
Глобальные группы из всех доверенных доменов
Универсальные группы из всех доменов того же самого леса
Объекты Универсальной группы и данные участников будут реплицироваться во все серверы глобального каталога. Универсальные группы придают необходимую гибкость для применения прав к любым ресурсам во всех доменах из одного и того же самого леса.
Группы поддерживают наличие прочих групп в качестве участников. Это имеет название вложенных групп (nested groups). Это дополнительно уменьшает изменения в конкретном ACL. Во всех предыдущих моментах мы перечислили какие типы групп допускается добавлять в качестве встраиваемых групп для каждой из областей действия.
Преобразование групп
Область действия группы необходимо определять в процессе настройки самой группы. Однако по причине рабочих требований или инфраструктурных изменений могут появляться ситуации, при которых уже имеющаяся область действия более не допустима. В таком случае вместо настройки какой- то новой группы у нас имеется возможность изменения области действия такой группы. Тем не менее, это не означает что мы можем изменять область действия имеющейся группы на что угодно. Имеется ряд приводимых ниже правил. Следующая таблица поясняет поддерживаемые способы преобразования групп:
Локальная в домене
Да (только в случае когда в ней не участвуют никакие прочие Локальные в домене группы)
Глобальная
Да (только в случае когда нет участников прочих Глобальных групп)
Универсальная
Да (только в случае когда в ней не участвуют никакие прочие Универсальные группы)
Установка групп
Точно так же как и для учётных записей пользователей, для создания групп и управления ими мы можем применять различные методы:
ADAC ( Active Directory Administrative Center )
PowerShell cmdlet -ы
В этом разделе я намерен применять cmdlet PowerShell для настройки групп AD и управления ими.
Для добавления некой новой группы в некую среду AD можно воспользоваться cmdlet-ом New-ADGroup . При помощи следующего мы можем просмотреть полный синтаксис этой команды:
В качестве примера я собираюсь создать некую новую группу безопасности с названием Sales Team :
Для нашей предыдущей команды справедливо следующее:
-GroupCategory : Определяет значение типа данной группы ( security или distribution ).
-GroupScope : Задаёт значение области действия этой группы.
-Path : Определяет значение пути для объекта этой группы. Когда параметр -Path не применяется, будет использован установленный по умолчанию контейнер, Users .
По причине важности этой группы я желаю защитить её объекты от непредумышленного удаления:
Это также можно установить при помощи окна свойств данной группы:
Рисунок 8-10
Теперь наша группа готова для новых участников. Чтобы добавить новые элементы мы можем воспользоваться следующим:
Наша предыдущая команда добавит пользователей tuser3 , tuser4 и tuser5 в созданную группу.
Если требуется удалить кого- то из пользователей в этой группе, мы можем применить такую команду:
При помощи cmdlet Get-ADGroup мы можем просмотреть свойства своей группы:
Воспользовавшись следующей командой мы можем выполнить выборку определённых значений из своей группы:
Наша предыдущая команда перечислит имеющиеся DistinguishedName и значения Members для нашей группы безопасности Sales Team :
Рисунок 8-11
Когда нам требуется изменить значение области действия своей группы, мы можем сделать это при помощи такой команды:
Она изменит область действия данной группы с Global на Universal :
Рисунок 8-12
И последнее, но не по значимости, группу можно удалять применяя cmdlet Remove-ADGroup :
Наша предыдущая команда удалит созданную ранее группу Sales Team .
Когда у вас установлен вариант значения для непредумышленного удаления данной группы, вам требуется вначале удалить его перед выполнением команды Remove-ADGroup . В противном случае вы получите отказ выполнения. Для удаления значения варианта непредумышленного удаления мы можем применить команду Get-ADGroup «Sales Team» | Set-ADObject -ProtectedFromAccidentalDeletion:$false .
Устройства и прочие объекты
Помимо компьютеров, AD также поддерживает несколько прочих типов устройств и объектов. В этом разделе мы рассмотрим такие различные типы объектов:
Принтеры : Принтеры являются одним из наиболее часто совместно используемых ресурсов в сетевых средах офиса. Мы можем применять различные методы настройки совместных принтеров для компьютеров пользователей. Мы можем настраивать их с помощью мастера настройки принтера в Windows и подключаться к принтеры через некий IP адрес. Также мы можем применять сценарии регистрации для установки соответствия и устанавливать принтеры в рабочих станциях. Когда некая организация использует принт- серверы, мы можем подключаться к ним и также устанавливать соответствующие принтеры. В некой среде AD мы можем зарегистрировать соответствующий принтер в качестве объекта AD. Это позволит надлежащим пользователям просматривать AD, обнаруживать требуемый принтер и затем устанавливать его в своей рабочей станции.
Для регистрации некого принтера в AD, пройдите в Printer properties , а затем в закладку Sharing . Здесь имеется флажок в блоке List in the directory для перечисления такого принтера в AD.
В соответствующей рабочей станции в процессе настройки такого принтера нам требуется выбрать необходимый вариант для перечисления принтеров из своего каталога чтобы увидеть все интегрированные с AD принтеры:
Рисунок 8-13
iNetOrgPerson : Этот объект определён в RFC 2798. Данный тп объекта применяется прочими службами каталога, которые основываются на LDAP и X.500. Данный тип объекта имеется в AD для поддержки миграции из не- Microsoft служб каталога и для поддержки приложений, которым необходимы объекты iNetOrgPerson . Данный объект, если это потребуется, может преобразовываться в обычного пользователя. Для добавления этого объекта мы можем применять ADAC, ADUC или PowerShell. В PowerShell вы могли бы применить тот же самый cmdlet New-ADUser :
Наша предыдущая команда добавит объект inetOrgPerson с названием Inet User1 . Единственное отличие в этой команде от команды для обычного пользователя AD состоит в –Type inetOrgPerson , который задаёт значение типа учётной записи как inetOrgPerson .
Мы можем преобразовать значение объекта inetOrgPerson в обычный объект пользователя AD при помощи следующей команды:
Наилучшие практические приёмы
Здесь мы рассмотрим некоторые рекомендации, которые можно применять для управления объектами AD:
Служебные действия : Важно время от времени просматривать адекватность объектов AD. Могут иметься объекты, которые больше не участвуют в работе. Для обработки таких объектов имеются некоторые способы:
Если на 100% можно убедиться что объекты на данный момент не применяются, их можно полностью удалить из AD.
Когда это невозможно подтвердить, эти объекты можно отключить и далее выполнять отслеживание событий. Если никакие события не происходят, такие объекты могут быть удалены из AD.
Для управления отключёнными объектами предлагается создавать некие отличающиеся OU и перемещать в них отключаемые объекты. Это позволит вам отслеживать их и разрешать доступ к ним когда это потребуется.
В AD могут иметься объекты, которые используются лишь ограниченное время. В качестве примера, могут иметься контрактники, которые работают лишь в определённых проектах. Создаваемые для таких контрактников учётные записи пользователей применяются лишь на протяжении проекта. Такие типы объектов можно оставлять отключёнными и включать лишь когда это потребуется. Бывшие сотрудники также попадают в разряд этой категории.
Добавление описаний : В объекте AD имеется некий атрибут, в который у вас есть возможность добавления описания такого объекта. Рекомендуется добавлять некое описание объекта, когда оно не описывается самим присваиваемым ему названием. Описание объекта позволяет инженерам быстро находить объект и понимать его цель.
Защита объектов от непредумышленного удаления : Эта функциональность была введена начиная с AD DS 2008. Она была включена для объектов пользователей, компьютеров и групп. Это предотвращает неумышленное удаление объектов. Её можно включать на уровне индивидуального объекта или на уровне OU/ каталога. Это свойство следует отключать когда вы желаете на самом деле удалить некий объект.
Соглашения об именовании объектов : При задании значений объектам всегда следуйте стандартам. В качестве примера, некие организации предпочитают применять первые несколько букв в качестве имени и фамилии для имени пользователя. Кое- кто может предпочитать формат имя.фамилия . Эти форматы могут отличаться от фирмы к фирме. Рекомендуется документировать их для того, чтобы участники команды также могли следовать таким предпочтениям. Если такой документ не существует, посмотрите окружающие типы объектов чтобы понять применяемые стандарты.
Выводы
В этой главе мы изучили объекты и атрибуты AD и как они определяются имеющейся схемой AD. Также мы изучили как добавлять индивидуальные атрибуты в имеющуюся схему AD. Затем мы рассмотрели создание шаблонов учётных записей пользователей и имеющиеся различные виды учётных записей служб. В некой среде AD порой требуется управлять правами для групп пользователей, которые имеют аналогичные требования для работы (то что им приходится делать в своих подразделениях, роли заданий и тому подобное). Это выполняется при помощи групп AD. Для выбора имеются различные категории групп. В этой главе мы рассмотрели такие виды групп и изучили как применять их подобающим образом. В этой главе мы также прошлись по рекомендациям управления объектами чтобы оказать вам содействие в ваше практике управления объектами AD.
В своей следующей главе мы изучим проектирование надлежащих OU и управление ими.
samAccountName vs userPrincipalName
In Active Directory based environment, everyone should come across the AD attribute names samAccountName and userPrincipalName or UPN. In this article, I am going to explain the difference between samAccountName and userPrincipalName(UPN).
The samAccountName is the User Logon Name in Pre-Windows 2000 (this does not mean samAccountName is not being used as Logon Name in modern windows systems). The userPrincipalName is a new way of User Logon Name from Windows 2000 and later versions. user Name part can be different for the same user like DomainNametestUser and userTest@DomainName.Com.
Before see the detailed explanation, we can check the summarized details of userPrincipalName and samAccountName.
SamAccountName
– The samAccountName attribute is the user logon name used to support clients and servers from a previous version of Windows ( Pre-Windows 2000).
– The user logon name format is : DomainName\testUser.
– The samAccountName must be unique among all security principal objects within the domain.
– The samAccountName should be less than 20 characters.
– Query for the new name against the domain to verify that the samAccountName is unique in the domain.
– The USERNAME environment variable is the samAccountName even when logging with UPN
UserPrincipalName – (UPN)
– The UPN is an Internet-style login name for the user based on the Internet standard RFC 822.
– The user logon name format is : testUser@DomainName.com.
– The UPN must be unique among all security principal objects within the directory forest.
– The advantage of using an UPN is that it can be the same as the users email address so that the user need to remember only a single name.
– The UPN is optional, it can be assigned or not when the user account is created.
– The userPrincipalName is unaffected by changes to other attributes of the user object, for example, if the user is renamed or moved, or changes to the domains in the tree, for example, if a parent domain was renamed or a domain was moved. Thus, a user can keep the same login name, although the directory may be radically restructured.
Working with samAccountName and userPrincipalName
Lets take the following test user whose samAccountName is Test2 and userPrincipalName is Test1@Work2008.local
Now, we can use the RunAs command to validate these two user logon names. To use RunAs command, you need to run the command prompt with an elevated privilege (Run As Administrator) and the Test user should be the member of Domain Admins group.
Use the below command to validate samAccountName login name
Use the below command to validate userPrincipalName login name
USERNAME environment variable is the sAMAccountName even when logging with UPN:
We have stated that the USERNAME environment variable is the sAMAccountName even when logging with UPN. To check this run the below command in new cmd window opened by RunAs command with userPrincipalName