ИТ-архитектура от А до Я: Комплексное решение. Первое издание

Tekst
Loe katkendit
Märgi loetuks
Kuidas lugeda raamatut pärast ostmist
Šrift:Väiksem АаSuurem Aa

•Прокладка кабеля желательно в стенах и максимально защищенных от внешнего воздействия местах.

•Определение мест размещения элементов системы.

•Физическое изолирование компонентов системы от департамента ИТ.

•Определение мест пульта охраны и т п.

Рекомендуется использовать:

•Широкоугольные объективы для наблюдения за входами, дверями, комнатами малых размером 5х5 метров.

•Узко-угольные объективы для наблюдения за коридорами, периметром, комнатами средних размеров 10х10 метров.

Общие рекомендации:

•Стараться избегать использование поворотных камер без особой надобности

•Установка с противоположной стороны от возможного вторжения

•При использовании компьютерных систем рекомендуется использовать запись по движению с настройками начала записи 10—20 секунд до начала движения и 5—10 секунд после окончания движения.

Типовое решение: камера 1.3Mpics, матрица 1/3 дюйма, объектив верификатор 2.8 дюйма, угол обзора 30—780 инфракрасная подсветка 20—30 метров, питание PoE.

F14: Система пожарной сигнализации

Система пожарной сигнализации (общие требования)

Система пожарной сигнализации является обязательным требованием для здания, и устанавливается специализированными компаниями. Являются «де-факто» элементом общей системы безопасности. Владелец системы как правило департамент безопасности. В общем случае система состоит из датчиков и сенсоров дыма или тепла, среды передачи и контролеров управления. Могут быть автономными, централизованными или интегрированными решениями. При проектировании системы со стороны ИТ предъявляются следующие требования и рекомендации:

•Обнаружение и оповещение о пожаре в помещениях дата центра.

•Обнаружение и оповещение в помещении серверной комнаты.

•Обнаружение и оповещение в помещении коммутационных комнат.

•Обнаружение и оповещение о пожаре отдельно стоящих коммуникационных шкафов.

•Обнаружение и оповещение о пожаре в технических и служебных помещениях.

Система пожарной сигнализации здания и помещений ЦОД

Помимо общих требований, при проектировании системы со стороны ИТ предъявляются следующие требования и рекомендации:

•Наличие системы обнаружения и оповещения о пожаре в помещениях ЦОД, серверной или коммутационной комнат.

•Наличие датчиков обнаружения и оповещения о пожаре в технических помещениях;

•Наличие системы мониторинга и контроля:

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

•Наличие датчиков обнаружения и оповещения о пожаре в коммуникационных шахтах;

Требования по интеграции Системы пожарной сигнализации

Со стороны отдела Безопасности определяются требования и рекомендации. Типовые вопросы:

•Обеспечение питанием от основной, резервной и бесперебойной систем электроснабжения.

•Прокладка кабеля желательно в стенах и максимально защищенных от внешнего воздействия местах.

•Определение мест размещения элементов системы.

•Определение мест пульта охраны и т п.

F15: Система автоматического пожаротушения

Система автоматического пожаротушения (общие требования)

Система автоматического пожаротушения не является обязательным требованием для здания (исключение специальные объекты) и устанавливается специализированными компаниями. Но являются «де-факто» элементом общей системы безопасности. Владелец системы как правило департамент безопасности. Системы могут использовать как водяное, так и газовое пожаротушение. При проектировании системы со стороны ИТ предъявляются следующие требования к обеспечению автоматического пожаротушения в помещениях дата центра, серверной комнаты, а также в технических и служебных помещениях.

Система автоматического пожаротушения ЦОД

Для помещения серверной комнаты (дата центра) со стороны ИТ предъявляются следующие требования:

•Использование газовой системы пожаротушения.

•Наличие системы мониторинга и контроля.

•Автоматическое пожаротушение в пространствах под фальшполом, рабочем пространстве и в пространстве над потолком.

•Возможность ручного запуска системы.

Требования по интеграции Системы

Со стороны отдела Безопасности определяются требования и рекомендации. Типовые вопросы:

•Обеспечение питанием от основной, резервной и бесперебойной систем электроснабжения.

•Определение мест размещения элементов системы.

•Определение мест пульта охраны и т п.

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

F16: Система оповещения и сигнализации

Система оповещения и сигнализации (общие требования)

Система оповещения и сигнализации не является обязательным требованием для здания, но являются «де-факто» элементом общей системы безопасности. Система позволяет сообщать работникам и посетителям здания важную информацию. Владелец системы как правило департамент безопасности или администрация здания. Может представлять из себя элементы звукового и визуального информирования сотрудников и клиентов, находящихся на територии объекта. К данной системе можно отнести аудио колонки, мониторы, настенные телевизоры, табло, индикаторы и знаки входа, выхода, доски объявлений и т п. В основном система используется при черезвычайных ситуациях, пожарах и т п, как второе назначение системы – рекламный и информационный характер. При проектировании системы со стороны ИТ предъявляются следующие требования и рекомендации по размещениею элементов системы в помещениях дата центра, серверной и коммутационных комнат, а также технические и служебные помещения.

Требования по интеграции Системы оповещения и сигнализации

Со стороны отдела Безопасности определяются требования и рекомендации. Типовые вопросы:

•Обеспечение питанием от основной, резервной и бесперебойной систем электроснабжения.

•Прокладка кабеля желательно в стенах и максимально защищенных от внешнего воздействия местах.

•Определение мест размещения элементов системы.

•Определение мест пульта охраны и т п.

Первичные ИТ сервисы

В данной главе представленно описание сервиса Активного каталога в наиболее полной форме.

P01: Активный каталог и служба DNS

Код сервиса: P01

Тип сервиса: Primary services

Вид сервиса: Technical Service

Наименование сервиса: Активный каталог и служба DNS

Производитель и платформа: Microsoft Windows 2016

Владелец сервиса: ИТ департамент

Управление сервисом: Подразделение Инфраструктуры

Важность сервиса (вес): CRITICAL (16.5)

Уровень восстановления (RLO): На уровне сервера и сервиса

Объект восстановления (RPO): 24 часа

Время восстановления (RTO): 24 часа

Очередность восстановления: 1

Назначение

Активный каталог представляет возможность централизованного управления ИТ ресурсами. Он представляет из себя единый каталог пользователей, групп, объектов и субъектов ИТ инфраструктуры. Возможности централизованного применения групповых политик, повышения уровня информационной безопасности, как отдельных компонентов, так и всей инфраструктуры в целом. Использование групповых политик для установки, удаления программного обеспечения. Дополнительные возможности по шифрованию съемных носителей и функционала «контроль приложений». Активный каталог представляет из себя базу DS и папку SYSVOL. Папка хранит шаблоны групповых политик, которые реплицируются между контролерами, скрипты и т п. Репликация SYSVOL происходит с помощью DFRS.

Структура каталога содержит следующие высокоуровневые контейнеры:

•Сайт (Site);

•Лес (Forest);

•Деревья доменов (Domain Trees);

•Домены (Domains);

•Организационные единицы (Organization Units);

Лес (Forests) – первый высокоуровневый объект. Является высокоуровневой связкой в контексте информационной безопасности. Содержит три раздела: Схема (Schema), Конфигурацию (Configuration) и Приложение (Application). Схема определяет все классы, объекты, такие как пользователи, группы и атрибуты. Схема доступна всем доменам леса. Раздел конфигурации содержит топологию, настройки леса, список контролеров, глобальных каталогов и т п. Раздел приложения содержит данные приложений, например, службы DNS.

Две из пяти ролей FSMO специфичны для леса: Мастер схемы (Schema Master) и Мастер Именования Домена (Domain Naming Master).

Домены (Domains) – логические контейнеры, следующие за лесом. Являются частью контекста безопасности леса. Домен включает в себя следующие компоненты:

•Схема (Schema);

•Глобальный Каталог (Global Catalog);

С•ервис Репликации (Replication Service);

•Роли Мастера Операций (Operation Master Roles или FSMO);

Схема также содержит объекты и атрибуты, Глобальный Каталог содержит информацию по всем объектам домена. Репликация данных между контролерами и рабочие роли. Контролеры домена включают в себя пять ролей (Flexible Single Master Operations FSMO):

•Мастер схемы (Schema Master);

•Мастер Именования Домена (Domain Naming Master);

•Мастер Инфраструктуры (Infrastructure Master);

•RID Мастер (Relative ID (RID) Master);

•Эмулятор Первичного Контролера Домена (PDC Emulator);

Необходимо знать, что одновременно может работать (владеть) каждой ролью только один контролер в одиночном домене. Т.е. либо все роли на одном сервере или максимум на пяти контролерах одновременно, хотя контролеров может быть больше.

Мастер Схемы (Schema Master) – роль служит для обновления схемы леса.

 

Мастер Именования Домена (Domain Naming Master) – служит для добавления и удаления доменов леса.

В каждом домене существуют три оставшиеся роли:

Мастер Инфраструктуры (Infrastructure Master) – синхронизирует объекты внутри базы, при отсутствии запрашивает с глобального каталога. В случае если все сервера являются глобальными каталогами, то значение роли не значительна.

•RID Мастер (Relative ID Master) – каждый новый объект в домене получает уникальный идентификатор безопасности (Security Identifier SID). SID включает в себя идентификатор домена, который уникален для каждого домена. RID Мастер отвечает за предоставление специфических уникальных идентификаторов (RID) в домене для каждого объекта, будь то компьютер, пользователь и т п. Тем самым комбинация SID и RID гарантирует, что каждый объект в домене уникален.

•Эмулятор PDC (PDC Emulator) – контролирует аутентификацию в домене по средствам Kerberos v5 или NTLM. Смена пароля пользователем обрабатывается данной ролью.

Сайт (Site) высокоуровневый контейнер расположения, топологии объектов каталога при его развёртывании. Лес доменов (Domain Trees) представляет из себя группу доменов, которые являются наследниками или дочерними корневого домена. Организационная Единица (Organization Units) минимальная логическая составляющая – контейнер, позволяющая организовать объекты в логическую структуру.

Доверенные связи (Trust) следующая важная составляющая активного каталога. Представляет из себя отношения между лесами и доменами. В лесу все домены по умолчанию связаны между собой двух сторонними прозрачными доверительными отношениями (two-way transitive trust relationship). Это позволяет аутентифицироваться между доменами. Существуют различные типы доверенных связей.

Следующей важной составляющей активного каталога является групповые политики (Group Policy GPO). Они предоставляют возможность централизованного конфигурирования и управления атрибутами объектов. Существует два раздела групповых политик: Пользовательские (User) и компьютерные (Computer). Групповые политики могут применяться на различные контейнеры – уровни. Последовательность влияния политик выглядит следующим образом:

•Local Group Policy;

•Site-linked Group Policies;

•Domain-linked Group Policies;

•OU-linked Group Policies;

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

База данных активного каталога содержится в файле ntds. dit в папке %SYSTEMROOT%\NTDS. В папке также содержатся файлы:

•Edb.chk – содержит проверку целостности базы;

•Edb. log – журнал активности базы;

•Temp. edb – временный файл активности;

•Res1.log или edbres0001.jrs – лог файл при недостатке места;

Репликация данных между контролерами домена один из важнейших механизмов поддержания целостности активного каталога. Репликация связана со следующими компонентами:

•DNS;

•Remote Procedure Call (RPC);

•SMTP (опционально);

•Kerberos;

•LDAP;

Кроме этого работа активного каталога чувствительна к синхронизации времени между контролерами.

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

Требования

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

Архитектура

Архитектура решения строится на базе решения Microsoft Windows Server 2016 Standard и встроенной службы Active Directory Service. Так как активный каталог тесно связан с DNS службой, то последняя также разворачивается на контролерах домена и является интегрированной службой.


Архитектура представлять из себя единый домен и лес – одноуровневая архитектура. Решение наиболее простое и подходит для большинства организаций. Также принимается во внимание наличие не менее двух «сайтов». Контролеры домена располагаются в дата центре основном и резервном. На сайтах компаний, обслуживающем 50 и более сотрудников, при необходимости можно установить контролеры домена с опцией только для чтения (RODC).

Для мульти-доменных организаций, или в целях повышения безопасности ИТ инфраструктуры можно использовать другое решение. В этом случае архитектура активного каталога строится по схеме единого «леса», и множества «деревьев» и «доменов». Корневой домен (forest root domain) предназначен для ИТ инфраструктуры. Домены леса, или в нашем случае один домен, предназначен для сотрудников организации. Компрометация административного доступа в данном домене не нанесет ущерба корневой ИТ инфраструктуре. Структура активного каталога в целях повышения уровня безопасности может представляет из себя следующую логическую архитектуру:

•Корневой домен леса (Forest Root Domain)

•Домен дерева головной компании (Tree Domain) и домены леса для портфелей.


Архитектура предполагает включение гипервизоров в состав корневого домена леса (Root Forest Domain). Головной офис входит в состав основного домена леса (Tree Domain). При расширении организации или сложной холдинговой структуре, ИТ инфраструктура портфелей и компаний входит в состав основного домена леса или могут использовать собственные домены.


Возможности решения

Возможности решения обеспечивают поддержку порядка 2 миллионов объектов в активном каталоге. Один контролер домена способен обслуживать порядка 5000 пользователей.


Ограничения решения

Ограничения, накладываемые данным решением:

•Процессор 1.4 GHz 64-битной архитектуры и выше;

•Память 512 МВ (2GB для версии с GUI);

•Минимальные требования к размеру диска 32GB;

•Создание Корневого домена леса (Forest Root Domain) возможно только при создании с «нуля»;

•Windows 2016, в отличие от Windows 2012R2 имеет только CORE и GUI интерфейсы (в Windows 2012 R2 имеется также GUI MINI).

•В Windows 2016 выбор интерфейса определяется на этапе установки сервера и не может быть изменен в процессе эксплуатации (в отличие от Windows 2012 R2);

•При именовании серверов и рабочих станций желательно учитывать ограничения в 16 символов NetBIOS;

•Максимальная длинна FQDN не более 64 символов;

•Полный путь к папкам SYSVOL, базе данных, лог файлу не должен превышать 260 символов;

•Имя компьютера (DNS host name) не должно превышать 24 символа;

•Максимальная длинна имени объекта «Организационная Единица OU» не должна превышать 64 символа;

•Атрибут «Display name» не должно превышать 256 символов;

•Атрибут «Common name» не должно превышать 64 символа;

•Атрибут «SAM-Account-Name» не должно превышать 20 символов для обратной совместимости с Pre-Windows 2000;

•Атрибут «DN (Distinguished Name) в LDAP» не должен превышать 255 символов;

•Максимальное количество применимых групповых политик (GPO) не должно превышать 999;

•KERBEROS путь для поиска ресурсов (Traverse trust links) не должно превышать 10;

•Количество объектов Trust Domain Objects (TDOs) не должно превышать 2400;


Инфраструктура

Минимальные компоненты инфраструктуры сервиса и включают в себя один сервер размера X-size для контролера домена с установленным на нем операционной системой Windows 2016 Server Core и запущенными сервисами ADDS и DNS.

Рекомендуемые компоненты инфраструктуры сервиса основного сайта (PDC) включают в себя два сервера контролера домена, один на базе физического сервера, а другой на базе виртуальной машины X-size, с установленной операционной системой Windows 2016 Standard Core и службами ADDS и DNS.


Физическая архитектура представляет из себя:

•ADDS-PDC-DC01 – контролер домена – физический сервер. Физические параметры соответствуют размеру XS. Операционная система сервера Windows 2016 Standard GUI.

•ADDS-PDC-DC02 – контролер домена – виртуальная машина. Размер виртуальной машины XS. Операционная система сервера Windows 2016 Standard CORE.


Логическая архитектура представляет из себя

ADDS-PDC-DC01 и ADDS-PDC-DC02 – Сервера располагаются в сегменте VLAN10 «T0 SERVERS» – физический сервер и VLAN20 «T1 SERVERS» – виртуальная машина. Роль серверов:

•Контролер леса: Holding. local

•Контролер домена (Forest Root Domain): Holding. local

•Уровень леса: Windows 2016

•Уровень домена: Windows 2016

•Сервера являются Глобальными каталогами (Global Catalog)


Лицензирование сервиса

Лицензирование сервиса включает в себя следующие компоненты:

•Лицензирование серверных операционных систем Windows 2016 Server Standard;

•Лицензирование клиентского доступа Windows CAL;


Компоненты сервиса встроенная служба Активного Каталога и встроенная служба DNS не требуют лицензирования.

Так как платформа виртуализации строится на платформе Microsoft Windows 2016 Datacenter, то стоимость лицензирования серверных операционных систем виртуальных машин сервиса включена в стоимость платформы виртуализации. Физические сервера лицензируются по количеству ядер.


Лицензирование доступа к сервису

Лицензирование клиентского доступа к сервису возможно на устройство или пользователя (Windows CAL DEV или Windows CAL USER). Для снижения стоимости лицензирования и учитывая дополнительные ИТ сервисы, рекомендуется указывать пакет лицензий (Microsoft Core CAL Suite или Microsoft Enterprise CAL Suite). Microsoft Core CAL Suite предоставляет возможность доступа к серверам версии «Standard»:

•Windows;

•Exchange Standard;

•SharePoint Standard;

•Skype for Business Standard;

•System Center CML;


Microsoft Enterprise CAL Suite включает в себя возможности «Core CAL Suite», а также предоставляет доступ к возможностям «Enterprise» версий.


Зависимости и окружение

Сервис Активного Каталога является ключевым сервисом для всей ИТ инфраструктуре. Для его развёртывания необходимы:

•Инженерные системы и системы безопасности (F01-F15)

•Гипервизоры платформы виртуализации (С01),

•Система Хранения Данных СХД (С02)

•Сетевая инфраструктура (С03).


Мощности

Сервера достаточны для обеспечения работы до 5000 пользователей или устройств. Требуемые вычислительные мощности:

•Минимальные компоненты сервиса представляют из себя физический сервер с двумя процессорами не более 8 ядер каждый, 8—16GB RAM, HDD SAS 10k rpm RAID1 +1 Spare.

•Рекомендуемые компоненты инфраструктуры сервиса основного сайта включают в себя: физический сервер с двумя процессорами не более 8 ядер каждый, 8—16GB RAM, HDD SAS 10k rpm RAID1 +1 Spare, и виртуальный сервер с параметрами 2CPU, 8GB RAM, HDD C:\ 60GB.


Масштабирование

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


Отказоустойчивость и восстановление

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


Роли и ответственности

•Административная роль «Adm_ADDS_Administrators» корневого домена леса необходима для конфигурирования серверов, изменений схемы леса, добавления DNS зон, администрирования активного каталога на серверах.

 

•Административная роль «Adm_ADDS_Administrators» домена дерева леса необходима для конфигурирования серверов, администрирования активного каталога в пределах дерева и домена.


Состав ролей:

Administrator (Forest) – Администратор леса и корневого домена. Входит в состав встроенных групп: Enterprise Admins, Schema Admins, Administrators, Domain Admins, Group Policy Creator Owners и Domain Users;

Administrator (Domain) – Администратор домена дерева. Входит в состав встроенных групп: Administrators, Domain Admins, Group Policy Creator Owners и Domain Users;


Сервисная роль для запуска серверов не предусмотрена. Возможно наличие учетной записи с правами оператора резервного копирования. За работу сервиса отвечает «системный администратор». Кроме этого можно выделить роль «Adm_GPO_Administrators» – отвечающие за создание и изменение групповых политик.


Установка

Первоначальная установка серверов происходит вручную.

Дальнейшая установка при сопровождении происходит из образа с использование скрипта.


Установка роли Active Directory Domain Service и DNS

•Выбираем Promote this server to Domain Controller

•Новый лес, новый домен (New Forest, New Domain)

•Необходимы права администратора схемы леса (Schema Admins)

•Для обоих серверов отмечаем Global Catalog (GC)

•Дальнейшие настройки по умолчанию.


Конфигурирование

Доступ к конфигурации серверов доступен через сервер управления в соответствии с процессом «Управления изменениями».


Настройка портов и протоколов


Настройка службы DNS

Создание DNS Reverse Zone «192.168.0.0». Дополнительные зоны.


Настройка Key Distribution Service (KDS) и генерация KDS ключа

Генерация KDS ключа необходима для создания Групповых Управляемых Служебных Записей (Group Managed Service Accounts gMSA). Управляемые сервисные служебные записи необходимы для запуска служб и ИТ сервисов. Также могут использоваться для запуска «планировщика задач», но только через оснастку PowerShell. Преимущества:

•Пароль длинной 240 символов

•Генерируется каждые 30 дней.

•Не хранится на локальной системе


Для их использования необходимо соблюдать следующие условия

Уровень схемы не ниже Windows 2012, контроллеры Windows 2012 и выше с включенной и настроенной службой Key Distribution Service (KDS), наличие оснастки PowerShell. Генерация ключа происходит вручную и раз через оболочку PowerShell на контроллере домена с правами Enterprise Admins. Ключ доступен через 10 часов после генерации, чтобы все контролеры домена реплицировали данные. Порядок выполнения:

•Входим на контроллер ADDS-PDC-DC01 с учетной записью HOLDING\Administrator и запускаем оснастку PowerShell.

•Запускаем команду Add-KDSRootKey —EffectiveImmediatly

Для тестовой среды можно активировать немедленно командой

Add-KDSRootKey —EffectiveTime ((get-date).addhours (-10))

Проверяем готовность: Get-KDSRootKey


Создание gMSA (Group Managed Service Accounts)

Следующий этап сопровождение Групповых Управляемых Служебных Записей (Group Managed Service Accounts gMSA. Порядок выполнения:

•Входим на контроллер ADDS-PDC-DC01 с учетной записью MyCompany\Administrator и запускаем оснастку PowerShell. Запускаем команду:

New-ADServiceAccount —name gMSA_SCOM_SQL_DB —DNSHostName ADDS-PDC-DC01.mycompany. local —PrincipalsAllowedToRetriewManagedPassword «gMSA_SCOM_SQL_DB_Group»


Где: gMSA_SCOM_SQL_DB – имя сервисной учетной записи, ADDS-PDC-DC01.MyCompany. local – имя DNS хоста, gMSA_SCOM_SQL_DB_Group – группа в активном каталоге куда входят все системы, которые будут использовать эту групповую управляемую служебную запись.


Проверяем через оснастку Active Directory Users & Computers что в контейнере Managed Service Accounts появилась запись.


Устанавливаем учетную запись gMSA на сервер

Следующий шаг установка учетной записи gMSA на сервер, где будет использоваться. Порядок выполнения: Проверяем, что сервер (SQL-PDC-DB01) входит в состав группы gMSA_SCOM_SQL_DB_Group. Входим на сервер (для примера SQL-PDC-DB01 с учетной записью MyCompany\Administrator и запускаем оснастку PowerShell. Запускаем команду: Install-ADServiceAccount —Identity gMSA_SCOM_SQL_DB

(Если нет модуля, то необходимо добавить Features -> RAST -> AD DS Tools -> AD module for PowerShell). Проверка: Test-ADServiceAccount gMSA_SCOM_SQL_DB

Если возвращает TRUE значит все в порядке.


Далее на сервере SQL-PDC-DB01 в настройках запуска службы (Logon) указываем имя учетной записи (с добавлением символа $ в конце обязательно). Пароль указывать нет необходимости. Сервисная учетная получает права «Log on As a Service» автоматически. Перезапускаем сервис.


Проверка и создание записи SPN (Service Provider Name) сервиса

Для примера для SQL сервера необходимо создавать запись для возможности сетевой проверки. Проверка возможна через протоколы: NTLM и Kerberos. Второй предпочтительно. SQL сервер поддерживает Kerberos для следующих протоколов:

•TCP/IP (рекомендуемый)

•Shared Pipes (рекомендуется отключить)

•Shared Memory (рекомендуется отключить)

•SQL сервер поддерживает Kerberos через Windows Security Support Provider (SSPI).


Порядок регистрации SPN записи возможен через несколько вариантов:

•Утилита SetSPN. exe.

Синтаксис: SetSPN —A <spn> <Account>.

Пример: SetSPN —A MSSQLSvc/SRV.domain. local: 1433 domain\ServiceAccount

SetSPN —A MSSQLSvc/SRV.domain. local: Inst1 domain\ServiceAccount


На один экземпляр нужно иметь две записи с портом и именем экземпляра. Для кластера: регистрация для каждой «ноды» и общего имени. Для «Always On»: регистрация для каждого «инстанса» на нодах плюс прослушиватель (listener). Для проверки дублированных записей используется ключ —S.

•Консоль ASDI

•Добавление в атрибут «ServicePrincipalName»

•Утилита KerberosConfigMgr. exe

•Добавление значения и учетной записи


Создание объектов в Активном Каталоге

Структура активного каталога как правило повторяет организационную структуру организации. Также желательно создать организационные единицы для групп, сервисов и пользователей.

Создание контейнера «Организационной Единицы» возможен через несколько вариантов:

•Оснастка Active Directory Users & Computers на контролере;

•Через RSAT на Выделенной Рабочей Станции Управления»;

•Оснастка PowerShell;



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



Организационная единица (OU) «Company_Computers» – включает в себя разделение по подгруппам: «VIP_Computers» – содержит компьютеры руководителей, «Adm_Computers» – компьютеры ИТ департамента и «All_computers» – все компьютеры организации. Последняя может содержать в себе подгруппы: «DA_Computers» и «Desktop_Computers».

Схожая структура применена для объектов групп, ИТ сервисов и пользователей. Данное разделение позволяет применять различные групповые политики и доступы. Так для примера, сервис RDS может включать в себя две подгруппы: SH и GW. Внутри данных объектов находятся сервера, соответствующего ИТ сервиса. Доступ к верхнему объекту на редактирование, ограничен только для роли администраторов ИТ сервиса RDS. Сервера «Session Hosts» и «Gateway, Broker» могут располагаться в различных подсетях и требовать различные групповые политики. Те же принципы применяются для групп и пользователей. Так подгруппа «VIP_Users» может содержать учетные записи руководства, сброс паролей которых не может быть выполнен группой Поддержки Пользователей. Группа «Business_Groups» может содержать группы с правами чтения, записи и т п для общих папок департаментов, расположенных на файловом сервере, группы доступов для бизнеса приложений и т п. Группа «Technical_Groups» может использоваться для разграничения прав сотрудников ИТ департамента. В общем виде для сервиса может быть использована группа «администраторов» ИТ сервиса, группа «только для чтения», специфические группы ИТ сервиса. В случае использования разделенных доменов или леса, филиалов и т п, состав и структура каталога может быть аналогична.


Local Administrator Password Solution (LAPS) настройка через GPO

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

Скачиваем LAPS (текущая версия 7.5). Пакет состоит из двух частей:

•AdmPwd GPO Extension – исполняемая часть LAPS

•Модули управления:

Fat Client UI – утилита для просмотра паролей;

PowerShell Module – модуль для управления LAPS;

GPO Editor Templates – административные шаблоны;


Открываем оснастку Group Policy Management на контроллере домена.

Создаем новую групповую политику: LAPS-INSTALL