Единичен център за влизане и управление

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

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

Профили

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

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

  • SP инициира ПРЕНАСОЧВАНЕ -> 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:неопределен

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

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

Единично излизане

Webex App поддържа единния профил за излизане. В Webex Appпотребителят може да излезе от приложението, което използва протокола SAML за единично излизане, за да прекрати сесията и да потвърди този изход с вашия IdP. Гарантирайте, че вашият IdP е конфигуриран за SingleLogout.

Интегриране на центъра за управление с ADFS

Ръководствата за конфигуриране показват конкретен пример за интегриране на SSO, но не предоставят изчерпателна конфигурация за всички възможности. Например стъпките за интеграция за nameid-формат urn:oasis:names:tc:SAML:2.0:nameid-формат:transient са документирани. Други формати като urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ще работи за интегриране на SSO, но са извън обхвата на нашата документация.

Настройте тази интеграция за потребители във вашата уебекс организация (включително Webex App, Webex Срещии други услуги, администрирани в контролния център). Ако вашият Webex сайт е интегриран в контролния център, Webex сайтът наследява управлението на потребителя. Ако нямате достъп до Webex Срещи по този начин и той не се управлява в контролния център, трябва да направите отделна интеграция, за да разрешите SSO за Webex срещи. (Вж. Конфигуриране на еднократна идентификация за 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--SP.xml.

Инсталиране на webex метаданни в ADFS

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

Контролният център поддържа 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:преходно

  • Конфигурирайте заявяване на IdP, за да включите името на атрибута uid със стойност, която е съпоставена с атрибута, избран в Cisco Directory Connector, или потребителския атрибут, който съвпада с този, избран в Webex Identity Service. (Този атрибут може да бъде например 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. Въведете име на правило за рекламация.

  2. Изберете Активна директория като хранилище на атрибути.

  3. Нанесете атрибута E-mail-адреси LDAP на типа изходяща претенция на 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.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">

      Копирайте само идентификационния номер на обекта от файла с метаданни на 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

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

5

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

6

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

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

7

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

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

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

Импортиране на IdP метаданните и разрешаване на еднократна идентификация след тест

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

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

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

1

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

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

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

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

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

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

3

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

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

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

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

4

Върнете се в раздела браузър на контролния център .

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

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

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

Използвайте процедурите в Синхронизиране на потребителите на Okta в Cisco Webex контролен център , ако искате да направите осигуряване на потребителя извън Okta в облака Webex.

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

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

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

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

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

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

1

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

2

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

3

Отворете Пауършел.

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.

Ако сте изтеглили сертификата за Webex SP 5 година и имате включено подписване или анулиране на сертификат за шифроване, трябва да изпълните тези две команди: Set-AdfsRelyingPartyТръст -ПодписванеСертификатRevocationПроверка няма -ШифрованеСертификатRevocationПроверка няма -TargetName "Webex".

6

Влезте в контролния център, след което тествайте интегрирането на SSO:

  1. Отидете на Настройки за управление > организация, превъртете до удостоверяванеи превключвайте на настройката "Еднократна идентификация ", за да стартирате съветника за конфигуриране.

  2. Щракнете върху "Напред ", за да пропуснете страницата Импортиране на метаданни на IdP.

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

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

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

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

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

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

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

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

При актуализиране на sSO сертификата, може да ви бъде представена тази грешка при влизане: Невалиден код на статус в отговора.

Ако видите тази грешка, проверете регистрационните файлове на event Viewer на ADFS сървъра и потърсете следната грешка: Възникна грешка по време на опита за изграждане на веригата от сертификати за доверителното доверие на разчитащата страна „https://idbroker.webex.com/<org-ID>' сертификат, идентифициран с отпечатък с палец „754B9208F1F75C5CC122740F3675C5D129471D80“. Възможни причини са, че сертификатът е отменен, веригата на сертификатите не можа да бъде проверена, както е посочено от настройките за отмяна на сертификата за шифроване на доверяващата се страна trust, или сертификатът не е в срока му на валидност.

Ако възникне тази грешка, трябва да изпълните командите Set-ADFSRelyingPartyTrust -TargetIdentifier https://idbroker.webex.com/<orgID> -EncryptionCertificateRevocationCheck Няма

ИД на федерацията

Идентификационният номер на Федерацията е чувствителен към случая. Ако това е организационният ви имейл адрес, въведете го точно както ADFS го изпраща или Webex не може да намери съвпадащия потребител.

Правило за персонализирано искане не може да бъде написано за нормализиране на атрибута LDAP, преди да бъде изпратено.

Импортирайте метаданните си от ADFS сървъра, който сте настроили във вашата среда.

Можете да проверите URL адреса, ако е необходимо, като навигирате до Сервиз > крайни точки > метаданни > тип:Метаданни на федерацията в управлението на ADFS.

Синхронизация на времето

Гарантирайте, че системният часовник на adfs сървъра ви се синхронизира с надежден източник на време в интернет, който използва Протокола за мрежово време (NTP). Използвайте следната команда PowerShell, за да изкривите часовника само за релацията Webex Relying Party Trust.

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

Шестнадесетична стойност е уникална за вашата среда. Моля, заменете стойността от СТОЙНОСТТА SP EntityDescriptor ID във файла с метаданни на Webex. Например:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:метаданни" entityID=" https://idbroker.webex.com/c0cb726f-a187-4ef6-b89d-46749e1abd7a">