Управление на потребители

Имаме централизирана система за управление на потребителите в основата на Control Hub, където потребителите са различни и уникални в рамките на цялата организация (и целия Webex). В администрирането на сайта потребителският профил е различен за всеки сайт за срещи.

Единичен вход (SSO) с автоматично създаване на акаунт

В Site Admin имате функция „автоматично създаване на акаунт“, която създава потребители, когато се удостоверяват чрез SSO.

Тази функция не е налична в Control Hub, защото има по-стабилни начини за добавяне на нови потребители. Трябва да деактивирате тази функция в Администриране на сайта, преди да актуализирате сайта си до Control Hub.

Много организации, които използват SSO, може да предпочетат централизирано да управляват своите потребители в инструменти за външни директории като Microsoft^® Active Directory и Microsoft Azure, както и да изискват удостоверяване с външни доставчици на идентичност.

Прочетете повече за:

• Добавяне на потребители към Control Hub: https://help.webex.com/n0qtkri

• Интегриране на вашата организация Control Hub с доставчик на идентичност: https://help.webex.com/nffx8kj/

Задължителни профилни данни и проследяващи кодове

Администрирането на сайта ви позволява да зададете задължителни полета в профила за нови потребители (предишна екранна снимка). Можете да разширите това, за да изисквате проследяващи кодове за създаване на потребител (екранна снимка по-долу). Ако конфигурирате тези допълнителни изисквания, не можете да добавяте потребители към сайта без тях.

Control Hub се нуждае само от екранно име и имейл адрес, за да създаде потребител.

Всички други потребителски полета са незадължителни, когато създавате нов потребител в Control Hub, така че ние не налагаме допълнителни данни за профили за управлявани от Control Hub сайтове.

Трябва да деактивирате задължителните полета на профилите и проследяващите кодове, преди да актуализирате сайта си до Control Hub.

Управление на пароли и блокиране

Администрирането на сайта има функция, която временно блокира потребителите, ако не успеят да влязат след няколко опита.

Control Hub има следните опции за предотвратяване на неоторизиран достъп:

• Автоматично изчакване след първите няколко неуспешни опита.

• Механизъм CAPTCHA (напълно автоматизиран публичен тест на Тюринг за разграничаване на компютрите и хората).

• Легитимните потребители имат опция за самообслужване да променят забравените си пароли.

Лицензиране на хост

Хостовете трябва да са във вашата организация Control Hub

В Site Admin можете да зададете лиценз за хост на всеки потребител. Когато управлявате сайта в Control Hub, можете да присвоявате лицензи за хост (и роля на присъстващ) само на потребители в същата организация на Control Hub.

Самостоятелна регистрация за хост акаунт

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

Когато управлявате сайт за срещи в Control Hub, потребителите не могат да поискат свой собствен хост акаунт за този сайт.

Control Hub има централизиран, автоматизиран начин вместо това да присвоявате лицензи за срещи на нови потребители. Прочетете https://help.webex.com/n3ijtao .

Можете също да управлявате потребителски лицензи чрез API или групово, като използвате CSV.

Ако искате потребителите да изискват своите хост акаунти, можете да конфигурирате помощта/поддръжката на сайта с указатели за връзка с администратори или връзка към други инструменти.

Трябва да деактивирате „Разрешаване на регистрация на хост акаунт“ и „Разрешаване на потребителите да изискват допълнителни услуги“ в Администрирането на сайта, преди да актуализирате сайта си до Control Hub.

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

Ако имате нужда от тази опция за автоматично деактивиране, а другите опции в Control Hub не са подходящи за вас, тогава трябва да избягвате да актуализирате сайта си до Control Hub в момента.

Автоматично създаване на акаунт за нови потребители

Ако вашият сайт на Webex е активирал автоматично създаване на акаунт в Site Admin, можете да активирате подобна функция в Control Hub с Автоматично създаване на SAML акаунт . Уверете се също, че сте настройвам шаблон за автоматичен лиценз така че новите потребители автоматично ще получават присвоени лицензи, след като техните акаунти бъдат създадени в организацията Control Hub.

Организации със синхронизиране на директории

Ако вашата организация е конфигурирана за синхронизиране на директории, тогава се уверете, че всички потребители, които искате да бъдат във вашата организация, присъстват в сайта. Това трябва да се направи 24 часа преди да започнете процеса на актуализиране на сайта, така че потребителите на сайта да могат да бъдат свързани с новите потребители във вашата организация Control Hub.

Актуализацията ще бъде неуспешна, ако активните потребители на сайта не могат да бъдат свързани с потребителите на Control Hub.

XML API

XML API-ите вече са съвместими за препращане с управлявани от Control Hub сайтове. Можете да прочетете за подробностите и предупрежденията в Актуализации на XML API 41.11.0.

URL адресите на услугите на XML API остават непроменени, след като сайтът се актуализира от Администратор на сайта до управляван Център за контрол. Същите API URL адреси ще продължат да работят. Cisco препоръчва всички интеграции на API да използват OAUTH за удостоверяване.

Удостоверяване в XML API

Интеграции, които не се използват Webex OAUTH за удостоверяване може да се провали, след като сайтът се актуализира до Control Hub. Следващата таблица показва кой тип удостоверяване на администратора ще продължи да работи след актуализиране на вашия сайт.

Таблица 1. Типове удостоверяване на администратор, които ще работят в XML API след актуализация на сайта

Тип удостоверяване на администратора в XML API преди актуализиране на сайта	Администратор в SSO org след актуализация на сайта	Администраторът не е в SSO организация след актуализация на сайта
потребителско име (webExID)/парола	ще работи*	ще работи*
потребителско име (webExID)/sessionTicket	ще работи	ще работи
потребителско име/OAUTH (webExAccessToken)	ще работи	ще работи
имейл/парола	ще работи*	ще работи*
email/sessionTicket	ще работи	ще работи
имейл/OAUTH (webExAccessToken)	ще работи	ще работи

* Обратна съвместимост — Cisco е активирало удостоверяването на потребителско име/парола да работи в XML API след актуализация на сайта, дори ако потребителското име не съвпада с имейл само за организации, които не са SSO . Съвместимостта е приложима само ако: Потребителските идентификационни данни са създадени преди актуализацията на сайта. Не са разрешени промени в потребителското име, в противен случай предишните идентификационни данни ще бъдат неуспешни. Идентификационните данни за удостоверяване на API не могат да имат различна парола в Control Hub спрямо сайта, когато е бил управляван в администрация на сайта. Можете да научите повече за интегрирането на XML API на управляваните от Control Hub сайтове, включително OAUTH удостоверяване, с това ръководство .

Потребителското име е настроено на имейл за всички потребители, когато сайтът се актуализира до Control Hub. Ако потребителското име се използва за полезни натоварвания на API , тогава полезните товари трябва да използват имейл, след като сайтът се актуализира.

Роля на администратор в Control Hub за интеграции на API

Администраторите само с роля на администратор на сайта може да не са в състояние да извършват някои операции с XML API, като например промяна на имейл адрес или показвано име на потребителя, след като сайтът се актуализира до сайт на Control Hub. За администратори, чиито идентификационни данни се използват за интеграции на API , препоръчваме да повишите тези администратори до пълни администратори на организация в Control Hub, в идеалния случай преди да актуализирате сайта до Control Hub.

Като най-добра практика препоръчваме първо да актуализирате тестов сайт, за да потвърдите, че вашите API интеграции ще работят непроменени след актуализиране до Control Hub.

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

също добавете (не е в раздела SSO ).

Потребителското име е настроено на имейл за всички потребители, когато сайтът се преобразува в CH.

Така че, ако потребителското име е полезни натоварвания на API , те трябва да имейлът на потребителя след конвертирането на сайта.

Разлики в XML API в Control Hub

Повечето интеграции на XML API трябва да работят, без никакви промени, след актуализиране на вашия сайт. Но има някои изключения, които са описани подробно в следния списък:

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

  createuser Завършването на API отнема повече време в управляваните от Control Hub сайтове. За по-добра производителност можете да добавите допълнителна нишка за паралелизиране createuser обаждания.

• SetUser —Може да доведе до присвояване или премахване на лиценз на сайта за срещи от потребителя (в зависимост от параметрите на API или полезния товар).
• DelUser —Премахва лиценза на сайта за срещи, но не изтрива потребителя от организацията Control Hub.
• LstsummaryUser —Връща също и на потребителя objectGUID.
• AuthenticateUser —На управляваните от Control Hub сайтове препоръчваме създаване на билет за сесия чрез AuthenticateUser вместо да използвате потребителско име и парола за всеки XML API. Използването на SAML отговор в основното съдържание не се поддържа с това обаждане за управлявани от Control Hub сайтове.

API тип REST

Control Hub има свои собствени API, включително People и License REST API за създаване и лицензиране на потребители на:

• 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

Въпреки това, горните REST API не поддържат всички функции за управление на потребителите, налични в XML API. Например, пак ще трябва да използвате XML API, за да присвоите лицензи за срещи на потребители извън организацията, която е собственик на сайта. People API не поддържа присвояване на роли на администратор на сайта на потребителите. Ако искате да зададете роли на администратор на сайта чрез API, все още трябва да използвате XML API.

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

Control Hub има специфични за сайта администраторски роли на Webex, но API за хора не може да присвои тази роля в момента.

Бъдещи планове (подлежат на промяна)

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

Как да проверите за потребители, които ще блокират актуализацията на сайта

1. Влезте в администрацията на сайта и отворете страницата Актуализиране на администрацията.

2. Отворете контролата Преглед на предпоставките за актуализиране на администрацията и кликнете върху Експортиране на засегнатите потребители в CSV.

3. Изчакайте експортирането да приключи. Този процес може да отнеме известно време в зависимост от началния час и броя на потребителите в сайта. Експортирането се поставя на пауза за 6 минути в началото на часа (между xx:57 до xx:03).

4. Кликнете върху Изтегляне на CSV, след като експортирането приключи.

   Вашият браузър се изтегля users-to-review.csv.

5. Отворете CSV файла и проверете колоната Препоръчано действие (последната колона). Извършете препоръчаното действие за всеки потребител във файла.

Потребители с несъответстващи имейл адреси

Някои потребители може да имат различен имейл адрес в центъра за администриране и контрол на сайта. Това е възможно, ако имейлът на потребителя е променен само на едно от двете места, след като потребителят е бил свързан от този сайт към Control Hub.

Опитайте тези действия, за да коригирате потребители с несъответстващи имейл адреси:

• Променете имейл адреса на потребителя в администратора на сайта, за да съответства на имейл адреса на Control Hub

  Потребителите могат да редактират своите профили на администратор на сайта: https://help.webex.com/n0qtkri

• Променете имейл адреса на потребителя в Control Hub, за да съвпада с имейл адреса на администратора на сайта: https://help.webex.com/n0qtkri

  Потребителите могат да променят собствените си имейл адреси в организацията Control Hub: https://help.webex.com/n0qtkri

Ако актуализирате сайта си до Control Hub, без да коригирате несъответствията на имейл адрес на потребителя, засегнатите потребители трябва да използват имейл адресите си в Control Hub, за да влизам в място за срещи. Тези потребители може да не успеят да влизам, ако се опитат да влизам с имейл адрес в администратора на сайта или ако имейл адрес им в Control Hub вече не е валиден в техния IdP (за SSO организации). Те няма да ви блокират да актуализирате сайта, но е по-добре да коригирате имейл адресите, преди да започнете актуализацията.

Външни потребители с лиценз за основни срещи

Външни потребители с Лицензи за основни срещи ще трябва да бъде деактивиран или надстроен до платени лицензи на Webex Meetings , преди да се актуализира сайтът от Администратор на сайта до Control Hub.

Как да деактивирате потребителите

Когато деактивирате потребителите, те губят лиценза си за хост или привилегията на присъстващите (в зависимост от ролята, която са имали, докато са Активни). Деактивираните потребители все още ще се показват в CSV файла за експортиране на сайта след актуализиране на сайта до Control Hub.

За деактивиране на индивидуален потребител в администрацията на сайта:

1. Отидете на Управление на потребителите > Редактиране на потребителя.

2. Използвайте контролите за индексиране, търсене и филтриране, за да намерите потребителя.

3. Премахнете отметката от квадратчето Активно.

4. Изпратете промените.

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

За групово деактивиране на потребители в администрацията на сайта:

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

2. Отворете CSV файла и променете Active стойности на колоната до N за всички засегнати потребители.

3. Импортирайте модифицирания CSV файл.

   Потребителите, които променихте, вече са Неактивни.

   Вижте Пакетно импортиране и експортиране на потребители на Webex в администрацията на сайта на Webex за повече подробности.

Потребители в организации със синхронизиране на директории

Ако има потребители без връзка, които трябва да са във вашата организация, но все още не са добавени, първо трябва да ги добавите към вашата организация. Това е особено важно за организации, които са конфигурирани за синхронизиране на директории (чрез Directory Connector или Azure AD), тъй като синхронизирането на директории няма да позволи на процеса на актуализиране на сайта да добавя потребители.

Актуализацията на сайта ще бъде неуспешна, ако активните потребители на сайта не могат да бъдат свързани с организация на Control Hub. Ако вашата организация е конфигурирана за синхронизиране на директории, уверете се, че всички потребители на сайта, които трябва да са част от организацията на Control Hub, са добавени първо към Directory Connector или Azure AD, преди да започнете актуализацията.

Отстранете потребителските проблеми, преди да започнете актуализацията

Ако се опитате да актуализирате сайта до Control Hub, без да разрешите проблемите за потребителите в users-to-review файл, процесът на администриране на актуализиране може да се провали. Инструментът не проверява дали сте коригирали проблемите, докато не стартирате окончателната актуализация.