ADDS, PowerShell, Windows Server 2016

Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 3-я — Инфраструктура управления

Leave a comment

В предыдущей части — Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 2-я — Пост-конфигурация

Вступление

Прощу прощения за длительный перерыв – за эти полгода произошло много всего, включая смену страны проживания и работы. А кроме того, как видно по предыдущим постам, я немного увлёкся PowerShell.
Во время написания этого поста меня тоже слегка занесло: мне даже пришлось разделить пост на две части. Поэтому сегодня у меня для вас не один, а целых два поста! Следующий находится вот здесь: Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 4-я — AGPM
До этого момента, мы работали с серверами в интерактивном режиме. Это считается не самой эффективной практикой, поскольку на поддержание интерактивной сессии тратятся ресурсы сервера. Также это достаточно неудобно при работе с большим количеством серверов.
Поэтому, в этой статье мы настроим удалённые административные рабочие станции, с помощью которых и будем в дальнейшем управлять инфраструктурой.

In this article:



Переменные, используемые в статье:

Как мы обсудили в предыдущей статье, правильное разделение привилегий очень важно — именно поэтому для управления инфраструктурой следует использовать отдельные административные учётные записи и рабочие станции.
Мы создадим 3 учётные записи — как минимум по одной на каждую зону безопасности. Также нам понадобятся административные рабочие станции, тоже по числу зон безопасности. Каждая зона безопасности должна быть чётко ограничена по привилегиям, поэтому для каждой зоны мы будем использовать свою рабочую станцию.

Warning

Административная рабочая станция – это компьютер, который используется исключительно для задач администрирования системы. В целях безопасности, вам НЕ следует выходить в Интернет или проверять почту с той же машины, которая используется для управления вашими ИТ-системами. В противном случае, если вы подхватите вредоносное ПО из Интернета, оно сможет попасть на ваши серверы и украсть данные привилегированных у/з, таких как администратор домена.

Important

Администраторы не должны использовать свои учётные записи совместно: у каждого администратора должна быть отдельная учётная запись для каждой зоны безопасности. Допустимо совместное использование административной рабочей станции в пределах одной зоны. Некоторые компании для этих целей используют VDI.

 

Remark

Когда я писал эту часть, то обнаружил, что моё предыдущее высказывание насчёт того, что для Зоны 0 мы не будем создавать никаких OU, было несколько преждевременным. Учитывая количество объектов, которые мы создадим в этой и следующей частях, будет разумно создать структуру OU для Зоны 0. Вот код для этого:

Обратите внимание, что структура хэш-таблицы $TierOU слегка изменилась: атрибут CompOUName я переименовал в ComputerOUName, UserOUName в AccountOUName и добавил новый атрибут — OUPath.

Создание административных учётных записей

Сначала создадим пользовательские учётные записи. Имя административной учётной записи обычно составляется по шаблону: общий для всех административных учётных записей идентификатор + личный идентификатор конкретного администратора + идентификатор зоны. Выглядеть это может например вот так: DA-admin-kf — это административная учётная запись для Зоны 0 (идентификатор зоны «DA» (переменная $TierIds.Tier0)), которую использую я (мой личный идентификатор/никнейм «kf»).
Поскольку в названии всех административных учётных записей присутствует часть «-admin-», то можно сохранить её в качестве переменной, чтобы не менять её каждый раз при смене соглашения о присвоении имён. Имя этой переменной будет $AdminUserNameTemplate.

Note

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

 

Имя пользователя мы передаём в параметр -Name, а полное отличительное имя OU для зоны – в параметр -Path.
В прошлой части мы говорили о шаблонов для строк. Здесь мы используем шаблоны немного по-другому: в параметре -Name заполнители отсутствуют. Это потому, что заполнители находятся непосредственно в шаблоне: $AdminUserNameTemplate = '{0}-admin'. Да, обращаясь к строкам через переменные, вы можете использовать их заполнители!

Note

Почему мы создаём учётные записи в Зоне 0? Для предотвращения кражи учётной записи. Например, вы присвоили некой учётной записи, которая не входит в ролевую группу, разрешение на управление пользовательской учётной записью в какой-то зоне. Если административные учётные записи этой зоны находятся в OU учётных записей этой зоны, то пользователь получает возможность сбросить пароль любой из этих административных учётных записей, повысив, таким образом, свои привилегии.

 
Учётные записи, которые мы только что создали, находятся в неактивном состоянии, потому что мы не задали для них паролей. Поэтому нам нужно сбросить их пароли. Вот как это делается в PowerShell:

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

Отлично, пароли есть, теперь мы можем активировать учётные записи:

Создание административных групп и определение полномочий

Мало просто создать пользователей, поскольку присвоение полномочий напрямую учётным записям – плохая идея: для присвоения полномочий следует использовать группы. У нас есть 4 зоны безопасности, а значит нам потребуется как минимум 4 группы. Группа для Зоны 0 уже существует — это Domain Admins! Теперь создадим отдельные группы для других зон. Я называю эти группы «ролевыми», поскольку они задают полный набор полномочий для каждой учётной записи.
Название ролевой группы выглядит примерно так: ADM-Administrator-SE, где «ADM» – идентификатор административной группы ($AdminGroupId), «-Administrator-» — шаблон имени ролевой группы ($RoleGroupNameTemplate), а «SE» – идентификатор зоны.

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

Первая строка в представленном фрагменте кода добавляет нашу административную учётную запись Зоны 0 в группу «Domain Admins». Почему я использую настолько сложный путь? Зачем применять DomainSID и что значит «512»?
Всё дело в локализации. В локализированных операционных системах группы по умолчанию могут называться не по-английски, но их относительные идентификаторы останутся теми же самыми, то есть RID – это единственный надёжный способ указать группу по умолчанию. RID группы Domain Admins всегда будет 512. Чтобы получить её SID, нужно взять SID домена и добавить в конце RID группы.

Хорошо, ролевые группы есть, административные учётные записи добавлены, но что толку, если группам не назначены полномочия в AD DS, и, соответственно включённые в них административные учётные записи тоже не имеют полномочий? Давайте раздавать полномочия! А вот как это следует делать: каждая ролевая группа (кроме группы Зоны 0) должна обладать следующими разрешениями, касающимися организационных единиц внутри своей Зоны:

  • Computers OU – Create/Delete Computer objects, Descendant Computer objects – Full control
  • Groups OU – Create/Delete Group objects, Descendant Group objects – Full control
  • Accounts OU – Create/Delete User objects, Descendant User objects – Full control,
    Create/Delete Contact objects, Descendant Contact objects – Full control,
    Create/Delete msDS-GroupManagedServiceAccount objects, Descendant msDS-GroupManagedServiceAccount objects – Full control
    • Note

    Почему я назначил именно такие права Accounts OU? На личном опыте я убедился, что объекты типов User и Contact часто используются совместно, а что касается msDS-GroupManagedServiceAccount — скоро нам понадобятся объекты этого класса, так что надо же их где-то хранить?

     
    Лучше всего назначать полномочия ролевой группе НЕ добавляя группы напрямую в DACL, а добавляя их в ДРУГИЕ административные группы, которым уже присвоены полномочия. Почему? Допустим, вам нужно делегировать часть полномочий ролевой группы учётной записи, которая не входит в указанную группу. Тогда вместо изменения DACL, вы сможете просто добавить учётную запись в соответствующую административную группу.

    Как видно из предложенного списка, есть 9 областей полномочий: 3 области для каждой Зоны (область полномочий Зоны 0 – весь домен). Каждой области безопасности требуется собственная группа безопасности, которой и будут присвоены полномочия.

    Note

    Область действия Univeral здесь — это всего лишь личное предпочтение, т.к. я долго работал с много-доменными лесами. Вы при желании можете использовать Global, поскольку мы, в соответствии с передовыми практиками, будем работать с однодоменным лесом AD.

     
    В прошлой части мы уже рассмотрели присвоение полномочий Active Directory с помощью PowerShell, так что здесь я просто расшифрую GUID:

    • bf967a86-0de6-11d0-a285-00aa003049e2 – Класс объектов Computer
    • bf967a9c-0de6-11d0-a285-00aa003049e2 – Класс объектов Group
    • bf967aba-0de6-11d0-a285-00aa003049e2 – Класс объектов User
    • 5cb41ed0-0e4c-11d0-a286-00aa003049e2 – Класс объектов Contact
    • 7b8b558a-93a5-4af7-adca-c017e67f1057 – Класс объектов Group Managed Service Account

    Первый в каждой паре метод AddAccessRule() присваивает группе разрешение Create/Delete для выбранного типа объектов, а второй — даёт полный доступ ко всем объектам-потомкам выбранного типа.

    Мы назначили права ролевым группам для зон 1-3. Группе Зоны 0, Domain Admins, права назначать не нужно, поскольку это происходит по умолчанию во время установки AD DS.
    Наша последняя задача – добавить ролевые группы в группы безопасности:

    Установка административных рабочих станций

    Имя каждого административного компьютера состоит из префикса рабочей станции, который помогает отличать учётные записи рабочих станций от серверных, идентификатора, который отличает административную рабочую станцию от обычной, и идентификатора зоны. Например, имя учётной записи может выглядеть вот так: WSADMSE — это административная рабочая станция в Зоне 1, идентификатор Зоны — «SE».
    Как и в случае с учётными записями, постоянная часть имени административной рабочей станции находится в переменной $AdminWSNameTemplate.

    Далее, на каждой рабочей станции проделайте следующее:

    1. Установите ОС. Выбор за вами: можете использовать Windows Server 2016 или Windows 10. Используйте самый свежий ISO-образ.
    2. Переименуйте компьютер по схеме именования.
    3. Установите все доступные обновления.
    4. Установите RSAT:
      • Для Windows 10
        1. Скачайте подходящий дистрибутив RSAT (Вам НЕ НУЖНА версия этого пакета для Windows 1709). Сейчас он расположен по этой ссылке: https://www.microsoft.com/en-us/download/details.aspx?id=45520.
        2. Установите RSAT:
          1. Скопируйте RSAT на компьютер во временную папку:
            $TempDirectory = New-Item -Type Directory -Name $TempDirectoryName -Path (Join-Path -Path $TempDirectoryPath -ChildPath '\')
          2. Примените пакет:
            Start-Process -FilePath 'wusa.exe' -ArgumentList ('{0} /quiet' -f $(Join-Path -Path ($TempDirectory.FullName) -ChildPath 'WindowsTH-RSAT_WS2016-x64.msu')) -Wait
      • Для Windows Server 2016:
        Install-WindowsFeature -Name RSAT, GPMC
    5. И удалите SMB1:
      • Windows 10:
        Start-Process -FilePath 'dism.exe' -ArgumentList '/Online /Disable-Feature /FeatureName:SMB1Protocol' -Wait; Restart-Computer
      • Windows Server 2016:
        Uninstall-WindowsFeature -Name FS-SMB1 -Restart

      6. Параметр -Restart командлета Uninstall-WindowsFeature означает, что компьютер перезагрузится автоматически, если это потребуется для удаления компонентов.

    6. Введите рабочую станцию в домен:
      1. Используйте IP-адреса контроллеров DC1 и DC2 в качестве DNS серверов:
        Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses @($DC1IPAddress, $DC2IPAddress)
      2. Теперь добавьте компьютер в домен:
        Add-Computer -DomainName $Domain.DNSRoot -Credential (Get-Credential) -Restart
    Warning

    Ни В КОЕМ СЛУЧАЕ не используйте на сетевых интерфейсах неавторитетные для вашей доменной зоны AD DS DNS-серверы. Обычно надо использовать только адреса контроллеров домена.
    В некоторых сетях, контролеры домена не предоставляют сервис DNS и запросы зоны обрабатываются отдельными UNIX-серверами — в этом случае, используйте в качестве DNS серверов только эти UNIX-серверы.

    Заключение

    В этой статье мы создали 4 административные учётные записи, которые позже мы используем для управления инфраструктурой (да, пришло время расстаться со встроенной учётной записью Administrator).
    Мы назначили этим учётным записям права и установили отдельные административные рабочие станции для каждой из них. Однако эти учётные записи всё ещё не обладают особыми правами на рабочих станциях: они даже не могут войти в систему по RDP. Что ещё хуже, учётная запись из более привилегированной Зоны может войти в систему рабочей станции менее привилегированной Зоны, что недопустимо.
    Для применения ограничений и протоколов безопасности, IT-администраторы часто применяют групповые политики. По умолчанию, изменения в групповых политиках не логируются, что затрудняет отслеживание того, кто, когда и почему изменил ту или иную настройку. Вообще, групповые политики – очень мощный и даже опасный инструмент: одно случайное нажатие может разрушить всю вашу инфраструктуру.
    Однако у этого вопроса есть изящное решение — и оно изложено в следующей статье, в которой мы рассмотрим расширенное управление групповыми политиками (AGPM).

Leave a Reply

Your email address will not be published. Required fields are marked *