Керування користувачами

У нас є централізована система управління користувачами, що лежить в основі Control Hub, де користувачі є окремими та унікальними в межах усієї організації (і всього Webex). В Адміністрації сайту профіль користувача відрізняється від місця зустрічі.

Єдиний вхід (SSO) з автоматичним створенням облікового запису

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

Ця функція доступна також і в Control Hub. Додаткову інформацію див. у розділі Створення та оновлення автоматичного облікового запису SAML в Control Hub .

Багато організацій, які використовують SSO, можуть вважати за краще централізовано керувати своїми користувачами в засобах зовнішніх каталогів, таких як Microsoft^® Active Directory і Microsoft Azure, а також вимагати автентифікації у зовнішніх постачальників посвідчень.

Детальніше про:

• Додавання користувачів до Control Hub.

• Інтеграція організації Control Hub із постачальником посвідчень.

Обов'язкові дані профілю та коди відстеження

Адміністрація сайту дозволяє вказати обов'язкові поля профілю для нових користувачів (попередній скріншот). Ви можете розширити це, щоб вимагати коди відстеження для створення користувача (скріншот нижче). Якщо ви налаштуєте ці додаткові вимоги, ви не зможете додавати користувачів на сайт без них.

Центр керування потребує лише короткого імені та адреси електронної пошти для створення користувача.

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

Ви повинні вимкнути обов'язкові поля профілю та коди відстеження, перш ніж оновлювати сайт до Центру керування.

Керування паролями та блокування

Адміністрація сайту має функцію, яка тимчасово блокує користувачів, якщо вони не можуть увійти після ряду спроб.

Control Hub має наступні опції для запобігання несанкціонованого доступу:

• Автоматичний тайм-аут після перших кількох невдалих спроб.

• Механізм CAPTCHA (повністю автоматизований публічний тест Тьюринга, щоб відрізнити комп'ютери та людей).

• Законні користувачі мають можливість самообслуговування змінювати свої забуті паролі.

Ліцензування хоста

Хости мають бути в організації Центру контролю

В Адміністраторі сайту ви можете призначити хост-ліцензію будь-якому користувачеві. Керуючи сайтом у Центрі керування, ліцензії на хост (і роль учасника) можна призначати лише користувачам у тій самій організації Control Hub.

Самостійна реєстрація для облікового запису Хоста

Адміністратор сайту може дозволити користувачам запитувати обліковий запис (хост) на сайті. Ви також можете дозволити користувачам з обліковим записом запитувати додаткові послуги на сайті. (див. скріншоти).

Коли ви керуєте сайтом нарад у Центрі керування, користувачі не можуть запитувати власний обліковий запис хоста для цього сайту.

Control Hub має централізований автоматизований спосіб призначення ліцензій на наради новим користувачам. Читати https://help.webex.com/n3ijtao.

Ви також можете керувати ліцензіями користувачів за допомогою API або групами за допомогою CSV.

Якщо ви хочете, щоб користувачі запитували свої облікові записи хостів, ви можете налаштувати довідку/підтримку сайту за допомогою вказівників, щоб зв'язатися з адміністраторами або зв'язатися з іншими інструментами.

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

Control Hub має інші параметри керування ліцензіями, наприклад шаблони автоматичного призначення. Ви можете отримати звіт про неактивні хости, які допоможуть вам видалити ліцензії у цих користувачів, окремо чи масово, або за допомогою API.

Якщо вам потрібна ця опція автоматичної деактивації, а інші параметри в Control Hub вам не підходять, то вам слід уникати оновлення сайту до Control Hub в цей час.

Автоматичне створення облікового запису для нових користувачів

Якщо на вашому веб-сайті ввімкнуто автоматичне створення облікового запису в адміністраторі сайту, ви можете ввімкнути подібну функцію в Центрі керування з автоматичним створеннямоблікового запису SAML. Обов'язково також налаштуйте автоматичний шаблон ліцензії, щоб нові користувачі автоматично отримували призначені ліцензії після створення облікових записів в організації Control Hub.

Організації із синхронізацією каталогів

Якщо вашу організацію настроєно на синхронізацію каталогів, переконайтеся, що на сайті присутні всі користувачі, яких потрібно включити до вашої організації. Це потрібно зробити за 24 години до початку процесу оновлення сайту, щоб користувачі на сайті могли бути пов'язані з новими користувачами у вашій організації Control Hub.

Доступ адміністратора до вебсайтів Webex після оновлення

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

API XML

API XML тепер сумісні з керованими сайтами Центру керування. Ви можете прочитати про деталі та застереження в оновленняхXML API 41.11.0.

URL-адреси служби XML API не змінюються після того, як сайт буде оновлено з адміністратора сайту до Control Hub. Ті ж URL-адреси API продовжать працювати. Cisco рекомендує всім інтеграціям API використовувати OAUTH для автентифікації.

Автентифікація в XML API

Інтеграції, які не використовують Webex OAUTH для автентифікації , можуть не вдатися після оновлення вебсайту до Control Hub. У наведеній нижче таблиці показано, який тип автентифікації адміністратора буде працювати після оновлення вашого вебсайту.

Таблиця 1. Типи автентифікації адміністратора, які працюватимуть в XML API після оновлення вебсайту.

Тип автентифікації адміністратора в XML API перед оновленням вебсайту	Адміністратор організації SSO після оновлення вебсайту	Адміністратор не працює в організації SSO після оновлення вебсайту
ім’я користувача (webExID)/пароль	Буде працювати*	Буде працювати*
ім’я користувача (webExID)/квиток на сеанс	Буде працювати	Буде працювати
ім’я користувача/OAUTH (webExAccessToken)	Буде працювати	Буде працювати
електронна пошта/пароль	Буде працювати*	Буде працювати*
електронна пошта/квиток на сеанс	Буде працювати	Буде працювати
електронна пошта/OAUTH (webExAccessToken)	Буде працювати	Буде працювати

Після оновлення вебсайту до Control Hub ім’я користувача встановлюється електронна пошта для всіх користувачів. Якщо для корисних навантажень API використовується ім’я користувача , тоді корисні навантаження повинні використовувати адресу електронної пошти після оновлення вебсайту.

Роль адміністратора в Control Hub для інтеграцій API

Адміністратори, які мають лише роль адміністратора вебсайту, можуть не виконувати деякі операції з XML API, як-от зміна адреси електронної пошти користувача або відображуваного імені після оновлення вебсайту на вебсайт Control Hub. Для адміністраторів, чиї облікові дані використовуються для інтеграції API, ми рекомендуємо рекламувати цих адміністраторів до повноправних адміністраторів організації в Control Hub, в ідеалі перед оновленням сайту до Control Hub.

Залежно від того, що робить ваша інтеграція, адміністраторам також може знадобитися призначити обліковий запис організатора нарад на вебсайті Control Hub, щоб інтеграція працювала (це не вимагалося для адміністраторів на сайтах адміністратора вебсайту).

Відмінності XML API в концентраторі керування

Більшість інтеграцій XML API повинні працювати, без будь-яких змін, після оновлення вашого сайту. Але є деякі винятки, які детально описані в наступному списку:

• CreateUser — На вебсайтах під керуванням Control Hub ця операція також може створити користувача в організації, яка володіє вебсайтом, перш ніж призначати ліцензію. Якщо користувач вже існує в іншій організації, ця операція провалиться. Параметр ідентифікатора PMR не набуде чинності для користувачів, які ще не мають активного стану в Control Hub.

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

• SetUser — це може призвести до призначення або видалення ліцензії сайту нарад у користувача (залежно від параметрів API або корисного навантаження).
• DelUser—видаляє ліцензію на сайт нарад, але не видаляє користувача з організації Control Hub.
• LstsummaryUser—Також повертає ідентифікатор об’єкта користувача.
• AuthenticateUser — На вебсайтах під керуванням Control Hub ми рекомендуємо створити посвідчення сеансу через AuthenticateUser , а не використовувати ім’я користувача й пароль для кожного XML API. Використання відповіді SAML у вмісті тіла не підтримується під час цього виклику для керованих сайтів Центру керування.

ІНШІ API

Control Hub має власні API, зокрема API «Люди» та «Ліцензійні REST» для створення та ліцензування користувачів за адресою:

• https://developer.webex.com/docs/api/v1/people

• https://developer.webex.com/docs/api/v1/licenses

Типи сеансів і коди відстеження також доступні з REST API на сторінці:

• https://developer.webex.com/docs/api/v1/session-types
• https://developer.webex.com/docs/api/v1/tracking-codes

Однак інші API, наведені вище, не підтримують усі функції керування користувачами, доступні в API XML. Наприклад, вам усе одно потрібно буде використовувати XML API для призначення ліцензій нарад користувачам за межами організації, що володіє вебсайтом. People API не підтримує призначення ролей адміністратора сайту користувачам. Якщо ви хочете призначити ролі адміністратора сайту через API, вам все одно потрібно використовувати XML API.

Можна використовувати People API для створення адміністраторів організації з повними дозволами (або лише для читання), а ці адміністратори також можуть керувати (або переглядати) вебсайтами для нарад під керуванням вашого Control Hub.

Майбутні плани (з урахуванням змін)

• Новий ліцензійний API, який також може надати ліцензії сайту для нарад зовнішнім користувачам, які не належать до тієї самої організації, яка створила сайт. Сьогодні ліцензії зовнішніх користувачів доступні вручну в Control Hub.
• SCIM API для створення та видалення користувачів в організації.
• Довгостроковий напрямок Cisco полягає в використанні лише REST API (для всіх операцій над користувачами та вебсайтами для нарад). XML API для управління користувачами продовжуватимуть підтримуватися до тих пір, поки REST API не зможуть використовуватися виключно для всіх операцій управління користувачами. XML API керування користувачами також будуть застарілі (дата TBD).

Майбутні зміни для випуску 43.6

Поки що, перш ніж перенести вебсайт до Control Hub, необхідно було вимкнути ці дві функції:

• Обов’язкові поля профілю організатора
• Обов’язкові коди відстеження

Починаючи з випуску 43.6, вебсайтам, які беруть участь у бета-версії для користувацьких атрибутів і обов’язкових функцій полів профілю організатора, більше не потрібно буде вимкнути ці функції перед оновленням вебсайту до Control Hub. Натомість майстер повідомить вам про перегляд цих двох функцій, оскільки поточну конфігурацію буде скопійовано в організацію Control Hub.

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

Якщо ви берете участь у обов’язковій бета-версії кодів відстеження та користувацьких атрибутів , ви побачите це доручення:

Якщо ви не берете участь у цих бетах, продовжуйте читати наступний розділ.

Вимкнути функції, які блокують оновлення вебсайту

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

Демонстрацію про те, як оновити сайт до Control Hub, дивіться в цьому відео.

1. Увійдіть у службу адміністрування вебсайту Webex і перейдіть до меню Конфігурація > Загальні налаштування вебсайту > Параметри.

   • Знайдіть і вимкніть опцію Дозволити реєстрацію облікового запису хоста.

   • Знайдіть Обов'язковий для реєстрації облікового запису: і очистіть усі поля для обов'язкових полів профілю користувача.

2. Клацніть Оновити.

3. Перейдіть до розділу Налаштування > Загальні параметри сайту > Кодивідстеження.

4. У стовпці Профіль хоста змініть усі рядки коду відстеження, позначені як Обов'язкові для AdminSet або Необов'язкові.

   • Детальніше про коди відстеження читайте за адресою https://help.webex.com/izu2ty.

   Усі значення коду відстеження для користувачів зберігаються під час оновлення сайту до Центру керування.

У майбутньому це обмеження буде скасовано, і ви зможете зіставити коди відстеження з обов’язковими користувацькими атрибутами в Control Hub для еквівалентної функціональності.

Як перевірити наявність користувачів, які блокуватимуть оновлення сайту

1. Увійдіть в обліковий запис Адміністрації сайту та відкрийте сторінку Адміністрування оновлень.

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

3. Дочекайтеся завершення експорту. Цей процес може зайняти деякий час в залежності від часу початку і кількості користувачів на сайті. Експорт призупиняється на 6 хвилин вгорі години (від xx:57 до xx:03).

4. Натисніть кнопку Завантажити файл CSV після завершення експорту.

   Ваш браузер завантажує users-to-review.csv.

5. Відкрийте файл CSV і встановіть прапорець Біля стовпця Рекомендована дія (останній стовпець). Виконайте рекомендовану дію для кожного користувача у файлі.

Користувачі з невідповідними адресами електронної пошти

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

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

• Змінення адреси електронної пошти користувача в адміністраторі сайту відповідно до адреси електронної пошти Центру керування

  Користувачі можуть редагувати свої профілі адміністратора сайту: https://help.webex.com/nmig1kcb

• Змініть адресу електронної пошти користувача в Control Hub, щоб вона відповідала адресу електронної пошти адміністратора вебсайту: https://help.webex.com/nsi3kgb.

  Користувачі можуть змінити власні адреси електронної пошти в організації Control Hub: https://help.webex.com/nme40aeb

Зовнішні користувачі з ліцензією Basic Meetings

Перш ніж здійснити перенесення вебсайту з адміністратора вебсайту до Control Hub, зовнішніх користувачів із ліцензіями Basic Meetings необхідно деактивувати або оновити до платних ліцензій Webex Meetings.

Як деактивувати користувачів

Для індивідуальної деактивації користувача в Адміністрації Сайту:

1. Перейдіть до розділу Керування користувачами > Редагувати користувача.

2. Використовуйте елементи керування індексом, пошуком і фільтром, щоб знайти користувача.

3. Зніміть прапорець Активний .

4. Надішліть зміни.

   Додаткову інформацію див. в розділі Керування обліковими записами користувачів у службі адміністрування вебсайту Webex .

Для пакетної деактивації користувача в Адміністрації Сайту:

1. Експортуйте користувачів до файлу CSV.

2. Відкрийте файл CSV й змініть значення стовпця Активний на N для всіх користувачів, які зазнали впливу.

3. Імпортуйте змінений файл CSV.

   Користувачі, яких ви змінили, тепер неактивні .

   Для отримання більш детальної інформації дивіться розділ Пакетний імпорт та експорт користувачів Webex в розділі Адміністрування сайту Webex.

Користувачі в організаціях із синхронізацією каталогів

Якщо у вашій організації є користувачі без зв'язків, які мають бути, але ще не додані, спочатку потрібно додати їх до своєї організації. Це особливо важливо для організацій, настроєних на синхронізацію каталогів (через з'єднувач каталогів або Azure AD), оскільки синхронізація каталогів не дозволяє процесу оновлення сайту додавати користувачів.

Виправте проблеми користувача перед початком оновлення.

Якщо ви спробуєте оновити вебсайт до Control Hub, не вирішуючи проблеми для користувачів у файлі users-to-review , процес адміністрування оновлення може не вдатися. Засіб не перевіряє, чи виправлено проблеми, доки не почнеться остаточне оновлення.

Оновлення вебсайтів SSO й сайтів без SSO, пов’язаних із організацією SSO

Організація Control Hub може підтримувати декілька постачальників посвідчень (IdP) для SSO, одним із яких є IdP Webex (локальна автентифікація)

Кілька IdP у Control Hub допоможуть:

• Де IdP для вебсайту SSO в адміністраторі вебсайту відрізняється від IdP SSO Control Hub.
• Якщо користувачі на вебсайті не належать до IdP SSO, налаштованого в організації, цих користувачів тепер можна просто додати до локального IdP Webex. Потім ви зможете перемістити цих користувачів до налаштованого IdP SSO пізніше.

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

• Додайте додаткові IdP SSO до організації Control Hub.
• Додайте користувачів до вже налаштованого IdP.
• Додайте користувачів до локального IdP Webex.

Перегляньте цю статтю , щоб дізнатися більше про декілька IdP у Control Hub.