Microsoft.com изнутри

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

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

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

К счастью, использование служб федерации Active Directory® (ADFS) позволяет очень просто разрешить проблему многократной проверки подлинности, что вполне по силам и вам. ADFS является компонентом Windows Server® 2003 R2, упрощающим установление доверия между двумя или несколькими организациями, что позволяет им совместно использовать несколько ресурсов, одновременно сохраняя для каждой из этих организаций возможность самостоятельного управления своими пользователями. В данной заметке я покажу, как Майкрософт планирует использовать ADFS для разрешения проблемы экстрасети, связанной с использованием нескольких ресурсов; полученные сведения потребуются вам в случае, если потребуется реализовать аналогичное решение. Однако перед тем, как перейти к подробному обсуждению, рассмотрите рис. 1, чтобы ознакомиться с некоторыми основными терминами служб ADFS.

Рис. 1  Терминология, относящаяся к ADFS

Решение ADFS

Когда пользователь пытается получить доступ к приложению, поддерживающему ADFS, обозреватель направляется к ресурсу служб федерации (FS-R — Federation Service Resource) для обнаружения области. В этот момент пользователь выбирает, какой набор учетных данных будет использоваться в течение этого сеанса. На основе выбранной клиентом области он перенаправляется на сервер учетных записей служб федерации (FS-A — Federation Service Accounts). Именно на этом сервере пользователь получает действительный маркер учетной записи (посредством файла «cookie»), основывающийся на учетных данных, введенных пользователем в форме удостоверения Windows Live™ ID (которое раньше называлось учетной записью цифрового паспорта), встроенной проверки подлинности Windows или проверки подлинности SSL (см. рис. 2). В этой модели забота об обслуживании своего сервера учетных записей федерации ложится на каждую отдельную организацию. В случае серверов партнеров Майкрософт это освобождает корпорацию от нагрузки по управлению каждой учетной записью среды. Конечно, устанавливая такой уровень ответственности, необходимо тщательно выбирать организации при объединении в федерацию и иметь гарантию того, что они активно управляют своей учетной информацией.

Следующей остановкой на этом маршруте является возврат на сервер FS-R для обмена маркера учетной записи на маркер ресурса. В нашей конфигурации этот маркер содержит полный список разрешений, предоставленных пользователю посредством процедуры сопоставления заявок, выполняемой на сервере FS-R. После получения маркера пользователь получает возможность единого входа (SSO) в приложения, поддерживающие взаимодействие с ADFS, на весь период сеанса, по умолчанию достигающего 24 часов (это окно допускает настройку). В результате у вас есть включенный единый вход в приложения, поддерживающие ADFS, что обеспечивает повышенную безопасность и эффективность рабочей среды пользователя. Для ознакомления с полным разбором процедуры проверки подлинности ADFS см. статью Мэта Стила под названием «Simplify Single Sign-on with ADFS» (Упрощение единого входа в систему при помощи служб ADFS) в июльском выпуске TechNet Magazine за 2006 г.

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

Наиболее важные вопросы при реализации заключались в балансировке нагрузки и изменении файлов политик ADFS. Балансировка нагрузки являлась сложной задачей как на глобальном, так и на локальном уровне. В производственной среде сначала будет использоваться глобальная балансировка со стороны наших партнеров по сети доставки содержимого (CDN — Content Delivery Network) Akamai или Savvis для кластеров интерфейсного веб-сервера в двух регионах. Это обеспечит доступность системы для конечных пользователей даже при маловероятном событии перехода в автономный режим пары региональных серверов. Это реализуется посредством автоматизации перехода на другой ресурс, основанной на службах проверки состояния сервера, предоставляемых сетями CDN. Кроме этого, имеется возможность легко и быстро добавить кластеры впоследствии. С целью сокращения затрат в наших подготовительных развертываниях было решено не использовать службу CDN.

На региональном уровне мы объединяли серверы в пары для обеспечения отказоустойчивости посредством кластеризации балансировки сетевой нагрузки (NLB). Мы не используем никаких специальных компонентов для балансировки нагрузки, настолько это легко осуществляется посредством аппаратных средств; однако, из соображений экономии мы снова используем NLB. Эта конфигурация обеспечивает гарантированную стабильность более чем на 99,9 процентов периода работоспособности во всех поддерживаемых рабочих средах.

Другой сложной задачей, с которой мы столкнулись, было обеспечение правильного распространения по всей рабочей среде файла политик ADFS, являющегося основой ADFS, и обеспечения репликации изменений, сделанных в этом файле. Для достижения этого используется еще один компонент Windows Server 2003 R2 — служба репликации распределенной системы файлов (DFS-R — Distributed File System-Replication), новый, основанный на состоянии, модуль репликации с несколькими хозяевами. На каждом фоновом сервере активировалось членство в группе DFS-R с 24-часовой репликации полной сетки. После этого не имеет значения, где возникает изменение файла политик — оно будет распространено на все серверы. До тех пор, пока сохраняется контроль за тем, кому разрешается изменять файл, служба остается стабильной и высокодоступной.

Была сделана попытка обеспечить выполнение всех изменений посредством оснастки ADFS. Однако на практике выяснилось, что время от времени приходится обновлять этот файл вручную. При обновлении вручную важно помнить, что ADFS отслеживает версию этого файла. Поэтому необходимо при расширении файла отражать эти изменения в рабочей среде:

urn:federation:parttestint 
127
 

Следует помнить также о том, что как и весь XML, файл XML с описанием политик чувствителен к регистру. В пределах файла XML с описанием политик имеется множество ссылок на приложения или другие серверы ADFS, и во всех случаях необходимо выполнять их дословное копирование с сервера на сервер. Обратите внимание на следующие распространенные примеры, где первый, RevocationCheckFlags, была введен вручную, а второй является адресом URL доверенного приложения, измененного с помощью пользовательского интерфейса:

None

https://adfstest.parttest.extranettest.microsoft.com/NTApp/

 В качестве дополнительного уровня защиты используется еще один компонент ADFS — прокси служб федерации (FS-P — Federation Service Proxy), который обеспечивает изоляцию слоя серверов FS-R от непосредственного доступа со стороны входящих запросов из Интернета. Уникальный метод реализации прокси в Microsoft.com состоит в использовании отдельного набора прокси для размещения нескольких рабочих сред ADFS в нашей подготовительной области. Интересно, что в период начального перевода технологии на рабочий режим было обнаружено, что для этого требуется внести небольшие изменения в раздел реестра. Раздел находится в HKLM\Software\Microsoft\WebSSO. Простым изменением значения исходного каталога в этом разделе обеспечивается возможность использовать прокси для нескольких сред. По умолчанию использовался следующий вариант:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”

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

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”

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

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

Не только для службы Active Directory

Не только Microsoft.com использует учетные записи Active Directory для проверки подлинности, но и мы тоже успешно внедрили учетные записи Windows Live ID. Было выяснено, что применение удостоверения Windows Live ID (WLID) 4.5 позволяет использовать учетную запись пользователя для делегирования прав доступа к ресурсам Майкрософт с помощью преобразования заявок пользователей. Это серьезная победа на пути к проверке подлинности типа единого входа, поскольку теперь нет необходимости в специальной доменной учетной записи.

Оставшиеся задачи

Основная задача, стоящая перед нами, заключается в управлении ADFS для обеспечения общего доступа к сертификатам подписывания маркера. Мы используем стандартные сертификаты, обычно остающиеся действительными в течение одного года, после чего требуется их обновление. При наступлении момента обновления все соответствующие серверы необходимо обновить согласованным образом, что окажет значительное влияние на серверы FS-R. При минимальной степени управляемости в случае 15 или 20 федераций хотелось бы обсудить масштаб, соответствующий сотням, если не тысячам. При таком масштабе потребовалось бы выделять специальный персонал для управления сертификатами SSL единой рабочей среды. У нас имеется несколько групп, рассматривающих методы автоматизации этого решения, но пока путь решения еще не найден.

Еще одна нерешенная задача состоит в том, что не все приложения поддерживают ADFS с момента установки. Для того чтобы узлы могли использовать преимущества ADFS, потребуется выполнить некоторую работу по программированию. Мы тесно сотрудничаем с группой служб Microsoft® Office SharePoint®, чтобы следующее поколение SharePoint поддерживало все, что необходимо для реализации ADFS.

Заключение

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

Для получения дополниетльных сведений см. статьи ADFS Overview (Обзор ADFS) и Active Directory Federation Services: A Path to Federated Identity and Access Management (Службы федерации Active Directory: путь к федеративному удостоверению и управление доступом).