Несколько лет назад я работал над проектом реструктуризации 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). Когда идентификация управляется из некой централизованной системы, важно чтобы все контроллеры домена были бы осведомлены о тех изменениях, которые производятся в имеющейся базе данных Active Directory. Допустим, некая пользователь, Джейн, из подразделения продаж, забыла свой пароль и просит своё подразделение ИТ выполнить его сброс. Через 30 минут она намерена работать из своего офиса отделения, расположенного в другом городе. Соответствующий администратор ИТ сбрасывает её пароль в контроллере домена самой штаб- квартиры, DC01. Для того чтобы иметь успешную регистрацию из офиса отделения это изменение должно быть реплицировано в соответствующий контроллер домена этого офиса отделения, DC05.

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

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

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

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

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

Всякий вид базы данных имеет свою собственную структуру, именуемую схемой. Это применимо также и к базе данных Active Directory. Такая схема описывает все имеющиеся в Active Directory объекты. Зная установленную схему вы можете изменять или расширять её. Это важно для разработки интегрированных с 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 содержит два вида объектов. Объектами могут быть либо объекты контейнеров (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 2016. Однако это не означает что он может применять свойства, предоставляемые Службой каталога Windows Server 2016 пока не будут обновлены уровни функциональности его домена и леса. Если вы обновите уровень функциональности его леса до Windows Server 2016, тогда вы сможете получить контроллеры домена исполняющими минимально только Windows Server 2016.

Домены

Возвращаясь обратно к моему примеру с дождевым лесом Амазонии, мы можем сказать что в нём живёт более 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 - ролей гибких операций с единственным хозяином).

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

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

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

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

Таблица 1-1. PowerShell cmdlet установки ролей сервера Active Directory

PowerShell cmdlet	Описание
Install-WindowsFeature AD-Domain-Services	Этот cmdlet установит роль AD DS
Install-WindowsFeature AD FS-Federation	Этот cmdlet установит роль AD FS
Install-WindowsFeature ADLDS	Этот cmdlet установит роль AD LDS
Install-WindowsFeature ADRMS	Этот cmdlet установит роль 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	Этот cmdlet установит роль 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:

Доступные только для чтения Контроллеры домена

В Windows Server 2008, Microsoft ввёл новый тип контроллера домена с названием RODC (read-only domain controller, доступного только для чтения контроллера домена). Он делает возможным для организаций иметь контроллеры домена в тех местоположениях, в которых безопасность данный и сетевая безопасность не могут быть гарантированы.

Контроллеры домена содержат некую доступную для записи копию своей базы данных AD DS. Она реплицируется по всем имеющимся контроллерам домена в одном и том же домене, однако доступные только для чтения контроллеры домена будут иметь базу данных AD DS, доступную лишь для чтения.

Такая функциональность очень полезна в сетевых средах филиалов (branch). Не каждый филиал офиса способен предоставить полностью сформированную сетевую среду с высокоскоростными выделенными линиями связи, возможности защищённого центра обработки данных, а также ИТ персонал. Если он находится в среде Active Directory и когда этому офису филиала требуется иметь соединение с основной корпоративной средой, инженерам потребуется также развернуть в сетевой среде офиса филиала и сам контроллер домена. Однако когда такой офис филиала имеет ограниченную связь с корпоративной сетевой средой, меньшими ИТ ресурсами и более скудной безопасностью физических данных и сетевых ресурсов, развёртывание контроллера домена в такой сети может быть большой угрозой безопасности для корпоративных сетевых сред. Тем не менее, развёртывание какого- то RODC защитит от подобных угроз имеющуюся безопасность инфраструктуры идентификации, а пользователи в своём офисе филиала всё ещё будут иметь возможность применения самых быстрых аутентификации и авторизации, предоставляемых AD DS.

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

AD FS делает для вас возможным разделять идентификацию между доверительными инфраструктурами идентификации и основывается на механизме CBA (claim-based authorization, основанной на требованиях авторизации). Рабочие потоки современной организации являются сложными. Поставщики сервисных приложений переместили большинство своих приложений в облачные решения (SaaS, software as a service). Кроме того, организации совместно с другими организациями для неких действий применяют системы и приложения на веб основе. Почти всем таким системам требуется некий вид процесса аутентификации и авторизации чтобы позволять пользователям выполнять доступ к приложениям или системам. Это усложняет требования к имеющейся инфраструктуре идентификации.

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

AD FS позволяет вам предоставлять доступ к защищённым приложениям без каких либо подобных рисков. Он будет доверять совершенно иным инфраструктурам идентификации и передавать информацию идентификации в виде заявок (claims) в те организации,которые размещают необходимые приложения. После этого, та компания, которая размещает данное приложение, установит соответствие для этой заявки тем заявкам, которые понимает данное приложение и осуществит принятие решения по данной авторизации. Самый важный момент здесь состоит в том, что данный процесс осуществляется с минимальными изменениями в имеющейся инфраструктуре. Обе организации будут поддерживать свои собственные инфраструктуры идентификации. Взаимодействие выполняется исключительно через протокол HTTPS и не будет никакой потребности открывать дополнительные порты межсетевого экрана между имеющимися сетевыми средами таких организаций.

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

В наши дни организации всё больше и больше используют веб приложения. Некоторые из них для их собственной работы, а часть сосредоточена на клиентах. Когда эти приложения являются интегрированными с Active Directory, их открытие в общедоступном интернете может создавать угрозы безопасности. AD FS кроме того может применяться для предоставления многофакторной аутентификации веб приложениям. AD FS может размещаться в некой DMZ (demilitarized zone) своей сетевой среды, причём это будет единственный сталкивающийся с общей доступностью интерфейс для данного приложения.

Существует четыре службы роли AD FS:

Данные роли федерализации могут быть установлены на отдельных серверах на основании требований федерализации самой организации.

Некоторые приложения требуют для работы среды с включённым каталогом. Однако при этом нет потребности в полностью укомплектованном Active Directory. Для включения хранилища данных и выборки данных приложениями с включённым каталогом Microsoft разработал AD LDS. После того как мы развёртываем AD DS, он удерживает свой собственный раздел каталога и ту схему, которая наследуется из его леса. Если требуется некий дополнительный раздел каталога, вам требуется развернуть другой домен или дочерний домен, однако AD LDS позволяет вам поддерживать некую независимую схему во всяком независимом экземпляре AD LDS. Вы также имеете возможность размещать в одном компьютере множество экземпляров AD LDS.

И AD DS, и AD LDS, обе построены на основе одних и тех же технологий ядра службы каталога. AD LDS не обязан зависеть от имеющихся домена Active Directory или установки леса. Тем не менее, в некой среде AD DS AD LDS может пользоваться AD DS для аутентификации.

AD RMоS способствует организациям в защите чувствительных данных от несанкционированного доступа.

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

AD RMS содержит две службы ролей:

AD CS помогает организациям в простом и эффективном в стоимостном отношении способе построения PKI (public key infrastructure, инфраструктуры общедоступных ключей). Выпускаемые Центром авторизации (certification authority) цифровые сертификаты могут применяться для авторизации пользователей, компьютеров и устройств. Соответствующий Центр авторизации отвечает за получение запросов сертификатов, проверку запросов сертификатов, а также выпуск, обновление и аннуляцию сертификатов.

Для AD CS имеются шесть ролей:

Microsoft начал своё путешествие Azure в далёком 2008. Windows Azure был доступен для всех начиная с 2010 (в 2014 он был переименован в Microsoft Azure). В наши дни это зрелая общедоступная облачная служба, являющаяся лидером в отрасли. Её предложениям IaaS (infrastructure as a service), PaaS (platform as a service) и SaaS хорошо доверяют многие такие стороны как государственная служба, компании Fortune 500, военные, университеты, госпитали, поставщики услуг и тому подобные. Теперь всё более часто бизнес перемещает свои данные, приложения и операции в Microsoft Azure; примите во внимание рост бизнеса, эффективность, опыт, подвижность, стоимость и гарантии.

Когда бизнес рассматривает перемещение имеющихся данных, приложений или операций в Azure, для рассмотрения имеются два варианта:

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

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

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

Самые последние статистические данные от Microsoft подтверждают что это остаётся сильным:

Azure AD способен предоставлять следующее:

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

В некой своей локальной среде нам обычно требуется добавлять дополнительные компоненты, например, AD FS, для включения приложениям SSO. Однако применяя Azure AD мы способны предоставлять практику SSO для рабочих потоков SaaS, рабочих нагрузок PaaS, либо для локальной загрузки без зависимости от дополнительных компонентов или сложных конфигураций. К тому же, если требуется, мы можем применять дополнительную функциональность безопасности, например, MFA (Multi-Factor Authentication) или условные правила доступа Azure совместно с SSO чтобы добавить дополнительный уровень защиты к процессу подписи.

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

Когда вашим рабочим нагрузкам требуются службы домена, совместимые с Windows Active Directory, такие как присоединение к домену, LDAP, либо аутентификация Kerberos/ NTLM, тогда Azure AD будет способен полностью выполнить это. Вы можете применять эти функции без развёртывания контроллеров под своей арендой Azure. Тем не менее, это управляемая служба; следовательно мы можем ожидать некой сопоставимой службы.

Когда мы желаем публиковать некое веб приложение из локальной инфраструктуры для общественного доступа, нам придётся выполнить ряд вещей. Нам требуется настроить для него необходимые важные правила межсетевого экрана и записи DNS. Если требуется SSO, нам понадобится сконфигурировать некую подобную AD FS службу. Когда это основанное на облаке прикладное решение, нам нет нужды делать какие- то подобные вещи; единственный момент, о котором нам стоит позаботиться, это практика применения подписи и защита. Мы можем применять Azure AD для аутентификации, а Azure MFA для дополнительного уровня безопасности. Однако не все приложения имеют возможности замены себя облачной версией. Посредник приложений (Application Proxy) Azure AD позволяет нам публиковать локальные приложения в Интернете и применять те же самые практики аутентификации и доступа, как в имеющихся приложениях SaaS. Это осуществляется при посредничестве агента с малым весом, который устанавливается в локальной сетевой среде. Я в дальнейшем объясню эту функциональность в Главе 17, Гибридная установка Azure Active Directory.

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

Azure AD B2B позволяет нам включать безопасный доступ между партнёрами. В такой ситуации управление идентификацией будет всё ещё управляемым, так как оно пребывает между известными средами. Но что если мы сталкиваемся с веб приложением для тысяч потребителей? Будет не практичным заставлять всех потребителей выполнять подключения B2B. Azure AD B2C позволяет потребителям применять имеющиеся учётные записи социальных сетей, такие как Microsoft, Gmail или Facebook для регистрации в определённом приложении. Если это требуется, они также могут подписываться в этом приложении напрямую.

Имеются различные версии Azure AD. Каждая из версий имеет различный набор функций:

Таблица 1-2. Свойства версий Azure AD

Свойства	Бесплатный	Office 365	Базовый	P1	P2
Объекты каталога	500 000	без ограничений	без ограничений	без ограничений	без ограничений
Управление пользователем	Да	Да	Да	Да	Да
SSO	10 приложений на пользователя	10 приложений на пользователя	10 приложений на пользователя	без ограничений	без ограничений
B2B	Да	Да	Да	Да	Да
Azure AD Connect	Да	Да	Да	Да	Да
Отчёты по безопасности	Базовый	Базовый	Базовый	Расширенный	Расширенный
Сброс пароля самостоятельного обслуживания	Да	Да	Да	Да	Да
Управление доступом на основе групп	-	Да	Да	Да	Да
Поддержка имён компаниий	-	Да	Да	Да	Да
Посредник приложений	-	Да	Да	Да	Да
SLA	-	Да	Да	Да	Да
Самостоятельный сброс пароля с обратной записью локально	-	-	-	Да	Да
Устройства с подтверждением	-	-	-	Да	Да
Azure MFA	-	Да	-	Да	Да
Диспетчер идентификации Microsoft	-	-	-	Да	Да
Обнаружение облачных прикладных приложений	-	-	-	Да	Да
Жизнеспособность подключений	-	-	-	Да	Да
Условный доступ	-	-	-	Да	Да
Защита идентификации	-	-	-	-	Да
Привилегированное управление идентификацией	-	-	-	-	Да
Безопасность облачных прикладных приложений Microoft	-	-	-	Да	Да

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

В своей следующей главе мы изучим новые свойства и расширения AD DS 2016, в частности, новые подходы к защите идентификации от современных угроз безопасности.