Conectare unică și Control Hub

Autentificarea unică (SSO) este un proces de autentificare a sesiunii sau a utilizatorului care îi permite unui utilizator să furnizeze date de autentificare pentru a accesa una sau mai multe aplicații. Procesul autentifică utilizatorii pentru toate aplicațiile pentru care li se acordă drepturi. Elimină solicitările suplimentare atunci când utilizatorii comută între aplicații în timpul unei anumite sesiuni.

Protocolul de federație pentru Security Assertion Markup Language (SAML 2.0) este utilizat pentru a furniza autentificare SSO între cloud-ul Webex și furnizorul dvs. de identitate (IdP).

Profiluri

Aplicația Webex acceptă numai profilul SSO al browserului web. În profilul SSO al browserului web, aplicația Webex acceptă următoarele conexiuni:

  • SP a inițiat legarea POST -> POST

  • SP a inițiat legarea REDIRECT -> POST

Format NameID

Protocolul SAML 2.0 acceptă mai multe formate NameID pentru comunicarea despre un anumit utilizator. Aplicația Webex acceptă următoarele formate 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

În metadatele pe care le încărcați din IdP, prima intrare este configurată pentru utilizare în Webex.

SingleLogout

Aplicația Webex acceptă profilul de deconectare unic. În Aplicația Webex, un utilizator se poate deconecta de la aplicație, care utilizează protocolul unic de deconectare SAML pentru a încheia sesiunea și pentru a confirma deconectarea cu IdP-ul dvs. Asigurați-vă că IdP-ul dvs. este configurat pentru SingleLogout.

Integrați Control Hub cu ADFS


 

Ghidurile de configurare prezintă un exemplu specific pentru integrarea SSO, dar nu oferă o configurație exhaustivă pentru toate posibilitățile. De exemplu, pașii de integrare pentru nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient sunt documentați. Alte formate precum urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress vor funcționa pentru integrarea SSO, dar nu intră în domeniul de aplicare al documentației noastre.

Configurați această integrare pentru utilizatorii din organizația dvs. Webex (inclusiv aplicația Webex , Webex Meetings și alte servicii administrate în Control Hub). Dacă site- Site Webex este integrat în Control Hub, Site Webex moștenește gestionarea utilizatorilor. Dacă nu puteți accesa Webex Meetings în acest mod și nu este gestionat în Control Hub, trebuie să efectuați o integrare separată pentru a activa SSO pentru Webex Meetings. (A se vedea Configurați Single Sign-On pentru Webex pentru mai multe informații despre integrarea SSO în Administrarea site-ului.)

În funcție de ceea ce este configurat în mecanismele de autentificare din ADFS, autentificarea integrată pentru Windows (IWA) poate fi activată în mod implicit. Dacă este activată, aplicațiile care sunt lansate prin Windows (cum ar fi Aplicația Webex și Cisco Directory Connector) se autentifică ca utilizator conectat, indiferent de adresa de e-mail introdusă în timpul solicitării inițiale de e-mail.

Descărcați metadatele Webex în sistemul dvs. local

1

Din vizualizarea clientului înhttps://admin.webex.com , accesați Management > Setări organizație , apoi derulați la Autentificare , apoi comutați pe Conectare unică pentru a porni expertul de configurare.

2

Alegeți tipul de certificat pentru organizația dvs.:

  • Semnat automat de Cisco —Recomandăm această alegere. Permiteți-ne să semnăm certificatul, așa că trebuie să îl reînnoiți doar o dată la cinci ani.
  • Semnat de o autoritate publică de certificare — Mai sigur, dar va trebui să actualizați frecvent metadatele (cu excepția cazului în care furnizorul dvs. IdP acceptă ancore de încredere).

 

Ancorele de încredere sunt chei publice care acționează ca o autoritate pentru verificarea certificatului unei semnături digitale. Pentru mai multe informații, consultați documentația IdP.

3

Descărcați fișierul cu metadate.

Numele fișierului cu metadate Webex este idb-meta-<org-ID> -SP.xml .

Instalați metadatele Webex în ADFS

Înainte de a începe

Control Hub acceptă ADFS 2.x sau o versiune ulterioară.

Windows 2008 R2 include doar ADFS 1.0. Trebuie să instalați minimum ADFS 2.x de la Microsoft.

Pentru serviciile SSO și Webex, furnizorii de identitate (IdP) trebuie să respecte următoarele specificații SAML 2.0:

  • Setați atributul pentru formatul NameID la urn:oasis:names:tc:SAML:2.0:nameid-format:tranzitoriu

  • Configurați o revendicare pe IdP pentru a include numele atributului uid cu o valoare care este mapată pe atributul ales în Cisco Directory Connector sau atributul de utilizator care corespunde celui ales în serviciul de identitate Webex. (Acest atribut poate fi Adresă de e-mail sau Nume principal utilizator, de exemplu.) Consultați informațiile de atribuire personalizate din https://www.cisco.com/go/hybrid-services-directory pentru îndrumare.

1

Conectați-vă la serverul ADFS cu permisiuni de administrator.

2

Deschideți consola ADFS Management și navigați la Relații de încredere > Încredere în partidul de încredere > Adăugare încredere în partidul de încredere.

3

Din fereastra Add Relying Party Trust Wizard , selectați Start.

4

Pentru a selecta sursa de date selectați Import date despre partea care se bazează dintr-un fișier, navigați la fișierul Metadate Control Hub pe care l-ați descărcat și selectați Înainte.

5

Pentru a specifica numele afișat, creați un nume afișat pentru această încredere de bază, cum ar fi Webex și selectați Înainte.

6

Pentru a alege Regulile de autorizare a eliberării, selectați Permite tuturor utilizatorilor să acceseze această parte care se bazează, și selectați Înainte.

7

Pentru a fi gata să adăugați încredere, selectați În continuare și finalizați adăugarea încrederii de bază la ADFS.

Creați reguli de revendicare pentru autentificarea Webex

1

În panoul principal ADFS, selectați relația de încredere pe care ați creat-o, apoi selectați Editare reguli de revendicare. În fila Reguli transformare problemă, selectați Adăugare regulă.

2

În pasul Selectare tip regulă, selectați Trimitere atribute LDAP ca revendicări, apoi selectați Înainte.

  1. Introduceți un nume de regulă revendicare.

  2. Selectați Active Directory ca Magazin de atribute.

  3. Cartografiați atributul Adrese de e-mail LDAP la tipul de revendicare uid de ieșire.

    Această regulă spune ADFS ce câmpuri să mapteze către Webex pentru a identifica un utilizator. Spell tipurile de revendicare de ieșire exact așa cum se arată.

  4. Salvați modificările.

3

Selectați Adăugare regulă din nou, selectați Trimitere revendicări utilizând o regulă personalizată, apoi selectați Înainte.

Această regulă oferă ADFS atributul „calificator nume de familie” pe care Webex nu îl oferă în alt mod.

  1. Deschideți editorul de text și copiați următorul conținut.

    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");

    Înlocuiți URL1 și URL2 în text după cum urmează:

    • URL1 este ID-ul de drepturi din fișierul de metadate ADFS pe care l-ați descărcat.

      De exemplu, următorul este un eșantion din ceea ce vedeți: <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">

      Copiați doar ID-ul de drepturi din fișierul metadate ADFS și lipiți-l în fișierul text pentru a înlocui URL1

    • URL2 este pe prima linie din fișierul de metadate Webex pe care l-ați descărcat.

      De exemplu, următorul este un eșantion din ceea ce vedeți: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">

      Copiați doar ID-ul de drepturi din fișierul cu metadate Webex și lipiți-l în fișierul text pentru a înlocui URL2.

  2. Cu URL-urile actualizate, copiați regula din editorul de text (începând cu „c:”) și lipiți-o în caseta de reguli particularizată de pe serverul ADFS.

    Regula finalizată ar trebui să arate astfel:

  3. Selectați Finalizare pentru a crea regula, apoi ieșiți din fereastra Editare reguli de revendicare.

4

Selectați Relying Party Trust în fereastra principală, apoi selectați Proprietăți în panoul din dreapta.

5

Când apare fereastra Proprietăți, navigați la fila Avansat , SHA-256 și apoi selectați OK pentru a salva modificările.

6

Răsfoiți următorul URL de pe serverul ADFS intern pentru a descărca fișierul: https://<AD_FS_Server>/FederationMetadata/2007-06/FederationMetadata.xml


 

Este posibil să fie necesar să faceți clic dreapta pe pagina și să vizualizați sursa paginii pentru a obține fișierul XML formatat în mod corespunzător.

7

Salvați fișierul la utilajul local.

Ce este de făcut în continuare

Sunteți gata să importați metadatele ADFS înapoi în Webex de pe portalul de gestionare.

Importați metadatele IdP și activați conectare singură după un test

După ce exportați metadatele Webex , configurați IdP și descărcați metadatele IdP în sistemul dvs. local, sunteți gata să le importați în organizația Webex din Control Hub.

Înainte de a începe

Nu testați integrarea SSO din interfața furnizorului de identitate (IdP). Acceptăm numai fluxurile inițiate de furnizorul de servicii (inițiate de SP), așa că trebuie să utilizați testul SSO Control Hub pentru această integrare.

1

Alegeți una:

  • Reveniți la pagina de selecție a certificatului Control Hub din browserul dvs., apoi faceți clic În continuare .
  • Dacă Control Hub nu mai este deschis în fila browserului, din clientul vizualizați înhttps://admin.webex.com , accesați Management > Setări organizație , derulați la Autentificare , apoi alegeți Acțiuni > Import metadate .
2

Pe pagina Import metadate furnizor de identități , fie glisați și plasați fișierul cu metadate IdP pe pagină, fie utilizați opțiunea browser fișier pentru a localiza și încărca fișierul cu metadate. Faceți clic pe Înainte.

Ar trebui să utilizați Mai sigur opțiune, dacă puteți. Acest lucru este posibil numai dacă IdP a utilizat un CA public pentru a-și semna metadatele.

În toate celelalte cazuri, trebuie să utilizați Mai puțin sigure opțiune. Aceasta include dacă metadatele nu sunt semnate, autosemnate sau semnate de un CA privat.


 

Okta nu semnează metadatele, așa că trebuie să alegeți Mai puțin sigure pentru o integrare Okta SSO .

3

Selectați Testați configurarea SSO , iar când se deschide o nouă filă de browser, autentificați-vă la IdP prin conectare.


 

Dacă primiți o eroare de autentificare, este posibil să existe o problemă cu datele de autentificare. Verificați numele de utilizator și parola și încercați din nou.

O eroare în aplicația Webex înseamnă de obicei o problemă cu configurarea SSO . În acest caz, parcurgeți din nou pașii, în special pașii în care copiați și lipiți metadatele Control Hub în configurația IdP.


 

Pentru a vedea direct experiența de conectare SSO, puteți, de asemenea, să faceți clic pe Copiați URL-ul în clipboard de pe acest ecran și lipiți într-o fereastră de browser privată. De acolo, puteți parcurge conectarea cu SSO. Acest pas oprește rezultatele fals pozitive din cauza unui token de acces care s-ar putea afla într-o sesiune existentă din momentul în care sunteți conectat.

4

Reveniți la fila browserului Control Hub.

  • Dacă testul a reușit, selectați Test reușit. Activați SSO și faceți clic În continuare .
  • Dacă testul nu a reușit, selectați Test nereușit. Dezactivați SSO și faceți clic În continuare .

 

Configurația SSO nu are efect în organizația dvs. decât dacă alegeți primul buton de radio și activați SSO.

Ce este de făcut în continuare

Utilizați procedurile din Sincronizați utilizatorii Okta în Cisco Webex Control Hub dacă doriți să efectuați configurarea utilizatorilor din Okta în cloud-ul Webex .

Utilizați procedurile din Sincronizați utilizatorii Azure Active Directory în Cisco Webex Control Hub dacă doriți să efectuați configurarea utilizatorilor din Azure AD în Webex .

Puteți urma procedura în Eliminați e-mailurile automate pentru a dezactiva e-mailurile care sunt trimise către noii utilizatori ai aplicației Webex din organizația dvs. Documentul conține, de asemenea, cele mai bune practici pentru trimiterea de comunicări către utilizatorii din organizația dvs.

Actualizați încrederea părții de încredere Webex în ADFS

Această sarcină este în special despre actualizarea ADFS cu noile metadate SAML de la Webex. Dacă este necesar, există articole similare configurați SSO cu ADFS , sau dacă este necesar actualizați (un alt) IdP cu metadate SAML pentru un nou certificat Webex SSO .

Înainte de a începe

Trebuie să exportați fișierul de metadate SAML din Control Hub înainte de a putea actualiza Webex Party Trust în ADFS.

1

Conectați-vă la serverul ADFS cu permisiuni de administrator.

2

Încărcați fișierul cu metadate SAML din Webex într-un folder local temporar de pe serverul ADFS, de ex. //ADFS_servername/temp/idb-meta-<org-ID>-SP.xml.

3

Deschideți Powershell.

4

Rulați Get-AdfsRelyingPartyTrust pentru a citi toate trusturile părților de baza.

Rețineți că TargetName parametrul de încredere al părții de încredere Webex . Utilizăm exemplul „Webex”, dar poate fi diferit în ADFS.

5

Rulați Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta-<org-ID>-SP.xml" -TargetName "Webex".

Asigurați-vă că înlocuiți numele fișierului și numele țintă cu valorile corecte din mediul dvs.

A se vedea https://docs.microsoft.com/powershell/module/adfs/update-adfsrelyingpartytrust.

 

Dacă ați descărcat certificatul Webex SP pe 5 ani și ați activat Semnarea sau Revocarea certificatului de criptare, trebuie să rulați aceste două comenzi: Set-AdfsRelyingPartyTrust -SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None -TargetName "Webex".

6

Conectați-vă la Control Hub, apoi testați integrarea SSO :

  1. Accesați Management > Setări organizație , derulați la Autentificare , și comutați pe Conectare unică pentru a porni expertul de configurare.

  2. Faceți clic În continuare pentru a sări peste pagina Import metadate furnizor de identități .

    Nu este necesar să repetați acest pas, deoarece ați importat anterior metadatele IdP.

  3. Testați conexiunea SSO înainte de a o activa. Acest pas funcționează ca un test și nu afectează setările organizației dvs. până când nu activați SSO în următorul pas.


     

    Pentru a vedea direct experiența de conectare SSO, puteți, de asemenea, să faceți clic pe Copiați URL-ul în clipboard de pe acest ecran și lipiți într-o fereastră de browser privată. De acolo, puteți parcurge conectarea cu SSO. Acest lucru ajută la eliminarea oricăror informații memorate în cache în browserul dvs. web care ar putea furniza un rezultat fals pozitiv la testarea configurației SSO.

  4. Conectați-vă pentru a finaliza testul.

Depanare ADFS

Erori ADFS în jurnalele Windows

În jurnalele Windows, puteți vedea un cod de eroare ADFS pentru jurnalul de evenimente 364. Detaliile evenimentului identifică un certificat nevalid. În aceste cazuri, gazda ADFS nu este permisă prin paravanul de protecție pe portul 80 pentru a valida certificatul.

A apărut o eroare în timpul unei încercări de a construi lanțul certificatului pentru încrederea în persoana care se bazează

La actualizarea certificatului SSO, puteți fi prezentat cu această eroare la conectarea la: Invalid status code in response.

Dacă vedeți această eroare, verificați jurnalele de vizualizare a evenimentului de pe serverul ADFS și căutați următoarea eroare: 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'. Cauzele posibile sunt faptul că certificatul a fost revocat, lanțul certificatului nu a putut fi verificat așa cum este specificat de setările de revocare a certificatului de criptare ale părții care se bazează sau certificatul nu se încadrează în perioada sa de valabilitate.

Dacă apare această eroare, trebuie să executați comenzile Set-ADFSRelyingPartyTrust -TargetIdentifier https://idbroker.webex.com/<orgID> -EncryptionCertificateRevocationCheck None

ID federație

ID-ul Federației este sensibil la caz. Dacă aceasta este adresa dvs. de e-mail organizațională, introduceți-o exact așa cum o trimite ADFS sau Webex nu poate găsi utilizatorul care se potrivește.

O regulă particularizată de revendicare nu poate fi scrisă pentru a normaliza atributul LDAP înainte de a fi trimis.

Importați metadatele de pe serverul ADFS pe care l-ați configurat în mediul dvs.

Puteți verifica URL-ul dacă este necesar, navigând la Serviciu > Puncte finale > Metadate > Tip:Metadate de federație în ADFS Management.

sincronizare Timp

Asigurați-vă că ceasul sistemului serverului ADFS este sincronizat cu o sursă de timp de internet fiabilă care utilizează Protocolul de timp de rețea (NTP). Utilizați următoarea comandă PowerShell pentru a glisa ceasul numai pentru relația Webex Relying Party Trust.

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

Valoarea hexazecimală este unică pentru mediul dvs. Vă rugăm să înlocuiți valoarea din valoarea ID-ului EntityDescriptor SP din fișierul metadate Webex. De exemplu:

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