Управління користувачем

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

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

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

Ця функція доступна і в Контрольному центрі. Для отримання додаткової інформації зверніться до розділу Автоматичне створення та оновлення облікового запису SAML для центру керування.

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

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

• Дод авання користувачів до центру управління.

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

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

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

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

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

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

Управління паролями та блокування

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

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

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

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

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

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

Хости повинні знаходитися у вашій організації Центру керування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XML API

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

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

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

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

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

Тип аутентифікації адміністратора в XML API перед оновленням сайту	Адміністратор в SSO org після оновлення сайту	Адміністратор не в органі SSO після оновлення сайту
ім'я користувача (WebExID) /пароль	Буде працюють*	Буде працюють*
ім'я користувача (WebExID) /SessionTicket	Буде працювати	Буде працювати
Ім'я користувача/OAuth (WebExAccessToken)	Буде працювати	Буде працювати
електронна пошта/пароль	Буде працюють*	Буде працюють*
Електронна пошта/сесійний квиток	Буде працювати	Буде працювати
Електронна пошта/OAuth (веб-доступ)	Буде працювати	Буде працювати

Usernameналаштовується на електронну пошту для всіх користувачів, коли сайт оновлюється до Центру керування. Якщо usernameвикористовується для корисних навантажень API, то корисні навантаження повинні використовувати електронну пошту замість цього після оновлення сайту.

Роль адміністратора в Контрольному центрі для інтеграції API

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

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

Відмінності XML API в Контрольному центрі

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

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

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

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

РЕСТ API

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

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

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

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

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

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

За допомогою API «Люди» можна створювати адміністраторів організації з повними (або лише для читання) дозволами. Ці адміністратори також можуть керувати (або переглядати) керовані сайти нарад Центру керування.

Майбутні плани (можуть бути змінені)

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

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

До цих пір ці дві функції потрібно було відключити перед оновленням сайту до Control Hub:

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

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

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

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

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

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

Деякі функції потрібно вимкнути, перш ніж ви зможете оновити сайт Webex до центру керування. Ви можете побачити список, який показує, яку функцію потрібно вимкнути. Обов'язково потрібно виконати функції, які позначені червоним колом іконкою 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оновлення сайтів SSO та сайтів, які не є SSO, пов'язані з організацією SSO

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

Кілька ВПО в Контрольному центрі допоможуть:

• Якщо Ідентифікатор для сайту SSO в Адміністраторі сайту відрізняється від IDP SSO Центру керування.
• Якщо користувачі сайту не перебувають у IDP SSO, налаштованому в організації, цих користувачів тепер можна просто додати до локального ідентифікатора Webex. Потім ви можете перенести цих користувачів до налаштованого IDP SSO пізніше.

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

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

Докладніше про декілька ВПО в Центрі керування див. в цій статті.