Глава 1. Основы Active Directory

Пандемия COVID-19 усилила наши человеческие чувства неуверенности в отношении физического и психического здоровья, состоятельности, семейных и социальных отношений, а также работы. Большинство испытали в своей жизни долговременные последствия, о которых даже и не подозревали. Некоторые из этих чрезычайных эффектов способны на годы затянуть наши жизни назад или вперёд. Сдвиг системы понятий, подгоняемый этой пандемией, заключается в ускоренной цифровой трансформации общества. Правила изоляции и возросший спрос на безопасную удалённую работу вытолкнули некоторые автономные ("offline") предприятия и отрасли в сферу Интернета ("online") раньше чем мы предполагали. Моя девятилетняя дочь сейчас берёт уроки игры на фортепиано через встречи в Zoom. Я никогда не предполагал, что будет практичным изучать какой- то инструмент через Интернет, но я ошибался. В самом начале пандемии финансовый сектор не был готов к принятию культуры работы из дома. Однако недавний опрос, проведённый Deloitte подтвердил, что почти три четверти (70%) сотрудников, трудящихся в финансовой сфере услуг положительно оценивают свой опыт работы на дому (Источник). Twilio это ведущая платформа облачных коммуникаций и взаимодействий с клиентами. Не так давно они опросили более 2 500 руководителей предприятий в Соединённых Штатах, Великобритании, Германии, Австралии, Франции, Испании, Италии, Японии и Сингапуре чтобы оценить их взгляды на цифровую трансформацию в результате COVID-19. Согласно результатам этого опроса, "97% руководителей предприятий считают, что пандемия ускорила цифровую трансформацию их компаний" (Источник). McKinsey & Company это международная американская консалтинговая компания по вопросам управления. Недавно они провели опрос среди 900 руководителей высшего звена и старших менеджеров, представляющих весь спектр регионов, отраслей, размеров компаний и функциональных особенностей. Согласно их исследованию, респонденты подтвердили, что их компании действовали в 20 - 25 раз быстрее, чем ожидалось, при реализации стратегий цифровой трансформации. Что касается удалённой работы, компании продвигались здесь в 40 раз быстрее.

Источник

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

Наступило их "время". Именно это было одним и тем же для многих компаний при их приспособлению к такому повсеместному характеру действий. Когда "время" начало стоить денег или когда "время" начинает влиять на продажи, собственно производственный процесс, поставки или производительность труда, у нас нет времени чтобы оценивать все за и против. У нас нет времени на возведение фундамента. Придётся рискнуть. Придётся нарушать установленные правила. Когда мы, люди, спешим, мы склонны совершать ошибки. Некоторые из этих ошибок открыли возможности для киберпреступников на протяжении 2020:

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

Идентификационные сведения это новый периметр. Имеющаяся модель защиты периметра больше не действует против современных угроз идентификации. Управление идентификационными данными и доступом это краеугольный камень цифровой трансформации. Согласно проведённому Ping Identity исследованию, 90% руководителей ИТ полагают, что управление идентификацией и доступом это ключевой фактор цифровой трансформации (Источник). Решения по управлению идентификацией и доступом зависят от служб каталогов для хранения / извлечения данных, относящихся к удостоверениям пользователей, таких как Active Directory Windows. Active Directory Windows была впервые выпущена 17 февраля 2000 г. и вот уже 21 год помогает организациям управлять идентификацией. Но теперь у нас есть новый набор проблем.

Согласно отчёту Предсказаний Кибербезопасности FireEye 2021 года (Источник), около 95% компаний обладают каким- то видом присутствия в облачных решениях.

Поэтому основные вопросы таковы:

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

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

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

Когда я впервые регистрировался своим терапевтом, он проверил форму идентификации и заверил мою личность. Затем он выдал мне уникальный номер NHS {National Health Service в Великобритании}; по этому уникальному номеру будет распознавать меня их вычислительная система. Когда я подписался на свой широкополосный интернет, поставщик услуги попросил меня установить некий уникальный пароль. Этот пароль будет применяться для подтверждения моей уникальности при их вызове для поддержки в следующий раз. Различные системы, приложения и службы применяют различные методы для подтверждения чьей- то идентичности. Такие системы пользуются базами данных и каталогами для хранения тех сведений, которые относятся к цифровым идентификациям.

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

Прежде чем мы рассмторим основы Active Directory, я полагаю, лучше поделиться некоторыми тенденциями в области управления идентификацией и доступом, которые ждут нас в 2021 году и посмотреть как Active Directory вписывется в эту картину.

В своих предыдущих двух разделах я несколько раз применял слова "управление идентификацией и доступом" (Identity and Access Management - IAM). Что именно означает управление идентификацией и доступом? Управление идентификацией и доступом это решение, примеряемое для регулирования собственно "жизненным циклом доступа" некого пользователя внутри какой- то организации. Основная роль этого состоит в том, чтобы гарантировать что верная персона обладает верными правами к верным ресурсам о верной причине. Решения управления идентичностью и доступом в целом обладают четырьмя компонентами.

Согласно приведёному выше определению, Active Directory не является системой управления идентификацией и доступом. Однако он играет важную роль в системе управления идентификацией и доступом. Такой элемент каталога системы управления идентификации и доступа не представляется только Active Directory Microsoft, это может быть любой каталог. Однако мы знаем, что наиболее широко применяемая служба каталога на рынке это Active Directory Microsoft. Успех решения IAM зависит от четырёх упомянутых мной ранее столпов. Как я пояснил в своём введении, IAM это ключевой фактор цифровой трансформации. Итак, каково же будущее IAM в 2021 и последующем?

Для большинства из нас этот год прошёл как американские горки. В связи с пандемией COVID-19 неопределённость повсеместно окружает нас. Это во многом изменило наше будущее. Возможно, вам пришлось реорганизовать свои приоритеты и отодвинуть на годы многие из своих планов. Вдобавок ко всему, нам пришлось много чего делать для поддержания своего психического здоровья. Киберпреступники - тоже люди. Таким образом, можно предположить, что пандемия также нанесла удар и по ним. Но похоже, что это не так. Кажется, они нашли возможности даже на протяжении пандемии. Вместо сокращения киберпреступности мы наблюдаем гигантский рост числа происшествий. ФБР заявляет о 300% росте киберпреступности в 2020 (Источник). Когда речь идёт об отрасли здравоохранения, мы ожидаем некого уважения, поскольку оно выступает спасательным кругом во время текущей пандемии. Однако для преступников это всего лишь дополнительная возможность. Отчёт Verizon О расследовании утечек данных (Источник) подтверждает рост утечек сведений в отрасли здравоохранения на 58% и большинство из этого было финансово мотивированными атаками. Кроме того, такие атаки день ото дня становятся всё более изощрёнными. Последняя атака Nobelium - отличный пример этого. SolarWinds Inc. это компания- разработчик программного обеспечения, которая создаёт решения наблюдения и управления за сетевыми устройствами, серверами, системами хранения и приложениями. 12 декабря 2020 года они объявили о сложной атаке на свою платформу Orion. Она затронула 18 000 клиентов SolarWinds, включая министерства торговли, обороны, энергетики, национальной безопасности, здравоохранения и государственного департамента США. Эта атака стала одним из крупнейших киберинцидентов, свидетелем которых стала общественность за последние годы. По данным Microsoft (Источник), 44% жертв этой атаки находились в ИТ отрасли и 18% были государственными учреждениями. Эта атака стала важной вехой в киберпреступности по следующим причинам:

Эта конкретная атака научила нас нескольким вещам:

Все атаки обладают чем- то схожим. Все они происходят после некоторого вида "доступа" к системам вначале.

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

Однако, в борьбе с киберпреступностью организациям приходится преодолевать и прочие проблемы. Согласно опубликованному (ISC)² Отчёту о корпоративных командах ИТ безопасности COVID-19, организации сталкиваются со следующими вызовами:

У нас уже имеется гигантская нехватка навыков в кибербезопасности. COVID-19 оказал негативное финансовое воздействие на некоторые предприятия. По этой причине у компаний в ближайшие годы возникнут трудности с финансирование проектов кибербезопасности и развитием навыков кибербезопасности.

о причине пандемии COVID-19 у многих компаний не было возможности позволять их сотрудникам работать из дома. Мы не можем защищать корпоративные сведения и идентификацию, появляющиеся в незащищённых домашних сетевых средах применяя те же самые подходы безопасности, которые мы используем с закрытых сетевых средах. Это создало огромные возможности для киберпреступников, поскольку большинство компаний не обладают временем для оценки значения тех рисков, которые связаны с удалённой работой и заранее подготовиться. Большинство компаний всё ещё "играют в догонялки" с рисками кибербезопасности, относящиеся к удалённой работе. Согласно отчёту IBM, удалённая работа увеличила среднюю стоимость утечки данных на $137 000. Согласно проведённому Malwarebytes опросу, 20% их респондентов сказали что они столкнулись со взломами безопасности в результате удалённого работника. 44% подтвердили что они не проводили никакого обучения кибербезопасности для сотрудников, посвящённых потенциальным угрозам при работе из дома.

Что занимательно, это исследование также подтвердило, что лишь 47% персонала знает о рекомендациях кибербезопасности при работе на дому.

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

Дополнительные сведения относительно атаки Nobelium доступны в следующих опубликованных Microsoft статьях:

Для усиления установленных в модели Нулевого доверия принципов, нам требуются решения IAM, такие как Azure Active Directory. На основании тех уроков, которые мы извлекли из атак, подобных Nobelium, всё больше и больше компаний начнут следовать этому подходу безопасности в последующие несколько лет.

Ещё в 2004 году, на Конференции по безопасности RSA (Сан франциско), Билл Гейтс сказал: "Несомненно, что со временем люди всё меньше и меньше будут полагаться на пароли. Люди применяют один и тот же пароль для различных систем, они записывают их и они просто не справятся ни с чем тем, что они на самом деле хотят сделать безопасным". С годами это утверждение подтверждалось снова и снова. Пароли больше не безопасны. Пароли взламываются. Национальный центр кибербезопасности Великобритании провёл исследование проверки утраченных в результате утечек данных паролей. Согласно нему, пароль с применением номер один это "123456".

Итак, раз пароли не работают, что ещё мы можем предпринять для усиления безопасности в процессе аутентификации Многофакторная аутентификация способна добавить в наш процесс аутентификации дополнительный уровень. Это может быть некий код SMS, или уведомление телефонного приложения для дальнейшего подтверждения подлинности запроса на доступ. На рынке существует множество разнообразных продуктов MFA (Multi-factor authentication). Тем не менее, MFA не отменяет требования к паролям.

Но теперь у нас имеется некий вариант замены традиционной аутентификации аутентификацией без пароля. Именно она, в основном, заменяет пароли на биометрию, PIN, сертификаты и ключи безопасности.

Стандартом для аутентификации без пароля выступает открытый стандарт Fast Identity Online (FIDO). Он делает возможным аутентификацию в системе при помощи некого внешнего ключа безопасности, встроенного в какое- то устройство.

Windows Hello for Business и Azure Active Directory поддерживают аутентификацию без пароля на основании ключей безопасности FIDO2.

FIDO2 это третий стандарт, выпущенный Альянсом FIDO. FIDO2 составлен из Client to Authenticator Protocol (CTAPBold, Протокола от клиента к аутентификатору) и стандарту W3C WebAuthn. Когда мы пользуемся ключами безопасности FIDO2 для аутентификации:

Дополнительные сведения относительно WebAuth доступны по следующим ссылкам:

За последние несколько лет, аутентификация без пароля значительно выросла и будет продолжать это в последующие года. Согласно Gartner, "к 2022 году Gartner прогнозирует, что 60% крупных и глобальных корпораций и 90% компаний среднего размера будут реализовывать методы без пароля в более чем 50% случаев применения - по сравнению с 5% в 2018 году". Azure AD теперь поддерживает аутентификацию без пароля с применением ключей FIDO2. Именно её можно применять для аутентификации в облачных ресурсах, а также в локальных ресурсах. Я уже писал несколько статей о настройке ключей FIDO2. Вы можете ознакомиться с ними здесь:

Step-by-step guide: Azure AD password-less sign-in using FIDO2 security keys.

Step-by-step guide: Enable Windows 10 password-less authentication with FIDO2 security keys (Azure AD + Microsoft Intune).

До сих пор в этой главе я несколько раз применял термин "цифровая идентификация". Цифровая идентификация это некий вид идентификации, которая может применяться для распознавания персоны при помощи цифровых каналов. Когда я регистрируюсь в своей учётной записи LinkedIn, я применяю имя пользователя и пароль. Эти имя пользователя и пароль были созданы когда я подписался на LinkedIn. Когда я регистрируюсь в службе интернет- портала своего банка, я применяю другие имя пользователя и пароль. Обе эти учётные записи представляют мою идентификацию. Вместо применения множества цифровых идентификаций, что если мы можем согласиться на один цифровой идентификатор, который сделает для нас доступным применение множества интернет- служб, таких как здравоохранение, банковское обслуживание, путешествия и досуг. Это снизит имеющуюся сложность доказательства идентичности. Согласно исследованию, выполненному McKinsey Digital, один миллиард людей в мире не обладает никакой законной формой идентификатора для доказательства своей идентичности. Представьте себе те возможности, которые они упускают в своей повседневной жизни.

Это может препятствовать им в получении общедоступных услуг, таких как образование и здравоохранение, это может повлиять на их права и может оказать воздействие на их близких. По причине пандемии COVID-19 всё больше и больше стран находятся в процессе принятия понятия единой цифровой идентификации. Правительство Великобритании уже создало основу для цифровой идентификации (Источник). Согласно данным правительства Великобритании, стоимость подтверждения идентификации вручную автономно может составлять £3.3 миллиарда в год. Правительство полагает, что "Такая новая цифровая идентификация не только упростит жизнь людей, но также и придаст ускорение цифровой экономике страны на сумму £149 миллиардов путём создания новых возможностей для инноваций, делая возможными более гладкие, более экономичные и более безопасные интернет транзакции и сохраняя компаниям деньги и время" (Источник). США недавно приняли Закон об улучшении цифровой идентификации 2020 года (Источник) для установки общегосударственного подхода к улучшению цифровой идентификации. DIACC (Digital ID & Authentication Council of Canada, Совет по цифровым идентификаторам и аутентификации Канады) создал Всеканадскую структуру доверия (Источник), которая определяет те критерии соответствия, которые необходимы для экосистемы цифровой идентификации и поясняет как будут применяться цифровые идентификаторы по все Канаде.

Как мы уже видели из вышесказанного, страны по всему миру уже работают над урегулированием цифровой идентификации. На этом пути также свою роль должно сыграть и IAM. Будут утверждаться новые законы, относящиеся к цифровой идентификации. Будут устанавливаться новые правила для их соблюдения. Организации будут обязаны найти действенный способ управления такими новыми цифровыми идентификациями. Что ещё более важно, нам необходима защита от кражи персональных данных. Мы не можем осуществлять её применяя исключительно наследуемую службу каталогов. Для управления полным жизненным циклом цифровой идентификацией нам нужны решения IAM.

Мы отчётливо видим, что Урправение идентификацией и доступом (IAM) ожидают непростые времена. Мы не способны говорить об IAM без обсуждения служб каталогов. Именно по этой причине, такая локальная служба каталогов, как Active Directory Windows, по- прежнему имеет первостепенной значение.

Доменные Службы Active Directory (AD DS, Active Directory Domain Services) впервые были предложены миру в Windows Server 2000. На протяжении более чем 21 года, AD DS помогали организациям управлять цифровой идентификацией.

Тем не менее, современные требования управления доступом усложняются. Теперь компании всё больше и больше применяют облачные службы. Большинство рабочего персонала всё ещё работает из дома и выполняет доступ к чувствительным корпоративным данным через не безопасные сетевые среды. Большинство производителей программного обеспечения перемещаются в сторону модели SaaS (Software as a Service, Программного обеспечения в виде службы). Киберпреступность взмывает ввысь ракетой и на кон поставлена защита персональных данных. Для решения этих проблем нам требуется выйти за рамки наследуемого управления доступом. Azure Active Directory это основанный на облачном решении, управляемый, поставщик IDaaS (Identity as a Service, Идентификации в качестве службы), который способен предоставлять безопасности мирового уровня, строгую аутентификацию и бесшовное сотрудничество. Azure Active Directory способен охватывать локальную идентификацию в своё облачное решение и предоставлять единую платформу аутентификации и авторизации для всех ресурсов, причём вне зависимости от местоположения. Это носит название гибридной идентификации.

Под Azure Active Directory обычно подразумевают некую облачную версию AD DS, однако это совершенно не так. Это подобно сопоставлению iPhone с телефоном Samsung. Оба способны применяться для выполнения вызовов, получения фотографий, просмотра видео и тому подобного. Некоторые прикладные приложения также доступны в обоих типах устройств. Однако вы не можете заменить один из них другим, поскольку каждый из них обладает уникальностью. То же самое и относительно AD DS и Azure Active Directory. Они обладают как своими схожестью, так и отличиями. Давайте забежим вперёд и сопоставим оба продукта на основе различных областей действия:

Таблица 1-1. Сопоставление AD DS и Azure Active Directory

Область действия	Доменная служба Active Directory	Azure Active Directory
Предоставление пользователя	Учётные записи пользователей могут создаваться вручную илипри помощи сторонних решений управления и автоматизации AD, например, Adaxes, для автоматизации соответствующего процесса предоставления пользователя.	У нас имеется возможность синхронизировать учётные записи пользователей с локальным Active Directory при помощи Azure AD Connect. Также мы можем вручную или автоматически, применяя приложения SaaS с использованием SCIM, создавать пользователей только облачного решения.
Участие в группах	Администраторам приходится управлять членством в гуппах вручную или для автоматического управления участием в группах применять сценарии PowerShell, либо сторонние инструменты, такие как Adaxes.	Поддерживает динамическое участие в группах.
Управление привилегированным доступом	Active Directory не поддерживает естественным образом Управление привилегированным доступом. Для управления привилегированным доступам (участие в чувствительных группах и рабочих потоках) нам приходится использовать такие решения как Microsoft Identity Manager или Adaxes.	Для предоставления всего- лишь- на- время (JIT, just-in-time) доступа на основании рабочео потока к привилегированным ролям можно применять Azure AD Privileged Identity Management (PIM).
Руководство идентификацией (Identity Governance)	Active Directory не поддерживает естественным образом руководство идентификацией. Для просмотра полномочий, участия в группах и поведения доступа нам приходится применять сценарии PowerShell и сторонние решения.	Чтобы быть уверенным в том, что правильные люди имеют правильный доступ к правильным ресурсам в правильное время пожно пользоваться Azure Active Directory Identity Governance.
Расширенная аутентификация	Active Directory не обладает встроенными MFA (многофакторной аутентификацией) или аутентификацией без пароля. У нас имеется возможность интеграции с Active Directory Azure MFA или с иным сторонним решением MFA. При помощи Windows Hello for Business (в гибридных установках) мы можем включать аутентификацию без пароля.	Azure MFA бесплатна для Azure AD и может применяться для улучшения безопасности в несколько кликов. Azure AD к тому же поддерживает аутентификацию без пароля на основе стандартов FIDO2.
Оценка рисков доступа	Active Directory не обладает возможностями оценки рисков доступа на основании местоположения пользователя, поведения подписи, рисков учётной записи пользователя и тому подобного.	Azure AD Conditional Access способен оценивать риски пользователя на основании многих настроек политик, а также разрешать или запрещать доступ.
Интеграция с приложениями SaaS	Active Directory имеет возможность интеграции с приложениями SaaS при помощи Active Directory Federation Service (AD FS).	Azure AD поддерживает непосредственную интеграцию с приложениями SaaS, которые поддерживают аутентификацию OAuth2, SAML и WS-*.
Наследуемые прикладные приложения	Active Directory сопровождает интеграцию с прикладными приложениями, основанными на LDAP или интегрированной с Windows аутентификацией.	Azure AD способен предоставлять современную практику аутентификации для локальных наследуемых прикладных приложений при помощи посредника (прокси) приложения Azure AD.
Внешняя идентификация	Для сотрудничества с внешними идентификациями Active Directory пользуется федеративными доверительными отношениями, доверительными отношениями леса и доверительными отношениями домена. Это привносит перекрытие управления и риски безопасности.	Azure AD B2B упрощает интеграцию с внешними идентификациями. Он не требует изменений на уровне инфраструктуры.
Управление устройством Windows	Групповая политика позволяет вам управлять состоянием устройства Windows на весьма гранулированном уровне. Мы запросто можем вводить стандарты для инкорпорирования устройств без дополнительных инструментов или служб.	Оконечные точки Azure AD Join могут управляться при помощи Microsoft Endpoint Manager.
Управление мобильным устройством	Active Directory не поддерживает естественным образом упралвение мобильными устройствами. Для осуществления этого нам требуются сторонние инструменты.	Интегрированный с Microsoft Endpoint Manager Azure AD имеет возможность управления мобильными устройствами.

Как мы можем видеть из приведённого выше сопоставления, мы не можем просто заменить одно решение, применяя другое. Однако гибридная идентификация с применением Azure AD позволяет организациям переделывать традиционное управление идентификацией и готовить себя к эре облачных решений. Итак, самый большой вопрос состоит в том, оставляет ли будущее место для Доменной службы Active Directory на этом пути?

Для большинства компаний путешествие в облачные решения начинается с SaaS приложений. В большинстве случаев это Office 365. И это не только Microsoft; в целом, большинство производителей программного обеспечения преобразовывают свои службы в соответствующую модель SaaS. Приложения SaaS применяют различные виды аутентификации. Если организация заинтересована в практике применения с одной подписью, у нас имеются два варианта. Мы можем установить ADFS (Active Directory Federation Service) и настроить аутентификацию на основе SAML для предоставления SSO. Однако это привносит дополнительные затраты и административные накладные расходы. Вместо этого мы можем просто синхронизировать локальную идентификацию с Azure Active Directory и для аутентификации интегрировать приложение SaaS с Azure Active Directory. Этот метод сулит несколько преимуществ:

Как вы можете видеть, это не означает что нам требуется избавляться от локального Active Directory для применения Azure Active Directory и его функциональных возможностей. Они оба способны работать бок о бок для предоставления пользователям единой практики доступа. Active Directory был топовым выбором в отрасли на протяжении 21 года и именно он наиболее широко применяемой службой каталога. Если мы способны переместить всё в облачное решение, да, это даст преимущества, но не практично и не так просто, как звучит. У нас могут иметься правила, которые нам приходится соблюдать. Мы можем обладать наследуемыми бизнес приложениями, которые невозможно сдвинуть в имеющиеся облачные службы. Мы ожем обладать навыками и пробелы в безопасности чтобы сливаться с облачными технологиями. Следовательно, гибридная идентификация не будет краткосрочным решением для большинства компаний. Большинство компаний предпочитает гибридную идентификацию вместо метода исключительно на облачном решении по причине её гибкости.

В атаке Nobelium киберпреступники сдвинулись в сторону после первоначального прорыва безопасности и получили контроль над ADFS (Active Directory Federation Services).

Это дало возможность злоумышленникам подделать маркеры SAML и получить доступ к облачным службам. Безопасность это одно из ключевых направлений для общедоступных облачных служб. Для защиты идентификации и данных в облачных решениях существуют доступными для выбора пользователями различные службы и функциональные возможности. В последнее время наметился некий рост атак в общедоступных облачных решениях, однако соотношение их успеха всё ещё относительно низкое по сравнению с атаками на локальные решения. Атака Nobelium подтверждает, что киберпреступники сейчас имеют целью локальные службы для получения доступа к облачным службам. Защита идентификации это совместная ответственность между Поставщиками облачных решений (CSP, cloud service providers) и пользователями облачных решений. Таким образом, именно сами пользователи несут ответственность за защиту от атак локальной идентификации. Даже в случае такой атаки, для защиты облачных служб требуется предотвращение некоторого бокового передвижения. Согласно Отчёту об угрозах облачным решениям Oracle и KPMG, у 92% респондентов имелся пробел в готовности к безопасности облачного решения. Это показывает, что мы не способны защитить своё облачное решение если мы не можем защищать некую локальную среду.

При гибридной идентификации Доменная служба Active Directory отвечает за управление и защиту локальных идентификаций. Имеется множество моментов, которые мы можем предпринять для защиты локальных идентификаций от изощрённых атак, подобных Nobelium. Мы можем предотвращать боковые движения вводя модель уровней самого Active Directory. Мы можем применять для стандартизации состояния имеющихся устройств и пользователей Групповые политики. Мы мжем ограничивать появление привилегированных учётных записей на Рабочие станции с привилегированным доступом (PAW, privileged access workstations). Когда мы находимся в некой гибридной среде, мы можем и дальше применять базирующиеся в облаке решения, такие как Microsoft Defender for Identity, Microsoft Defender for Endpoint и Azure Sentinel для выявления потенциальных рисков безопасности в такой среде и решать их активным образом.

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

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

Приводимая ниже схема отображает этот процесс:

Когда мы обдумаем эту процедуру, мы обнаруживаем что он содержит функции службы каталогов:

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

Всякая организация имеет свою собственную организационную структуру. Это наиболее распространённый способ для группирования ролей, средств и обязанностей разнообразных подразделений; например, продаж, ИТ, производства и гарантии качества. Помимо навыков и знаний, сотрудники применяют ресурсы компании, такие как приложения и аппаратные устройства для достижения своих целей. Для действенного применения этих ресурсов важно, там где требуется, обладать неким видом контроля доступа. Эти ресурсы должны быть доступны для необходимых пользователей в необходимое время. Это очень просто, когда все сведения о пользователях, приложениях и ресурсах записаны в централизованном репозитории, который применяет для управления ресурсами аутентификацию и авторизацию. Именно это и составляет основные характеристики некой служб в каталога.

Различные поставщики служб имеют различные службы каталога; например, служба каталога Novell, служба каталога Oracle, а также служба каталога Red Hat. Однако служба Active Directory Microsoft в нашей отрасли является наиболее часто применяемой.

Active Directory хранит сведения цифровой идентификации пользователей, приложений и ресурсов в некой базе данных со множеством хозяев (multi-master). Эта база данных носит название ntds.dit и она основывается на механизме базы данных JET (Joint Engine Technology). Все сведения в этой базе данных могут изменяться при помощи любого альтернативного контроллера домена. Такая база данных Active Directory способна хранить почти 2 миллиарда объектов. Пользователи могут применять хранящиеся в Active Directory данные идентификации для доступа к ресурсам из любого места в имеющейся сетевой среде. Администраторы могут управлять установками аутентификации и авторизации цифровой идентификации определённой организации из централизованного местоположения. В отсутствии служб каталога идентификация дублировалась бы по различным системам, что добавляло бы накладные расходы для управления имеющимися сведениями.

Имеются организации, которые используют единственный контроллер домена. Но когда дело касается требований сложных компаний, например офисов отделений и высокой доступности, требуется множество контроллеров (мы намерены рассмотреть размещение контроллеров домена в Главе 11, Службы Active Directory Часть 01). Когда цифровая идентификация управляется из некой централизованной системы, важно чтобы все контроллеры домена были бы осведомлены о тех изменениях, которые производятся в общей базе данных Active Directory. Допустим, некая пользователь, Джейн, из подразделения продаж, забыла свой пароль и просит своё подразделение ИТ выполнить его сброс.

Через 30 минут она намерена работать из своего офиса отделения, расположенного в другом городе. Соответствующий администратор ИТ сбрасывает её пароль в контроллере домена самой штаб- квартиры, DC01. Для того чтобы иметь успешную регистрацию из офиса отделения, это изменение должно быть реплицировано в соответствующий контроллер домена этого офиса отделения, DC05.

Microsoft Active Directory имеет два вида репликаций. Если некий контроллер домена предаёт гласности те изменения, которые выполнены в данном конкретном контроллере домена в соседние контроллеры домена, это имеет название исходящих репликаций (outbound replication). Когда какой- то контроллер домена принимает те изменения, которые преданы гласности соседними контроллерами домена, это именуется входящими репликациями (inbound replication). Сами соединения репликаций (от кого и к кому), а также расписание репликаций могут изменяться на основании требований конкретной компании.

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

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

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

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

Всякий вид базы данных имеет свою собственную структуру, именуемую схемой. Это применимо также и к базе данных Active Directory. Схема Active Directory в основном состоит из двух видов сведений.

На основании значения версии AD, значение чисел определяемых в его схеме классов объектов и атрибутов могут отличаться. Зная установленную схему вы можете изменять или расширять её. Это важно для разработки интегрированных с Active Directory приложений. Microsoft публикует ADSI (Active Directory Service Interfaces) с неким множеством интерфейсов COM (Component Object Model) и их можно применять для доступа к функциям службы Active Directory из поставщиков различных сетевых сред. Разработчики приложений имеют возможность применять их для развития своих приложений интегрированными с Active Directory и публиковать их в соответствующем каталоге. Пользователи способны отыскивать требуемую службу через Active Directory, а приложения могут по мере необходимости получать доступ к объектам Active Directory.

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

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

Компоненты Active Directory можно подразделить на две основные категории:

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

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

Сама логическая структура Active Directory содержит два вида объектов. Объектами могут быть либо объекты контейнеров (container objects) или листовых объектов (leaf objects). Объекты контейнеров могут быть связаны с прочими объектами в имеющейся логической структуре. Листовые объекты выступают в качестве наименьших составляющих в рассматриваемой логической структуре. Они не будут иметь никаких иных связанных с ними объектов потомков.

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

Леса

Амазония является самым большим в мире дождевым лесом. В ней существует множество разнообразных видов животных и там проживает более 400 племён. Каждый из этих видов животных отличается друг от друга. Рептилии, млекопитающие, змеи и рыбы, все они обладают отличительными характеристиками и можем группировать все их в соответствии с их свойствами. Живущие в этих лесах племена также имеют свои собственные языки, культуры и границы. Но все эти животные и племена совместно проживают в одном лесу. Они используют пищу, воду и прочие ресурсы дождевых лесов Амазонии для выживания. Сам дождевой лес Амазонии имеет хорошо очерченные границы. Прочие леса в 100 милях от самой Амазонии не именуются Амазонскими дождевыми лесами. Его название и границы уникальны.

Имеющийся в Active Directory лес также может быть описан аналогичным образом. Он представляет некий полный экземпляр Active Directory. Он создаётся из одного или более доменов и деревьев доменов. В своих следующих разделах мы изучим что представляют собой домен и дерево доменов. Всякий домен имеет свои собственные характеристики, границы и ресурсы. Однако в то же самое время все они совместно используют общую логическую структуру, схему и конфигурацию каталога внутри своего леса. Аналогично, племена имеют взаимосвязи с самим лесом и прочими племенами, а домены в определённом лесу Active Directory будут иметь двусторонние доверительные отношения. Различные племена в Амазонии не именуются в честь Амазонии; каждое племя имеет своё собственное название. Аналогично, домены в неком лесу могут содержать любое имя домена:

Важным является самый первый контроллер в развёртывании конкретной службы Active Directory. Когда вы создаёте самый первый домен, он также создаст свой лес. Затем этот первый домен станет корневым доменом своего леса. Некое дерево домена содержит свой собственный корневой домен, однако лес может содержать множество корневых доменов.

В нашей предыдущей диаграмме, Rebeladmin Corp. является поставщиком ИТ решений. rebeladmin.com выступает корневым доменом леса. Он имеет ещё две компании: одной является Rebeladmin IT со своим именем домена rebeladminit.com и она предоставляет управляемые ИТ службы. Другой компанией выступает My training с именем домена mytraining.ca, причём она предоставляет ИТ обучение для профессионалов. rebeladminit.com и mytraining.ca оба являются корневыми доменами в своих собственных деревьях доменов. Оба домена в этом лесу будут доверять друг другу при помощи двустороннего транзитивного доверия (two-way transitive trust).

После того как Microsoft выпускает новую версию службы Active Directory, новые свойства ограничены уровнем функциональности конкретных леса и домена. Если вы желаете применять свойства уровня леса Службы доменов Active Directory 2016, ваш лес каталога Active Directory обязан использовать функциональный уровень леса Windows Server 2016. Вплоть до Windows Server 2012 R2 обновления функционального уровня леса были односторонними. Теперь имеется возможность выполнять обратный откат в случае необходимости. Сам уровень функциональности леса зависит от самой старой версии контроллера домена в имеющейся сетевой среде.

Например, если в имеющемся лесу уровнем функциональности является Windows Server 2008, это позволяет нам устанавливать внутри такого леса определённый контроллер домена с операционной системой Windows Server 2022. Однако это не означает что он может применять свойства, предоставляемые Службой каталога Windows Server 2022 пока не будут обновлены уровни функциональности его домена и леса. Если вы обновите уровень функциональности его леса до Windows Server 2016, тогда вы сможете получить контроллеры домена исполняющими минимально только Windows Server 2022.

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

Таблица 1-2. ОС, поддерживающие уровень функциональности

Уровень функциональности	Операционная система Доменного контроллера
Windows Server 2016	Windows Server 2022 Windows Server 2019 Windows Server 2016
Windows Server 2012R2	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2
Windows Server 2012	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012
Windows Server 2008R2	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2
Windows Server 2008	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows Server 2008

Домены

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

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

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

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

Деревья доменов

Некое дерево доменов (domain tree) является коллекцией доменов, которая отражает организационную структуру. Мои родители и я ограничены взаимосвязью предок- потомок. Это очевидным образом отличается от прочих видов взаимосвязей. Аналогично домены внутри заданного дерева домена имеют взаимосвязь предок- потомок. Самый первый домен в выбранном дереве домена именуется родительским (parent) доменом. он также является корневым доменом (root domain). Все прочие домены в этом дереве домена имеют название доменов потомков (child). В неком дереве домена будет иметься лишь один родительский домен.

В части документации домены потомков (дочерние домены) также именуются подчинёнными доменами subdomains. Когда мы имеем дело с доменами Интернета, порой требуется создание некого дополнительного заполнителя (placeholder), какого- то подчинённого URL. К примеру, rebeladmin.com выступает тем именем домена, которое применяется для значения вебсайта и организации, необходимого для размещения другого вебсайта чтобы сопровождать запросы поддержки. Однако это требует применение того же самого непрерывного пространства имён. Для выполнения этого мы можем создать другую папку в своём корневом домене и сделать запись DNS (Domain Name System) для соответствующего подчинённого домена: support.rebeladmin.com:

Некий лес Active Directory может содержать не непрерывные имена доменов. Однако внутри конкретного дерева доменов они будут совместно использовать одно и то же самое непрерывное пространство имён. В нашем предыдущем примере rebeladmin.com выступает родительским доменом для общего дерева доменов. Он также имеет два дочерних домена, it.rebeladmin.com и sales.rebeladmin.com. Как вы можете видеть, они совместно используют одно и то же пространство имён rebeladmin.com. Аналогично, при переходе вниз на следующий уровень в заданном дереве доменов они совместно используют пространство имён с предыдущего уровня. Всякий дочерний домен поддерживает свой собственный раздел домена.

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

Организационные подразделения

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

Не будет ли лучшим способом группировать эти объекты внутри своего домена? Именно здесь вступают в действие организационные единицы (organizational units). Организационные единиц (подразделения) помогают группировать объекты меньшего масштаба внутри их домена. Наиболее общий способ состоит в группировании воедино объектов которые имеют аналогичные безопасность и административные требования. Например, в подразделении продаж имеется более 50 пользователей. Подразделение продаж использует общие разделяемые папки и принтеры. Их требования безопасности для данных и сетевой среды аналогичны. По этой причине мы можем создать некую организационную единицу (OU, organizational unit) с названием sales и сгруппировать в ней всех пользователей из подразделения продаж. Теперь мы можем применять политики безопасности на полученном уровне OU вместо уровня конкретного пользователя.

При развёртывании контроллера домена создаётся некая структура OU по умолчанию для сегментации всех наиболее распространённых типов объектов, таких как пользователи, компьютеры и контроллеры домены. Имеющиеся администраторы в случае необходимости способны добавлять, перемещать и удалять некую OU.

После того как некий объект назначен в какую- то OU, он наследует те настройки безопасности и разрешения, которые применяются на самом уровне OU. Если те же самые объекты перемещаются в некую иную OU, тогда будут применены соответствующие настройки из этой новой OU и отброшены те установки, которые были применены в своей предыдущей OU. OU также помогают индивидуально делегировать административный контроль для особых задач. Однако имеется возможность создавать администраторов и назначать им управление объектами и ресурсами на неком уровне OU. Для этих администраторов данная OU будет конкретной границей безопасности. Не будет возможности изменять какие бы то ни было прочие объекты вне определённой OU. Позднее в этой книге я буду пояснять делегирование администрирования. OU выступают контейнерами объектов. Их можно ассоциировать с аналогичными или иными объектами. Также как и предки- потомки доменов, OU также способны содержать дочерние OU. Это также встроенные организационные единицы (nested organization units).

OU также могут содержать такие типы объектов как пользователи, группы, контакты, компьютеры, организационные единицы и принтеры:

В нашем предыдущем примере Rebeladmin Corp. имела некое Sales department (подразделение продаж). В имеющейся иерархии OU, самый первый момент, который необходимо предпринять, это создать некую OU с названием Sales department. Все имеющиеся региональные офисы имеют свои собственные подразделения продаж. Большая часть установленных требований безопасности и администрирования для объектов в таких подразделениях продаж те же самые. Однако создание OU на основании географических областей позволит администраторам домена делегировать управление таким объектам индивидуалов или групп в имеющиеся региональные офисы. Кроме того, если требуется применить конкретную политику к какому- то подразделению продаж регионального офиса, она может быть применена на подходящем уровне OU, вместо тог чтобы применять её ко всем Sales department по имеющимся офисам отделений. По умолчанию все устанавливаемые OU наследуют те полномочия, которые применяются к их родительскому OU.

В нашем предыдущем примере те индивидуалы и группы, которые имеют полномочия управления объектами Sales department, по умолчанию имеют контроль над всеми объектами в OU Europe, Asia и North America. Устанавливаемая иерархия OU является независимой. Она не намерена оказывать воздействие на прочую иерархию OU домена. Определённая OU к тому же может содержать объекты лишь из того же самого домена.

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

Контроллеры доменов

Контроллером домена является компьютер, который работает под управлением операционной системы Windows Server и содержит соответствующую роль Служб домена Active Directory (AD DS). Это может быть либо физический, либо виртуальный сервер.

Конкретно выбранный контроллер домена содержит раздел своего каталога, который будет реплицироваться во все прочие контроллеры в том же самом домене. Домен может обладать любым числом контроллеров домена. Общее число контроллеров зависит от размера самой компании, географического размещения и сетевой сегментации. В Windows NT он применял множество контроллеров домена, но он поддерживал схему с единственным хозяином. Это означало, что изменения каталога могли выполняться лишь с определённого контроллера домена. начиная с Windows 2000 имелась поддержка для режима со множеством хозяев. Любые изменения уровня объектов, выполненные в одном контроллере домена будут реплицированы во все прочие контроллеры домена (относящиеся к службе домена). При этом некоторые изменения относящихся к самой Active Directory ролей могут модифицироваться специально выделенным владельцем роли хозяина операций (ролей FSMO, Flexible single-master operations - ролей гибких операций с единственным хозяином).

Сервер глобального каталога

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

Дополнительные сведения относительно серверов глобального каталога и размещения сервера глобального каталога можно обнаружить в Главе 3, Проектирование инфраструктуры Active Directory.

Площадки Active Directory

Площадки (сайты) Active Directory определяют некую физическую топологию самой сетевой среды. Площадками могут выступать отдельные здания в сетевой среде кампуса с соответствующим офисом отделения в обособленном городе либо даже в отдельной стране. Например, штаб- квартира Rebeladmin Corp. располагается в Лондоне, Великобритания. В ней запущено несколько контроллеров домена (DC01 и DC02) в пределах её физической сетевой среды. Для своей сети она применяет выделение IP адресов с подсетями 192.168.148.0/24, 10.10.10.0/24 и 172.25.16.0/24. По причине своих требований бизнеса эта компания открыла офисное отделение в Торонто, Канада. Оно получило для запуска свои собственные контроллеры домена (DC03 и DC04), однако логически они пребывают в тех же самых лесу и домене Active Directory. Обе сетевые среды взаимодействуют по выделенной линии.

В Канаде сетевая среда применят подсети IP 10.11.11.0/24 и 172.0.2.0/24:

В приведённой выше диаграмме имеющиеся два офиса могут быть определены в качестве двух площадок. Это обусловлено тем, что очевидно присутствуют два сетевых сегмента. Сама логическая архитектура Active Directory в действительности не учитывает сегментацию физической сетевой среды. Поскольку они расположены в одних и тех же домене и лесе, DC01 и DC04 обязаны реплицировать изменения друг в друга для сопровождения жизнеспособной структуры идентификации.

В целом имеются три преимущества, на которые мы можем указать:

Дополнительные сведения относительно площадок Active Directory доступны в Главе 11, Службы Active Directory - Часть 01.

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

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

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

Точно так же как мы применяем характеристики для описания персон или предметов, объекты Active Directory используют атрибуты для описания своей природы. Например, следующий снимок экрана отображает мастер, который может быть представлен вам при создании некой учётной записи пользователя. В этом мастере на следующем снимке экрана (с левой стороны) атрибутами являются First name, Last name, Full name и User logon name. Точно так же, когда вы создаёте учётную запись какого- то компьютера, это потребует задания атрибута Computer name (в правой части).

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

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

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

Некоторые из этих атрибутов являются обязательными для классов объектов. К примеру, при создании учётной записи пользователя, чтобы продолжить обязательно должно быть предоставлено User logon name (Регистрационное имя пользователя). Тем не менее, если мы не представим Last name (фамилию), мы всё ещё продолжим создание своей учётной записи пользователя. Значения атрибутов также следует предоставлять с приемлемым форматом данных, который определён в имеющейся схеме. Иногда по причине имеющихся рабочих требований организации могут требовать индивидуальные атрибуты. Изменяя схему Active Directory можно добавлять в установленные классы объектов дополнительные атрибуты. Это будет продемонстрировано впоследствии в Главе 7, Управление объектами Active Directory.

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

В некой базе данных Active Directory могут храниться примерно 2 миллиарда объектов. Как она будет уникально идентифицировать все объекты? Всякий раз когда в Active Directory создаётся некий объект, ему будет назначаться одно или два уникальных значения. Если это объект пользователя или группы, они получат GUID (globally unique identifier, глобально уникальный идентификатор) и SID (security identifier, идентификатор безопасности). Величина значения GUID будет сохранена в атрибуте objectGUID каждого объекта, а числовое значение SID будет храниться в атрибуте objectSid каждого объекта.

Для просмотра отображения значений GUID и SID для определённой учётной записи пользователя в его контроллере домена можно запустить такую команду PowerShell:

Get-ADUser username
		

Здесь username следует заменить на реальное имя пользователя искомого участника.

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

ObjectGUID является некий значением из 128- бит и применяется ко всем объектам в Active Directory. Это значение служит не только для конкретного домена Active Directory. Оно также имеет силу и глобально. После того как GUID назначен некому объекту, он будет существовать до тех пор пока сам объект не будет удалён из данного каталога. Изменение или перемещение объектов не будет изменять значение величины самого GUID. Значение атрибута ObjectGUID будет опубликовано для имеющихся серверов глобального каталога. Когда некому приложению в домене требуется отыскать какой- то объект пользователя, наилучшим методом будет запрос при помощи ObjectGUID, ибо он выдаст точный результат.

Величина значения SID для некого объекта уникальна внутри своего домена. Определение значения SID будет изменено если объект его пользователя мигрирует в другой домен. Некое назначенное в одном домене значение SID не будет приниматься другим доменом. Как только некий объект пользователя мигрирует в другой домен, будет выработано новое значение SID. После этого старое значение SID будет сохранено в соответствующем атрибуте sIDHistory.

Этот атрибут может содержать множество значений. Когда конкретная система создаёт некий маркер (ticket) Kerberos для аутентификации пользователя, она будет принимать во внимание некое новое значение SID, а также все прочие SID, перечисляемые в его атрибуте sIDHistory. sIDHistory является важным, в особенности при перестроении Active Directory. Имеющиеся в определённом домене ресурсы принимают решение дать полномочия пользовательской учётной записи или запретить ей доступ на основании ACL (access control list, списка контроля доступа). Этот ACL использует имеющиеся значения SID. Поэтому, когда некий объект перемещается в какой- то другой домен без sIDHistory, он утратит доступ к ресурсам пока не будет изменён сам ACL. Однако когда система при подтверждении некого маркера доступа принимает во внимание sIDHistory, и когда старое значение SID перемещается в свой новый домен, этот пользователь всё ещё будет иметь возможность доступа к тем ресурсам, которые ему назначены.

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

Существует три типа атрибутов именования Active Directory, которые могут применяться при выработке отличительного названия.

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

CN=Dishan Francis,CN=Users,DC=rebeladmin,DC=com
		

Здесь DC=rebeladmin, DC=com представляют название домена, CN=Users представляет текущий контейнер пользователя, и, наконец, CN=Dishan Francis представляет собственно реальное название объекта.

Значением RDN (relative distinguished name, относительного отличительного имени) выступает некое уникальное название внутри его родительского контейнера. Для нашего предыдущего примера значением RDN для приведённого объекта является CN=Dishan Francis. Active Directory допускает вам иметь то же самое RDN для множества объектов внутри своего каталога, но все они обязаны располагаться в различных контейнерах. Не допускается наличие того же самого RDN для присутствующих в одном и том же контейнере объектов.

В нашем предыдущем разделе вы изучили что величина значения SID для определённого объекта не будет изменяться до тех пор, пока он не мигрирует в другой контроллер домена. Изменение значений в самом объекте не изменяет величину значения SID. Однако если изменено значение иерархического пути, будет изменено значение DN (Distinguished Name). Например, если вы переместите некий объект пользователя из одной OU в другую, будет изменено определение значения DN для объекта такого пользователя.

Имеется пять основных ролей сервера Active Directory. Эти роли сгруппированы вместе в обязательной среде Active Directory для установки и настройки ролей сервера Active Directory:

Начиная с Windows Server 2008, эти роли можно устанавливать и настраивать при помощи Диспетчера сервера Windows. Windows Server 2022 придерживается того же самого.

Каждая из этих ролей также может быть установлена и настроена при помощи PowerShell. Для установки ролей сервера Active Directory могут применяться следующие командлеты PowerShell:

Таблица 1-3. Командлеты PowerShell установки ролей сервера Active Directory

Командлеты PowerShell	Описание
Install-WindowsFeature AD-Domain-Services	Этот командлет установит роль AD DS. Обратите внимание, что он устанавливать на соответствующий сервер лишь саму роль AD DS. Это разъясняется дополнительно в Главе 6, Миграция в Active Directory 2022
Install-WindowsFeature AD FS-Federation	Этот командлет установит роль AD FS
Install-WindowsFeature ADLDS	Этот командлет установит роль AD LDS
Install-WindowsFeature ADRMS	Этот командлет установит роль AD RMS. Данная роль имеет две подчинённые роли, которыми являются AD Rights Management Server (Сервер управления правами) и Identity Federation Support (Федеративная поддержка идентификации). Если это требуется, такие индивидуальные роли могут быть установлены при помощи Install-WindowsFeature ADRMS ADRMS-Server, Install-WindowsFeature ADRMS ADRMS-Identity или Install-WindowsFeature ADRMS -IncludeAllSubFeature. Они также установят все необходимые подчинённые функциональности.
Install-WindowsFeature AD-Certificate	Этот командлет установит роль AD CS. Данная роль имеет шесть подчинённых ролей, которыми выступают Центр авторизации (ADCS-Cert-Authority), Веб службы политики регистрации сертификатов (ADCS-Enroll-Web-Pol), Службы веб регистрации сертификатов (ADCS-Cert-Enroll-Web-Svc), Службы веб регистрации сертификатов (ADCS-Cert-Web-Enrollment), Службы регистрации сетевого устройства (ADCS-Device-Enrollment) и Ответчика в реальном времени (ADCS-Online-Cert). Эти подчинённые функции могут добавляться индивидуально или совместно.

Дополнительно ознакомиться с этими ролями можно в следующих главах:

Это конец нашей вводной главы в основы Active Directory. Я уверен что большинство из вас уже знают о функциях AD DS. Однако не будет пустым делом освежить ваши знания относительно Active Directory и его операций, прежде чем углубляться в более продвинутые темы. В этой главе мы рассмотрели будущее управления идентификацией и затем рассмотрели роль гибридной идентификации Active Directory, значения GUID и SID, а также DN.

В своей следующей Главе 2, Службы домена Active Directory Windows 2022 вы изучите новые свойства и расширения AD DS 2022, в частности, новые подходы к защите цифровых идентификаций от современных угроз безопасности.