Pakket

• U moet een standaardpakket selecteren wanneer u een sjabloon maakt (zie Pakketten in het gedeelte Overzicht voor meer informatie. Alle gebruikers aan wie die sjabloon is ingericht, ontvangen het standaardpakket, ongeacht of ze doorstromen of zelf provisioning.

• U kunt de pakketselectie voor verschillende klanten beheren door meerdere sjablonen te maken en verschillende standaardpakketten in elk te selecteren. U kunt dan verschillende provisioningskoppelingen of verschillende adpaters voor provisioning per bedrijf distribueren, afhankelijk van uw gekozen gebruikersvoorzieningenmethode voor deze sjablonen.

• U kunt het pakket met specifieke abonnees wijzigen vanaf deze standaard, met behulp van de inrichtings-API (zie Integreren met Webex voor BroadWorks Provisioning API in het gedeelte Referentie) of via Partner Hub.

• U kunt het pakket van een abonnee niet wijzigen vanuit BroadWorks. De toewijzing van de geïntegreerde IM&P-service is aan of uit; als de abonnee deze service in BroadWorks heeft toegewezen, wordt het pakket definiëren in de Partner Hub-sjabloon die is gekoppeld aan de inrichtings-URL van de abonnee.

Reseller en ondernemingen of serviceprovider en groepen?

• De manier waarop uw BroadWorks-systeem is geconfigureerd, heeft een invloed op de flow-through provisioning. Als u een reseller bij Enterprise bent, moet u de Enterprise-modus inschakelen wanneer u een sjabloon maakt.
• Als uw BroadWorks-systeem is geconfigureerd in serviceprovider modus, kunt u de Enterprise-modus uitschakelen in uw sjablonen laten.
• Als u van plan bent om organisaties van klanten in te stellen met behulp van beide BroadWorks-modi, moet u verschillende sjablonen voor groepen en ondernemingen gebruiken.

Verificatiemodus

Hoe verifiëren de abonnees van klanten?

(Optie) Certificaatvereisten voor TLS-bridge Proxy

• Webex toont een openbaar ondertekend clientcertificaat aan de proxy.

• De proxy vertrouwt de interne CISCO-CA die het clientcertificaat heeft ondertekend. U kunt deze CA/keten downloaden via Control Hub en deze toevoegen aan de trust store van de proxy. Het openbaar ondertekende XSP-servercertificaat wordt ook geladen in de proxy.

• De proxy toont het openbaar ondertekende servercertificaat voor Webex.

• Webex vertrouwt de openbare certificeringsstantie (CA) die het servercertificaat van de proxy heeft ondertekend.

• De proxy toont een intern ondertekend clientcertificaat voor de XSP's.

  Dit certificaat moet het toestelveld X509.v3 extension field Extended Key usage hebben ingevuld met de BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 en hetTLS-clientAuth-doel. Bijvoorbeeld.:

  X509v3-extensies:
      X509v3 Gebruik uitgebreide sleutel:
          1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS-webclientverificatie

  Houd er bij het genereren van interne clientcertificaten voor de proxy rekening mee dat SAN-certificaten niet worden ondersteund. Interne servercertificaten voor de XSP kunnen SAN zijn. Openbare certificeringsinstanties zijn mogelijk niet bereid certificaten te ondertekenen met de eigen broadworks OID die vereist is. In het geval van een gebridgingsproxy moet u mogelijk een interne CA gebruiken om het clientcertificaat te ondertekenen dat de proxy voor de XSP presenteert.

• De XSP's vertrouwen de interne CA.

• De XSP's presenteren een intern ondertekend servercertificaat.

• De proxy vertrouwt de interne CA.

• De ClientIdentity van de toepassingsserver bevat de cn van het intern ondertekende clientcertificaat dat door de proxy aan de XSP wordt gepresenteerd.

(Optie) Certificaatvereisten voor TLS-passthrough Proxy of XSP in DMZ

• Webex presenteert een intern door CA ondertekend clientcertificaat van Cisco voor de XSP's.

• De XSP's vertrouwen de interne Cisco-CA die het clientcertificaat heeft ondertekend. U kunt deze CA/keten downloaden via Control Hub en deze toevoegen aan de trust store van de proxy. Het openbaar ondertekende XSP-servercertificaat wordt ook geladen in de XSP's.

• De XSP's presenteren de openbaar ondertekende servercertificaten aan Webex.

• Webex vertrouwt de openbare CA die de XSP's servercertificaten heeft ondertekend.

• De ClientIdentity van de toepassingsserver bevat de cn van het door Cisco ondertekende clientcertificaat dat door Webex aan de XSP wordt getoond.

Hoe Cisco Webex Cloud XSP-adressen vindt

Cisco Webex Cloud-services voert een DNS A/AAAA-opzoekactie uit van de geconfigureerde XSP-hostnaam en maakt verbinding met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn of de XSP-server zelf. Als er meerdere IP-adressen worden geretourneerd, wordt de eerste vermelding in de lijst geselecteerd.

Voorbeelden 2 & 3 hieronder tonen de toewijzing van A/AAAA-records aan één en meerdere IP-adressen.

In het scenario met meerdere IP-adressen adviseren wij dat u uw DNS-vermeldingen zo configureert dat ze bij toer draaien zodat de clientverbindingen van Webex worden verdeeld.

Hoe clients XSP-adressen vinden

De client probeert de XSP-knooppunten te vinden met behulp van de volgende DNS-stroom:

1. De client haalt aanvankelijk de URL's voor Xsi-Acties/Xsi-Events op vanuit Cisco Webex Cloud (u hebt deze ingevoerd bij het maken van de gekoppelde BroadWorks-belcluster). De Xsi-hostnaam/het domein wordt geparseerd met de URL en de client voert SRV een volgende zoekactie uit:

   1. Client voert een SRV-zoekactie uit _xsi-client._tcp.<xsi domain="">

      (Zie het volgende voorbeeld 1)

   2. Als de SRV een of meer richtingen retourneert:

      De client doet een A/AAAA-zoekactie naar de teruggebrachte IP-adressen en caches van de klant.

      De client maakt verbinding met de SRV op een van de geretourneerde IP-adressen. Er wordt een adres gekozen op basis van SRV prioriteit en vervolgens het gewicht (of willekeurig, als ze allemaal gelijk zijn).

   3. Als de SRV niet de volgende doelen wer:

      De client zoekt de Xsi-hoofdparameter a/AAAA en probeert vervolgens verbinding te maken met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn of de XSP-server zelf.

      (Zie de volgende voorbeelden 2 en 3)

2. (Optioneel) Vervolgens kunt u aangepaste XSI-Acties/XSI-Events-gegevens verstrekken in de apparaatvervolging voor de Webex Teams client, met de volgende tags:

   
   <protocols>
       <xsi>
           <paths>
               <root>%XSI_ROOT_WXT%</root>             <actions>%XSI_ACTIONS_PATH_WXT%</actions>             <events>%XSI_EVENTS_PATH_WXT%</events>
           </paths>
       </xsi>
   </protocols>

   1. Deze configuratieparameters hebben voorrang op elke configuratie in uw BroadWorks-cluster in Control Hub.

   2. Als deze bestaan, wordt de client vergeleken met het oorspronkelijke XSI-adres dat het heeft ontvangen via de broadWorks-clusterconfiguratie.

   3. Als er verschil is gedetecteerd, wordt de Client voor de XSI-acties/XSI Events-verbinding opnieuw initialiseren. De eerste stap in dit proces is het uitvoeren van hetzelfde DNS-opzoekproces dat wordt weergegeven onder stap 1, dit keer met gebruik van de parameter %XSI_ROOT_WXT% uit het configuratiebestand.

      Zorg dat u de bijbehorende records SRV maken als u deze tag gebruikt om de Xsi-interfaces te wijzigen.

Voorbeeld van DNS-records

XSP-knooppunten DNS-aanbevelingen

• Gebruik één A/AAAA-record:

  • als u een load balancing reverse proxy moet oplossen voor de XSP-servers

• U moet de A/AAAA-records bij de round-robin gebruiken:

  •  als u meerdere XSP-servers via internet hebt

• U moet DNS-servicedetectie gebruiken als u:

  • Directory zoeken nodig in omgevingen met meerdere XSP's.

  • Al bestaande integraties hebben waarvoor detectie SRV vereist.

  • Heeft unieke configuraties waarbij standaard A/AAAA-records onvoldoende zijn.