Konfigurieren des Identitätsanbieters für den Cisco Identity Service zur Aktivierung von SSO

Einleitung

In diesem Dokument wird die Konfiguration des Identity Providers (IdP) für Cisco Identity Service (IdS) zur Aktivierung von Single Sign On (SSO) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Unified Contact Center Express (UCCX) Version 11.5 bzw. Cisco Unified Contact Center Enterprise Version 11.5 bzw. Packaged Contact Center Enterprise (PCCE) Version 11.5
• Microsoft Active Directory - AD auf Windows Server installiert
• Active Directory Federation Service (ADFS) Version 2.0/3.0

Hinweis: In den Screenshots und Beispielen wird in diesem Dokument auf UCCX verwiesen. Die Konfiguration ist jedoch in Bezug auf die Cisco IdS (UCCX/UCCE/PCCE) und die IdP ähnlich.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Cisco IDs-Bereitstellungsmodelle

Produkt	Bereitstellung
UCCX	Mitansässig
PCCE	Co-Resident mit CUIC (Cisco Unified Intelligence Center) und LD (Live-Daten)
UCCE	Gleichzeitige Implementierung mit CUIC und LD für 2k-Bereitstellungen Standalone für Bereitstellungen der Serien 4000 und 12000.

Überblick über SSO

Cisco bietet zahlreiche Services in unterschiedlichen Formen an. Als Endbenutzer sollten Sie sich nur einmal anmelden, um Zugriff auf alle Cisco Services zu erhalten. Wenn Sie Kontakte aus einer der Anwendungen und Geräte von Cisco suchen und verwalten möchten, nutzen Sie alle möglichen Quellen (Firmenverzeichnis, Outlook, mobile Kontakte, Facebook, LinkedIn, Verlauf), und lassen Sie sie auf eine standardisierte und konsistente Weise darstellen, die die erforderlichen Informationen liefert, um ihre Verfügbarkeit zu kennen und um die besten Kontaktmöglichkeiten zu erhalten.

SSO mit SAML (Security Assertion Markup Language) erfüllt diese Anforderung. SAML/SSO bietet Benutzern die Möglichkeit, sich über eine gemeinsame Konto- und Autorisierungsidentität, die IdP, bei mehreren Geräten und Services anzumelden. Die SSO-Funktion ist ab UCCX/UCCE/PCCE 11.5 verfügbar.

Konfigurationsübersicht

Konfigurieren

Authentifizierungstypen

Cisco IdS unterstützt nur die formularbasierte Authentifizierung von IdPs.

In den folgenden MSDN-Artikeln erfahren Sie, wie Sie die Formularauthentifizierung in ADFS aktivieren.

• Informationen zu ADFS 2.0 finden Sie in diesem Microsoft TechNet-Artikel:
  http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx
• Informationen zu ADFS 3.0 finden Sie in diesem Microsoft TechNet-Artikel:
  https://learn.microsoft.com/en-us/archive/blogs/josrod/enabled-forms-based-authentication-in-adfs-3-0

Hinweis: Cisco IdS 11.6 und höher unterstützt die formularbasierte und Kerberos-Authentifizierung. Damit die Kerberos-Authentifizierung funktioniert, müssen Sie die formularbasierte Authentifizierung deaktivieren.

Aufbau einer Vertrauensbeziehung

Führen Sie zum Onboarding und zur Ermöglichung der Verwendung von Cisco IdS für SSO durch Anwendungen den Metadatenaustausch zwischen IdS und IdP durch.

• SAML SP-Metadatendatei herunterladen  sp.xml.
• Von Settings, navigieren Sie zu IdS Trust auf der Seite "IDs Management".

• Laden Sie die IdP-Metadatendatei von der IdP von der URL herunter:
  https://<ADFSServer>/federationmetadata/2007-06/federationmetadata.xml

• Laden Sie auf der IDs-Verwaltungsseite die IdP-Metadatendatei hoch, die im vorherigen Schritt heruntergeladen wurde.

Mit diesem Verfahren werden die IDs-Metadaten hochgeladen und Anspruchsregeln hinzugefügt. Dies ist für ADFS 2.0 und 3.0 geplant.

ADFS 2.0

Schritt 1: Navigieren Sie im ADFS-Server zu Start > All Programs > Administrative Tools > ADFS 2.0 Management, wie in der Abbildung dargestellt:

Schritt 2: Navigieren Sie zu Add ADFS 2.0 > Trust Relationship > Relying Party Trust, wie in der Abbildung dargestellt:

Schritt 3: Wählen Sie die gewünschte Option aus, wie im Bild gezeigt. Import data about the relying party from a file.

Schritt 4: Vollständige Einrichtung des Vertrauens der vertrauenden Seite.

Schritt 5: Wählen Sie in den Eigenschaften von Relying Party Trust die Option Identifier aus.

Schritt 6: Legen Sie den Bezeichner als vollqualifizierten Hostnamen des Cisco Identity Server fest, von dem sp.xml heruntergeladen wird.

Schritt 7. Klicken Sie mit der rechten Maustaste auf die Vertrauensstellung der vertrauenden Partei, und klicken Sie dann auf Edit Claim Rules.

Sie müssen zwei Anspruchsregeln hinzufügen. Die eine ist, wenn die LDAP-Attribute (Lightweight Directory Access Protocol) zugeordnet werden, während die zweite über benutzerdefinierte Anspruchsregeln erfolgt.

uid - Dieses Attribut wird für die Anwendungen benötigt, um den authentifizierten Benutzer zu identifizieren.
user_principale - Dieses Attribut wird von Cisco IdS benötigt, um den Bereich des authentifizierten Benutzers zu identifizieren.

Anspruchsregel 1:

Regel nach Namen hinzufügen NameID des Typs (die Werte des LDAP-Attributs als Ansprüche senden):

• Attributspeicher als Active Directory auswählen
• LDAP-Attribut zuordnen User-Principal-Name zu user_principal (Kleinbuchstaben)
• Wählen Sie das LDAP-Attribut aus, das verwendet werden soll als userId für Anwendungsbenutzer, um sich anzumelden und sie uid (Kleinbuchstaben)

Konfigurationsbeispiel in SamAccountName ist als Benutzer-ID zu verwenden:

• Zuordnen des LDAP-Attributs SamAccountName zu uid.
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Beispielkonfiguration bei UPN als Benutzer-ID:

• Zuordnen des LDAP-Attributs User-Principal-Name zu uid.
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Konfigurationsbeispiel in PhoneNumber als Benutzer-ID:

• Ordnen Sie das LDAP-Attribut telephoneNumber zu uid .
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Hinweis: Sie müssen sicherstellen, dass das für die Benutzer-ID bei der CUCM-LDAP-Synchronisierung konfigurierte LDAP-Attribut mit dem LDAP-Attribut für übereinstimmt. uid in der ADFS-Anspruchsregel NameID. Dies dient zum ordnungsgemäßen Funktionieren der CUIC- und Finesse-Anmeldung.

Hinweis: Dieses Dokument verweist auf Einschränkungen für den Namen der Anspruchsregel und zeigt Namen wie NameID, FQDN (Fully Qualified Domain Name) von UCCX usw. an. Obwohl benutzerdefinierte Felder und Namen in verschiedenen Abschnitten verwendet werden können, werden die Namen der Anspruchsregeln und die Anzeigenamen durchgehend als Standard beibehalten, um die Konsistenz und die Best Practices in der Namenskonvention zu wahren.

Anspruchsregel 2:

• Fügen Sie eine weitere Regel vom Typ "Benutzerdefinierte Anspruchsregel" mit dem Namen "Vollqualifizierter Hostname" von Cisco Identity Server hinzu, und fügen Sie diesen Regeltext hinzu.
  
  

  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"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• Im Cisco Identity Server-Cluster sind alle vollständig qualifizierten Hostnamen die des primären oder Herausgeberknotens von Cisco Identity Server.
• Beim <full qualified hostname of Cisco Identity Server> wird die Groß-/Kleinschreibung beachtet, sodass er genau (einschließlich der Groß-/Kleinschreibung) mit dem FQDN des Cisco Identity Server übereinstimmt.
• Beim <ADFS-Server-FQDN> wird die Groß-/Kleinschreibung beachtet, sodass er genau (einschließlich der Groß-/Kleinschreibung) mit dem ADFS-FQDN übereinstimmt.

Schritt 8: Klicken Sie mit der rechten Maustaste auf die Vertrauensstellung der vertrauenden Partei, und klicken Sie dann auf Properties und wählen Sie die Registerkarte "Erweitert" aus, wie im Bild dargestellt.

Schritt 9. Wählen Sie Secure Hash Algorithm (SHA) als SHA-256 aus, wie im Bild gezeigt.

Schritt 10. Klicken Sie auf OK.

ADFS 3.0

Schritt 1: Navigieren Sie im ADFS-Server zu Server Manager > Tools > ADFS Management.

Schritt 2: Navigieren Sie zu ADFS > Trust Relationship > Relying Party Trust.

Schritt 3: Wählen Sie die Option Import data about the relying party from a file.

Schritt 4: Vollständige Einrichtung des Vertrauens der vertrauenden Seite.

Schritt 5: Wählen Sie in den Eigenschaften von Relying Party Trust die Option Identifier aus.

Schritt 6: Legen Sie den Bezeichner als vollqualifizierten Hostnamen des Cisco Identity Server fest, von dem sp.xml heruntergeladen wird.

Schritt 7. Klicken Sie mit der rechten Maustaste auf Vertrauenswürdigkeit der vertrauenden Partei, und klicken Sie dann auf Edit Claim Rules.

Sie müssen zwei Anspruchsregeln hinzufügen. Die eine ist, wenn die LDAP-Attribute zugeordnet werden, während die zweite über benutzerdefinierte Anspruchsregeln erfolgt.

uid - Dieses Attribut wird benötigt, damit die Anwendungen den authentifizierten Benutzer identifizieren können.
user_principale - Dieses Attribut wird von Cisco IdS benötigt, um den Bereich des authentifizierten Benutzers zu identifizieren.

Anspruchsregel 1:

Regel nach Namen hinzufügen NameID vom Typ (die Werte des LDAP-Attributs werden als Ansprüche gesendet):

• Attributspeicher als Active Directory auswählen
• LDAP-Attribut zuordnen User-Principal-Name zu user_principal (Kleinbuchstaben)
• Wählen Sie das LDAP-Attribut aus, das verwendet werden soll als userId für Anwendungsbenutzer, die sich anmelden und der uid(Kleinbuchstaben)

Beispielkonfiguration bei SamAccountName ist als Benutzer-ID zu verwenden:

• Zuordnen des LDAP-Attributs SamAccountName zu uid.
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Beispielkonfiguration, wenn UPN als Benutzer-ID verwendet werden muss:

• Zuordnen des LDAP-Attributs User-Principal-Name zu uid.
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Beispielkonfiguration bei PhoneNumber als Benutzer-ID:

• Zuordnen des LDAP-Attributs telephoneNumber zu uid.
• Zuordnen des LDAP-Attributs User-Principal-Name zu user_principal.

Hinweis: Sie müssen sicherstellen, dass das für die Benutzer-ID bei der CUCM-LDAP-Synchronisierung konfigurierte LDAP-Attribut mit dem LDAP-Attribut für übereinstimmt. uid in der ADFS-Anspruchsregel NameID. Dies dient der ordnungsgemäßen Funktion der CUIC- und Finesse-Anmeldung.

Hinweis: In diesem Dokument wird auf Einschränkungen für den Namen der Anspruchsregel und Anzeigenamen wie NameID, FQDN von UCCX usw. verwiesen. Obwohl benutzerdefinierte Felder und Namen in verschiedenen Abschnitten verwendet werden können, werden die Namen der Anspruchsregeln und die Anzeigenamen durchgehend als Standard beibehalten, um die Konsistenz und die bewährten Verfahren in der Namenskonvention zu erhalten.

Anspruchsregel 2:

• Fügen Sie eine weitere Regel vom Typ "Benutzerdefinierte Anspruchsregel" mit dem Namen "Vollqualifizierter Hostname" von Cisco Identity Server hinzu, und fügen Sie diesen Regeltext hinzu.
                                

  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"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• Im Cisco Identity Server-Cluster sind alle vollständig qualifizierten Hostnamen die des primären oder Herausgeberknotens von Cisco Identity Server.
• Beim <full qualified hostname of Cisco Identity Server> wird die Groß-/Kleinschreibung beachtet, sodass er genau (einschließlich der Groß-/Kleinschreibung) mit dem FQDN des Cisco Identity Server übereinstimmt.
• Beim <ADFS-Server-FQDN> wird die Groß-/Kleinschreibung beachtet, sodass er genau (einschließlich der Groß-/Kleinschreibung) mit dem ADFS-FQDN übereinstimmt.

Schritt 8: Klicken Sie mit der rechten Maustaste auf Vertrauenswürdigkeit der vertrauenden Partei, und klicken Sie dann auf Properties und wählen Sie advanced aus.

Schritt 9. Wählen Sie SHA als SHA-256 aus, wie im Bild gezeigt.

Schritt 10. Klicken Sie auf OK.

Diese Schritte sind nach Schritt 10 obligatorisch.

Signierte SAML-Assertionen für die Vertrauensstellung der vertrauenden Seite (Cisco IDs) aktivieren

Schritt 1: Klicken Sie auf Start und geben Sie PowerShell ein, um Windows PowerShell zu öffnen.

Schritt 2: Fügen Sie ADFS CmdLet der PowerShell mit dem Befehl Add-PSSnapin Microsoft.Adfs.Powershell.

Schritt 3: Führen Sie den Befehl Set-ADFSRelyingPartyTrust -TargetName -SamlResponseSignature "MessageAndAssertion" .

          

Hinweis: Schritt 2. ist nicht erforderlich, wenn Sie ADFS 3.0 verwenden, da CmdLet bereits als Teil des Hinzufügens der Rollen und Funktionen installiert ist.

Hinweis:  Groß- und Kleinschreibung beachten, sodass die Groß- und Kleinschreibung mit dem übereinstimmt, was auf der Registerkarte Identifier der Trust-Eigenschaften der vertrauenden Partei festgelegt ist.

Hinweis: Cisco IdS unterstützt ab UCCX-Version 12.0 SHA-256. Die Vertrauensstellung der vertrauenden Partei verwendet SHA-256 zum Signieren der SAML-Anforderung und erwartet dieselbe Antwort von ADFS.

Konfiguration mehrerer Domänen für Federated ADFS

Wenn ein ADFS in einer bestimmten Domäne im Fall der Verbund-Funktion in ADFS die verbündete SAML-Authentifizierung für Benutzer in anderen konfigurierten Domänen bereitstellt, sind diese zusätzlichen Konfigurationen erforderlich.

In diesem Abschnitt bezieht sich der Begriff primäres ADFS auf das ADFS, das in IdS verwendet werden muss. Der Begriff Federated ADFS bezeichnet diejenigen ADFS, deren Benutzer sich über IdS anmelden können und somit das primäre ADFS sind.

Federated ADFS-Konfiguration

In jedem der verknüpften ADFS muss die Vertrauensstellung der vertrauenden Partei für das primäre ADFS und die Anspruchsregeln erstellt werden, die wie im vorherigen Abschnitt beschrieben konfiguriert wurden.

Primäre ADFS-Konfiguration

Für primäre ADFS ist neben der Vertrauensstellung der vertrauenden Partei für IDs diese zusätzliche Konfiguration erforderlich.

Hinzufügen Claim Provider Trust mit dem ADFS, für das der Verbund eingerichtet werden muss.

Stellen Sie im Claim Provider Trust sicher, dass die Pass through or Filter an Incoming Claim Regeln werden so konfiguriert, dass alle Anspruchswerte als Option weitergegeben werden:

• Namens-ID
• Wählen Sie die Name-ID aus dem Incoming Claim Type Absetzkasten
• Auswählen Transient als Option für das Format "Incoming NameID"
• uid: Dies ist ein benutzerdefinierter Anspruch. Geben Sie den Wert uid im Feld Incoming Claim Type Absetzkasten
• user_principale: Dies ist ein benutzerdefinierter Anspruch. Geben Sie den Wert user_principale im Feld Incoming Claim Type Absetzkasten

Fügen Sie unter Relying Party Trust for IDs (Vertrauenswürdige Partei für IDs) Folgendes hinzu: Pass though or Filter an Incoming Claim -Regeln, wobei alle Anspruchswerte als Option weitergegeben werden.

• NameIDFromSubdomäne
• Namens-ID auswählen aus Incoming Claim Type Absetzkasten
• Auswählen Transient als Option für das Format "Incoming NameID"
• uid: Dies ist ein benutzerdefinierter Anspruch. Geben Sie uid in das Feld Incoming Claim Type Absetzkasten
• user_principale: Dies ist ein benutzerdefinierter Anspruch. Geben Sie den Wert user_principale im Feld Incoming Claim Type Absetzkasten

Automatischer ADFS-Zertifikatrollover

Der automatische Zertifikats-Rollover wird für UCCX 11.6.1 und höher unterstützt. (Dieses Problem konnte durch das Fedlet Library-Upgrade auf Version 14.0 in UCCX 11.6 behoben werden.)

Kerberos-Authentifizierung (integrierte Windows-Authentifizierung)

Die integrierte Windows-Authentifizierung (IWA) stellt einen Mechanismus für die Authentifizierung der Benutzer bereit, lässt jedoch keine Übertragung von Anmeldeinformationen über das Netzwerk zu. Wenn Sie die integrierte Windows-Authentifizierung aktivieren, arbeitet auf der Grundlage von Tickets, um Knoten die Kommunikation über ein unsicheres Netzwerk zu ermöglichen, um ihre Identität untereinander auf sichere Weise zu beweisen. Benutzer können sich nach der Anmeldung bei ihren Windows-Computern bei einer Domäne anmelden.

Hinweis: Die Kerberos-Authentifizierung wird nur ab Version 11.6 unterstützt.

Domänenbenutzer, die bereits beim Domänencontroller (DC) angemeldet sind, werden nahtlos bei SSO-Clients angemeldet, ohne dass die Anmeldeinformationen erneut eingegeben werden müssen. Für Benutzer ohne Domäne greift IWA auf New Technology Local Area Network Manager (NTLM) zurück, und der Anmeldedialog wird angezeigt. Die Qualifizierung für IdS mit IWA-Authentifizierung erfolgt mit Kerberos gegen ADFS 3.0.

Schritt 1: Öffnen Sie die Windows-Eingabeaufforderung, und führen Sie sie als Administrator aus, um den HTTP-Dienst beim setspn command setspn -s http/ \ .

Schritt 2: Deaktivieren der Formularauthentifizierung und Aktivieren der Windows-Authentifizierung für Intranet-Sites Navigieren Sie zu ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit. Vergewissern Sie sich unter Intranet, dass nur Windows-Authentifizierung aktiviert ist (deaktivieren Sie die Option Formularauthentifizierung).

Konfiguration für Microsoft Internet Explorer für IWA-Support

Schritt 1: Stellen Sie Folgendes sicher Internet Explorer > Advanced > Enable Integrated Windows Authentication ist aktiviert.

Schritt 2: ADFS-URL muss hinzugefügt werden zu Security > Intranet zones > Sites  (winadcom215.uccx116.com ist die ADFS-URL).

Schritt 3: Stellen Sie Folgendes sicherInternet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon  ist so konfiguriert, dass die Anmeldedaten für Intranet-Sites verwendet werden.

Erforderliche Konfiguration für Mozilla Firefox für IWA-Support

Schritt 1: Wechseln Sie in den Konfigurationsmodus für Firefox. Öffnen Sie Firefox, und geben Sie about:config  in der URL. Akzeptieren Sie die Risikoübersicht.

Schritt 2: Suchen nach ntlm  und aktivieren Sie die network.automatic-ntlm-auth.allow-non-fqdn  und auf "true" festgelegt.

Schritt 3: Stellen Sie network.automatic-ntlm-auth.trusted-uris  der Domäne oder explizit der ADFS-URL.

Konfiguration erforderlich für Google Chrome zur IWA-Unterstützung

Google Chrome in Windows verwendet die Internet Explorer-Einstellungen, so konfigurieren Sie in Internet Explorer Tools > Internet Options oder in der Systemsteuerung unter Internet Options innerhalb der Unterkategorie Network and Internet.

Weitere Konfiguration für SSO

In diesem Dokument wird die Konfiguration aus dem IdP-Aspekt für SSO zur Integration in Cisco IdS beschrieben. Weitere Informationen finden Sie in den jeweiligen Produktkonfigurationsanleitungen:

• UCCX
• UCCE
• PCCE

Überprüfung

Anhand dieses Verfahrens wird ermittelt, ob die Vertrauensstellung der vertrauenden Partei zwischen Cisco IdS und IDP ordnungsgemäß eingerichtet wurde.

• Geben Sie im Browser die URL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN> ein.
• ADFS stellt das Anmeldeformular bereit. Diese Option steht zur Verfügung, wenn die oben angegebene Konfiguration korrekt ist.
• Nach erfolgreicher Authentifizierung muss der Browser eine Umleitung zu https://<IDS_FQDN>:8553/ids/saml/response durchführen. Daraufhin wird eine Checklistenseite angezeigt.

Hinweis: Die Seite "Checkliste", die als Teil des Überprüfungsprozesses angezeigt wird, ist kein Fehler, sondern eine Bestätigung, dass die Vertrauensstellung ordnungsgemäß eingerichtet ist.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.html.

UCCX SSO-Umgehungs-/Wiederherstellungs-URLs

• Cisco Unified CCX-Verwaltung
• Cisco Unified CCX Serviceability

SSO deaktivieren

• GUI: Navigieren zu CCX Administration > Single Sign-On (SSO) > Disable.
• CLI: set authmode non_sso (Mit diesem Befehl muss SSO für Pub und Sub deaktiviert werden. Er kann bei einem HA-Cluster (High Availability) von einem der beiden UCCX-Knoten ausgeführt werden.)

Screenshots

CCX-Administration - Nicht_SSO

CCX-Administration - SSO aktiviert

Finesse-Anmeldung - Nicht-SSO

Finesse-Anmeldung - SSO aktiviert

CUIC - Nicht_SSO

CUIC - SSO aktiviert