- Выбор нового сертификата взаимодействия между сервисами (service communication certificate)
- Выпуск сертификата
- Изменение ssl сертификата в конфигурации
- Использование ad federation service для авторизации пользователей на aws с раздачей прав
- Проверка корректности установки новых сертификатов
- Установка сертификата в хранилище сертификатов компьютера
- Заключение
Выбор нового сертификата взаимодействия между сервисами (service communication certificate)
После импорта нужного нам сертификата в консоли администрирования AD FS необходимо указать, что для взаимодействия между сервисами необходимо использовать именно этот сертификат:
1. Запустим оснастку управления AD FS (AD FS Management) и перейдем в узел управления сертификатами:
2. Справа в меню действий выбираем пункт “Set Service Communication Certificare…”.
3. В появившемся диалоговом окне необходимо выбрать актуальный сертификат и нажать “OK”.
Выпуск сертификата
Мы не будем рассматривать непосредственно процесс выпуска сертификата. Однако, отмечу, что в нашем случае был выпущен бесплатный сертификат от Let’s Encrypt, как рассказано в этой статье.
Изменение ssl сертификата в конфигурации
Далее нам необходимо изменить сертификат в конфигурации AD FS.
Для этого нам необходимо знать отпечаток нашего нового сертификата:
Изменим SSL сертификат в конфигурации AD FS:
Set-AdfsSslCertificate –Thumbprint 62ae53ebc1efc7e9db916fced37d1e5840b7acf9Использование ad federation service для авторизации пользователей на aws с раздачей прав
Вольный перевод статьи Jeff Wierer “
Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0
” с добавлениями и уточнениями.
1. Исходные данные
2. Подготовка
3. Конфигурирование AD
4. Установка ADFS
5. Конфигурирование ADFS
6. Конфигурирование AWS
7. Тестирование
8. Известные ошибки и их решения

1. Исходные данные
Поднятый AD Windows 2021
Автор использовал EC2 c Windows 2008R2 на Amazon, я виртуалку в локальной сети Windows 2021 с доступом в интернет.
Аккаунт AWS (который будет платить за все )
Прямые руки
Цель: Дать возможность пользователю AD авторизоваться в AWS с заданными правами (получить роль) в зависимости от группы AD.
Схема:

1. Пользователь (будет Bob) открывает страницу (https://ADFS.domain.name/adfs/ls/IdpInitiatedSignOn.aspx)
2. Bob авторизуется (ADFS запрашивает необходимые поля в AD)
3. Браузер Bob-а получает необходимые данные в формате SAML от ADFS
4. Браузер отправляет полученые данные на серсис авторизации SAML (https://signin.aws.amazon.com/saml)
5. Браузер Bob-а получает URL для входа на консоль AWS
2. Подготовка
2.1. У вас уже поднят AD и заведены пользователи, которые состоят в различных группах.
2.2. Поднят IIS (как поднять роль IIS)
2.3. Сгенерировать самоподписанный SSL сертификат. (как сгенерировать самодписаный SSL сертификат) сразу установите его для дефолтного сайта.
3. Конфигурирование AD
3.1. Необходимо создать две группы AWS-Production и AWS-Billing
3.2. Создать пользователя Bob (Внимание!!! у пользователя должно быть заполнено поле email: bob@youdomain.com, в противном случае вы получите ошибку при входе на AWS консоль)
3.3. Добавить Bob в созданные группы AWS-Production и AWS-Billing
3.4. Создать еще одного пользователя ADFSSVC. Специальный сервисный аккаунт для соединения с AD.
4. Установка ADFS
Существует несколько версий ADFS
Автор скачивает ADFS v2 и производит его установку.
Мы же будем поднимать роль ADFS
Сложности там никакой нет, три скриншота помогут нажать кнопку далее >
5. Конфигурирование ADFS
Вот по этому линку можно вызвать конфигуратор ADFS



Соединяемся с AD с текущим пользователем.

Тут нам нужен сертификат, который мы сгенерировали в IIS (п. 2.3) и имя нашего будущего ADFS (adfs.you-domain.com) дисплайнайм — NAME YOUR COMPANY

Выбираем сервис аккаунт ADFSSVC который мы создали в п. 3.4

Создаем новую базу данных

Проверяем…

Прединсталяционная проверка… Жмем Configure

Готово.
Запускается консоль поиском «AD Management» в сроке поиска windows


Далее переходим Trust Relationships and choose Relying Party Trusts
Правая кнопка -> Add Relying Party Trust

Выбираем Claims aware

Выбираем «Import data the relying party published online …» и вводим строчку https://signin.aws.amazon.com/static/saml-metadata.xml она для всех одинакова и предоставляется AWS.

Вбиваем имя “AWS GO” на ваше усмотрение или оставляем как есть.

Выбираем «Permit all user…» доступ разрешен всем.

Перепроверить и Готово.

Правой кнопкой на нашем релеи и выбираем «Edit Claim Issuence Policy»

Начинаем добавлять наши правила:
5.1 Получение имени пользователя. Шаблон: Transform an Incoming Claim далее заполняем поля:
a. Claim rule name: NameId
b. Incoming claim type: Windows Account Name
c. Outgoing claim type: Name ID
d. Outgoing name ID format: Persistent Identifier
e. Pass through all claim values: checked

Готово.
5.2 Получение списка ролей для пользователя. Шаблон: Send LDAP Attributes as Claims,

поля:
a. Claim rule name: RoleSessionName
b. Attribute store: Active Directory
c. LDAP Attribute: E-Mail-Addresses
d. Outgoing Claim Type:
https://aws.amazon.com/SAML/Attributes/RoleSessionName
Готово
5.3 Важное замечание: В этом правиле будут извлечены все роли для пользователя и сопоставлены с подобными ролями в IAM (т.е. роли которые начинаются с AWS-…). Данное правило извлекает все членства в AD. Шаблон: Send Claims Using a Custom Rule

, поля
a. Claim rule name: Get AD Groups
b. Custom role:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);
к добавлению следующего правила нужно будет вернуться после п.6 (или же его можно добавить и в последующем изменить ID)
5.4 Добавляем еще одно правило подобно 5.3 оно будут такое:
a. Claim rule name: Roless
b. Custom role:
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/ADFS-"));

Тут вам нужно поменять значение 123456789012 на свое из IAM AWS

Это будет описано в п.6
6. Конфигурирование AWS
Все действия происходят в консоле AWS 🙂
6.1 Создание SAML провайдера
a. IAM -> Identity providers -> Create Provider
Provider Type — SAML
Provider Name — ADFS
Metadata Document — это тайл нужно взять (скачать) на вашем FS сервере по адресу https:///FederationMetadata/2007-06/FederationMetadata.xml
если файл недоступен посмотрите п.8 — Известные ошибки и их решения

b. Создадим две роли для наших пользователей
IAM Roles Roles -> Create Role

Набрасывайте необходимые политики (например Billing (дефолтная политика) для пользователей кто будет следить за деньгами, или можете предварительно создать свою собственную политику и тут ее назначить)

присвоить тэги, если нужно…

Дать имя: Имя после “-” должно совпадать с именем в AD после “-” ASFS-Billing = AWS-Billing в этом случае ваш пользователь попадал в нужную группу.
И нажать Create role

7. Тестирование
7.1 В вашем любимом браузере зайдите на страницу вашего сервера https://localhost/adfs/ls/IdpInitiatedSignOn.aspx (самоподписанный сертификат нужно будет подтвердить)
Откроется страница с подобным содержанием

Вводим данные нашего пользователя AD

И нас перенаправляет на страницу AWS с предложением роли под которой пользователь будет работать в AWS

это происходит потому что наш Bob состоит сразу в двух группах AD (AWS-Production и AWS-billing).
Выбираем AWS-billing и видим необходимые настройки (можем смотреть и править бюджет но не имеет права создавать EC2 согласно тем ролям которые мы ему определили)

8. Известные ошибки и их решения
8.1 Портал не отвечает или не находит нужные страницы. Например:
https://localhost/adfs/ls/IdpInitiatedSignOn.aspxРешение:
На сервере ADFS необходимо выполнить PowerShell команду
Set-AdfsProperties -EnableIdPInitiatedSignonPage $trueТут же можно поставить лого на страницу приветствия
Set-AdfsWebTheme -TargetName default -Illustration @{path="C:pathadfslogo.jpg"}8.2 При перенаправлении на консоль AWS вы получайте ошибку вида:
RoleSessionName is required in AuthnResponse (Service: AWSSecurityTokenService; Status Code: 400; Error Code: InvalidIdentityToken; Request ID: e4ddf8cd-d7b7-11e9-8729-09c90d2561b0). Please try againРешение:
Вероятнее всего у вашего пользователя не заполнено поле email в AD

Решение 2: Вероятно есть ошибка в написании группы в AD и роли в AWS
Проверка корректности установки новых сертификатов
Проверить корректно ли установились все необходимые сертификаты или нет можно указанным ниже способом.
- Сначала проверим – корректно ли установился SSL сертификат:
Get-AdfsSslCertificateМы видим, что отпечаток сертификата соответствует тому сертификату, который мы установили ранее, т.е. SSL сертификат установился корректно.
2. Далее проверим сертификат (Service Communication):
Get-AdfsCertificate -CertificateType Service-CommunicationsКак видно из скриншота выше – установлен именно тот сертификат, который нам нужен.
3. Последним шагом можем выполнить тестовый вход. Для этого в любом браузере перейдите по следующему пути:
Установка сертификата в хранилище сертификатов компьютера
После того, как сертификат был выпущен его необходимо установить в локальное хранилище сертификатов компьютера. Для этого выполним импорт сертификата:
1. Запустим мастер импорта и выберем локальное хранилище компьюетра:
2. Укажем путь до файла с сертификатом:
3. Укажем пароль к PFX файлу и скажем, что мы сделаем закрытый ключ экспортируемым:
4. Выберем опцию автоматического определения контейнера в хранилище сертификатов компьютера. В таком случае сертификат импортируется в контейнер “Personal“. Это именно то, что нам нужно:
5. Завершим процедуру импорта:
6. В случае успешного импорта мастер импорта сертификата сообщит нам об этом:
Так же мы увидим наш сертификат в контейнере “Личное” локального хранилища сертификатов компьютера:
Заключение
В данной публикации мы выполнили замену SSL сертификата на сервер с AD FS, а также замену сертификата для Service Communication.
Затем мы выполнили шаги для проверки – корректно ли установились все необходимые нам сертификаты или нет.
