Единичен вход и контролен център

Единичен вход (SSO) е процес на удостоверяване на сесия или потребител, който позволява на потребителя да предостави идентификационни данни за достъп до едно или повече приложения. Процесът удостоверява потребителите за всички приложения, за които са им дадени права. Той елиминира допълнителни подкани, когато потребителите превключват приложения по време на определена сесия.

Протоколът за маркиране на езика за потвърждаване на сигурността (SAML 2.0) се използва за осигуряване на SSO удостоверяване между облака на Webex и вашия доставчик на идентичност (IdP).

Профили

Приложението Webex поддържа само SSO профила на уеб браузъра. В SSO профила на уеб браузъра, приложението Webex поддържа следните обвързвания:

  • SP инициира POST -> POST свързване

  • SP инициира REDIRECT -> POST свързване

Формат на NameID

Протоколът SAML 2.0 поддържа няколко NameID формата за комуникация за конкретен потребител. Приложението Webex поддържа следните формати на 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 поддържа единичен профил за излизане. В приложението Webex потребителят може да излизам от приложението, което използва SAML протокол за еднократно излизане, за да прекрати сесията и да потвърди това излизам с вашия IdP. Уверете се, че вашият IdP е конфигуриран за SingleLogout.

Интегрирайте 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 във вашата локална система

1

От изглед на клиента вhttps://admin.webex.com , отидете на Управление > Настройки на организацията и след това превъртете до Удостоверяване , и след това включете Единичен вход настройка за стартиране на съветника за настройка.

2

Изберете типа сертификат за вашата организация:

  • Самоподписан от Cisco — Препоръчваме този избор. Нека подпишем сертификата, така че трябва да го подновявате само веднъж на всеки пет години.
  • Подписано от публичен сертифициращ орган —По-сигурно, но ще трябва често да актуализирате метаданните (освен ако вашият доставчик на IdP поддържа доверителни котви).

 

Доверените котви са публични ключове, които действат като орган за проверка на сертификата на цифров подпис. За повече информация вижте документацията на вашия IdP.

3

Изтеглете файла с метаданни.

Името на файла с метаданни на 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 доставчиците на идентичност (IdPs) трябва да отговарят на следната спецификация SAML 2.0:

  • Задайте атрибута NameID Format на urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • Конфигурирайте иск за IdP, за да включите 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

1

В главния панел ADFS изберете връзката на доверие, която сте създали, и след това изберете Редактиране на правилата за претенции . В раздела Правила за трансформиране на издаване изберете Добавяне на правило .

2

В стъпката Изберете тип правило изберете Изпращане на LDAP атрибути като претенции и след това изберете Следваща .

  1. Въведете a Име на правилото за искане .

  2. Изберете Active Directory като магазин за атрибути.

  3. Картирайте на E-mail-адреси атрибут за LDAP към uid тип изходящ иск.

    Това правило казва на ADFS кои полета да се съпоставят с Webex , за да се идентифицира потребител. Изпишете изходящите типове искове точно както е показано.

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

3

Изберете Добавяне на правило отново изберете Изпращайте искове с помощта на персонализирано правило и след това изберете Следваща .

Това правило предоставя на ADFS атрибута „spname qualifier“, който 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 е entityID от файла с метаданни на 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">

      Копирайте само entityID от ADFS файла с метаданни и го поставете в текстовия файл, за да замените URL1

    • URL2 е на първия ред във файла с метаданни на Webex , който сте изтеглили.

      Например, следното е извадка от това, което виждате: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">

      Копирайте само entityID от файла с метаданни на Webex и го поставете в текстовия файл, за да замените URL2.

  2. С актуализираните URL адреси копирайте правилото от вашия текстов редактор (започвайки от "c:") и го поставете в полето за персонализирано правило на вашия ADFS сървър.

    Попълненото правило трябва да изглежда така:

  3. Изберете Край за да създадете правилото и след това излезте от прозореца Редактиране на правилата за искане.

4

Изберете Доверие на разчитащата страна в главен прозорец и след това изберете Свойства в десния панел.

5

Когато се появи прозорецът Свойства, прегледайте до Разширено раздел, SHA-256 и след това изберете ОК за да запазите промените си.

6

Прегледайте следния URL на вътрешния ADFS сървър, за да изтеглите файла: https://< АД_ FS_ Сървър >/FederationMetadata/2007-06/FederationMetadata.xml


 

Може да се наложи да щракнете с десния бутон върху страницата и да видите източника на страницата, за да получите правилно форматирания XML файл.

7

Запазете файла на вашата локална машина.

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

Готови сте да импортирате метаданните на ADFS обратно в Webex от портала за управление.

Импортирайте метаданните на IdP и активирайте еднократен вход след тест

След като експортирате метаданните на Webex , конфигурирате своя IdP и изтеглите метаданните на IdP във вашата локална система, вие сте готови да ги импортирате във вашата Webex организация от Control Hub.

Преди да започнете

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

1

Изберете един:

  • Върнете се в Control Hub – страницата за избор на сертификат във вашия браузър и след това щракнете Следваща .
  • Ако Control Hub вече не е отворен в раздела на браузъра, от изгледа на клиента вhttps://admin.webex.com , отидете на Управление > Настройки на организацията , превъртете до Удостоверяване , и след това изберете Действия > Импортиране на метаданни .
2

На страницата Импортиране на метаданни за IdP или плъзнете и пуснете файла с метаданни на IdP върху страницата или използвайте опцията за файлов браузър, за да намерите и качите файла с метаданни. Щракнете върху Напред.

Трябва да използвате По-сигурно вариант, ако можете. Това е възможно само ако вашият IdP е използвал публичен CA за подписване на своите метаданни.

Във всички останали случаи трябва да използвате По-малко сигурен опция. Това включва, ако метаданните не са подписани, самоподписани или подписани от частен CA.


 

Okta не подписва метаданните, така че трябва да изберете По-малко сигурен за интеграция на Okta SSO .

3

Изберете Тествайте настройката на SSO , и когато се отвори нов раздел на браузъра, удостоверете се с IdP, като влезете.


 

Ако получите грешка при удостоверяване, може да има проблем с идентификационните данни. Проверете потребителското име и паролата и опитайте отново.

Грешка в приложението Webex обикновено означава проблем с настройката на SSO . В този случай преминете отново през стъпките, особено стъпките, при които копирате и поставяте метаданните на Control Hub в настройката на IdP.


 

За да видите директно средата за влизане с SSO, можете също да щракнете върху Копиране на URL адреса в клипборда от този екран и да го поставите в поверителен прозорец на браузъра. Оттам можете да преминете през влизането с SSO. Тази стъпка спира фалшивите положителни резултати поради токен за достъп, който може да е в съществуваща сесия, след като сте влезли.

4

Върнете се в раздела на браузъра Control Hub.

  • Ако тестът е бил успешен, изберете Успешен тест. Включете SSO и щракнете Следваща .
  • Ако тестът е бил неуспешен, изберете Неуспешен тест. Изключете SSO и щракнете Следваща .

 

Конфигурацията на SSO не влиза в сила във вашата организация, освен ако не изберете първия радио бутон за избор и не активирате SSO.

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

Използвайте процедурите в Синхронизирайте потребителите на Okta в Cisco Webex Control Hub ако искате да направите обезпечаване на потребители от Okta в облака на Webex .

Използвайте процедурите в Синхронизирайте потребителите на Azure Active Directory в Cisco Webex Control Hub ако искате да направите обезпечаване на потребители извън Azure AD в облака на Webex .

Можете да следвате процедурата в Потискайте автоматизирани имейли за да деактивирате имейли, които се изпращат до нови потребители на Webex App във вашата организация. Документът също така съдържа най-добри практики за изпращане на съобщения до потребители във вашата организация.

Актуализирайте доверието на разчитащата страна на Webex в ADFS

Тази задача е конкретно за актуализиране на ADFS с нови SAML метаданни от Webex. Има свързани статии, ако трябва конфигурирайте SSO с ADFS , или ако трябва актуализиране (различен) SSO със SAML метаданни за нов сертификат за единно включване на Webex .

Преди да започнете

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

1

Влезте в ADFS сървъра с администраторски права.

2

Качете файла с метаданни SAML от Webex във временна локална папка на ADFS сървъра, напр. //ADFS_servername/temp/idb-meta-<org-ID>-SP.xml.

3

Отворете Powershell.

4

Изпълнете Get-AdfsRelyingPartyTrust да прочете всички тръстове на разчитащи се партии.

Обърнете внимание на TargetName параметър на доверието на разчитащата страна на Webex . Използваме примера "Webex", но той може да е различен във вашия ADFS.

5

Изпълнете Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta-<org-ID>-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 .

    Не е необходимо да повтаряте тази стъпка, тъй като преди това сте импортирали метаданните на IdP.

  3. Тествайте SSO връзката, преди да я активирате. Тази стъпка служи за пробно изпълнение и не засяга настройките на вашата организация, докато не активирате SSO в следващата стъпка.


     

    За да видите директно средата за влизане с SSO, можете също да щракнете върху Копиране на URL адреса в клипборда от този екран и да го поставите в поверителен прозорец на браузъра. Оттам можете да преминете през влизането с SSO. Това помага да се премахне всяка информация, кеширана във вашия интернет браузър, която може да доведе до фалшив положителен резултат при тестване на вашата конфигурация за SSO.

  4. Влезте, за да завършите теста.

ADFS отстраняване на неизправности

ADFS грешки в регистрационните файлове на Windows

В регистрационните файлове на Windows може да видите код на грешката в регистъра на събитията на ADFS 364. Подробностите за събитието идентифицират невалиден сертификат. В тези случаи ADFS хост не е разрешено чрез защитната стена на порт 80 за валидиране на сертификата.

Възникна грешка по време на опит за изграждане на верига за сертификати за доверието на разчитащата страна

Когато актуализирате сертификата за SSO , може да получите тази грешка при влизане: Invalid status code in response.

Ако видите тази грешка, проверете регистрационните файлове на Event Viewer на 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 EntityDescriptor ИД във файла с метаданни на Webex . Например:

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