Microsoft. com изнутри

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

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

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

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

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

Термин
Определение
Федерация Пара областей либо доменов, установившая доверие федерации Active Directory.
Ресурс служб федерации (FS-R — Federation Service Resource) Направляет входящий запрос проверки подлинности серверу FS-A и требуемым ресурсам.
Учетные записи служб федерации (FS-A — Federation Service Accounts) Предоставляет маркер учетной записи для проверки на подлинность на сервере FS-R.
Прокси служб федерации (FS-P — Federation Service Proxy) Обеспечивает слой, изолирующий серверы FS от входящего трафика Веба.
Заявка Заявление, которое делает сервер (к примеру имя, удостоверение, ключ, группа, льгота либо способность) о юзере.
Обнаружение области У каждого сервера FS-A имеется домен либо область, в какой хранятся учетные данные для входа в систему. Операция обнаружения области определяет, какой FS-A употребляется для сеанса ADFS.

Решение ADFS

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

Microsoft.com изнутри
Рис.
2 Поток ADFS

Последующей остановкой на этом
маршруте является возврат на сервер 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 для кластеров интерфейсного
веб-сервера в 2-ух регионах. Это обеспечит доступность системы для
конечных юзеров даже при маловероятном событии перехода в
автономный режим пары региональных серверов. Это реализуется
средством автоматизации перехода на другой ресурс, основанной на
службах проверки состояния сервера, предоставляемых сетями 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, и во всех случаях
нужно делать их дословное копирование с сервера на сервер.
Направьте внимание на последующие всераспространенные примеры, где 1-ый,
RevocationCheckFlags, была введен вручную, а 2-ой является адресом
URL доверенного приложения, модифицированного при помощи пользовательского
интерфейса:

None

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

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

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWebSSO]
“InitialDirectory”=”E:\\ADFS\\parttestint”

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

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWebSSO]
“InitialDirectory”=”E:\\ADFS\\parttest”

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

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

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

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

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

Основная задачка, стоящая
пред нами, заключается в управлении ADFS для обеспечения общего
доступа к сертификатам подписывания маркера. Мы используем
стандартные сертификаты, обычно остающиеся действительными в течение
1-го года, после этого требуется их обновление. При пришествии
момента обновления все надлежащие серверы нужно обновить
согласованным образом, что окажет существенное воздействие на серверы
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: путь к
федеративному удостоверению и управление доступом).

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.

Ремонт вмятин на кузове без покраски http://remontgruzovik.ru/ Руководство по ремонту кузова всех моделей.