Sign-on unic și Control Hub

Sign-on unic (SSO) este o sesiune sau un proces de autentificare utilizator care permite unui utilizator să furnizeze acreditări pentru a accesa una sau mai multe aplicații. Procesul autentifică utilizatorii pentru toate aplicațiile cărora li se acordă drepturi. Elimină solicitările suplimentare atunci când utilizatorii comută aplicațiile în timpul unei anumite sesiuni.

Protocolul de federalizare a limbajului de marcare a aserțiunii de securitate (SAML 2.0) este utilizat pentru a furniza autentificarea SSO între cloud-ul Webex și furnizorul de identitate (IdP).

Profiluri

Webex App acceptă numai profilul SSO al browserului web. În profilul SSO al browserului web, Webex App acceptă următoarele legături:

  • SP a inițiat legarea POST-> POST

  • SP a inițiat redirect -> POST obligatorii

Format NameID

Protocolul SAML 2.0 acceptă mai multe formate NameID pentru comunicarea despre un anumit utilizator. Webex App acceptă următoarele formate NameID.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:tranzitoriu

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

  • 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 unic de deconectare. În AplicațiaWebex, un utilizator se poate deconecta de la aplicație, care utilizează protocolul de deconectare unică SAML pentru a încheia sesiunea și a confirma că deconectați-vă cu IdP-ul dvs. Asigurați-vă că IdP-ul este configurat pentru SingleLogout.

Integrarea Control Hub cu ADFS

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

Configurați această integrare pentru utilizatorii din organizația Webex (inclusiv Webex App, Webex Meetingsși alte servicii administrate în Control Hub). Dacă site-ul webex este integrat în Control Hub, site-ul Webex moștenește gestionarea utilizatorilor. Dacă nu puteți accesa Webex Meetings în acest fel ș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 în integrarea SSO în Administrarea site-ului.)

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

Descărcați metadatele Webex în sistemul local

1

Din vizualizarea client din https://admin.webex.com, accesați Gestionare > Setăriorganizație, apoi defilați la Autentificare, apoi comutați la setarea Conectare unică pentru a porni expertul de configurare.

2

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

  • Autosemnat de Cisco—Vă recomandăm această opțiune. Permiteți-ne să semnăm certificatul, astfel încât să trebuiască să îl reînnoiți doar o dată la cinci ani.
  • Semnat de o autoritate de certificare publică—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 a verifica certificatul unei semnături digitale. Pentru mai multe informații, consultați documentația IdP.

3

Descărcați fișierul de metadate.

Denumirea fișierului cu metadate Webex este idb-meta--SP.xml.

Instalarea metadatelor Webex în ADFS

Înainte de a începe

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

Windows 2008 R2 include numai ADFS 1.0. Trebuie să instalați un minim de ADFS 2.x de la Microsoft.

Pentru serviciile SSO și Webex, furnizorii de identitate (IPP) 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:tranzitorie

  • Configurați o revendicare pe IdP pentru a include numele de atribut uid cu o valoare care este mapată la atributul care este ales în Cisco Directory Connector sau atributul de utilizator care se potrivește cu cel care este ales în serviciul de identitate Webex. (Acest atribut poate fi Adrese de e-mail sau Nume principal utilizator, de exemplu.) Consultați informațiile despre atribut 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 de gestionare ADFS și navigați la Relații de încredere > Încredere parte bazându-se trusturi > Adăugați încredere parte bazându-se.

3

Din fereastra Adăugare expert încredere parte bazându-se, selectați Start.

4

Pentru Selectați sursa de date , selectați Importați datele despre persoana care se bazează dintr-un fișier, navigați la fișierul cu metadate Control Hub pe care l-ați descărcat și selectați Înainte.

5

La Specificați numele afișat, creați un nume afișat pentru acest tip de încredere de parte, cum ar fi Webex , și selectați Înainte.

6

Pentru a alege regulile de autorizare de eliberare , selectați Permiteți tuturor utilizatorilor să acceseze această parte bazându-seși selectați Următorul .

7

Pentru Gata de adăugare a încrederii , selectați Următorulși terminați adăugarea încrederii bazându-se la ADFS.

Crearea regulilor 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. Pe fila Emitere reguli de transformare, selectați Adăugare regulă.

2

În pasul Alegeți tipul de regulă, selectați Trimitere atribute LDAP ca revendicări , apoi selectați Următorul .

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

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

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

    Această regulă indică ADFS ce câmpuri să mapeze la Webex pentru a identifica un utilizator. Scrieți tipurile de revendicări de ieșire exact așa cum se arată.

  4. Salvați modificările.

3

Selectați Adăugați din nou regulă, selectați Trimitere revendicări utilizând o regulă particularizată , apoi selectați Următorul .

Această regulă furnizează ADFS atributul "spname qualifier" pe care Webex nu îl furnizează altfel.

  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 entityID din fișierul cu metadate ADFS pe care l-ați descărcat.

      De exemplu, următorul este un exemplu 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 entityID-ul din fișierul de metadate ADFS și lipiți-l în fișierul text pentru a înlocui URL1

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

      De exemplu, următorul exemplu este un exemplu 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 entityID-ul din fișierul de 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 de la "c:") și lipiți-o în caseta de reguli particularizată de pe serverul ADFS.

    Regula completată ar trebui să arate astfel:

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

4

Selectați Încredere parte bazându-se în fereastra principală, apoi selectați Proprietăți în panoul din dreapta.

5

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

6

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

Poate fi necesar să faceți clic dreapta pe pagină și să vizualizați sursa paginii pentru a obține fișierul XML formatat corect.

7

Salvați fișierul pe computerul local.

Ce trebuie să faceți în continuare

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

Importul metadatelor IdP și activarea conectării unice după un test

După ce exportați metadatele Webex , configurați IdP-ul și descărcați metadatele IdP în sistemul 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), deci trebuie să utilizați testul Control Hub SSO pentru această integrare.

1

Alegeți una:

  • Reveniți la Control Hub – pagina de selectare a certificatelor din browser, apoi faceți clic pe Înainte.
  • Dacă Control Hub nu mai este deschis în fila browserului, din vizualizarea client în https://admin.webex.com, accesați Gestionare > Setări organizație, derulați la Autentificare, apoi alegeți Acțiuni > Importați metadatele.
2

Pe pagina Import metadate IdP, trageți și fixați fișierul de metadate IdP pe pagină sau utilizați opțiunea browserului de fișiere pentru a localiza și încărca fișierul de metadate. Faceți clic pe Următorul.

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

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

Okta nu semnează metadatele, deci trebuie să alegeți Mai puțin sigur pentru o integrare Okta SSO.

3

Selectați Testare configurație SSO și, atunci când se deschide o filă nouă de browser, autentificați-vă la IdP conectându-vă.

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

O eroare Webex App î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 configurarea 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 simbol de acces care ar putea fi într-o sesiune existentă de la dvs.

4

Reveniți la fila browserului Control Hub .

  • Dacă testul a avut succes, selectați Test de succes. Activați SSO și faceți clic pe Următorul.
  • Dacă testul nu a reușit, selectați Test nereușit. Dezactivați SSO și faceți clic pe Următorul.

Configurația SSO nu are efect în organizația dvs., cu excepția cazului în care alegeți primul buton radio și activați SSO.

Ce trebuie să faceți în continuare

Utilizați procedurile din Sincronizarea utilizatorilor Okta în Cisco Webex Control Hub dacă doriți să faceți asigurarea accesului utilizatorilor din Okta în cloud-ul Webex.

Utilizați procedurile din Sincronizarea utilizatorilor Azure Active Directory în Cisco Webex Control Hub dacă doriți să efectuați furnizarea utilizatorilor din Azure AD în cloud Webex.

Puteți urma procedura din Suprimarea e-mailurilor automate pentru a dezactiva e-mailurile care sunt trimise noilor 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 bazându-se Webex în ADFS

Această sarcină se referă în mod specific la actualizarea ADFS cu noile metadate SAML din Webex. Există articole asociate dacă trebuie să configurați SSO cu ADFSsau dacă trebuie să actualizați (un alt) IdP cu metadate SAML pentru un nou certificatWebex SSO.

Înainte de a începe

Trebuie să exportați fișierul cu metadate SAML din Control Hub înainte de a putea actualiza Webex Relying 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 exemplu, //ADFS_servername/temp/idb-meta--SP.xml.

3

Deschideți Powershell.

4

Rulați Get-AdfsRelyingPartyTrust pentru a citi toate bazele de date de încredere ale partidelor.

Rețineți parametrul TargetName al încrederii părții Webex. Folosim exemplul "Webex", dar ar putea fi diferit în ADFS.

5

Rulați Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta--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 de 5 ani și aveți activată revocarea certificatului de semnare sau 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 Gestionare > Setăriorganizație, defilați la Autentificareși comutați la setarea Conectare unică pentru a porni expertul de configurare.

  2. Faceți clic pe Următorul pentru a sări peste pagina Import metadate IdP.

    Nu trebuie 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, este posibil să vedeți un cod de eroare jurnal de evenimente ADFS 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.

Eroare a apărut în timpul unei încercări de a construi lanțul de certificate pentru încredere parte bazându-se

La actualizarea certificatului SSO, este posibil să vi se prezinte această eroare atunci când vă conectați: Cod de stare nevalid în răspuns.

Dacă vedeți această eroare, verificați jurnalele Vizualizator evenimente pe serverul ADFS și căutați următoarea eroare: A apărut o eroare în timpul unei încercări de a construi lanțul de certificate pentru certificatul de încredere al părții care se bazează 'https://idbroker.webex.com/<org-ID>' certificat identificat prin amprenta miniaturală '754B9208F1F75C5CC122740F3675C5D129471D80'. Cauzele posibile sunt că certificatul a fost revocat, lanțul de certificate nu a putut fi verificat așa cum este specificat de setările de revocare a certificatului de criptare al trustului de criptare al părții bazându-se 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-ul federației

ID-ul federației este sensibil la litere mari și mici. Dacă aceasta este adresa de e-mail a organizațională, introduceți-o exact așa cum o trimite ADFS sau Webex nu poate găsi utilizatorul potrivit.

O regulă de revendicare particularizată 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 Service > Endpoints > metadate > Tip:Metadate federație în ADFS Management.

Sincronizarea timpului

Asigurați-vă că ceasul de sistem al serverului ADFS este sincronizat cu o sursă de timp Internet fiabilă care utilizează Network Time Protocol (NTP). Utilizați următoarea comandă PowerShell pentru a oblic 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. Înlocuiți valoarea din valoarea SP EntityDescriptor ID din fișierul de metadate Webex. De exemplu:

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