Єдиний вхід і центр керування

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

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

Профілі

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

  • ІП ініціював прив'язку POST -> POST

  • СП ініціював ПЕРЕНАПРАВЛЕННЯ -> прив'язка ПОСТ

Формат 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.

SingleLogout

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

Інтеграція Центру керування з 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). Якщо ваш вебекс-сайт інтегровано в Control Hub, веб-сайт успадковує керування користувачами. Якщо ви не можете отримати доступ до вебекс-зустрічей таким чином, а керування ними не здійснюється в Центрікерування, необхідно виконати окрему інтеграцію, щоб увімкнути єдиний вхід для вебекс-зустрічей.

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

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

1

Увійдіть у Центркерування.

2

Перейти до Управління > Безпека > Аутентифікація.

3

Перейдіть на вкладку Постачальник ідентифікаційних даних та натисніть Активувати єдиний вхід.

4

Виберіть постачальника ідентифікаційних даних.

5

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

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

Прив'язки довіри – це відкриті ключі, які діють як орган перевірки сертифіката цифрового підпису. Для отримання додаткової інформації зверніться до документації IdP.

6

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

Ім'я файлу метаданих Webex — idb-meta-<org-ID>-SP.xml.

Встановлення метаданих Webex в ADFS

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

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

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

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

  • Встановіть атрибут NameID Format на urn:oasis:names:tc:SAML:2.0:nameid-format:тимчасовий

  • Налаштуйте твердження на постачальнику ідентифікаційних даних, щоб включити ім'я атрибута 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

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

5

Для Вкажіть відображуване ім'ястворіть відображуване ім'я для цієї довіри покладаючоїся сторони, наприклад Webex, і виберіть Далі.

6

Для опції Вибрати правила авторизації видачівиберіть Дозволити всім користувачам доступ до цієї покладаючої сторонита натисніть Далі.

7

Для параметра Готово до додавання довіривиберіть Далі та завершіть додавання довіри, що залежить від неї, до ADFS.

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

1

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

2

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

  1. Введіть назву правила заявки.

  2. Виберіть Active Directory як сховище атрибутів.

  3. Зіставте атрибут LDAP E-mail-Addresses з типом вихідного твердження uid.

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

  4. Збережіть зміни.

3

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

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

  1. Відкрийте текстовий редактор і скопіюйте наступний вміст.

    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, який ви завантажили.

      Наприклад, ось приклад того, що ви бачите: http://ad0a.identitylab20.ciscolabs.com/adfs/services/trust" ID="_55515dde-8147-4183-8a85-b704d26b5dba">

      Скопіюйте лише ідентифікатор сутності з файлу метаданих ADFS та вставте його в текстовий файл, щоб замінити URL1.

    • URL2 знаходиться в першому рядку завантаженого вами файлу метаданих Webex.

      Наприклад, ось приклад того, що ви бачите: https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">

      Скопіюйте лише ідентифікатор сутності з файлу метаданих Webex та вставте його в текстовий файл, щоб замінити URL2.

  2. З оновленими URL-адресами скопіюйте правило з текстового редактора (починаючи з "c:") і вставте його в поле настроюваного правила на вашому сервері ADFS.

    Завершене правило має виглядати так:

  3. Виберіть «Готово», щоб створити правило, а потім вийдіть з вікна «Редагувати правила заявки».

4

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

5

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

6

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

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

7

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

Що далі

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

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

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

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

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

1

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

  • Поверніться на сторінку вибору сертифіката Центру керування у вашому браузері та натисніть Далі.
  • Знову відкрийте Центр керування, якщо він більше не відкритий у вкладці браузера. З перегляду клієнта в Control Hub перейдіть до розділу Керування > Безпека > Автентифікація, виберіть постачальника ідентифікаційних даних, а потім виберіть Дії > Імпорт метаданих.
2

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

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

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

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

3

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

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

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

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

4

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

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

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

Що далі

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

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

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

Оновлення довіри покладеної сторони Webex у ADFS

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

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

Перш ніж оновлювати довіру довірчої сторони Webex у ADFS, потрібно експортувати файл метаданих SAML з Control Hub.

1

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

2

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

3

Відкрийте Powershell.

4

Виконайте Get-AdfsRelyingPartyTrust, щоб прочитати всі довірчі угоди покладаючоїся сторони.

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

5

Виконати Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta--SP.xml" -TargetName "Webex".

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

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

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

6

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

  1. Перейти до Управління > Безпека > Аутентифікація.

  2. На вкладці Постачальник ідентифікації перейдіть до IdP та натисніть Додаткове меню

  3. Виберіть Тестовий постачальник ідентифікаторів.

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

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

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

Виправлення неполадок 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/' certificate identified by thumbprint '754B9208F1F75C5CC122740F3675C5D129471D80'. Можливі причини полягають у тому, що сертифікат було відкликано, ланцюжок сертифікатів не вдалося перевірити, як зазначено в налаштуваннях відкликання сертифіката шифрування довірчої сторони, що покладається, або термін дії сертифіката закінчився.

Якщо виникає ця помилка, вам потрібно виконати команди Set-ADFSRelyingPartyTrust -TargetIdentifier https://idbroker.webex.com/ -EncryptionCertificateRevocationCheck None

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

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

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

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

За потреби ви можете перевірити URL-адресу, перейшовши до Сервіс > Кінцеві точки > Метадані > Type:Federation Метадані в керуванні ADFS.

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

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

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

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