Руководства по развертыванию Windows Server Active Directory на виртуальных машинах Azure

В этом документе описываются важные отличия, которые есть при локальном развертывании доменных служб Windows Server Active Directory (AD DS) и служб федерации Active Directory (AD FS) по сравнению с их развертыванием на виртуальных машинах Microsoft Azure (ВМ).

Содержание

• Область и аудитория
• Связанные ресурсы
• Введение
• Термины и определения
• Безопасно ли виртуализировать контроллеры домена Windows Server Active Directory?
• Почему стоит развертывать Windows Server AD DS на виртуальных машинах Azure?
• Разница между развертыванием контроллеров домена Windows Server Active Directory на виртуальных машинах Azure и локальным развертыванием
• Можно ли развернуть Windows Server AD FS на виртуальных машинах Azure?
• Contrasts between deploying Windows Server AD FS on Azure Virtual Machines versus on-premises
• Варианты развертывания
• Факторы и различные решения, принимаемые при развертывании

Область и аудитория

Этот документ предназначен для администраторов, имеющих опыт локального развертывания Active Directory. В документе описываются различия при развертывании Active Directory на виртуальных машинах Microsoft Azure и в виртуальных сетях Azure и традиционном локальном развертывании Active Directory. Виртуальные машины Azure и виртуальные сети Azure являются частью услуги «Инфраструктура как служба» (IaaS), которая предоставляется организациям для использования вычислительных ресурсов в облаке.

Для тех, кто не знаком с развертыванием AD, см. статьи Руководство по развертыванию AD DS и Планирование развертывания AD FS.

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

• Развертывание и управление Windows Server AD DS

• Развертывание и настройка DNS для поддержки инфраструктуры Windows Server AD DS

• Развертывание и управление Windows Server AD FS

• Развертывание, настройка приложений проверяющей стороны (веб-сайтов и веб-служб), которые могут принимать токены службы федерации Windows Server AD, и управление ими

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

В документе освещаются требования для гибридного развертывания, при котором службы Windows Server AD DS или AD FS развертываются частично локально и частично на виртуальных машинах Azure. Сначала описываются важные различия между запуском служб Windows Server AD DS и AD FS на виртуальных машинах Azure и на локальных компьютерах, затем приводятся важные решения по архитектуре, которые влияют на дизайн и развертывание системы. В остальной части документа даются подробные рекомендации по принятию решений на каждом важном этапе и методы их применения в различных вариантах развертывания.

В этом документе не обсуждается настройка Azure Active Directory, которая является службой, основанной на REST-интерфейсе, предоставляющей возможности управления идентификаторами и управления доступом для облачных приложений. Однако Azure Active Directory (AD) и Windows Server AD DS предназначены для совместной работы и предоставления решения по управлению доступом и удостоверениями для современных гибридных ИТ-сред и приложений. Чтобы понять различия и соответствия между Windows Server AD DS и Azure AD, следует учесть следующее.

1. Windows Server AD DS можно запускать на виртуальных машинах Azure при использовании Azure для расширения локального центра обработки данных в облако.

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

3. С помощью Azure AD (ее службы управления допуском) можно предоставить пользователям возможность подключения к приложениям, размещенным в облаке или локально, с использованием идентификаторов от Facebook, Google, Microsoft или от других поставщиков удостоверений.

Дополнительные сведения об этих различиях см. в разделе Идентификатор Azure.

Связанные ресурсы

Можно загрузить и запустить средство оценки готовности виртуальной машины Azure. Это средство оценки автоматически проверит локальную среду и создаст настраиваемый отчет на основе рекомендаций из данной статьи, чтобы помочь вам перевести свою среду в Azure.

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

• Настройка виртуальной сети только для облака на портале управления
• Настройка виртуальной частной сети «сеть-сеть» на портале управления
• Установка нового леса Active Directory в виртуальной сети Azure
• Установка реплики контроллера домена Active Directory в Azure
• Windows Azure IT Pro IaaS. Основы виртуальных машин (01)
• Windows Azure IT Pro IaaS. Создание виртуальных сетей и подключения между организациями (05)

Введение

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

1. Возможно, виртуальным машинам Azure необходимо будет предоставить соединение с локальной корпоративной сетью.

   Для подключения виртуальных машин Azure к локальной корпоративной сети требуется виртуальная сеть Azure, которая включает VPN-компонент «сеть-сеть» или «точка-сеть», с помощью которого можно легко соединить виртуальные машины Azure и локальные компьютеры. Посредством этого VPN-компонента компьютеры, участники локального домена, также могут обращаться к домену Windows Server Active Directory, чьи контроллеры размещены только на виртуальных машинах Azure. Однако следует отметить, что, если виртуальная частная сеть выйдет из строя, проверки подлинности и другие операции, которые зависят от Windows Server Active Directory, также не будут работать. В этом случае пользователи все еще смогут входить в систему с применением кэшированных учетных данных, но все одноранговые проверки подлинности и проверки подлинности «клиент-сервер», для которых необходимо выдать билеты или чьи билеты устарели, будут завершаться ошибкой.

   На странице Виртуальная сеть можно найти демонстрационные видеоролики и список пошаговых руководств, включая руководство Настройка виртуальной частной сети «сеть-сеть» на портале управления.

   Примечание

   Windows Server Active Directory можно также развернуть в виртуальной сети Azure, у которой нет соединения с локальной сетью. В рекомендациях, приведенных в данном разделе, подразумевается, что используется виртуальная сеть Azure, поскольку она предоставляет возможности по применению IP-адресов, которые необходимы для Windows Server.

2. Статические IP-адреса необходимо настраивать с помощью Azure PowerShell.

   Динамические адреса выделяются по умолчанию, однако вместо этого назначьте статический IP-адрес с помощью командлета Set-AzureStaticVNetIP. Этот командлет устанавливает статический IP-адрес, который будет сохраняться при восстановлении службы, а также при остановке и перезапуске ВМ. Дополнительные сведения см. в статье Настройка статического внутреннего IP-адреса (DIP) для ВМ.

Термины и определения

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

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

• Виртуальная сеть Azure: сетевая служба в Azure, которая позволяет клиентам создавать виртуальные сети в Azure и управлять ими, а также безопасно соединять их с собственной локальной сетевой инфраструктурой с помощью виртуальной частной сети (VPN).

• Виртуальный IP-адрес (VIP): IP-адрес, доступный из Интернета и не привязанный к конкретному компьютеру или интерфейсу сетевого адаптера. Облачным службам назначается VIP-адрес для получения сетевого трафика, который перенаправляется в ВМ Azure. VIP — это свойство облачной службы, которое может содержать одну или несколько виртуальных машин Windows Azure. Также обратите внимание, что виртуальная сеть Azure может содержать одну или несколько облачных служб. VIP-адреса обеспечивают встроенные возможности балансировки рабочей нагрузки.

• Динамический IP-адрес (DIP): Это IP-адрес, который является только внутренним. Он должен настраиваться как статический IP-адрес (с помощью командлета Set-AzureStaticVNetIP) для ВМ, на которых размещаются роли сервера DC/DNS.

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

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

  • MAC-адрес адаптера виртуальной сети не изменится

  • Изменится идентификатор процессора (CPU ID) виртуальной машины

  • IP-конфигурация виртуального сетевого адаптера не изменяется, пока VM подключена к виртуальной сети и ее IP-адрес статичен.

  Ни один из этих процессов не влияет на Windows Server Active Directory, поскольку эта технология не зависит от MAC-адреса или CPU ID, и рекомендуется запускать все развертывания Windows Server Active Directory в Azure в виртуальной сети Azure, как описано выше.

Безопасно ли виртуализировать контроллеры домена Windows Server Active Directory?

Для развертывания контроллеров домена Windows Server Active Directory на виртуальных машинах Azure действуют те же правила, что и при запуске контроллеров на локальной виртуальной машине. Выполнение виртуализованных контроллеров домена будет безопасно, если выполняются рекомендации по резервному копированию и восстановлению контроллеров. Дополнительные сведения об ограничениях и рекомендациях по работе с виртуализованными контроллерами см. в разделе Работа с контроллерами домена в Hyper-V.

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

Подобные откаты вводят так называемые USN-пузыри (разницу номеров последовательного обновления), что может привести к наличию постоянных дивергентных состояний между контроллерами. Кроме того, это может вызвать следующие проблемы:

• наличие устаревших объектов;

• наличие несогласованных паролей;

• наличие несогласованных значений атрибутов;

• несоответствие в схеме при откате контроллера хозяина схемы.

Дополнительные сведения о влиянии на контроллеры домена см. в разделе USN и откат USN.

Начиная с Windows Server 2012, в AD DS встроены дополнительные меры безопасности. Эти меры безопасности помогают защитить виртуализированные контроллеры доменов от упомянутых выше опасностей, при условии, что базовая платформа низкоуровневой оболочки поддерживает VM-GenerationID. Azure поддерживает VM-GenerationID, это значит, что контроллеры домена, работающие с Windows Server 2012 или более поздними версиями на виртуальных машинах Azure будут защищены дополнительными мерами безопасности.

Почему стоит развертывать Windows Server AD DS на виртуальных машинах Azure?

Множество вариантов развертывания Windows Server AD DS хорошо подходят для развертывания в виде виртуальных машин в Azure. Например, предположим, что имеется компания в Европе, которой необходимо выполнять проверку подлинности пользователей в удаленном местоположении в Азии. Компания ранее не выполняла развертывание контроллеров домена Windows Server Active Directory в Азии из-за стоимости развертывания или ограниченного опыта работы с серверами после развертывания. В результате запросы проверки подлинности из Азии обслуживаются КД в Европе с неоптимальной производительностью. В этом случае можно развернуть КД на виртуальной машине, для которой была указано, что она должна выполняться в центре обработки данных Azure, расположенном в Азии. Присоединение данного КД к виртуальной сети Azure, подключенной непосредственно к удаленному местоположению, улучшит производительность процесса проверки подлинности.

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

Наконец, возможно, вам необходимо будет развернуть сетевое приложение в Azure, например SharePoint, которому требуется Windows Server Active Directory, но не требуется локальная сеть или корпоративная служба Windows Server Active Directory. В этом случае оптимальным будет развертывание изолированного леса в Azure для соответствия требованиям сервера SharePoint. Опять же поддерживается и развертывание сетевых приложений, которым требуется подключение к локальной сети и корпоративной службы Active Directory.

Разница между развертыванием контроллеров домена Windows Server Active Directory на виртуальных машинах Azure и локальным развертыванием

• Для любого сценария развертывания Windows Server Active Directory, в котором применяется более одной виртуальной машины, для обеспечения целостности IP-адресов необходимо использовать виртуальную сеть Azure. Обратите внимание, что в этом руководстве подразумевается следующее: КД выполняются в виртуальной сети Azure.

• Как и в случае локальных контроллеров доменов, рекомендуются статические IP-адреса. Статический IP-адрес можно настроить только с помощью Azure PowerShell. См. статью Настройка статического внутреннего IP-адреса (DIP) для ВМ. Если у вас имеются системы мониторинга или другие решения, которые проверяют конфигурацию статических IP-адресов в гостевой операционной системе, то можно назначить тот же статический IP-адрес свойствам сетевого адаптера ВМ. Однако необходимо учитывать, что сетевой адаптер будет удален, если ВМ пройдет восстановление службы, или если будет выполнено завершение работы ВМ на портале управления, и назначение ей адреса будет отменено. В таком случае придется сбросить статический IP-адрес в гостевой операционной системе.

• Развертывание ВМ в виртуальной сети не подразумевает (и не требует) обратной связи с локальной сетью, виртуальная сеть лишь обеспечивает данную возможность. Для закрытого обмена данными между Azure и вашей локальной сетью обязательно требуется создать виртуальную сеть. Необходимо развернуть конечную VPN-точку в локальной сети. VPN-соединение открывается из Azure по направлению к локальной сети. Дополнительные сведения см. в статьях Обзор виртуальной сети и Настройка VPN типа "сеть-сеть" на портале управления.

  Примечание

  Возможность создания VPN-соединения «точка-сеть» доступна путем подключения отдельных компьютеров Windows напрямую к виртуальной сети Azure.

• Независимо от того, была ли создана виртуальная сеть, Azure выставляет счет за исходящий трафик, а не за входящий. Различные варианты архитектуры Windows Server Active Directory могут снизить объем трафика, исходящего из развертывания. Например, развертывание контроллера RODC ограничивает исходящий трафик, поскольку он не реплицирует отправляемые данные. Однако решение по развертыванию RODC необходимо оценивать с учетом необходимости выполнения операций записи в контроллере домена и совместимости приложений и служб сайта с RODC. Дополнительные сведения о выставлении счетов за трафик см. в разделе Краткая информация о расценках на Azure.

• При использовании локальных ВМ у вас есть полный контроль над тем, какие серверные ресурсы, например объем ОЗУ, место на диске и прочее, будут отведены под машины. А вот при работе с ВМ в Azure нужно будет выбрать из списка предварительно определенных размеров сервера. Для КД в дополнение к диску операционной системы также требуется диск данных для хранения базы данных Windows Server Active Directory.

Можно ли развернуть Windows Server AD FS на виртуальных машинах Azure?

Да, службы Windows Server AD FS можно развернуть на виртуальных машинах в Azure. Рекомендации по развертыванию AD FS в локальной среде относятся и к развертыванию AD FS в Azure. Некоторые рекомендации по AD FS, например по балансировке нагрузки и высокому уровню доступности, требуют применения технологий, выходящих за рамки реализованных в самих службах AD FS. Они должны предоставляться базовой инфраструктурой. Рассмотрим некоторые из этих рекомендаций, чтобы узнать, как их реализовать с помощью ВМ Azure и виртуальной сети Azure.

1. Никогда не предоставляйте доступ к серверам службы токенов безопасности (STS) непосредственно из Интернета.

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

2. Развертывайте контроллеры домена Active Directory для всех доменов пользователей в сети, в которой размещены серверы AD FS.

   Серверы AD FS используют доменные службы Active Directory для проверки подлинности пользователей. Рекомендуется развернуть контроллеры домена в той же сети, что и серверы AD FS. Это обеспечивает непрерывность бизнеса в случае разрыва связи между сетью Azure и локальной сетью и позволяет уменьшить задержки при и повысить производительность входа в систему.

3. Разверните несколько узлов AD FS для обеспечения высокой доступности и балансировки нагрузки.

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

4. Разверните один или несколько узлов прокси веб-приложения для доступа к Интернету.

   Если пользователям требуется доступ к приложениям, защищенным службами AD FS, эти службы должны быть доступны из Интернета. Это достигается путем развертывания службы прокси веб-приложения. Настоятельно рекомендуется развернуть несколько узлов для обеспечения высокого уровня доступности и балансировки нагрузки.

5. Ограничьте доступ к ресурсам внутренней сети из узлов прокси веб-приложения.

   Чтобы разрешить внешним пользователям доступ к службам AD FS из Интернета, необходимо развернуть узлы прокси веб-приложения (или прокси-сервера AD FS в более ранних версиях Windows Server). Узлы прокси веб-приложения напрямую доступны из Интернета. Не требуется присоединять их к домену и им необходимо доступ к серверам служб AD FS по TCP-портам 443 и 80. Настоятельно рекомендуется заблокировать связь со всеми остальными компьютерами (особенно контроллерами домена).

   Это обычно реализуется локально с помощью DMZ. Брандмауэры используют режим белого списка для ограничения трафика из DMZ в локальную сеть (т. е. разрешен только трафик с указанных IP-адресов и через указанные порты, весь остальной трафик блокируется).

На следующей схеме показано, как это выглядит в традиционном локальном развертывании AD FS.

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

Параметр	Преимущество	Недостаток
Списки управления доступом сети Azure	Менее дорогостоящие, простая начальная настройка	Если новые виртуальные машины будут добавлены в развертывание, потребуется дополнительная настройка ACL.
Брандмауэр Barracuda NG	Режим белого списка, настройка ACL не требуется	Более дорогостоящий, сложная начальная настройка.

Далее представлены высокоуровневые действия для развертывания AD FS.

1. Создание виртуальной сети с подключением между организациями с помощью подключения VPN или ExpressRoute.

2. Развертывание контроллеров домена в виртуальной сети. Этот шаг является необязательным, но рекомендуется.

3. Развертывание присоединенных к домену серверов AD FS в виртуальной сети.

4. Создание внутреннего комплекта балансировки нагрузки, включающего серверы AD FS и использующего новый частный IP-адрес в виртуальной сети (DIP).

   1. Обновление DNS-сервера для создания полного доменного имени, указывающего на частный IP-адрес (DIP) внутренней подсистемы балансировки нагрузки.

5. Создание облачной службы (или отдельной виртуальной сети) для узлов прокси веб-приложения.

6. Развертывание узлов прокси веб-приложения в облачной службе или виртуальной сети

   1. Создание внешнего комплекта балансировки нагрузки, который включает в себя узлы прокси веб-приложения.

   2. Обновление внешнего DNS-имени (полного доменного имени), указывающего на общедоступный IP-адрес (VIP) облачной службы.

   3. Настройка прокси-серверов AD FS для использования полного доменного имени, соответствующего внутреннему комплекту балансировки нагрузки для серверов AD FS.

   4. Обновление веб-сайтов на основе утверждений для использования полного доменного имени для поставщика утверждений.

7. Ограничение доступа между прокси веб-приложения для всех компьютеров в виртуальной сети AD FS.

Чтобы ограничить трафик, комплекта балансировки нагрузки для внутренней подсистемы балансировки нагрузки Azure необходимо настроить только для трафика по TCP-портам 80 и 443, при этом весь остальной трафик внутреннего DIP комплекта балансировки нагрузки отклоняется

Трафик на серверы AD FS допускается от следующих источников:

• внутренняя подсистема балансировки нагрузки Azure;

• IP-адрес администратора в локальной сети.

Недостаток этого вариант заключается в необходимости настройки списков ACL сети для нескольких устройств, включая внутреннюю подсистему балансировки нагрузки, серверы AD FS и другие серверы, которые добавляются к виртуальной сети. Если какое-то устройство добавляется к развертыванию без настройки сетевых списков ACL для ограничения трафика к нему, все развертывание может быть под угрозой. Если IP-адреса узлов прокси веб-приложения изменятся, необходимо сбросить сетевые списки ACL (т. е. прокси-серверы нужно настроить для использования статических DIP-адресов).

Другой вариант — использовать брандмауэр Barracuda NG для управления трафиком между прокси-серверами AD FS и серверами AD FS. Этот вариант соответствует рекомендациям по безопасности и высокой доступности и требует меньше администрирования после начальной настройки, так как брандмауэр NG Barracuda использует режим белого списка и его можно установить непосредственно в виртуальной сети Azure. Это избавляет от необходимости настроить сетевые списки ACL при добавлении нового сервера в развертывание. Однако при использовании этого варианта первоначальное развертывание становится сложнее и дороже.

В этом случае две виртуальные сети развертываются вместо одной. VNet1 содержит прокси-серверы, а VNet2 STS — службы STS и сетевое подключение к корпоративной сети. Таким образом VNet1 физически (хотя и виртуально) изолирована от VNet2 и, в свою очередь, от корпоративной сети. VNet1 подключается к VNet2 с помощью специальной технологии туннелирования TINA. Туннель ТИНА присоединяется к каждой из виртуальных сетей с помощью брандмауэра Barracuda NG — один брандмауэр Barracuda используется в каждой из виртуальных сетей.  Для высокой доступности рекомендуется развернуть два брандмауэра Barracuda в каждой виртуальной сети — один активный, другой пассивный. Они предоставляют множество полезных возможностей, которые позволяют имитировать работу традиционной локальной демилитаризованной зоны (DMZ) в Azure.

Дополнительные сведения см. в 2. AD FS: расширение локального клиентского приложения с обработкой утверждений для работы через Интернет..

Альтернатива развертыванию AD FS, если целью является только реализация единого входа Office 365

Существует другой способ развертывания AD FS, если вы хотите только включить единый вход для Office 365. В этом случае можно просто развернуть службу DirSync с синхронизацией с паролем локально и добиться того же конечного результата с помощью простого развертывания, поскольку этот подход не требует использования AD FS или Azure.

В следующей таблице приведено сравнение работы процессов входа в систему при развертывании AD FS.

Единый вход в Office 365 с использованием AD FS и DirSync

Такой же единый вход в Office 365 с использованием DirSync и синхронизации паролей

Пользователь выполняет вход в корпоративную сеть, после чего производится проверка его подлинности в Windows Server Active Directory. Пользователь пытается получить доступ к Office 365 (я @contoso.com). Office 365 перенаправляет пользователя в Azure AD. Поскольку Azure AD не может проверить подлинность пользователя и учитывает, что существуют соотношения доверия с локальным AD FS, то пользователь перенаправляется к AD FS Пользователь отправляет билет Kerberos в службу токенов безопасности AD FS. AD FS преобразовывает билет Kerberos в требуемый формат токена и утверждения и перенаправляет пользователя в Azure AD. Пользователь проходит проверку подлинности в Azure AD (выполняется еще одно преобразование). Azure AD перенаправит пользователя в Office 365. Пользователь без уведомления подписывается на Office 365

Пользователь выполняет вход в корпоративную сеть, после чего производится проверка его подлинности в Windows Server Active Directory. Пользователь пытается получить доступ к Office 365 (я @contoso.com). Office 365 перенаправляет пользователя в Azure AD. Azure AD не может принимать билеты Kerberos напрямую, и отношений доверия не существует, поэтому пользователю направляется запрос для ввода учетных данных. Пользователь вводит тот же локальный пароль, и Azure AD проверяет их по имени пользователя и паролю, которые были синхронизированы с DirSync. Azure AD перенаправит пользователя в Office 365. Пользователь может войти в Office 365 и OWA, используя токен Azure AD.

В сценарии Office 365 со службой DirSync с синхронизации паролей (без AD FS) единый вход заменяется на "такой же вход", т. е. пользователю нужно повторно ввести те же учетные данные локально при доступе к Office 365. Обратите внимание, что эти данные может сохранить браузер, чтобы сократить число запросов учетных данных в будущем.

Дополнительные сведения для размышления

• При развертывании прокси-сервера AD FS на виртуальной машине Azure требуется связь с серверами AD FS. Если они размещены локально, рекомендуется использовать VPN-подключение типа "сеть-сеть", предоставляемое виртуальной сетью, чтобы узлы прокси веб-приложения могли взаимодействовать со своими серверами AD FS.

• При развертывании сервера AD FS на виртуальной машине Azure необходимо подключение к контроллерам домена Windows Server Active Directory, хранилищам атрибутов и базам данных конфигурации. Также может потребоваться подключение ExpressRoute или VPN-подключение типа "сеть-сеть" между виртуальной сетью Azure и локальной сетью.

• Счета выставляются за исходящий трафик со всех виртуальных машин Azure. Если затраты являются определяющим фактором, целесообразно развертывать узлы прокси веб-приложения в Azure, оставив серверы AD FS в локальной среде. Если серверы AD FS развернуты также на виртуальных машинах Azure, дополнительные затраты будут вызваны проверкой подлинности локальных пользователей. Исходящий трафик приводит к затратам независимо от того, проходит ли он через подключение ExpressRoute или VPN-подключение типа "сеть-сеть".

• При использовании собственных функций балансировки нагрузки сервера Azure для достижения высокого уровня доступности серверов AD FS, обратите внимание, что балансировка нагрузки предоставляет пробы, используемые, чтобы определить состояние виртуальных машин внутри облачных служб. В случае применения виртуальных машин Azure (вместо рабочих и веб-ролей) необходимо использовать пользовательский зонд, поскольку на виртуальных машинах Azure отсутствует агент, который отвечает на зондирование по умолчанию. Для простоты можно использовать пользовательские TCP-зонды. Для этого нужно только TCP-соединение (отправить сегмент TCP SYN и получить ответ с сегментом TCP SYN ACK) для определения исправности виртуальной машины. Вы можете настроить пользовательский зонд на использование любого TCP-порта, который активно прослушивается на ваших виртуальных машинах. Это описывается в разделе Настройка комплекта балансировки нагрузки.

  Примечание

  Компьютеры, которые должны иметь тот же открытый для Интернета набор портов (например, порты 80 и 443), не могут совместно использовать одну и ту же облачную службу. Поэтому рекомендуется создать выделенную облачную службу для ваших серверов Windows Server AD FS во избежание потенциальных перекрытий в требованиях к портам для приложения и службы Windows Server AD FS.

 

Варианты развертывания

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

• 1. AD DS: развертывание приложения, работающего с AD DS без требования о подключении к корпоративной сети

  Например, служба SharePoint, доступная из Интернета, разворачивается на виртуальной машине Azure. Приложение не имеет зависимостей от ресурсов корпоративной сети. Приложению требуется служба Windows Server AD DS, но НЕ требуется корпоративный экземпляр Windows Server AD DS.

• 2. AD FS: расширение локального клиентского приложения с обработкой утверждений для работы через Интернет.

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

• 3. AD DS: развертывание приложения, работающего с Windows Server AD DS, которому требуется подключение к корпоративной сети

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

1. AD DS: развертывание приложения, работающего с AD DS без требования о подключении к корпоративной сети

Рис. 1

Описание

Развертывание SharePoint выполнено на виртуальной машине Azure, и приложение не имеет зависимостей от ресурсов корпоративной сети. Приложению требуется служба Windows Server AD DS, но НЕ требуется корпоративный экземпляр Windows Server AD DS. Не требуется служба Kerberos и федеративные доверенности, поскольку пользователи самостоятельно провизионируются через приложение в домен Windows Server AD DS, который также размещается в облаке на виртуальных машинах Azure.

Соображения касательно этого варианта и применяемые в его рамках технологии

• Сетевая топология: создайте виртуальную сеть Azure без связи между организациями («сеть-сеть»).

• Конфигурация развертывания КД: разверните новый контроллер домена в новый лес Windows Server Active Directory в одном домене. Он должен развертываться вместе с DNS-сервером Windows.

• Топология сайта Windows Server Active Directory: используйте стандартный сайт Windows Server Active Directory (все компьютеры будут в Default-First-Site-Name).

• IP-адресация и DNS:

  • Установите статический IP-адрес для контроллера домена с помощью командлета Set-AzureStaticVNetIP Azure PowerShell.

  • Установите и настройте Windows Server DNS на контроллерах домена в Azure.

  • Настройте свойства виртуальной сети, указав имя и IP-адрес виртуальной машины, на которой размещены серверные роли DC и DNS.

• Глобальный каталог: первый DC в лесе должен быть сервером глобального каталога. Дополнительные КД также должны быть настроены как сборки мусора, так как в лесе одного домена глобальный каталог не требует какой-либо дополнительной работы со стороны КД.

• Размещение базы данных Windows Server AD DS и SYSVOL: добавьте диск данных к контроллерам домена, выполняющимся как виртуальные машины Azure, для хранения базы данных, журналов и SYSVOL.

• Резервное копирование и восстановление: определитесь, где вы будете хранить резервные копии состояния системы. При необходимости добавьте к виртуальной машине КД другой диск данных для хранения резервных копий.

2. AD FS: расширение локального клиентского приложения с обработкой утверждений для работы через Интернет.

Рис. 2

Описание

Приложение, поддерживающее утверждения, успешно развернутое локально и используемое корпоративными пользователями, стало доступным напрямую из Интернета. Приложение выступает в роли веб-клиента к базе данных SQL, в которой оно хранит данные. Серверы SQL, используемые приложением, также находятся в корпоративной сети. Два сервера службы токенов безопасности Windows Server AD FS и подсистема балансировки нагрузки развернуты локально для предоставления доступа корпоративным пользователям. Теперь требуется, чтобы приложение дополнительно было доступно напрямую через Интернет обоим деловым партнерам при использовании их корпоративных удостоверений, а также существующим корпоративным пользователям.

Чтобы упростить систему и выполнить выдвинутое новое требование к развертыванию и конфигурации, решено, что в виртуальных машинах Azure будут установлены два дополнительных веб-клиента и два прокси-сервера службы Windows Server AD FS. Все четыре виртуальные машины будут доступы из Интернета и будут иметь связь с локальной сетью через VPN-подключение типа «сеть-сеть» виртуальной сети Azure.

Соображения касательно этого варианта и применяемые в его рамках технологии

• Сетевая топология: создайте виртуальную сеть Azure и настройте обмен данными между сетями.

  Примечание

  Для каждого из сертификатов службы Windows Server AD FS убедитесь, что URL-адрес, определенный в шаблоне сертификата и полученных сертификатах, доступен экземплярам службы Windows Server AD FS, запущенным в Azure. Для этого может потребоваться наличие связи между частями вашей инфраструктуры ключевого показателя эффективности. Например, если конечная точка CRL основана на LDAP и размещается только локально, то потребуется связь между сетями. Если это нежелательно, то, возможно, необходимо будет использовать сертификаты, выданные центрами сертификации, чьи списки CRL доступны через Интернет.

• Конфигурация облачных служб: убедитесь, что имеется две облачные службы, чтобы предоставлялось два балансируемых по нагрузке VIP-адреса. VIP-адрес первой облачной службы будет направляться на две виртуальные машины прокси-сервера служб федерации AD Windows Server (на порты 80 и 443). Виртуальные машины прокси-сервера служб федерации AD Windows Server будут настроены так, чтобы указывать на IP-адрес локальной подсистемы балансировки загрузки, которая расположена перед серверами службы токенов безопасности служб федерации AD Windows Server. VIP-адрес второй облачной службы будет направляться на две виртуальные машины с веб-клиентом (снова на порты 80 и 443). Настройте пользовательский зонд, чтобы подсистема балансировки загрузки направляла трафик к исправным виртуальным машинам прокси-сервера и веб-клиента Windows Server AD FS.

• Конфигурация сервера федерации: настройте службу Windows Server AD FS как сервер федерации (STS) для формирования токенов безопасности для леса Windows Server Active Directory, созданного в облаке. Задайте поставщик федеративных утверждений для отношений доверия с различными партнерами, от которых нужно принимать удостоверения, и настройте доверенные отношения проверяющей стороны с различными приложениями, которым необходимо формировать токены.

  В большинстве случаев в целях безопасности прокси-серверы службы Windows Server AD FS развертываются c возможностью доступа из Интернета, а соответствующие им части федерации Windows Server AD FS остаются изолированными от Интернета. Независимо от варианта развертывания, необходимо настроить для облачной службы VIP-адрес, который предоставит открытый IP-адрес и порт с возможностью балансировки нагрузки по двум экземплярам Windows Server AD FS STS или по экземплярам прокси.

• Конфигурация высокого уровня доступности службы Windows Server AD FS: рекомендуется развернуть ферму Windows Server AD FS по крайней мере с двумя серверами для отработки отказа и балансировки нагрузки. Вероятно, следует подумать об использовании внутренней базы данных Windows (WID) для данных конфигурации службы Windows Server AD FS и возможности внутренней балансировки нагрузки в Azure для распределения входящих запросов по всем серверам в ферме.

  Дополнительные сведения см. в руководстве по развертыванию AD DS.

3. AD DS: развертывание приложения, работающего с Windows Server AD DS, которому требуется подключение к корпоративной сети

Рис. 3

Описание

Приложение, работающее с LDAP, которое поддерживает встроенную в Windows проверку подлинности и использует Windows Server AD DS в качестве репозитория для конфигурации и данных профиля пользователя, развертывается на виртуальной машине Azure. Желательно, чтобы приложение использовало существующую корпоративную службу Windows Server AD DS и обеспечивало единый вход. Приложение не работает с утверждениями. Пользователи также должны иметь доступ к приложению непосредственно из Интернета. Для оптимизации производительности и стоимости решено, что вместе с приложением в Azure будут развернуты два дополнительных контроллера домена.

Соображения касательно этого варианта и применяемые в его рамках технологии

• Сетевая топология: создайте виртуальную сеть Azure с возможностью подключения между сетями.

• Метод установки: разверните контроллер домена реплики из корпоративного домена Windows Server Active Directory. Для КД реплики можно установить Windows Server AD DS на виртуальной машине и при необходимости использовать функцию установки с носителя для сокращения объема данных, которые требуется реплицировать в новый КД во время установки. Руководство см. в статье Установка контроллера домена Active Directory реплики в Azure. Даже при использовании функции установки с носителя создание виртуальных локальных КД и перемещение всего VHD-диска в облако вместо репликации Windows Server AD DS во время установки может быть более эффективно. В целях безопасности после копирования VHD-файла в Azure рекомендуется удалить его из локальной сети.

• Топология сайта Windows Server Active Directory: создайте новый сайт Azure в сайтах и службах Active Directory. Создайте объект подсети Windows Server Active Directory для представления виртуальной сети Azure и добавьте подсеть к сайту. Создайте новую связь, которая включает новый сайт Azure и сайт, в котором расположена конечная точка VPN виртуальной сети Azure, для управления и оптимизации передачи трафика Windows Server Active Directory в Azure и обратно.

• IP-адресация и DNS:

  • Установите статический IP-адрес для контроллера домена с помощью командлета Set-AzureStaticVNetIP Azure PowerShell.

  • Установите и настройте Windows Server DNS на контроллерах домена в Azure.

  • Настройте свойства виртуальной сети, указав имя и IP-адрес виртуальной машины, на которой размещены серверные роли DC и DNS.

• Географически распределенные КД: при необходимости настройте дополнительные виртуальные сети. Если топология сайта Active Directory требует контроллеры доменов в географических регионах, соответствующих разным регионам Azure, то следует создавать сайты Active Directory соответствующим образом.

• Контроллеры домена только для чтения: вы можете развернуть на сайте Azure контроллер домена только для чтения в зависимости от требований к выполнению операций записи по отношению к КД и совместимости приложений и служб сайта с подобными контроллерами. Дополнительные сведения о совместимости приложений см. в разделе Руководство по совместимости приложений с контроллерами домена только для чтения.

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

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

• Размещение базы данных Windows Server AD DS и SYSVOL: добавьте диск данных к контроллерам домена, выполняющимся как виртуальные машины Azure для хранения базы данных, журналов и SYSVOL.

• Резервное копирование и восстановление: определитесь, где вы будете хранить резервные копии состояния системы. При необходимости добавьте к виртуальной машине КД другой диск данных для хранения резервных копий.

Факторы и различные решения, принимаемые при развертывании

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

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

Номер элемента	Технологическая область Windows Server Active Directory	Решения	Факторы
1	Сетевая топология	Создается виртуальная сеть?	Требования по доступу к корп. ресурсам Проверка подлинности Управление учетными записями
2	Конфигурация развертывания КД	Развертывается отдельный лес без доверенностей? Развертывается новый лес с федерацией? Развертывается новый лес с доверием леса Windows Server Active Directory для протокола Kerberos? Расширяется корпоративный лес путем развертывания КД реплики? Расширяется корпоративный лес путем развертывания нового дочернего домена или доменного дерева?	Безопасность Соответствие требованиям Стоимость Устойчивость к сбоям Совместимость приложений
3	Топология сайта Windows Server Active Directory	Как выполняется настройка подсетей, сайтов и связей с виртуальной сетью Azure для оптимизации трафика и снижения стоимости?	Подсети и определения сайта Свойства связи с сайтом и уведомления об изменении Сжатие репликации
4	IP-адресация и DNS	Как настраиваются IP-адреса и разрешение имен?	Используйте командлет Set-AzureStaticVNetIP для назначения статического IP-адреса Установите DNS-сервер Windows Server и настройте свойства виртуальной сети, указав имя и IP-адрес виртуальной машины, на которой размещены серверные роли DC и DNS.
5	Географически распределенные КД	Как выполнять репликацию на контроллеры доменов в отдельных виртуальных сетях?	Если топология сайта Active Directory требует контроллеры доменов в географических регионах, соответствующих разным регионам Azure, то следует создавать сайты Active Directory соответствующим образом. Настройте связь между сетями VNet для репликации между контроллерами доменов в разных сетях VNet.
6	Контроллеры домена только для чтения	Использовать контроллеры домена только для чтения или с возможностью записи?	Фильтрация атрибутов HBI/PII Фильтрация секретных данных Ограничение исходящего трафика
7	Глобальный каталог	Установить глобальный каталог?	Для леса с одним доменом сделайте все КД носителями сборки мусора Для мультидоменного леса сборки мусора необходимы для проверки подлинности
8	Метод установки	Как устанавливать КД в Azure?	Установите службу AD DS с помощью Windows PowerShell или Dcpromo -или- Переместите VHD-файл виртуального локального КД
9	Размещение базы данных Windows Server AD DS и SYSVOL	Где хранить базу данных Windows Server AD DS, журналы и SYSVOL?	Измените значения по умолчанию приложения Dcpromo.exe Важно! Эти критически важные файлы Active Directory НЕОБХОДИМО разместить на дисках данных Azure, а не на дисках операционной системы, на которых реализовано кэширование записи.
10	Резервное копирование и восстановление	Как обезопасить и восстанавливать данные?	Создавайте резервные копии состояния системы
11	Конфигурация сервера федерации	Выполнить развертывание нового леса с федерацией в облаке? Выполнить локальное развертывание AD FS и открыть доступ к прокси в облаке?	Безопасность Соответствие требованиям Стоимость Доступ к приложениям для деловых партнеров
12	Конфигурация облачных служб	Облачная служба неявно развертывается при первоначальном создании виртуальной машины. Нужно ли развертывать дополнительные облачные службы?	Виртуальная машина или машины должны быть доступны из Интернета? Требуется ли службе балансировка нагрузки?
13	Требования к серверу федерации для открытого и закрытого обращения по IP-адресам (DIP- или VIP-адреса)	Требуется ли, чтобы экземпляр Windows Server AD FS был доступен непосредственно через Интернет? Требуется ли приложению, которое развертывается в облаке, собственный открытый для Интернета IP-адрес и порт?	Создайте одну облачную службу для каждого VIP-адреса, которые требуются вашему развертыванию
14	Конфигурация высокого уровня доступности службы Windows Server AD FS	Сколько узлов в моей ферме серверов Windows Server AD FS? Сколько узлов развернуть в ферме прокси Windows Server AD FS?	Устойчивость к сбоям

Сетевая топология

Чтобы соответствовать требованиям по согласованности IP-адресов и имен DNS службы Windows Server AD DS необходимо сначала создать виртуальную сеть Azure и присоединить к ней виртуальные машины. Во время ее создания необходимо решить, нужна ли связь с локальной корпоративной сетью, которая прозрачно соединит виртуальные машины Azure с локальными компьютерами, что достигается за счет использования традиционной технологии виртуальных частных сетей и требует наличия открытой конечной точки на краю корпоративной сети. Другими словами, VPN-соединение инициируется из Azure в корпоративную сеть, а не наоборот.

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

Конфигурация развертывания КД

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

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

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

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

Требования к доступности и отказоустойчивости также повлияют на ваш выбор. Например, если связь будет разорвана, приложения, использующие доверенность Kerberos или федерации, скорее всего, не будут работать, если вы не развернете достаточную инфраструктуру в Azure. Альтернативные конфигурации развертывания, такие как КД реплики (с записью или только для чтения), повышают вероятность справиться с разрывами связи.

Топология сайта Windows Server Active Directory

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

• Также взимается номинальная плата за час для самого шлюза.

  • Он может быть запущен и остановлен по вашему желанию

  • Если он остановлен, виртуальные машины Azure будут изолированы от сети организации

• Плата за входящий трафик не взимается

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

  • При использовании нескольких виртуальных сетей настройте связи и их стоимость соответствующим образом, чтобы Windows Server AD DS не давала приоритет сайту Azure перед сайтом, который может предоставить тот же уровень обслуживания бесплатно. Можно также рассмотреть возможность отключения функции BASL (мост для всех связей сайтов), которая по умолчанию включена. Это гарантирует, что только непосредственно связанные сайты будут реплицироваться друг с другом. КД в сайтах, которые связаны не на постоянной основе, больше нельзя будет непосредственно реплицировать друг с другом, они должны реплицироваться через общий сайт или сайты. Если посреднические сайты по каким-либо причинам станут недоступны, репликация между КД в сайтах, которые связаны не на постоянной основе, не произойдет, даже если есть связь между сайтами. Наконец, там, где части поведения транзитивной репликации остаются желательными, создайте мосты связей сайтов, которые содержат соответствующие связи и сайты, например на локальные, корпоративные сетевые узлы.

  • Настройте стоимость связей сайтов соответствующим образом во избежание формирования нежелательного трафика. Например, если включен параметр «Пробовать следующий ближайший сайт», убедитесь, что сайты виртуальной сети не являются ближайшими, поскольку это увеличит стоимость, связанную с объектом связи, который соединяет сайт Azure обратно с корпоративной сетью.

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

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

• Возможно еще больше сократить объем сетевого трафика, формируемого в результате репликации между сайтами, сменив алгоритм сжатия репликации. Алгоритм сжатия управляется ключом реестра REG_DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator. Значение по умолчанию 3, что соответствует алгоритму Xpress Compress. Можно изменить значение на 2, соответствующее алгоритму MSZip. В большинстве случаев это обеспечит большее сжатие, но за счет большей загрузки ЦП. Дополнительные сведения см. в разделе Как работает топология репликации Active Directory.

IP-адресация и DNS

Виртуальным машинам Azure по умолчанию выделяются адреса, арендованные в DHCP. Поскольку пространство динамических адресов виртуальной сети Azure сохраняется за виртуальной машиной в течение всего времени ее существования, требования для службы Windows Server AD DS выполняются полностью.

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

Однако если работа виртуальной машины завершается, ее динамический адрес освобождается. Чтобы предотвратить освобождение IP-адреса, можно использовать командлет Set-AzureStaticVNetIP для назначения статического IP-адреса.

Для разрешения имен разверните собственную (или используйте существующую) инфраструктуру DNS-сервера. Служба DNS Azure не отвечает расширенным требованиям, которые необходимы для Windows Server AD DS. Например, она не поддерживает динамические SRV-записи и т. д. Разрешение имен - это важнейший элемент конфигурации для КД и клиентов, присоединенных к домену. КД должен быть способен регистрировать записи ресурсов и находить записи ресурсов других КД.

Для обеспечения отказоустойчивости и наилучшей производительности оптимальным решением будет установка службы Windows Server DNS на КД, запущенном в Azure. Затем настройте свойства виртуальной сети Azure, указав имя и IP-адрес DNS-сервера. Когда запускаются другие виртуальные машины в виртуальной сети, их параметры сопоставителя клиента DNS настраиваются DNS-сервером в рамках процесса выделения динамических IP-адресов.

Виртуальные машины регистрируют свое DNS-имя автоматически при запуске или при изменении имени.

Дополнительные сведения об этом и других примерах, демонстрирующих подготовку первой ВМ и установку на нее службы AD DS, cм. в разделе Установка нового леса Active Directory в Windows Azure. Дополнительные сведения об использовании Windows PowerShell см. в справке по Azure PowerShell и в статье Командлеты управления Windows Azure.

Географически распределенные КД

Windows Azure предоставляет некоторые преимущества при размещении нескольких КД в разных виртуальных сетях.

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

• Физическая близость к филиалам (меньшая задержка)

Сведения о настройке прямого взаимодействия между виртуальными сетями см. в статье Настройка связи типа "VNet to VNet".

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

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

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

Контроллеры только для чтения предоставляют дополнительное преимущество, потому что можно добавить атрибуты, содержащие конфиденциальные данные, в отфильтрованный набор атрибутов контроллера только для чтения (FAS). FAS - это настраиваемый набор атрибутов, которые не реплицируются в контроллеры для чтения. Набор FAS можно использовать в целях безопасности в случае, если не разрешено или нежелательно хранить параметры PII или HBI в Windows Azure. Дополнительные сведения см. в разделе Отфильтрованный набор атрибутов контроллера домена только для чтения.

Убедитесь, что приложения будут совместимы с контроллерами только для чтения, которые вы собираетесь использовать. Многие приложения для Windows Server Active Directory будут хорошо работать с контроллерами только для чтения, однако некоторые приложения могут работать неоптимально или же вообще не работать при отсутствии доступа к КД с записью. Дополнительные сведения см. в разделе Руководство по совместимости приложений с контроллерами домена только для чтения.

Глобальный каталог

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

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

Затраты, связанные со сборкой мусора, менее прогнозируемые, так как они размещают каждый домен (частично). Если рабочая нагрузка содержит службу, доступную из Интернета, и проверяет пользователей по Windows Server AD DS, затраты будут совершенно непредсказуемыми. С целью сокращения количества запросов к сборкам мусора во время проверки подлинности за пределами облачного сайта можно включить кэширование для членов универсальной группы.

Метод установки

Необходимо выбрать способ установки КД в виртуальной сети.

• Ввести новый КД. Дополнительные сведения см. в статье Установка нового леса Active Directory в виртуальной сети Azure.

• Переместите VHD-файл локального КД в облако. В этом случае необходимо убедиться, что локальный виртуальный КД «перемещен», а не «скопирован» или «клонирован».

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

Не используйте SYSPREP для развертывания или клонирования КД. Возможность клонирования контроллеров домена появилась только в Windows Server 2012. Функции клонирования требуется поддержка VMGenerationID в базовой низкоуровневой оболочке. Hyper-V в Windows Server 2012 и виртуальные сети Windows Azure поддерживают VMGenerationID, как и ПО виртуализации сторонних поставщиков.

Размещение базы данных Windows Server AD DS и SYSVOL

Выберите, где следует разместить базу данных Windows Server AD DS, журналы и SYSVOL. Они должны быть развернуты на дисках данных Azure. “

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

Это важно для службы Windows Server AD DS, поскольку кэширование диска при записи делает недействительными предположения КД. Windows Server AD DS пытается отключить кэширование записи, но уже подсистема ввода-вывода диска решает, отключить кэш или нет. Неудача при отключении кэширования записи может в некоторых случаях ввести откат USN, что приведет к появлению устаревших объектов и других проблем.

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

• Установить значение NONE для параметра "Настройки кэша узла" диска данных Azure. Это предотвращает проблемы при кэшировании операций записи для операций AD DS.

• Хранить базу данных, журналы и SYSVOL либо на одном диске данных, либо на отдельных дисках данных. Обычно это диск, отличный от того, который используется для самой операционной системы. Ключевой вывод - база данных Windows Server AD DS и SYSVOL не должны храниться на диске операционной системы Azure. По умолчанию в процессе установки Windows Server AD DS эти компоненты устанавливаются в папку %systemroot%, что НЕ РЕКОМЕНДУЕТСЯ для Azure.

Резервное копирование и восстановление

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

Создавайте резервные копии состояния системы с применением только такого ПО резервного копирования, которое учитывает требования для Windows Server AD DS, например с помощью Windows Server Backup.

Не копируйте и не клонируйте VHD-файлы КД вместо регулярного выполнения резервного копирования. Если потребуется восстановление, его выполнение с помощью скопированного или клонированного VHD-файла без Windows Server 2012 и поддерживаемой низкоуровневой оболочки приведет к формированию в системе USN-пузырей.

Конфигурация сервера федерации

Конфигурация серверов федерации (STS) AD FS Windows Server отчасти зависит от того, нужен ли приложениям, развертываемым в Azure, доступ к ресурсам в локальной сети.

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

• Они принимают токены безопасности SAML

• Они доступны через Интернет

• Они не обращаются к локальным ресурсам

В этом случае настройте серверы федерации Windows Server AD FS следующим образом.

1. Настройте изолированный лес из одного домена в Azure.

2. Предоставьте федеративный доступ к лесу, настроив ферму серверов федерации Windows Server AD FS.

3. Настройте Windows Server AD FS (ферму серверов федерации и ферму прокси-сервера федерации) для локального леса.

4. Установите отношения доверия федерации между локальным и облачным экземпляром Windows Server AD FS.

С другой стороны, если приложению требуется доступ к локальным ресурсам, можно настроить Windows Server AD FS с приложением в Azure следующим образом.

1. Настройте связь между локальными сетями и Azure.

2. Настройте ферму серверов федерации Windows Server AD FS для локального леса.

3. Настройте ферму прокси-сервера федерации Windows Server AD FS в Azure.

Эта конфигурация уменьшает доступность локальных ресурсов извне, что аналогично настройке службы Windows Server AD FS с приложениями в пограничной сети.

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

Конфигурация облачных служб

Облачные службы необходимы, если вы хотите предоставить доступ к ВМ из Интернета или сделать то же самое для приложения с балансировкой нагрузки. Это возможно благодаря тому, что каждая облачная служба предоставляет единый настраиваемый VIP-адрес.

Требования к серверу федерации для открытого и закрытого обращения по IP-адресам (DIP- или VIP-адреса)

Каждая виртуальная машина Azure получает DIP-адрес. DIP - это закрытый адрес, доступный только внутри Azure. Однако в большинстве случаев необходимо будет настроить VIP-адрес для развертываний Windows Server AD FS. VIP-адрес необходим для предоставления доступа из Интернета к конечным точкам службы Windows Server AD FS, которые будут использоваться участниками федерации и клиентами для проверки подлинности и управления. VIP-адрес - это свойство облачной службы, которая может содержать одну или несколько виртуальных машин Azure. Если развернутое в Azure приложение, поддерживающее утверждения, и служба Windows Server AD FS доступны из Интернета и имеют общие порты, им потребуются отдельные VIP-адреса и нужно будет создать одну облачную службу для приложения и вторую для Windows Server AD FS.

Определения терминов VIP и DIP см. в разделе Термины и определения.

Конфигурация высокого уровня доступности службы Windows Server AD FS

Хотя есть возможность развернуть автономные службы федерации Windows Server AD FS, для рабочих сред рекомендуется развертывание фермы как минимум мере с двумя узлами, для роли сервера федерации AD FS и для прокси-серверов.

См. подраздел Соображение о топологии Windows Server AD FS 2.0 в руководстве по проектированию Windows Server AD FS 2.0, чтобы определить, какие варианты конфигурации развертывания лучше всего подходят под ваши нужды.