Налаштування єдиного входу в Control Hub за допомогою служб федерації Active Directory (ADFS)

Центр єдиного входу та керування

Єдиний вхід (SSO) - це сеанс або процес автентифікації користувача, який дозволяє користувачеві надавати облікові дані для доступу до однієї або декількох програм. Процес автентифікації користувачів для всіх додатків, на які їм надані права. Це виключає подальші підказки, коли користувачі змінюють програми під час певного сеансу.

Протокол Федерації мови розмітки тверджень безпеки (SAML 2.0) використовується для забезпечення автентифікації SSO між хмарою Webex і вашим постачальником ідентифікаційних даних (IdP).

Профілі

Webex App підтримує лише профіль SSO веб-браузера. У профілі SSO веб-браузера додаток Webex підтримує такі прив 'язки:

SP ініціював ПОСТ -> зв 'язування ПОСТІВ
SP ініціював ПЕРЕНАПРАВЛЕННЯ -> прив 'язка до ПУБЛІКАЦІЇ

Формат NameID

Протокол SAML 2.0 підтримує декілька форматів NameID для спілкування про конкретного користувача. Webex App підтримує наступні формати NameID.

urn:oasis:names:tc:SAML:2.0:nameid-format:transient
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

У метаданих, які ви завантажуєте з вашого IdP, перший запис налаштовано для використання в Webex.

Єдиний вихід

Програма Webex підтримує профіль єдиного виходу. У програмі Webex користувач може вийти з програми, яка використовує протокол єдиного виходу SAML, щоб завершити сеанс і підтвердити вихід за допомогою вашого IdP. Переконайтеся, що ваш IdP налаштований для єдиного виходу.

Інтегруйте Control Hub з ADFS

У посібниках із налаштування не описується налаштування всіх можливих конфігурацій, а наведено лише конкретний приклад інтеграції SSO. Наприклад, задокументовано дії для інтеграції nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient. Інші формати, як-от urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, використовуються для інтеграції SSO, але їх не охоплено в нашій документації.

Налаштуйте цю інтеграцію для користувачів у вашій організації Webex (включаючи Webex App, Webex Meetings та інші служби, адмініструвані в Control Hub). Якщо ваш сайт Webex інтегрований в Control Hub, сайт Webex успадковує управління користувачами. Якщо ви не можете отримати доступ до Webex Meetings таким чином, і він не керується в Control Hub, ви повинні зробити окрему інтеграцію, щоб увімкнути SSO для Webex Meetings. (Див. Налаштування єдиного входу для Webex для отримання додаткової інформації про інтеграцію SSO в Адміністрацію сайту.)

Залежно від того, що налаштовано в механізмах автентифікації в ADFS, інтегровану автентифікацію Windows (IWA) можна ввімкнути за замовчуванням. Якщо цей параметр увімкнено, програми, які запускаються через Windows (наприклад, Webex App і Cisco Directory Connector), автентифікуються як користувач, який увійшов у систему, незалежно від того, яку адресу електронної пошти було введено під час початкового електронного запиту.

Завантажте метадані Webex у локальну систему

У вікні клієнта перейдіть до розділу https://admin.webex.com" Керування" > "Параметри організації", а потім перейдіть до пункту "Аутентифікація", а потім увімкніть параметр "Єдиний вхід", щоб запустити майстер налаштування.

Виберіть тип сертифіката для вашої організації:

Самостійно підписаний Cisco- Ми рекомендуємо цей вибір. Дозвольте нам підписати сертифікат, щоб вам потрібно було поновлювати його лише раз на п 'ять років.
Підписано державним органом сертифікації - Більш безпечно, але вам потрібно буде часто оновлювати метадані (якщо ваш постачальник IdP не підтримує якорі довіри).

Якоря довіри - це відкриті ключі, які діють як повноваження для перевірки сертифіката цифрового підпису. Щоб отримати додаткову інформацію, зверніться до документації свого призначеного лікаря.

Завантажте файл метаданих.

Назва файлу метаданих Webex - idb-meta-<org-ID>-SP.xml.

Установіть метадані Webex в ADFS

Перш ніж почати

Control Hub підтримує ADFS версії 2.x або пізнішої.

Windows 2008 R2 містить лише ADFS 1.0. Необхідно встановити принаймні ADFS 2.x від Microsoft.

Для SSO та служб Webex постачальники ідентифікаційних даних (IdP) повинні відповідати такій специфікації SAML 2.0:

Установіть для атрибута формату NameID значення urn: oasis:names:tc:SAML:2.0:nameid-format:transient.
Налаштуйте заявку на постачальника посвідчень, щоб включити uid ім’я атрибута зі значенням, яке зіставлено з атрибутом, вибраним у Cisco Directory Connector або атрибутом користувача, що збігається з атрибутом, вибраним у службі ідентифікації Webex. (Наприклад, таким атрибутом може бути E-mail-Addresses або User-Principal-Name.) Див. інформацію про користувацький атрибут уhttps://www.cisco.com/go/hybrid-services-directory для інструкції.

1.	Увійдіть на сервер ADFS з дозволами адміністратора.
2.	Відкрийте консоль керування ADFS і перейдіть до Довірчі відносини > Довіри надійної сторони > Додайте довіру перевіряючої сторони .
3.	З Додати майстер довіри перевіряючої сторони вікно, виберіть Почати .
4.	Для Виберіть Джерело даних виберіть Імпортуйте дані про перевіряючу сторону з файлу , перейдіть до файлу метаданих Control Hub, який ви завантажили, і виберіть Далі .
5.	Для Укажіть відображуване ім’я , створіть відображуване ім’я для цієї довіри перевіряючої сторони, наприклад Webex і виберіть Далі .
6.	Для Виберіть Правила авторизації випуску , виберіть Дозволити всім користувачам доступ до цієї довіреної сторони і виберіть Далі .
7.	Для Готово додати довіру , виберіть Далі і завершите додавання повіреної довіри до ADFS.

Створіть правила заявки для автентифікації Webex

На головній панелі ADFS виберіть довірчі відносини, які ви створили, а потім виберіть Змінити правила запиту . На вкладці Правила перетворення випуску виберіть Додати правило .

На кроці Вибрати тип правила виберіть Надіслати атрибути LDAP як вимоги , а потім виберіть Далі .

Введіть a Ім’я правила запиту .
Виберіть Active Directory як сховище атрибутів.
Зіставте Адреси електронної пошти Атрибут LDAP для uid тип вихідної вимоги.

Це правило вказує ADFS, які поля зіставити з Webex для ідентифікації користувача. Напишіть типи вихідних заяв точно так, як показано.
Збережіть зміни.

Виберіть Додати правило знову, виберіть Надсилайте запити за допомогою користувацького правила , а потім виберіть Далі .

Це правило надає ADFS атрибут кваліфікатора імені SP, який Webex не надає.

Відкрийте текстовий редактор і скопіюйте наведений далі контент.
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "URL1", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "URL2");

Замініть URL1 і URL2 в тексті таким чином:
- URL1 є ідентифікатором запису із завантаженого файлу метаданих ADFS.
  Наприклад, нижче наведено зразок того, що ви бачите: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://ad0a.identitylab20.ciscolabs.com/adfs/services/trust" ID="_55515dde-8147-4183-8a85-b704d26b5dba">
  Скопіюйте лише ідентифікатор запису з файлу метаданих ADFS і вставте його в текстовий файл, щоб замінити URL1
- URL2 у першому рядку завантаженого файлу метаданих Webex.
  Наприклад, нижче наведено зразок того, що ви бачите: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">
  Скопіюйте лише ідентифікатор запису з файлу метаданих Webex і вставте його в текстовий файл, щоб замінити URL2.
За допомогою оновлених URL-адрес скопіюйте правило з текстового редактора (починаючи з "c:") і вставте його в поле користувацького правила на сервері ADFS.

Завершене правило має виглядати так:
Виберіть Завершити , щоб створити правило, а потім закрийте вікно «Змінити правила заявки».

Виберіть Довіра перевіряючої сторони в головному вікні, а потім виберіть Властивості на правій панелі.

Коли з’явиться вікно властивостей, перейдіть до розділу Розширений вкладка, SHA-256 а потім виберіть OK , щоб зберегти зміни.

Щоб завантажити файл, перейдіть за такою URL-адресою на внутрішньому сервері ADFS: https://< AD_ FS_ Сервер >/FederationMetadata/2007-06/FederationMetadata.xml

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

Збережіть файл на локальному комп’ютері.

Що далі

Ви готові імпортувати метадані ADFS назад у Webex із порталу керування.

Імпортуйте метадані IdP та увімкніть єдиний вхід після тесту

Після експорту метаданих Webex, налаштування вашого IdP та завантаження метаданих IdP до вашої локальної системи, ви готові імпортувати їх до вашої організації Webex з Control Hub.

Перш ніж почати

Не перевіряйте інтеграцію SSO з інтерфейсом постачальника ідентифікаційних даних (IdP). Ми підтримуємо лише потоки, ініційовані постачальником послуг (SP-ініційовані), тому ви повинні використовувати тест SSO Control Hub для цієї інтеграції.

Виберіть один із варіантів:

Поверніться на сторінку вибору сертифіката Control Hub у веб-переглядачі, а потім натисніть кнопку Далі.
Якщо Центр керування більше не відкривається на вкладці браузера, перейдіть у розділ " https://admin.webex.comКерування" > "Параметри організації", перейдіть до пункту "Автентифікація", а потім виберіть " Дії" > "Імпортувати метадані".

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

Ви повинні використовувати більш безпечний варіант, якщо ви можете. Це можливо лише в тому випадку, якщо ваш IdP використовував публічний ЦС для підписання своїх метаданих.

У всіх інших випадках ви повинні використовувати менш безпечний варіант. Це включає випадки, коли метадані не підписані, самопідписані або підписані приватним ЦС.

Okta не підписує метадані, тому ви повинні вибрати Менш безпечний для інтеграції Okta SSO.

Виберіть Test SSO setup (Тестування налаштування SSO), а коли відкриється нова вкладка браузера, аутентифікуйтеся за допомогою IdP, увійшовши в обліковий запис.

Якщо ви отримали помилку автентифікації, може виникнути проблема з обліковими даними. Перевірте ім 'я користувача та пароль та повторіть спробу.

Помилка Webex App зазвичай означає проблему з налаштуванням SSO. У цьому випадку повторіть кроки, особливо кроки, коли ви копіюєте та вставляєте метадані Control Hub в налаштування IdP.

Для безпосереднього спостереження за процесом SSO також можна клацнути Скопіювати URL у буфер обміну на цьому екрані й вставити в приватне вікно браузера. Після цього можна виконати вхід за допомогою SSO. Цей крок зупиняє помилкові позитивні результати через маркер доступу, який може бути в існуючому сеансі від входу в систему.

Поверніться на вкладку браузера Control Hub.

Якщо тест пройшов успішно, виберіть Успішний тест. Увімкніть SSO і натисніть кнопку Далі.
Якщо тест виявився невдалим, виберіть Невдалий тест. Вимкніть SSO і натисніть Далі.

Конфігурація SSO не набуває чинності у вашій організації, якщо ви не виберете першу перемикач і не активуєте SSO.

Що далі

Використовуйте процедури синхронізації користувачів Okta в Cisco Webex Control Hub, якщо ви хочете виконати підготовку користувачів з Okta в хмарі Webex.

Використовуйте процедури синхронізації користувачів Azure Active Directory в Cisco Webex Control Hub, якщо ви хочете виконати підготовку користувачів з Azure AD до хмари Webex.

Щоб вимкнути електронні листи, які надсилаються новим користувачам додатка Webex у вашій організації, виконайте процедуру, описану в розділі Придушити автоматизовані електронні листи. Документ також містить найкращі практики для розсилки повідомлень користувачам у вашій організації.

Оновлення довіри сторони, яка покладається на Webex, до ADFS

Це завдання стосується оновлення ADFS новими метаданими SAML з Webex. Є пов 'язані статті, якщо вам потрібно налаштувати SSO з ADFS, або якщо вам потрібно оновити (інший) IdP з метаданими SAML для нового сертифіката Webex SSO.

Перш ніж почати

Вам потрібно експортувати файл метаданих SAML з Control Hub, перш ніж ви зможете оновити Webex Relying Party Trust в ADFS.

Увійдіть на сервер ADFS з дозволами адміністратора.

Завантажте файл метаданих SAML з Webex до тимчасової локальної папки на сервері ADFS, наприклад. //ADFS_servername/temp/idb-meta-<org-ID>-SP.xml.

Відкрийте Powershell.

Виконайте команду Get-AdfsRelyingPartyTrust читати всі довірені сторони.

Зверніть увагу на TargetName параметр довіри сторони, що довіряє Webex. Ми використовуємо приклад "Webex", але він може відрізнятися у вашій ADFS.

Виконайте команду Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta-<org-ID>-SP.xml" -TargetName "Webex".

Переконайтеся, що ім 'я файлу та ім' я цілі замінено правильними значеннями з вашого середовища.

Див https://docs.microsoft.com/powershell/module/adfs/update-adfsrelyingpartytrust..

Якщо ви завантажили сертифікат Webex SP 5 year і увімкнули функцію відкликання сертифіката підпису або шифрування, вам потрібно виконати ці дві команди: Set-AdfsRelyingPartyTrust -SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None -TargetName "Webex".

Увійдіть в Control Hub, а потім перевірте інтеграцію SSO:

Перейдіть до меню Керування > Параметри організації, перейдіть до пункту Автентифікація та ввімкніть параметр єдиного входу, щоб запустити майстер налаштування.
Клацніть Next (Далі), щоб пропустити сторінку Import IdP Metadata (Імпорт метаданих IdP).

Вам не потрібно повторювати цей крок, оскільки ви раніше імпортували метадані IdP.

Перевірте з 'єднання SSO, перш ніж ввімкнути його. На цьому кроці виконується пробний запуск, що не впливає на налаштування вашої організації, поки не буде ввімкнено SSO на наступному кроці.

Для безпосереднього спостереження за процесом SSO також можна клацнути Скопіювати URL у буфер обміну на цьому екрані й вставити в приватне вікно браузера. Після цього можна виконати вхід за допомогою SSO. Це дає змогу видалити будь-яку інформацію, кешовану у вашому веббраузері, яка може призвести до отримання хибнопозитивного результату під час тестування конфігурації SSO.

Увійдіть, щоб завершити тест.

Усунення несправностей ADFS

Помилки ADFS в журналах Windows

У журналах Windows можна побачити код помилки журналу події ADFS 364. Деталі події ідентифікують недійсний сертифікат. У цих випадках хост ADFS не дозволяється через брандмауер на порту 80 перевіряти сертифікат.

Під час спроби побудувати ланцюжок сертифікатів для довіри перевіряючої сторони сталася помилка

Під час оновлення сертифіката SSO під час входу може з’явитися така помилка: Invalid status code in response.

Якщо ви бачите цю помилку, перевірте журнали засобу перегляду подій на сервері ADFS і знайдіть таку помилку: An error occurred during an attempt to build the certificate chain for the relying party trust 'https://idbroker.webex.com/<org-ID>' certificate identified by thumbprint '754B9208F1F75C5CC122740F3675C5D129471D80'. Можливими причинами є те, що сертифікат було відкликано, ланцюжок сертифікатів не вдалося перевірити, як зазначено в параметрах відкликання сертифіката шифрування довіреної сторони, або сертифікат не має терміну дії.

У разі виникнення цієї помилки необхідно запустити команди Set-ADFSRelyingPartyTrust -TargetIdentifier https://idbroker.webex.com/<orgID> -EncryptionCertificateRevocationCheck None

Ідентифікатор федерації

Ідентифікатор федерації чутливий до регістру. Якщо це адреса електронної пошти вашої організації, введіть її точно так, як її надсилає ADFS, інакше Webex не зможе знайти відповідного користувача.

Користувацьке правило запиту неможливо записати для нормалізації атрибута LDAP до його надсилання.

Імпортуйте метадані із сервера ADFS, який ви налаштували у своєму середовищі.

За потреби можна перевірити URL, перейшовши до Служба > Кінцеві пристрої > Метадані > Тип: метадані федерації в Керуванні ADFS.

Синхронізація часу

Переконайтеся, що системний годинник вашого сервера ADFS синхронізовано з надійним джерелом часу в Інтернеті, що використовує протокол мережевого часу (NTP). Використовуйте наведену далі команду PowerShell, щоб перекосити годинник лише для відносин довіри з перевіряючої сторони Webex.

Set-ADFSRelyingPartyTrust -TargetIdentifier "https://idbroker.webex.com/$ENTITY_ID_HEX_VALUE" -NotBeforeSkew 3

Шістнадцяткове значення є унікальним для вашого середовища. Замініть значення зі значення ідентифікатора дескриптора об’єкта SP у файлі метаданих Webex. Наприклад:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/c0cb726f-a187-4ef6-b89d-46749e1abd7a">