Конфигурирование SharePoint 2010 и ADFS v2 Сквозной конец

В этом посте я собираюсь подробно рассказать о том, как настроить SharePoint 2010 и ADFS v2 вместе для использования проверки подлинности на основе утверждений SAML. Я включу шаги и сценарии PowerShell для демонстрации и постараюсь собрать все части в одну большую публикацию.

Сначала краткий обзор участвующих компонентов и того, что нам нужно сделать. В этом сценарии ADFS v2 является нашим провайдером идентификации, также известным как IP-STS (служба маркеров безопасности). Нам нужно настроить ADFS с информацией о нашей проверяющей стороне или RP. В этом случае SharePoint - это наша RP - она ​​зависит от ADFS, чтобы выполнить аутентификацию и предоставить претензии. С точки зрения SharePoint, мы должны настроить его так, чтобы он доверял IP-STS, который отправляет нам заявки, а затем нам нужно настроить веб-приложение и сайт, которые будут использовать эти заявки.

Начнем с создания проверяющей стороны в ADFS. Обратите внимание, что действительно не имеет значения, в каком порядке вы делаете эти вещи, но на практике я обычно сначала настраиваю ADFS. Перейдите на сервер, на котором установлен ADFS, и откройте приложение управления AD FS 2.0. Разверните узел Доверительные отношения и щелкните узел Доверяющая сторона.

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

Нажмите кнопку Пуск, чтобы продолжить.

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

Введите отображаемое имя и, при необходимости, описание для проверяющей стороны, а затем нажмите кнопку «Далее».

Выберите параметр для использования профиля AD FS 2.0, а затем нажмите кнопку «Далее».

Вы можете выбрать сертификат для шифрования самого токена SAML. Это делается не часто, потому что ADFS потребует, чтобы наше соединение с SharePoint было установлено по SSL, поэтому канал, по которому передается токен, уже зашифрован. Нажмите кнопку Далее.

Установите флажок Включить поддержку для пассивного протокола WS-Federation . Для URL-адреса протокола необходимо ввести URL-адрес корневого сайта веб-приложения SharePoint и включить подкаталог «_trust». В этом примере URL-адрес моего веб-приложения SharePoint https: // seo14 Таким образом, URL-адрес пассивного протокола WS-Federation https: // seo14 / _trust / , После ввода URL-адреса нажмите кнопку «Далее».

Для идентификатора доверия проверяющей стороны необходимо указать область, которую ваше веб-приложение будет передавать в ADFS при входе пользователей в веб-приложение. Область обычно создается в формате urn: foo: bar. Область связана с веб-приложением и показывает, как ADFS может сопоставить запрос на вход в систему, который поступает с проверяющей стороной, которой он доверяет. При использовании с SharePoint ADFS видит область, связанную с запросом входа в систему, ищет ее, чтобы найти доверие проверяющей стороны, а затем, после аутентификации пользователя, обращается к этому пассивному URL-адресу WS-Federation, чтобы узнать, куда перенаправить пользователя. после этого. Так что в этом случае я вошел в область urn: seo: sharepoint. Когда я пытаюсь перейти на свой сайт SharePoint в https: // seo14 Я буду перенаправлен в ADFS и настрою SharePoint для использования области urn: seo: sharepoint для этого запроса. Как только ADFS подтвердит подлинность, он снова перенаправит меня на https: // seo14 / _trust / потому что это пассивный протокол URL для этой проверяющей стороны. Добавьте любую область, которую вы хотите использовать, и запишите ее, потому что вам нужно будет ввести ее снова при настройке SharePoint. Затем нажмите кнопку «Далее».

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

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

Мы завершили настройку доверия проверяющей стороны, но нам все еще нужно создать правило для заявок, чтобы сообщить ADFS, какие заявки нужно отправить обратно в SharePoint. Поэтому оставьте флажок, чтобы открыть диалоговое окно «Изменить правила заявки», и нажмите кнопку «Закрыть».

Теперь мы собираемся создать новое правило, поэтому нажмите кнопку «Добавить правило…».

Мы собираемся отправлять атрибуты LDAP в качестве претензий, потому что в этом случае мы получаем информацию из Active Directory, то есть мы будем проходить аутентификацию в ADFS, а ADFS будет использовать корпоративную Active Directory для аутентификации нас и определения наших атрибутов. Поэтому оставьте значение по умолчанию выбранным и нажмите кнопку «Далее», чтобы продолжить.

Начните с ввода имени правила Claim; это может быть что угодно. Далее в раскрывающемся списке «Хранилище атрибутов» выберите Active Directory. Далее, для нашего сценария мы хотим отправить адрес электронной почты и группы, к которым пользователь принадлежит, обратно в SharePoint. Мы собираемся использовать адрес электронной почты в качестве идентификатора этого человека, и мы хотим, чтобы все группы, к которым принадлежит пользователь, были отправлены в заявке на роль. Чтобы выполнить сопоставление, выберите нужный атрибут в раскрывающемся списке слева, а затем выберите утверждение, что оно будет отправлено, как в раскрывающемся меню на правой панели. В этом случае мы хотим, чтобы атрибут E-Mail-Addresses из Active Directory отправлялся в стандартной заявке на адрес электронной почты. Мы хотим, чтобы группы, к которым принадлежит пользователь, были отправлены в стандартной заявке на роль. В этом случае я выбрал Token-Groups - Unqualified Names, потому что он отправляет имя группы в виде простой строки - имя группы. Вы можете отправить SID групп, но это становится все труднее использовать, когда вы пытаетесь назначить заявку на роль для группы SharePoint. После того, как вы закончили настройку этого правила, как описано здесь, нажмите кнопку Готово, чтобы завершить правило.

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

Там есть раздел для сертификатов для подписи токенов. У вас может быть от одного до нескольких сертификатов подписи токенов, но всегда будет ТОЛЬКО один основной сертификат подписи токенов. Нажмите на этот сертификат, а затем нажмите на ссылку Просмотр сертификата в правой панели.

В этом конкретном случае я решил использовать сертификат, который я создал для SSL на веб-сайте ADFS. Я не предполагаю, что это необходимо или даже рекомендую; это именно то, что я решил сделать. Теперь, когда вы просматриваете сертификат, нажмите на вкладку Details в верхней части диалогового окна.

Нажмите кнопку «Копировать в файл…». Это запустит мастер для сохранения копии сертификата на диск.

Нажмите кнопку Далее, чтобы продолжить.

Вам не нужен закрытый ключ, поэтому примите настройки по умолчанию и нажмите кнопку Далее.

Формат по умолчанию подходит, поэтому нажмите кнопку «Далее», чтобы продолжить.

Выберите место для сохранения сертификата и нажмите кнопку «Далее». Убедитесь, что вы помните это местоположение, поскольку вам нужно будет скопировать сертификат с того места, где вы его сохранили, на сервер SharePoint.

Вся информация, необходимая для локального копирования сертификата, была собрана, поэтому нажмите кнопку «Готово», чтобы завершить работу мастера и сохранить сертификат в локальном файле. Скопируйте этот файл на сервер SharePoint, и тогда мы закончили с сервером ADFS.

Переключитесь на сервер SharePoint, и мы начнем его настраивать. Прежде чем мы начнем настройку SharePoint, я рекомендую вам создать новое веб-приложение сейчас. Создайте его, чтобы использовать проверку подлинности на основе утверждений, но выберите «Встроенная проверка подлинности Windows - NTLM» для параметров проверки подлинности. Убедитесь, что вы настроили веб-приложение для использования порта 443 и выбрали переключатель с надписью Use Secure Sockets Layer (SSL). Создав веб-приложение, не забудьте зайти в диспетчер IIS и отредактировать привязки для нового виртуального сервера, чтобы можно было назначить соответствующий сертификат SSL. Эти шаги выходят за рамки данной публикации, но хорошо документированы во многих местах в Интернете. Напомним, что для нашего сценария есть веб-приложение, которое я создал, использующее порт 443 и SSL, а URL-адрес для этого веб-приложения: https: // seo14 ,

Первое, что я собираюсь сделать на стороне SharePoint, - это добавить сертификат подписи токена, который я скопировал с сервера ADFS. Прежде чем я сделаю это, мне нужно взглянуть на сертификат. Сертификат подписи токена может иметь один или несколько родительских сертификатов в своей цепочке. Если это произойдет, мне нужно добавить каждый сертификат в этой цепочке в список доверенных корневых органов SharePoint. Чтобы понять это, я найду сертификат подписи токена, который я скопировал из ADFS, и дважды щелкну по нему; это вызывает окно свойств сертификата. Если вы нажмете на вкладку «Путь сертификации», вы увидите, есть ли в цепочке другие сертификаты. В моем сценарии у моего сертификата подписи токена есть родитель - это сертификат корневого центра сертификации.

Что мне нужно сделать сейчас, так это для каждого сертификата в цепочке над моим сертификатом подписи токена мне нужно сохранить копию каждого из них локально. Я могу сделать это, нажав на сертификат, который активирует кнопку View Certificate в диалоговом окне. Если я нажму на это, откроется отдельное диалоговое окно свойств для этого сертификата. Затем я могу выполнить тот же процесс, который я описал ранее, чтобы сохранить копию сертификата на диск: нажмите на вкладку Details, нажмите кнопку Copy to File…, затем сохраните сертификат локально в виде файла .CER. В моем случае я сделал это и сохранил его в C: \ adfsParent.cer. Итак, теперь на моем сервере SharePoint у меня есть два сертификата:

· C: \ adfs.cer, который является сертификатом подписи токена, который я скопировал с моего сервера ADFS

· C: \ adfsParent.cer, который является родительским сертификатом для моего сертификата подписи токена.

Теперь, когда у меня есть оба этих сертификата, мне нужно добавить их в мой список доверенных корневых прав. Я собираюсь сделать это в PowerShell с помощью этого сценария:

$ root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 («C: \ adfsParent.cer»)

New-SPTrustedRootAuthority -Название «родительский токен для подписи токена» -Сертификат $ root

$ cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 («C: \ adfs.cer»)

New-SPTrustedRootAuthority -Имя «Сертификат подписи токена» -Сертификат $ cert

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

Далее я собираюсь создать сопоставления заявок, которые SharePoint будет использовать. Если вы помните, как ранее в этой статье я говорил, что собираюсь использовать адреса электронной почты и утверждения ролей в SharePoint. Вот PowerShell, который я буду использовать для создания этих сопоставлений:

$ map = New-SPClaimTypeMapping -IncomingClaimType « http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221 ; -IncomingClaimTypeDisplayName «EmailAddress» -SameAsIncoming

$ map2 = New-SPClaimTypeMapping -IncomingClaimType « http://schemas.microsoft.com/ws/2008/06/identity/claims/role&#8221 ; -IncomingClaimTypeDisplayName «Role» -SameAsIncoming

Далее я собираюсь создать переменную для области, которую я хочу использовать в SharePoint. Для этого сценария я сказал, что собираюсь использовать urn области: seo: sharepoint. Вот PowerShell для создания моей переменной области:

$ realm = «urn: seo: sharepoint»

Теперь я готов создать свой SPTrustedIdentityTokenIssuer. Здесь я связываю всю информацию о конфигурации, чтобы SharePoint знал, как подключаться и работать с IP-STS. Я покажу здесь PowerShell, а затем объясню важные части:

$ ap = New-SPTrustedIdentityTokenIssuer -Имя «Провайдер SAML» -Описание «Защищено SharePoint с помощью SAML» -realm $ realm -ImportTrustCertificate $ cert -ClaimsMappings $ map, $ map2 -SignInUrl « https: //congen1.contoso.local/adfs/ls&#8221 ; -IdentifierClaim « http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221 ;

Атрибут «Имя» - это то, что будет отображаться в вашем веб-приложении при настройке поставщика аутентификации, который он должен использовать. Атрибут «область» - это то, где мы подключаем область, которую мы хотим, чтобы SharePoint использовал с этим доверенным издателем маркеров идентификации. Атрибут ImportTrustCertificate - это то место, где мы передаем ему сертификат подписи токена, который мы скопировали с сервера ADFS. Атрибут «ClaimsMappings» - это то, где мы сообщаем ему, каковы утверждения о том, что мы хотим, чтобы этот доверенный издатель токена идентификации использовал. «SignInUrl» - это URL-адрес, на который должны перенаправляться пользователи для аутентификации с помощью IP-STS. В этом случае мы хотим, чтобы пользователи проходили аутентификацию на сервере ADFS с использованием встроенной безопасности Windows, поэтому мы отправляем их в подкаталог / adfs / ls. Наконец, атрибут «IdentifierClaim» сообщает SharePoint, какое из утверждений будет тем утверждением, которое используется для идентификации пользователей. В этом случае мы говорим, что адрес электронной почты - это то, как вы идентифицируете человека.

После выполнения этой последней команды PowerShell у нас есть SPTrustedIdentityTokenIssuer, который можно использовать с нашим веб-приложением SharePoint. Итак, теперь мы откроем браузер и перейдем к Центру администрирования. Нажмите ссылку «Управление веб-приложениями», затем выберите веб-приложение в списке, в котором будет использоваться ADFS для аутентификации, затем нажмите кнопку «Поставщики проверки подлинности» на ленте. Нажмите на ссылку в диалоговом окне, которая соответствует зоне, в которой вы собираетесь использовать ADFS для аутентификации. Прокрутите вниз до раздела Типы аутентификации. Теперь вы можете отменить выбор NTLM, и вы должны увидеть нового провайдера под названием «SAML Provider» в списке доверенных провайдеров.

Установите флажок рядом с ним и нажмите кнопку Сохранить, чтобы сохранить изменения. Теперь вы можете перейти и создать семейство сайтов для веб-приложения. Опять же, пошаговое описание этого процесса не входит в сферу этой публикации, но при этом необходимо помнить одну важную вещь. Когда вы добавляете Администратора семейства сайтов, не забудьте ввести имя в формате вашего удостоверения личности. Например, в этом случае заявка на удостоверение личности является адресом электронной почты. Поэтому, когда я добавил администратора семейства сайтов, я использовал имя [email protected], потому что это адрес электронной почты человека, которого я хочу стать администратором семейства сайтов.

Теперь я готов попробовать перейти на мою новую коллекцию сайтов. Я открываю браузер и набираю https: // seo14 и нажмите ввод. Первое, что происходит, это то, что я перенаправлен в SignInUrl для SPTrustedIdentityTokenIssuer, который связан с моим веб-приложением. Если вы помните из PowerShell, который использовался для создания SPTrustedIdentityTokenIssuer, этот URL-адрес https: //congen1.contoso.local/adfs/ls , Итак, вот что я вижу после ввода URL-адреса моего сайта SharePoint в браузере:

Вы можете видеть, что URL в окне браузера теперь указывает на мой сервер ADFS, и вы можете видеть изображение на заднем плане позади диалогового окна входа для сервера ADFS. Вы также можете заметить, что я вхожу в систему, используя свои учетные данные Windows, т.е. домен \ пользователь. Помните, что я могу сделать это, потому что я аутентифицируюсь на сервере ADFS, а не в SharePoint. SharePoint настроен на использование адреса электронной почты в качестве моей личности, но в будущем я буду проходить проверку подлинности в ADFS, а затем использую правило утверждений, которое мы создали, чтобы извлечь свой адрес электронной почты и группы и поместить их в утверждения. это будет отправлено обратно в SharePoint. Итак, после проверки подлинности я перенаправлен обратно в SharePoint на https: // seo14 / _trust / , как я настроил в проверяющей стороне, я настроил в ADFS. На этом этапе SharePoint завершит процесс аутентификации на своей стороне, поскольку он принимает заявки, полученные в токене SAML, и преобразует их в SPUser. Тогда я наконец прихожу на главную страницу сайта:

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

Это полный сквозной процесс с небольшим объяснением на стороне. Вы сможете использовать его для настройки и работы своих сайтов, следуя этим инструкциям.

Вы можете скачать приложение здесь:

Похожие