In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie die SAML (Single Security Assertion Markup Language) Identity Provider-Verbindung bzw. -Vereinbarung pro Cluster mit AD FS (Active Directory Federation Service) konfiguriert wird.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:
Bei SAML SSO muss es sich um einen Vertrauenskreis zwischen dem Service Provider (SP) und dem IdP handeln. Diese Vertrauenswürdigkeit wird im Rahmen von SSO Enablement erstellt, wenn Vertrauenswürdigkeit (Metadaten) ausgetauscht wird. Laden Sie die Metadaten vom CUCM herunter und laden Sie sie auf IdP hoch, laden Sie die Metadaten ähnlich von IdP herunter und laden Sie sie in CUCM hoch.
Vor CUCM 11.5 generiert der Ausgangsknoten die Metadatendatei. Außerdem werden die Metadatendateien von anderen Knoten im Cluster gesammelt. Es fügt alle Metadatendateien einer einzelnen ZIP-Datei hinzu und präsentiert sie dann dem Administrator. Der Administrator muss diese Datei entpacken und alle Dateien auf der IDP bereitstellen. Beispielsweise 8 Metadatendateien für einen Cluster mit 8 Knoten.
Eine SAML-ID-Verbindung/Vereinbarung pro Cluster-Funktion wird ab 11.5 eingeführt. Im Rahmen dieser Funktion generiert CUCM eine einzige Metadatendatei für Service Provider für alle CUCM- und IMP-Knoten im Cluster. Das neue Namensformat für die Metadatendatei ist <hostname>-single-agreement.xml
Grundsätzlich erstellt ein Knoten die Metadaten und leitet sie an andere SP-Knoten im Cluster weiter. Dadurch wird die Bereitstellung, Wartung und Verwaltung vereinfacht. Beispiel: 1 Metadatendatei für einen Cluster mit 8 Knoten.
Die Metadatendatei für den Cluster verwendet ein Multiserver-Tomcat-Zertifikat, das sicherstellt, dass das Schlüsselpaar für alle Knoten im Cluster identisch ist. Die Metadatendatei verfügt außerdem über eine Liste von ACS-URLs (Assertion Consumer Service) für die einzelnen Knoten im Cluster.
CUCM und Cisco IM and Presence Version 11.5 unterstützen sowohl die SSO-Modi, clusterweit (eine Metadatendatei pro Cluster) und pro Knoten (vorhandenes Modell).
In diesem Dokument wird beschrieben, wie der clusterweite Modus der SAML SSO mit AD FS 2.0 konfiguriert wird.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Öffnen Sie einen Webbrowser, melden Sie sich als Administrator bei CUCM an, und navigieren Sie zu System > SAML Single Sign On.
Standardmäßig ist das Optionsfeld Clusterweit aktiviert. Klicken Sie auf Alle Metadaten exportieren. Die Metadatendatei wird dem Administrator im Namen <hostname>-single-agreement.xml präsentiert.
Informationen zum Herunterladen von IdP-Metadaten finden Sie unter https:// <FQDN des ADFS>/federationmetadata/2007-06/federationmetadata.xml
Navigieren Sie, wie im Bild gezeigt, zu AD FS 2.0 Management/Trust Relation Ships/Relying Party Trust. Klicken Sie auf Vertrauenswürdige Partei hinzufügen.
Der Assistent für das Hinzufügen von Gruppenvertrauen wird geöffnet, wie im Bild gezeigt. Klicken Sie jetzt auf Start.
Klicken Sie auf Importdaten, die angeben, ob eine Partei aus einer Datei stammt. Durchsuchen Sie die von der CUCM SAML SSO-Konfigurationsseite heruntergeladenen SP-Metadaten. Klicken Sie anschließend auf Weiter, wie im Bild gezeigt:
Geben Sie den Display Name (Anzeigenamen) und alle optionalen Notizen für die Relying Party (Partei) ein. Klicken Sie auf Weiter, wie im Bild gezeigt:
Wählen Sie Zulassen aller Benutzer für den Zugriff auf diese vertrauliche Partei, um allen Benutzern den Zugriff auf diese Partei zu gestatten, und klicken Sie dann auf Weiter, wie im Bild gezeigt:
Auf der Seite Ready to Add Trust (Bereit zum Hinzufügen von Vertrauenswürdigkeit) können Sie die Einstellungen für die konfigurierte Relying Party Trust (Vertrauenswürdigkeit) überprüfen. Klicken Sie jetzt auf Weiter, wie im Bild gezeigt:
Finish Page (Abschließende Seite) bestätigt, dass die Vertrauenswürdigkeit der Partei erfolgreich der AD FS-Konfigurationsdatenbank hinzugefügt wurde. Deaktivieren Sie das Kontrollkästchen, und klicken Sie auf Schließen, wie im Bild gezeigt:
Klicken Sie mit der rechten Maustaste auf Relying Party Trusts, und klicken Sie auf Edit Claim Rules (Anspruchsregeln bearbeiten), wie im Bild gezeigt:
Klicken Sie jetzt auf Regel hinzufügen, wie im Bild gezeigt:
Wenn die Regel für das Hinzufügen von Umwandlungsforderungen geöffnet wird, klicken Sie auf Weiter mit der Standardlastenvorlage LDAP-Attribute als Ansprüche senden, wie im Bild gezeigt:
Klicken Sie auf Anspruchsregel konfigurieren, wie in diesem Bild gezeigt. Das LDAP-Attribut muss mit dem LDAP-Attribut in der LDAP-Verzeichniskonfiguration im CUCM übereinstimmen. Verwalten Sie den ausgehenden Anspruchtyp als uid. Klicken Sie auf Fertig stellen, wie im Bild gezeigt:
Fügen Sie die benutzerdefinierte Regel für die vertrauende Partei hinzu. Klicken Sie auf Regel hinzufügen. Wählen Sie Anträge mit einer benutzerdefinierten Regel senden aus, und klicken Sie dann auf Weiter, wie im Bild gezeigt:
Geben Sie in der Regel zur Anspruchskonfiguration einen Namen für eine Anspruchsregel ein, und kopieren Sie anschließend die angegebene und die Vergangenheit der Anspruchsregel im Feld Benutzerdefinierte Regel im Assistenten. Damit wird der Namensgleichrichter und der Spname-Qualifizierer in der Anspruchsregel geändert. Klicken Sie auf Fertig stellen, wie im Bild gezeigt:
Anspruchsregel:
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://<FQDN of ADFS>/adfs/com/adfs/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<Entity ID in the SP Metadata>"); Entity ID = Open the SP metadata and check the Entity ID. Basically, its the CUCM Publisher’s FQDN.
Klicken Sie, wie im Bild gezeigt, auf Übernehmen und dann auf OK.
Öffnen Sie einen Webbrowser, melden Sie sich als Administrator bei CUCM an, und navigieren Sie zu System > SAML Single Sign On.
Standardmäßig ist das Optionsfeld Clusterweit aktiviert. Klicken Sie auf Saml SSO aktivieren, wie im Bild gezeigt:
Wie im Bild gezeigt, benachrichtigt das Popup-Fenster die Warnung für den Neustart des Webservers und informiert, dass die clusterweite SAML SSO oder Per-Node SAML SSO gemäß idp ausgewählt wird. Klicken Sie auf Weiter.
Das Kriterium für die Aktivierung der clusterweiten SSO besteht darin, dass Sie bereits über ein Multiserver-Tomcat-Zertifikat verfügen müssen. Klicken Sie auf Test for Multi-Server Tomcat Certificate, wie im Bild gezeigt:
Nach der Bestätigung wird für alle Knoten das Multi-Server-Zertifikat angezeigt. Alle Knoten verfügen über das Multi-Server-Zertifikat, und klicken Sie dann auf Weiter, wie im Bild gezeigt:
Klicken Sie, wie im Bild gezeigt, auf Weiter.
Durchsuchen und wählen Sie die heruntergeladenen IdP-Metadaten aus. Klicken Sie auf Import IdP Metadata, wie im Bild gezeigt:
Die Seite bestätigt den für alle Server erfolgreich importierten Import, und klicken Sie dann auf Weiter, wie im Bild gezeigt:
Klicken Sie, wie im Bild gezeigt, auf Weiter, da die SP-Metadaten bereits von der ersten SAML SSO-Konfigurationsseite exportiert wurden.
CUCM muss mit dem LDAP-Verzeichnis synchronisiert sein. Der Assistent zeigt die gültigen, im LDAP-Verzeichnis konfigurierten Administratorbenutzer an. Wählen Sie den Benutzer aus, und klicken Sie auf SSO-Test ausführen, wie im Bild gezeigt:
Geben Sie, wie im Bild gezeigt, die Benutzer-ID und das entsprechende Kennwort ein, sobald Sie dazu aufgefordert werden.
Wie im Bild gezeigt, bestätigt das Popup-Fenster, dass der Test erfolgreich war.
Klicken Sie, wie im Bild gezeigt, auf Fertig stellen, um die Konfiguration für die Aktivierung der SSO abzuschließen.
Die im Bild angezeigte Seite bestätigt, dass der SAML SSO-Aktivierungsprozess auf allen Servern initiiert wird.
Melden Sie sich mit SAML SSO-Anmeldeinformationen ab, und melden Sie sich wieder beim CUCM an. Navigieren Sie zu System >SAML Single Sign On. Klicken Sie auf SSO-Test für andere Knoten im Cluster ausführen, wie im Bild gezeigt:
In diesem Abschnitt überprüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Bestätigen Sie, dass der SSO-Test für die Knoten erfolgreich ist, für die SAML SSO aktiviert ist. Navigieren Sie zu System >SAML Single Sign On. Erfolgreiche SSO-Tests zeigen den Status Bestanden an.
Nach Aktivierung der SAML SSO werden installierte Anwendungen und Plattformanwendungen für die CUCM-Anmeldeseite aufgelistet, wie in diesem Bild gezeigt.
Nach Aktivierung der SAML SSO werden installierte Anwendungen und Plattformanwendungen für die Anmeldeseite IM und Presence aufgelistet, wie in diesem Bild gezeigt:
Dieser Abschnitt enthält Informationen zur Fehlerbehebung in Ihrer Konfiguration.
Um die SSO-Protokolle auf Debuggen festzulegen, verwenden Sie den Befehl SampleTrace Level DEBUG.
Erfassen Sie die SSO-Protokolle mithilfe von RTMT oder vom Speicherort activelog /tomcat/logs/ssosp/log4j/*.log mithilfe der CLI.
Beispiel für SSO-Protokolle zeigt die generierten und an andere Knoten gesendeten Metadaten
2016-05-28 14:59:34,026 DEBUG [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Call GET API to generate Clusterwide SP Metadata in the Local node. 2016-05-28 14:59:47,184 DEBUG [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Call to post the generated SP Metadata to other nodes 2016-05-28 14:59:47,185 INFO [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Begin:postClusterWideSPMetaData 2016-05-28 14:59:47,186 DEBUG [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Nodes [cucm1150, cucm1150sub.adfs.ucce.com] 2016-05-28 14:59:47,186 DEBUG [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Post ClusterWideSPMetadata to the cucm1150 2016-05-28 14:59:47,187 DEBUG [http-bio-443-exec-297] cluster.SAMLSSOClusterManager - Post ClusterWideSPMetadata to the cucm1150sub.adfs.ucce.com