Глава 8. Управление пользователями, группами и устройствами

Содержание

Глава 8. Управление пользователями, группами и устройствами
Атрибуты объекта
Индивидуальные атрибуты
Синхронизация индивидуальных атрибутов с AD Azure
Учётные записи пользователя
MSA
gMSA
Деинсталляция MSA
Группы
Область действия группы
Преобразование групп
Настройка групп
Устройства и прочие объекты
Рекомендации
Выводы

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

Основные характеристики объектов описываются при помощи атрибутов. Некоторые из этих атрибутов являются общими для различных типов объектов, а другие уникальны. Когда то необходимо, мы также можем добавлять в объект свои собственные атрибуты. В этой главе мы изучим атрибуты объектов и то как ими управлять. Также мы изучим как добавлять индивидуальные атрибуты. Когда организация применяет индивидуальные атрибуты в некой гибридной среде, возможно, что такие индивидуальные атрибуты также потребуют синхронизации с AD Azure. В этой главе я продемонстрирую как мы можем выполнять синхронизацию индивидуальных атрибутов из локального Active Directory в AD Azure. В среде Active Directory объекты пользователей обычно предоставляют людей. Однако мы также можем использовать объекты пользователей для представления учётных записей служб. Microsoft рекомендует вам применять для служб и приложений MSA (Managed Service Accounts, Управляемые учётные записи служб) и gMSA (Group Managed Service Accounts, Групповые управляемые учётные записи служб) вместо обычных учётных записей пользователей. В этой главе мы изучим эти различные типы учётных записей служб и как использовать их. В некой среде AD мы группируем объекты с помощью групп AD. Такие группы имеют различные категории. В этой главе мы изучим различные виды групп AD и как их действенно применять.

В данной главе мы рассмотрим такие вопросы:

  • Атрибуты объектов

  • Создание индивидуальных атрибутов

  • Синхронизацию индивидуальных атрибутов с Azure AD

  • Различные типы учётных записей пользователей и их действия

  • Различные типы групп и их роли

  • Различные типы устройств и прочих объектов, которыми можно управлять через AD

  • Рекомендации по управлению объектами

Без атрибутов мы не можем описывать объект Active Directory. Поэтому давайте двинемся далее и начнём эту главу с рассмотрения атрибутов.

Атрибуты объекта

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

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

На нашем следующем снимке экрана я открыл некий объект пользователя при помощи Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC).

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

 

Рисунок 8-1


Редактор атрибутов

Для представления Attribute Editor нам потребуется кликнуть в ADUC по View | Advanced Features

Воспользовавшись этим окном, мы можем добавлять, изменять или удалять значения для некоторых атрибутов. Большинство из названий этих атрибутов не соответствуют названиям в том мастере, в котором вы создавали данный объект. В качестве примера, атрибут givenName (имя из LDAP или Lightweight Directory Access Protocol) соответствует самому первому имени (отображаемому названию) в мастере создания учётной записи пользователя.

Все прочие учётные записи в AD будут иметь в точности те же наборы атрибутов. Они задаются неким классом в установленной схеме AD:

 

Рисунок 8-2


Оснастка схемы AD

[Совет]Совет

Чтобы открыть имеющуюся оснастку схемы 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 и допустимое значение типа.

Индивидуальные атрибуты

Схема Active Directory принимает индивидуальные атрибуты. Основываясь на требованиях бизнеса, порой организациям приходится вводить индивидуальные атрибуты для классов объекта. В большинстве случаев это относится к требованиям интеграции приложений с инфраструктурой AD. Некоторые приложения обладают своими собственными способами обработки учётных записей и полномочий собственных пользователей. Такие приложения могут также обладать своими собственными атрибутами, задаваемыми в их собственных системах баз данных для хранения сведений. Порой такие атрибуты приложений могут не совпадать с атрибутами Active Directory.

Некоторое время назад я помогал фармацевтической компании с проектом Active Directory. Заказчик уже имел у себя некую среду Active Directory. У них также поддерживалась некая система Кадров, которая не была интегрирована с Active Directory. У них появилось новое требование для приложения совместной работы пользователей, которое требовало ввода данных неким особым образом. Они определили свои поля в имеющейся базе данных, а нам требовалось установить соответствие своих данных в порядке с выделенными полями. Некоторые из этих полей требовали сведений о пользователях, которые можно было получать из Active Directory, а некоторые пользовательские данные можно было выбирать из имеющейся системы Кадров. Вместо того чтобы применять наполнение двумя наборами сведений, мы приняли решение рассматривать AD как целиком доверенный источник сведений для такой новой системы. Раз Active Directory требовалось содержать все необходимые данные, нам также потребовалось хранить и данные, которые поступают из имеющейся системы Кадров. Решение состояло в добавлении индивидуальных атрибутов в установленную схему Active Directory и их ассоциации с классом 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:

    
#--- 
$Prefix="1.2.840.113556.1.8000.2554" 
$GUID=[System.Guid]::NewGuid().ToString() 
$Parts=@() 
$Parts+=[UInt64]::Parse($guid.SubString(0,4),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(4,4),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(9,4),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(14,4),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(19,4),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(24,6),
"AllowHexSpecifier") 
$Parts+=[UInt64]::Parse($guid.SubString(30,6),
"AllowHexSpecifier") 
$OID=[String]::Format("{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}",
$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],
$Parts[5],$Parts[6]) 
$oid 
#---

  • Синтаксис: Это поле задаёт представление для хранения самого объекта. Вам разрешается применять только определённый Microsoft синтаксис. Один атрибут может быть ассоциирован лишь с одним синтаксисом. В приводимой ниже таблице перечисляется ряд обычно применяемых синтаксисов:

    Таблице 8-1.

    Таблица 8-1. Синтаксис атрибутов
    Синтаксис Описание

    Boolean

    True или False

    Строка 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


Индивидуальный атрибут под Classes

Теперь, когда мы открываем некую учётную запись пользователя, мы можем обнаружить этот новый атрибут:

 

Рисунок 8-8


Индивидуальный атрибут для пользователя

После добавления необходимых сведений, мы можем выполнять фильтрацию необходимой информации:


Get-ADuser "tuser4" -Properties nINumber | ft nINumber

Здесь мы изучили как добавлять вручную некий индивидуальный атрибут. Иногда интегрированные с AD приложения также требуют размещения каких -то атрибутов для хранения дополнительных сведений. Обычно это выполняется через какой- то автоматический процесс расширения схемы. Отличным примером некого приложения, которое требует какого- то расширения схемы является Exchange Server Microsoft. В процессе установки Exchange Server, имеющаяся схема AD будет расширена новыми классами. Дополнительные сведения относительно изменений схемы AD для Microsoft Exchange Server можно найти по ссылке https://bit.ly/3nJ0nRL.

[Замечание]Замечание

Для добавления в схему атрибутов вам требуется иметь полномочия Администратора схемы или Администратора предприятия. После добавления новых атрибутов вам рекомендуется перегрузить свою систему чтобы отразить такие новые изменения в установленной схеме. Однако в некоторых ситуациях даже после перезапуска значение нового атрибута может не быть доступным в этом объекте. В таком случае откройте ADSI edit и подключитесь к каждому контексту именования | правая кнопка | исполните Update Schema Now. После исполнения этого для всех четырёх контекстов именования перезапустите свой Контроллер домена.

Синхронизация индивидуальных атрибутов с AD Azure

В своём предыдущем разделе я пояснил как создавать индивидуальные атрибуты Active Directory. Когда мы выполняем синхронизацию пользователей из локального Active Directory в AD Azure при помощи Azure AD Connect, некоторые установленные атрибуты также выполнят синхронизацию, но не все. Полный перечень атрибутов которые не будут осуществлять синхронизацию с Azure AD Connect доступны в https://bit.ly/32lpFNn.

Однако порой могут существовать требования бизнеса для выполнения синхронизации таких индивидуальных атрибутов Active Directory в Azure AD. Их можно применять с облачными приложениями (SaaS) или применять их с перенесённым в Azure устаревшим производственным приложением (LOB, Line-of-Business). Мы можем осуществлять синхронизацию таких индивидуальных атрибутов в Azure AD применяя функциональную возможность "Directory extension attribute sync" Azure AD Connect.

В своей демонстрационной среде я собираюсь показать как выполнить синхронизацию вновь созданного индивидуального атрибута Active Directory (класса user) в Azure AD. Для упрощения этого процесса я уже установил Azure AD Connect и настроил его для синхронизации Azure AD. Если вы не знакомы с настройкой Azure AD Connect, обратитесь, пожалуйста к Главе 18, Гибридная идентификация.

Для настройки синхронизации индивидуального атрибута:

  1. Запустите консоль Azure AD Connect в своём сервере Azure AD Connect.

  2. Затем, из перечня параметров выберите Customize synchronization options кликните по Next.

     

    Рисунок 8-9


    Azure AD Connect - изменение параметров синхронизации

  3. Сначала пройдите все шаги необходимой аутентификации и далее, в окне Optional features кликните по Directory extension attribute sync | Next.

     

    Рисунок 8-10


    Azure AD Connect - расширение синхронизации атрибутов Каталога

  4. Следующее окно перечислит вниз все доступные атрибуты. Из этого списка я выбрал вновь созданный индивидуальный атрибут nINumber и кликните Next для завершения процесса настройки.

     

    Рисунок 8-11


    Azure AD Connect - выбор индивидуального атрибута

В самом конце этого мастера настройки значения вашего нового атрибута выполнит синхронизацию в Azure AD.

Мы можем удостовериться в этих синхронизированных значениях при помощи Microsoft Graph Explorer. Если вы новичок с этим инструментом, не беспокойтесь - мы рассмотрим это в Главе 16, Рекомендации безопасности Active Directory. Здесь всё что я применяю, это проверка того, что синхронизация выполнена так как ожидалось.

В своей демонстрационной среде для верификации значения атрибута nINumber я применяю:

https://graph.microsoft.com/v1.0/users/testuser2@M365x581675.onmicrosoft.com?$select=displayName,givenName,extension_7c51781fcb5b481a98ba6efa5c7578d6_nINumber

В приведённом выше, testuser2@M365x581675.onmicrosoft.com, это учётная запись нашего пользователя. displayName и givenName это атрибуты, синхронизированные из нашего локального Active Directory через установленные по умолчанию настройки Azure AD Connect.

Как вы можете видеть, для определения значения атрибута nINumber мне пришлось применить extension_7c51781fcb5b481a98ba6efa5c7578d6_nINumber. В данной строке 7c51781fcb5b481a98ba6efa5c7578d6 это значение идентификатора для нашего приложения с наименованием Tenant Schema Extension App." Все эти значения индивидуального атрибута доступны в нашем Tenant Schema Extension App. Когда вы ссылаетесь на индивидуальный атрибут в группе или приложении Azure AD, вы должны применять тот же самый формат. Значение идентификатора приложения отличается от одного арендатора к другому. Это приложение можно найти в прикладных приложениях Azure AD Enterprise.

 

Рисунок 8-12


Идентификатор приложения

Когда я применяю Microsoft Graph Explorer, как и ожидалось, я могу увидеть значение индивидуального атрибута.

 

Рисунок 8-13


Значение индивидуального атрибута в Azure AD

Кроме того, оно соответствует нашему значению в локальном объекте пользователя.

 

Рисунок 8-14


Значение индивидуального атрибута в Active Directory

Как мы можем видеть, если это необходимо, имеется возможность синхронизации индивидуальных атрибутов в Azure AD.

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

Что является наиболее распространённой задачей администрирования в AD? Очевидно, создание учётных записей пользователей и администрирование ими. Некая учётная запись пользователя не просто хранит некое имя пользователя; она также содержит такие сведения, как участие в группах, путь удалённого профиля, значение пути домашней папки, сведения о сценарии регистрации, полномочия удалённого дозвона и многое иное. Всякий раз когда мы настраиваем какую- то новую учётную запись, нам требуется задавать значения этих атрибутов. Когда общее число атрибутов растёт, также возрастает и общее число ошибок, которое может происходить в процессе создания конкретной учётной записи. Здесь на кону идентичность некой организации; даже небольшая ошибка может оказаться дорогостоящей для организации. Например, если вы случайно добавите пользователя в неправильную группу, он/ она получит доступ к некоторым ресурсам, к которым он не должен иметь доступа.

Когда я создаю некую Заявку на работу (SoW, Statement of Work) или план реализации для заказчика, я всегда начинаю с какого- то шаблона. Этот шаблон содержит разделы, которые создают контур того что мне требуется изменять в соответствии с каждым из требований заказчика. Когда я применяю некий шаблон, это не просто сберегает моё время, но также исключает какой бы то ни было риск того что может произойти в процессе форматирования документа. Аналогично, а некой среде AD учётные записи пользователя могут обладать общими атрибутами и уровнями привилегий. В качестве примера, все пользователи подразделения продаж будут участниками одной и той же группы безопасности. Они также будут иметь тот же самый сценарий регистрации в системе для установки соответствий совместным ресурсам. Тем самым, вместо того чтобы создавать некую учётную запись пользователя продавца с нуля, я могу создать некий шаблон со всеми значениями общих атрибутов и применять его для создания новой учётной записи пользователя. Microsoft поддерживает такое создание шаблонов учётных записей пользователей начиная с Windows NT.

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

Имеется несколько моментов, которые следует учитывать при создании шаблонов пользователей:

  • Не копируйте учётные записи пользователей в качестве шаблона: Я наблюдал как многие инженеры просто случайным образом выбирают какого- то пользователя из OU (Organizational Unit) и применяют его в качестве какого- шаблона для новой учётной записи пользователя. Шаблоны должны создавать некий базовый уровень. Прочие учётные записи пользователей могут обладать уникальными полномочиями и значениями атрибутов, даже когда они расположены в одном и том же OU. Следовательно, всегда удерживайте учётные записи пользователей обособленно от шаблонов.

  • Отключённые учётные записи: Никто не должен применять учётные записи шаблона для аутентификации. При создании некого шаблона убедитесь что вы настроили его в качестве отключённой учётной записи. В процессе создания соответствующей новой учётной записи пользователя данное состояние создаваемой учётной записи может быть изменено.

Для демонстрации всего этого я намерен создать некий шаблон пользователя для пользователей Technical Department. Я применяю такую команду:


New-ADUser -Name "_TechSupport_Template" -GivenName "_TechSupport" -Surname "_Template" -SamAccountName "techtemplate" -UserPrincipalName "techtemplate@rebeladmin.com" -Path "OU=Users,OU=Europe Office,DC=rebeladmin,DC=com" -AccountPassword(Read-Host -AsSecureString "Type Password for User") -Enabled $false

Наша предыдущая команда создаёт некую учётную запись пользователя с названием _TechSupport_Template. Она также устанавливает эту учётную запись пользователя в отключённое состояние.

Я также намерен добавлять такую учётную запись в имеющуюся группу безопасности Technical Department:


Add-ADGroupMember "Technical Department" "techtemplate"

Теперь, когда мы заходим в ADUC, мы можем наблюдать этот новый шаблон. Чтобы создать из него какую- то новую учётную запись, кликните правой кнопкой по Copy...:

 

Рисунок 8-15


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

Затем пройдите и заполните все сведения в соответствующем мастере и завершите этот процесс создания учётной записи пользователя.

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

В своём следующем разделе мы намерены изучить различные виды учётных записей служб и то как мы можем верно использовать их в некой среде AD.

MSA

При установке приложений или служб в некой инфраструктуре рекомендуется применять учётные записи служб. Некая учётная запись службы представляет собой какую- то выделенную учётную запись с особыми привилегиями, которые применяются запускаемыми службами, пакетными заданиями и задачами управления. В большинстве инфраструктур учётные записи служб это обычные учётные записи пользователей с вариантом 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, мы можем воспользоваться приводимой ниже командой. Я запускаю её в своём контроллере домена.


New-ADServiceAccount -Name "MyAcc1" -RestrictToSingleComputer

В своей предыдущей команде я создал некую учётную запись службы с названием MyAcc1 и я ограничил её одним компьютером.

Своим следующим шагом я ассоциирую эту учётную запись службы с сервером хоста REBEL-SRV01, в котором я намерен применять данную учётную запись службы:


Add-ADComputerServiceAccount -Identity REBEL-SRV01 -ServiceAccount "MyAcc1"

Наш следующий шаг состоит в установке учётной записи службы в своём сервере REBEL-SRV01. Для этого нам потребуется модуль AD PowerShell. Мы можем установить его воспользовавшись RSAT (Remote Server Administration Tools, Инструментами удалённого администрирования серверами). Это можно сделать запустив команду Install-WindowsFeature RSAT-AD-Tools. Когда всё готово, выполните такую команду:


Install-ADServiceAccount -Identity "MyAcc1"

Мы можем проверить свою учётную запись службы воспользовавшись следующей командой:


Test-ADServiceAccount "MyAcc1"

Она возвращает True, что означает что проверка прошла успешно.

Из соответствующего сервера AD мы можем проверить созданную учётную запись службы выполнив такую команду:


Get-ADServiceAccount "MyAcc1"
[Совет]Совет

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

gMSA

В своём предыдущем разделе мы обсудили 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. Это требуется выполнять в контроллере домена с полномочиями Администратора домена или Администратора предприятия:


Add-KdsRootKey –EffectiveImmediately

После выполнения этого имеется установленный по умолчанию предел в 10 часов для репликации этого ключа корня во все контроллеры домена и запуска обработки запросов gMSA. В некой тестовой среде с единственным контроллером домена вы можете принудительно удалить такое время ожидания и запускать отклики на запросы gMSA немедленно. Это не рекомендуется для промышленных сред. Мы можем удалить такой предел времени репликации в 10 часов воспользовавшись следующей командой:


Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

После этого мы можем создать самую первую учётную запись gMSA. Я создал некую группу, IISFARM, и добавил в неё все свои серверы IIS. Эта ферма будет применять вновь создаваемый gMSA:


New-ADServiceAccount "Mygmsa1" -DNSHostName "web.rebeladmin.com" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"

В нашей предыдущей команде Mygmsa1 это создаваемая учётная запись службы, а web.rebeladmin.com это FQDN (fully qualified domain name) данной службы. После её выполнения мы можем проверить такую новую учётную запись при помощи следующей команды:


Get-ADServiceAccount "Mygmsa1"

Наш следующий шаг состоит в установке Mygmsa1 в определённом сервере из имеющейся фермы IIS. Mygmsa1 требует для запуска модуль AD PowerShell/ Mygmsa1 можно установить при помощи RSAT:


Install-ADServiceAccount -Identity "Mygmsa1"
[Совет]Совет

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

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


Test-ADServiceAccount "Mygmsa1"

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

Деинсталляция MSA

Иногда вам требуется удалять MSA. Это можно выполнить при помощи такой команды:


Test-ADServiceAccount "Mygmsa1"

Наша предыдущая команда удалит Mygmsa1. Это применимо к обоим видам MSA.

Группы

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

В среде AD имеются две категории групп:

  • Группы безопасности: Этот тип применяется для назначения прав к ресурсам. В качестве примера, Rebeladmin Corp. имеет команду из 10 продавцов. Они используют некую совместную папку с названием Sales. Все в этой команде продавцов имеют одни и те же полномочия доступа к ней. Когда эти права управлялись на уровне пользователя, его ACL (Access Control List, Список управления доступом) для папки Sales приходилось иметь 10 записей для представления этих пользователей.

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

  • Группы распространения: Они используются в некой системе электронной почты, например, в Microsoft Exchange. Они применяются для распространения одного электронного письма в какую- то группу. В этих группах не включена безопасность, поэтому вы не можете применять их для назначения прав.

Область действия группы

Сферы групп помогают определять границы определённой операции внутри имеющегося леса Active Directory. Имеются три предварительно определённых областей действия для их выбора при создании групп Active Directory:

  • Domain Local (Локально в домене): Локальные в домене группы могут применяться для управления правами для ресурсов в неком отдельном домене. Это не означает, что данная группа будет иметь только участников внутри одного и того же самого домена. Они могут иметь такие типы участников:

    • Учётные записи пользователей для всех доверенных доменов

    • Учётные записи компьютеров для всех доверенных доменов

    • Универсальные группы для всех доверенных доменов

    • Локальные в домене группы из того же самого домена

    • Глобальные группы для всех доверенных доменов

    Объекты Локальных в домене групп и данные их участников будут реплицироваться во все Контроллеры домена в том же самом домене.

  • Global (Глобальные): Глобальные группы могут применяться для управления правами к ресурсам в любом домене из одного и того же леса. Глобальные группы могут содержать следующие типы участников:

    • Учётные записи пользователей из одного и того же домена

    • Учётные записи компьютеров из одного и того же домена

    • Глобальные группы из одного и того же домена

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

  • Universal (Универсальные): Аналогично Глобальным группам, Универсальные группы могут использоваться для управления привилегиями в любом домене определённого леса. Однако, они позволяют вам иметь участников из любого из доменов. Например домены rebeladmin.com и rebeladmin.net из одного и того же леса могут обладать некой Универсальной группой с названием Sales Managers с участниками из обоих доменов. Затем, я могу назначить её полномочия для соответствующей папки в rebeladmin.org из того же самого леса. Универсальная группа может обладать такими типами участников:

    • Учётные записи пользователей из всех доверенных доменов

    • Учётные записи компьютеров из всех доверенных доменов

    • Глобальные группы из всех доверенных доменов

    • Универсальные группы из всех доменов того же самого леса

    Объекты Универсальной группы и данные участников будут реплицироваться во все серверы Глобального каталога. Универсальные группы придают необходимую гибкость для применения прав к любым ресурсам во всех доменах из одного и того же самого леса.

[Замечание]Замечание

Группы поддерживают наличие прочих групп в качестве участников. Это имеет название вложенных групп (nested groups). Это дополнительно уменьшает изменения в конкретном ACL. Во всех предыдущих моментах мы перечислили какие типы групп допускается добавлять в качестве встраиваемых групп для каждой из областей действия.

Преобразование групп

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

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

Таблица 8-2. Способы преобразования групп
Область действия Локальная в домене Глобальная Универсальная

Локальная в домене

не доступно

X

Да (только в случае когда в ней не участвуют никакие прочие Локальные в домене группы)

Глобальная

X

не доступно

Да (только в случае когда нет участников прочих Глобальных групп)

Универсальная

Да

Да (только в случае когда в ней не участвуют никакие прочие Универсальные группы)

не доступно

Настройка групп

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

  • ADAC (Active Directory Administrative Center)

  • ADUC MMC

  • PowerShell командлеты

В этом разделе я намерен применять командлеты PowerShell для настройки групп AD и управления ими.

Для добавления некой новой группы в какую- то среду AD можно воспользоваться командлетом New-ADGroup. При помощи следующего мы можем просмотреть полный синтаксис этой команды:


Get-Command New-ADGroup -Syntax

В качестве примера я собираюсь создать некую новую группу безопасности с названием Sales Team:


New-ADGroup -Name "Sales Team" -GroupCategory Security -GroupScope Global -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com"

Для нашей предыдущей команды справедливо следующее:

  • -GroupCategory: Определяет значение типа данной группы (security или distribution).

  • -GroupScope: Задаёт значение области действия этой группы.

  • -Path: Определяет значение пути для объекта этой группы. Когда параметр -Path не применяется, будет использован установленный по умолчанию контейнер, Users.

По причине важности этой группы я желаю защитить её объекты от непредумышленного удаления:


Get-ADGroup "Sales Team" | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Это также можно установить при помощи окна свойств данной группы:

 

Рисунок 8-16


Защита объекта от неумышленного удаления

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


Add-ADGroupMember "Sales Team" tuser3, tuser4, tuser5

Наша предыдущая команда добавит пользователей tuser3, tuser4 и tuser5 в созданную группу.

Если требуется удалить кого- то из пользователей в этой группе, мы можем применить такую команду:


Remove-ADGroupMember "Sales Team" tuser4

При помощи командлета Get-ADGroup мы можем просмотреть свойства своей группы:


Get-ADGroup "Sales Team"

Воспользовавшись следующей командой мы можем выполнить выборку определённых значений из своей группы:


Get-ADGroup "Sales Team" -Properties DistinguishedName,Members | fl DistinguishedName,Members

Наша предыдущая команда перечислит имеющиеся DistinguishedName и значения Members для нашей группы безопасности Sales Team:

 

Рисунок 8-17


Значения DN и участников

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


Set-ADGroup "Sales Team" -GroupScope Universal

Она изменит область действия данной группы с Global на Universal:

 

Рисунок 8-18


Сфера действия группы

И последнее, но не по значимости, группу можно удалять применяя командлет Remove-ADGroup:


Remove-ADGroup "Sales Team"

Наша предыдущая команда удалит созданную ранее группу Sales Team.

[Совет]Совет

Когда у вас установлен вариант значения для непредумышленного удаления данной группы, вам требуется вначале удалить его перед выполнением команды Remove-ADGroup. В противном случае вы получите отказ выполнения. Для удаления значения варианта непредумышленного удаления мы можем применить команду Get-ADGroup "Sales Team" | Set-ADObject -ProtectedFromAccidentalDeletion:$false.

Устройства и прочие объекты

Помимо компьютеров, Active Directory также поддерживает несколько прочих типов устройств и объектов. В этом разделе мы рассмотрим такие различные типы объектов:

  • Принтеры: Принтеры являются одним из наиболее часто совместно используемых ресурсов в сетевых средах офиса. Мы можем применять различные методы настройки совместных принтеров для компьютеров пользователей. Мы можем настраивать их с помощью мастера настройки принтера в Windows и подключаться к принтеры через некий IP адрес. Также мы можем применять сценарии регистрации для установки соответствия и устанавливать принтеры в рабочих станциях. Когда некая организация использует принт- серверы, мы можем подключаться к ним и также устанавливать соответствующие принтеры. В некой среде AD мы можем зарегистрировать соответствующий принтер в качестве объекта AD. Это позволит надлежащим пользователям просматривать AD, обнаруживать требуемый принтер и затем устанавливать его в своей рабочей станции.

    Для регистрации некого принтера в AD, пройдите в Printer properties, а затем в закладку Sharing. Здесь имеется флажок в блоке List in the directory для перечисления такого принтера в Active Directory.

    В соответствующей рабочей станции в процессе настройки такого принтера нам требуется выбрать необходимый вариант для перечисления принтеров из своего каталога чтобы увидеть все интегрированные с Active Directory принтеры:

     

    Рисунок 8-19


    Объект принтера

  • iNetOrgPerson: Этот объект определён в RFC 2798. Данный тип объекта применяется прочими службами каталога, которые основываются на LDAP и X.500. Данный тип объекта имеется в AD для поддержки миграции из не- Microsoft служб каталога и для поддержки приложений, которым необходимы объекты iNetOrgPerson. Данный объект, если это потребуется, может преобразовываться в обычного пользователя. Для добавления этого объекта мы можем применять ADAC, ADUC или PowerShell. В PowerShell вы могли бы применить тот же самый командлет New-ADUser:

    
New-ADUser -Name "Inet User1" -GivenName "Inet"
 -Surname "User1" -SamAccountName "inetuser1"
 -UserPrincipalName "isuer1@rebeladmin.com"
 -AccountPassword (Read-Host -AsSecureString "Type Password for User")
 -Enabled $true -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com"
 –Type iNetOrgPerson

    Наша предыдущая команда добавит объект inetOrgPerson с названием Inet User1. Единственное отличие в этой команде от команды для обычного пользователя AD состоит в –Type inetOrgPerson, который задаёт значение типа учётной записи как inetOrgPerson.

    Мы можем преобразовать значение объекта inetOrgPerson в обычный объект пользователя AD при помощи следующей команды:

    
Set-ADUser "inetuser1" -Remove @{objectClass='inetOrgPerson'}

Рекомендации

Здесь мы рассмотрим некоторые рекомендации, которые можно применять для управления объектами Active Directory:

  • Уборка: Важно время от времени просматривать адекватность объектов Active Directory. Могут иметься объекты, которые больше не участвуют в работе. Для обработки таких объектов имеются некоторые способы:

    • Если на 100% можно убедиться что объекты на данный момент не применяются, их можно полностью удалить из Active Directory.

    • Когда это невозможно подтвердить, эти объекты можно отключить и далее выполнять отслеживание событий. Если никакие события не происходят, такие объекты могут быть удалены из Active Directory.

    Для управления отключёнными объектами предлагается создавать некие отличающиеся OU и перемещать в них отключаемые объекты. Это позволит вам отслеживать их и разрешать доступ к ним когда это потребуется.

    В Active Directory могут иметься объекты, которые используются лишь ограниченное время. В качестве примера, могут иметься контрактники, которые работают лишь в определённых проектах. Создаваемые для таких контрактников учётные записи пользователей применяются лишь на протяжении проекта. Такие типы объектов можно оставлять отключёнными и включать лишь когда это потребуется. Бывшие сотрудники также попадают в разряд этой категории.

  • Добавление описаний: В объектах Active Directory имеется некий атрибут, в который у вас есть возможность добавления описания такого объекта. Рекомендуется добавлять некое описание объекта, когда оно не описывается самим присваиваемым ему названием. Описание объекта позволяет инженерам быстро находить объект и понимать его цель.

  • Защита объектов от непредумышленного удаления: Эта функциональность была введена начиная с AD DS 2008. Она была включена для объектов пользователей, компьютеров и групп. Это предотвращает неумышленное удаление объектов. Её можно включать на уровне индивидуального объекта или на уровне OU/ каталога. Это свойство следует отключать когда вы желаете на самом деле удалить некий объект.

  • Соглашения об именовании объектов: При задании значений объектам всегда следуйте стандартам. В качестве примера, некие организации предпочитают применять первые несколько букв в качестве имени и фамилии для имени пользователя. Кое- кто может предпочитать формат имя.фамилия. Эти форматы могут отличаться от фирмы к фирме. Рекомендуется документировать их для того, чтобы участники команды также могли следовать таким предпочтениям. Если такой документ не существует, посмотрите окружающие типы объектов чтобы понять применяемые стандарты.

Выводы

В этой главе мы изучили объекты и атрибуты Active Directory и как они определяются имеющейся схемой Active Directory. Также мы изучили как добавлять индивидуальные атрибуты в имеющуюся схему Active Directory. Затем мы рассмотрели создание шаблонов учётных записей пользователей и имеющиеся различные виды учётных записей служб. В некой среде Active Directory порой требуется управлять правами для групп пользователей, которые имеют аналогичные требования для работы (то что им приходится делать в своих подразделениях, роли заданий и тому подобное). Это выполняется при помощи групп Active Directory. Для выбора имеются различные категории групп. В этой главе мы рассмотрели такие виды групп и изучили как применять их подобающим образом. В этой главе мы также прошлись по рекомендациям управления объектами чтобы оказать вам содействие в ваше практике управления объектами Active Directory.

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