CUCM-Sicherheit als Standard und ITL-Betrieb und Fehlerbehebung

Einleitung

In diesem Dokument wird die SBD-Funktion (Security By Default) von Cisco Unified Communications Manager (CUCM) Version 8.0 und höher beschrieben.

Hintergrundinformationen

In CUCM Version 8.0 und höher wird die SBD-Funktion eingeführt, die aus ITL-Dateien (Identity Trust List) und dem Trust Verification Service (TVS) besteht.

Alle CUCM-Cluster verwenden jetzt automatisch ITL-basierte Sicherheit. Es besteht ein Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit/Benutzerfreundlichkeit, den Administratoren beachten müssen, bevor sie bestimmte Änderungen an einem CUCM-Cluster der Version 8.0 vornehmen.

Dieses Dokument dient als Ergänzung zu den offiziellen Standarddokumenten für Sicherheit und enthält betriebliche Informationen und Tipps zur Fehlerbehebung, die Administratoren helfen und die Fehlerbehebung vereinfachen.

Es ist eine gute Idee, mit diesen Kernkonzepten von SBD vertraut zu werden: Asymmetric Key Cryptography Wikipedia Artikel und Public Key Infrastructure Wikipedia Artikel.

SBD - Übersicht

Dieser Abschnitt bietet einen kurzen Überblick über die Funktionen von SBD. Vollständige technische Details der einzelnen Funktionen finden Sie im Abschnitt SBD-Details und Informationen zur Fehlerbehebung.

SBD bietet die folgenden drei Funktionen für unterstützte IP-Telefone:

• Standardauthentifizierung heruntergeladener TFTP-Dateien (Konfiguration, Gebietsschema, Ringliste), die einen Signaturschlüssel verwenden
• Optionale Verschlüsselung von TFTP-Konfigurationsdateien mit einem Signaturschlüssel
• Zertifikatüberprüfung für telefoninitiierte HTTPS-Verbindungen, die einen entfernten Zertifikatvertrauensspeicher auf dem CUCM (TVS) verwenden

Dieses Dokument bietet einen Überblick über die einzelnen Funktionen.

TFTP-Download-Authentifizierung

Wenn eine CTL- (Certificate Trust List) oder ITL-Datei vorhanden ist, fordert das IP-Telefon eine signierte TFTP-Konfigurationsdatei vom CUCM-TFTP-Server an.

Mit dieser Datei kann das Telefon überprüfen, ob die Konfigurationsdatei von einer vertrauenswürdigen Quelle stammt. Wenn CTL-/ITL-Dateien auf Telefonen vorhanden sind, müssen Konfigurationsdateien von einem vertrauenswürdigen TFTP-Server signiert werden.

Die Datei befindet sich während der Übertragung im Klartext im Netzwerk, wird jedoch mit einer speziellen Verifizierungssignatur ausgeliefert.

Das Telefon fordert SEP<MAC-Adresse>.cnf.xml.sgn an, um die Konfigurationsdatei mit der speziellen Signatur zu erhalten.

Diese Konfigurationsdatei wird vom privaten TFTP-Schlüssel signiert, der CallManager.pem auf der Seite "Operating System (OS) Administration Certificate Management" (Zertifikatsverwaltung für Betriebssystem) entspricht.

Die signierte Datei hat eine Signatur an der Spitze, um die Datei zu authentifizieren, ist aber ansonsten in Klartext-XML.

Das folgende Bild zeigt, dass der Signierer der Konfigurationsdatei CN=CUCM8-Publisher.bbburns.lab ist, die wiederum von CN=JASBURNS-AD signiert wird.

Das bedeutet, dass das Telefon die Signatur von CUCM8-Publisher.bbburns.lab anhand der ITL-Datei überprüfen muss, bevor diese Konfigurationsdatei akzeptiert wird.

Im folgenden Diagramm wird dargestellt, wie der private Schlüssel zusammen mit einer Message Digest Algorithm (MD)5- oder Secure Hash Algorithm (SHA)1-Hashfunktion verwendet wird, um die signierte Datei zu erstellen.

Bei der Signaturüberprüfung wird dieser Prozess durch die Verwendung des öffentlichen Schlüssels rückgängig gemacht, der zum Entschlüsseln des Hashs passt. Wenn die Hashes übereinstimmen, wird Folgendes angezeigt:

• Diese Datei wurde während der Übertragung nicht geändert.
• Diese Datei stammt von der in der Signatur aufgeführten Partei, da alles, was mit dem öffentlichen Schlüssel erfolgreich entschlüsselt wurde, mit dem privaten Schlüssel verschlüsselt wurde.

Verschlüsselung der TFTP-Konfigurationsdatei

Wenn die optionale TFTP-Konfigurationsverschlüsselung im zugeordneten Telefonsicherheitsprofil aktiviert ist, fordert das Telefon eine verschlüsselte Konfigurationsdatei an.

Diese Datei wird mit dem privaten TFTP-Schlüssel signiert und mit einem symmetrischen Schlüssel verschlüsselt, der zwischen dem Telefon und dem CUCM ausgetauscht wird (vollständige Details finden Sie im Cisco Unified Communications Manager Security Guide, Release 8.5(1)).

Sein Inhalt kann mit einem Netzwerk-Sniffer nur gelesen werden, wenn der Beobachter über die notwendigen Schlüssel verfügt.

Das Telefon fordert SEP<MAC-Adresse>.cnf.xml.enc.sgn an, um die signierte verschlüsselte Datei abzurufen.

Die verschlüsselte Konfigurationsdatei hat die Signatur auch am Anfang, aber es gibt keine Klartextdaten nach, nur verschlüsselte Daten (verworrene Binärzeichen in diesem Texteditor).

Das Bild zeigt, dass der Signierer derselbe ist wie im vorherigen Beispiel, daher muss dieser Signierer in der ITL-Datei vorhanden sein, bevor das Telefon die Datei akzeptiert.

Außerdem müssen die Entschlüsselungsschlüssel korrekt sein, bevor das Telefon den Inhalt der Datei lesen kann.

Trust Verification Service (Remote Certificate and Signature Verification)

IP-Telefone verfügen über einen begrenzten Arbeitsspeicher und können darüber hinaus eine große Anzahl von Telefonen in einem Netzwerk verwalten.

Der CUCM fungiert über den TVS als Remote-Vertrauensspeicher, sodass nicht auf jedem IP-Telefon ein vollständiger Zertifikatvertrauensspeicher platziert werden muss.

Wenn das Telefon eine Signatur oder ein Zertifikat nicht über die CTL- oder ITL-Dateien überprüfen kann, wird der TVS-Server zur Überprüfung aufgefordert.

Dieser zentrale Vertrauensspeicher ist einfacher zu verwalten, als wenn er auf allen IP-Telefonen vorhanden wäre.

SBD-Details und Informationen zur Fehlerbehebung

In diesem Abschnitt wird der SBD-Prozess im Detail beschrieben.

ITL-Dateien und -Zertifikate in CUCM vorhanden

Zunächst müssen einige Dateien auf dem CUCM-Server selbst vorhanden sein. Der wichtigste Bestandteil ist das TFTP-Zertifikat und der private TFTP-Schlüssel.

Das TFTP-Zertifikat finden Sie unter Betriebssystem-Verwaltung > Sicherheit > Zertifikats-Management > CallManager.pem.

Der CUCM-Server verwendet den privaten und den öffentlichen Schlüssel des Zertifikats CallManager.pem für den TFTP-Dienst (sowie für den Cisco Call Manager (CCM)-Dienst).

Das Bild zeigt, dass das Zertifikat CallManager.pem für CUCM8-publisher.bbburns.lab ausgestellt und von JASBURNS-AD signiert wird. Alle TFTP-Konfigurationsdateien werden mit dem unten angegebenen privaten Schlüssel signiert.

Alle Telefone können den öffentlichen TFTP-Schlüssel im Zertifikat CallManager.pem verwenden, um alle mit dem privaten TFTP-Schlüssel verschlüsselten Dateien zu entschlüsseln und alle mit dem privaten TFTP-Schlüssel signierten Dateien zu überprüfen.

Zusätzlich zum privaten Schlüssel für das Zertifikat CallManager.pem speichert der CUCM-Server auch eine ITL-Datei, die den Telefonen angezeigt wird.

Der Befehl show itl zeigt den vollständigen Inhalt dieser ITL-Datei über SSH (Secure Shell)-Zugriff auf die Betriebssystem-CLI des CUCM-Servers an.

In diesem Abschnitt wird die ITL-Datei Stück für Stück aufgeführt, da sie eine Reihe wichtiger Komponenten enthält, die für das Telefon verwendet werden.

Der erste Teil ist die Signaturinformation. Selbst die ITL-Datei ist eine signierte Datei. Diese Ausgabe zeigt, dass sie vom privaten TFTP-Schlüssel signiert wird, der mit dem vorherigen CallManager.pem-Zertifikat verknüpft ist.

admin:show itl
Length of ITL file: 5438
The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   296 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       110
4       SIGNERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
5       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
6       CANAME          15      CN=JASBURNS-AD
*Signature omitted for brevity*

Die nächsten Abschnitte enthalten jeweils ihren Zweck innerhalb eines speziellen Function-Parameters. Die erste Funktion ist das Sicherheitstoken des Systemadministrators. Dies ist die Signatur des öffentlichen TFTP-Schlüssels.

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1972
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      15      CN=JASBURNS-AD
6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5 
                                8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

Die nächste Funktion ist CCM+TFTP. Dies ist wieder der öffentliche TFTP-Schlüssel, der zum Authentifizieren und Entschlüsseln heruntergeladener TFTP-Konfigurationsdateien dient.

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1972
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       CCM+TFTP
5       ISSUERNAME      15      CN=JASBURNS-AD
6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5 
                                8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)

Die nächste Funktion ist TVS. Es gibt einen Eintrag für den öffentlichen Schlüssel jedes TVS-Servers, mit dem das Telefon verbunden ist.

Auf diese Weise kann das Telefon eine SSL-Sitzung (Secure Sockets Layer) mit dem TVS-Server herstellen.

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       743
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       TVS
5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB 
                                AA FE 66 5B EC 41 42 5D
12      HASH ALGORITHM  1       SHA-1

Die letzte in der ITL-Datei enthaltene Funktion ist die CAPF (Certificate Authority Proxy Function).

Mit diesem Zertifikat können die Telefone eine sichere Verbindung mit dem CAPF-Dienst auf dem CUCM-Server herstellen, sodass das Telefon ein LSC (Locally Significant Certificate) installieren oder aktualisieren kann.

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       455
2       DNSNAME         2
3       SUBJECTNAME     61      CN=CAPF-9c4cba7d;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       CAPF
5       ISSUERNAME      61      CN=CAPF-9c4cba7d;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       0A:DC:6E:77:42:91:4A:53
7       PUBLICKEY       140
8       SIGNATURE       128
11      CERTHASH        20      C7 3D EA 77 94 5E 06 14 D2 90 B1 
                                A1 43 7B 69 84 1D 2D 85 2E
12      HASH ALGORITHM  1       SHA-1

The ITL file was verified successfully.

Im nächsten Abschnitt wird genau beschrieben, was beim Booten eines Telefons geschieht.

Telefon lädt ITL- und Konfigurationsdatei herunter

Nachdem das Telefon gestartet wurde und eine IP-Adresse sowie die Adresse eines TFTP-Servers bezieht, werden zuerst die CTL- und die ITL-Dateien angefordert.

Diese Paketerfassung zeigt eine Telefonanfrage für die ITL-Datei. Wenn Sie nach tftp.opcode == 1 filtern, werden alle TFTP-Leseanforderungen vom Telefon angezeigt:

Da das Telefon CTL- und ITL-Dateien erfolgreich vom TFTP empfangen hat, fordert das Telefon eine signierte Konfigurationsdatei an.

Die Protokolle der Telefonkonsole, die dieses Verhalten anzeigen, sind über die Webschnittstelle des Telefons verfügbar:

Zunächst fordert das Telefon eine CTL-Datei an, die erfolgreich ist:

837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv
846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from 
14 . 48 . 44 . 80
847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes

Als Nächstes fordert das Telefon auch eine ITL-Datei an:

868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from 
14 . 48 . 44 . 80
869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes 

Telefon verifiziert ITL- und Konfigurationsdatei

Nachdem die ITL-Datei heruntergeladen wurde, muss sie überprüft werden. Es gibt eine Reihe von Zuständen, in denen sich ein Telefon zu diesem Zeitpunkt befinden kann. Daher werden diese in diesem Dokument alle Zustände behandelt.

• Auf dem Telefon ist keine CTL- oder ITL-Datei vorhanden, oder ITL ist aufgrund des Parameters "Cluster für Rollback auf Pre 8.0 vorbereiten" leer. In diesem Zustand vertraut das Telefon blind der nächsten heruntergeladenen CTL- oder ITL-Datei und verwendet diese Signatur von nun an.
• Das Telefon verfügt bereits über eine CTL, aber nicht über eine ITL. In diesem Zustand vertraut das Telefon einer ITL nur, wenn diese durch die CCM+TFTP-Funktion in der CTL-Datei verifiziert werden kann.
• Das Telefon verfügt bereits über eine CTL- und eine ITL-Datei. In diesem Zustand überprüft das Telefon, ob die zuletzt heruntergeladenen Dateien mit der Signatur auf dem CTL-, ITL- oder TVS-Server übereinstimmen.

Das folgende Flussdiagramm beschreibt, wie das Telefon signierte Dateien und HTTPS-Zertifikate überprüft:

In diesem Fall kann das Telefon die Signatur in den ITL- und CTL-Dateien überprüfen. Das Telefon verfügt bereits über eine CTL und eine ITL, sodass es einfach mit ihnen abgeglichen und die richtige Signatur gefunden hat.

877: NOT 09:13:17.925249 SECD: validate_file_envelope: 
File sign verify SUCCESS; header length <296>

Da das Telefon die CTL- und ITL-Dateien heruntergeladen hat, werden von diesem Zeitpunkt an NUR noch signierte Konfigurationsdateien angefordert.

Dies veranschaulicht, dass die Telefonlogik darauf ausgelegt ist, die Sicherheit des TFTP-Servers auf der Grundlage von CTL und ITL zu ermitteln und dann nach einer signierten Datei zu fragen:

917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml 
max size = 550001
918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:
14 . 48 . 44 . 80 
919: NOT 09:13:18.458937 tftpClient: look up server - 0
920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure
921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762 
tftpClient: ::ffff:14 . 48 . 44 . 80 is a secure server 
923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE
924: NOT 09:13:18.469485 tftpClient: Secure file requested
925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn 
-- SEP0011215A1AE3.cnf.xml.sgn
926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn 
from 14 . 48 . 44 . 80 with size limit of 550001
927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes 

Sobald die signierte Konfigurationsdatei heruntergeladen wurde, muss sie vom Telefon anhand der Funktion für CCM+TFTP im ITL authentifiziert werden:

937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS 
</usr/ram/SEP0011215A1AE3.cnf.xml>

Telefonkontakte TVS für unbekanntes Zertifikat

Die ITL-Datei stellt eine TVS-Funktion bereit, die das Zertifikat des TVS-Dienstes enthält, der auf dem TCP-Port 2445 des CUCM-Servers ausgeführt wird.

Der TVS wird auf allen Servern ausgeführt, auf denen der CallManager-Dienst aktiviert ist. Der CUCM-TFTP-Dienst verwendet die konfigurierte CallManager-Gruppe, um eine Liste der TVS-Server zu erstellen, die das Telefon in der Telefonkonfigurationsdatei kontaktieren muss.

In einigen Übungen wird nur ein einziger CUCM-Server verwendet. In einem CUCM-Cluster mit mehreren Knoten können bis zu drei TVS-Einträge für ein Telefon vorhanden sein, einer für jeden CUCM in der CUCM-Gruppe des Telefons.

Dieses Beispiel zeigt, was passiert, wenn die Telefonverzeichnis-Taste am IP-Telefon gedrückt wird. Die Verzeichnisse-URL ist für HTTPS konfiguriert, sodass das Tomcat-Webzertifikat vom Verzeichnisse-Server auf dem Telefon angezeigt wird.

Dieses Tomcat-Webzertifikat (tomcat.pem in der BS-Verwaltung) ist nicht in das Telefon geladen, daher muss sich das Telefon mit dem TVS in Verbindung setzen, um das Zertifikat zu authentifizieren.

Eine Beschreibung der Interaktion finden Sie im vorherigen TVS-Übersichtsdiagramm. Die Protokollperspektive für die Telefonkonsole sieht folgendermaßen aus:

Zuerst finden Sie die Verzeichnis-URL:

1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:
? - Directory url https://14 . 48 . 44 . 80:8443/ccmcip/xmldirectory.jsp

Es handelt sich um eine sichere SSL/TLS-HTTP-Sitzung (Transport Layer Security), die einer Überprüfung bedarf.

1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP: 
14 . 48 . 44 . 80, Port : 8443
1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,
<14 . 48 . 44 . 80> c:8 s:9 port: 8443
1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,
<14 . 48 . 44 . 80> c:8 s:9
1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake, 
<14 . 48 . 44 . 80> c:8 s:9
1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate 
Validation needs to be done

Das Telefon überprüft zunächst, ob das vom SSL/TLS-Server bereitgestellte Zertifikat in der CTL vorhanden ist. Anschließend prüft das Telefon die Funktionen in der ITL-Datei, um festzustellen, ob eine Übereinstimmung gefunden wird.

Diese Fehlermeldung lautet "HTTPS-Zertifikat nicht in CTL", was bedeutet, dass "die Zertifizierung nicht in CTL oder ITL gefunden werden kann".

1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file
1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file
1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,
<14 . 48 . 44 . 80>

Nachdem der direkte Inhalt der CTL- und ITL-Datei auf das Zertifikat überprüft wurde, wird als Nächstes der TVS-Cache vom Telefon überprüft.

Dies dient dazu, den Netzwerkverkehr zu reduzieren, wenn das Telefon kürzlich den TVS-Server nach dem gleichen Zertifikat gefragt hat.

Wenn das HTTPS-Zertifikat nicht im Telefoncache gefunden wird, können Sie eine TCP-Verbindung zum TVS-Server selbst herstellen.

1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate 
Authentication request
1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching 
entry found at cache
1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists, 
must be created
1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound 
to </tmp/secClnt_secd>
1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode
1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address
1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started 
a TLS connection establishment to the TVS server: IP:14 . 48 . 44 . 80, port:2445
(default); Waiting for it to get connected.

Denken Sie daran, dass die Verbindung zum TVS selbst SSL/TLS (Secure HTTP oder HTTPS) ist. Es handelt sich also auch um ein Zertifikat, das gegenüber der CTL gegenüber ITL authentifiziert werden muss.

Wenn alles richtig läuft, befindet sich das TVS-Serverzertifikat in der TVS-Funktion der ITL-Datei. Siehe ITL-Datensatz #3 im vorherigen Beispiel der ITL-Datei.

1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation 
needs to be done
1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL: 
Searching TL from CTL file 
1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL: 
Searching TL from ITL file
1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and 
hash in TL MATCH
1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash 
from TL, <14 . 48 . 44 . 80>

Erfolg Das Telefon verfügt nun über eine sichere Verbindung zum TVS-Server. Der nächste Schritt besteht darin, den TVS-Server zu fragen: "Hallo, vertraue ich diesem Directory-Serverzertifikat?"

Dieses Beispiel zeigt die Antwort auf diese Frage - eine Antwort von 0 bedeutet Erfolg (kein Fehler).

1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate 
Certificate : request sent to TVS server - waiting for response
1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response 
received, status : 0

Da eine erfolgreiche Antwort vom TVS vorliegt, werden die Ergebnisse für dieses Zertifikat im Cache gespeichert.

Wenn Sie also innerhalb der nächsten 86.400 Sekunden erneut die Taste Directories (Verzeichnisse) drücken, müssen Sie sich nicht an den TVS-Server wenden, um das Zertifikat zu verifizieren. Sie können einfach auf den lokalen Cache zugreifen.

1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate 
in TVS cache with default time-to-live value: 86400 seconds
1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS

Überprüfen Sie abschließend, ob die Verbindung zum Verzeichnisserver erfolgreich war.

1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:? 
- listener.httpSucceed:  https://14 . 48 . 44 . 80:8443/ccmcip/
xmldirectoryinput.jsp?name=SEP0011215A1AE3

Das nachfolgende Beispiel zeigt, was auf dem CUCM-Server geschieht, auf dem der TVS ausgeführt wird. TVS-Protokolle können mit dem Cisco Unified Real-Time Monitoring Tool (RTMT) erfasst werden.

Die CUCM-TVS-Protokolle zeigen an, dass Sie einen SSL-Handshake mit dem Telefon durchführen, das Telefon fragt TVS nach dem Tomcat-Zertifikat, und TVS antwortet, um anzugeben, dass das Zertifikat im TVS-Zertifikatspeicher übereinstimmt.

15:21:01.954 |   debug 14 . 48 . 44 . 202: tvsSSLHandShake Session ciphers - AES256-SHA
15:21:01.954 |   debug TLS HS Done for ph_conn .
15:21:02.010 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ
15:21:02.011 |   debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-
Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75

15:21:02.011 |   debug CertificateDBCache::getCertificateInformation - 
Certificate compare return =0 
15:21:02.011 |   debug CertificateDBCache::getCertificateInformation -
Certificate found and equal
15:21:02.011 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

Der TVS-Zertifikatspeicher ist eine Liste aller Zertifikate, die auf der Webseite Betriebssystemverwaltung > Zertifikatsverwaltung enthalten sind.

Überprüfen Sie manuell, ob Telefon-ITL mit CUCM-ITL übereinstimmt. 

Ein häufiges Missverständnis während der Fehlerbehebung betrifft die Tendenz, die ITL-Datei mit der Hoffnung zu löschen, dass sie ein Problem mit der Dateiverifizierung löst.

Manchmal ist das Löschen der ITL-Datei erforderlich, aber die ITL-Datei muss nur gelöscht werden, wenn ALLE diese Bedingungen erfüllt sind.

• Die Signatur der ITL-Datei auf dem Telefon stimmt nicht mit der Signatur der ITL-Datei auf dem CM TFTP-Server überein.
• Die TVS-Signatur in der ITL-Datei stimmt nicht mit dem vom TVS vorgelegten Zertifikat überein.
• Auf dem Telefon wird die Meldung "Verification Failed" (Überprüfung fehlgeschlagen) angezeigt, wenn versucht wird, die ITL-Datei oder die Konfigurationsdateien herunterzuladen.
• Der alte private TFTP-Schlüssel wurde nicht gesichert.

Hier ist, wie Sie die ersten beiden dieser Bedingungen überprüfen.

Zuerst können Sie die Prüfsumme der auf dem CUCM vorhandenen ITL-Datei mit der Prüfsumme der ITL-Datei des Telefons vergleichen.

Es gibt derzeit keine Möglichkeit, die MD5sum der ITL-Datei auf dem CUCM selbst zu betrachten, bis Sie eine Version mit dem Fix für diesen Cisco Bug CSCto60209 ausführen.

Führen Sie den Vorgang in der Zwischenzeit mit Ihren bevorzugten GUI- oder CLI-Programmen aus:

jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14 . 48 . 44 . 80
tftp> get ITLSEP0011215A1AE3.tlv
Received 5438 bytes in 0.0 seconds
tftp> quit
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum 
ITLSEP0011215A1AE3.tlv
b61910bb01d8d3a1c1b36526cc9f2ddc  ITLSEP0011215A1AE3.tlv

Dies zeigt, dass die MD5-Summe der ITL-Datei in CUCM b61910bb01d8d3a1c1b36526cc9f2ddc ist.

Nun können Sie das Telefon selbst betrachten, um den Hash der dort geladenen ITL-Datei zu bestimmen: Einstellungen > Sicherheitskonfiguration > Vertrauensliste.

Dies zeigt, dass die MD5-Summen übereinstimmen. Dies bedeutet, dass die ITL-Datei auf dem Telefon mit der Datei auf dem CUCM übereinstimmt, sodass sie nicht gelöscht werden muss.

Wenn sie übereinstimmt, müssen Sie mit dem nächsten Vorgang fortfahren - bestimmen Sie, ob das TVS-Zertifikat im ITL mit dem vom TVS vorgelegten Zertifikat übereinstimmt. Dieser Vorgang ist etwas komplizierter.

Sehen Sie sich zunächst die Paketerfassung des Telefons an, das mit dem TVS-Server an TCP-Port 2445 verbunden ist.

Klicken Sie in Wireshark mit der rechten Maustaste auf ein beliebiges Paket in diesem Stream, klicken Sie auf Decode As, und wählen Sie SSL aus. Suchen Sie nach dem Serverzertifikat, das wie folgt aussieht:

Sehen Sie sich das TVS-Zertifikat in der vorherigen ITL-Datei an. Dann sehen Sie einen Eintrag mit der Seriennummer 2E3E1A7BDAA64D84.

admin:show itl
        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       743
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       TVS
5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84

Erfolg, die Datei TVS.pem innerhalb der ITL-Datei stimmt mit dem TVS-Zertifikat überein, das im Netzwerk präsentiert wird. Sie müssen die ITL nicht löschen, und der TVS zeigt das richtige Zertifikat an.

Wenn die Dateiauthentifizierung weiterhin fehlschlägt, überprüfen Sie den Rest des vorherigen Flussdiagramms.

Einschränkungen und Interaktionen

Zertifikate neu erstellen/Cluster neu erstellen/Zertifikatablauf

Das wichtigste Zertifikat ist jetzt das Zertifikat CallManager.pem. Dieser private Zertifikatschlüssel wird zum Signieren aller TFTP-Konfigurationsdateien verwendet, die die ITL-Datei enthalten.

Wenn die Datei CallManager.pem neu generiert wird, wird ein neues CCM+TFTP-Zertifikat mit einem neuen privaten Schlüssel generiert. Außerdem ist die ITL-Datei jetzt mit diesem neuen CCM+TFTP-Schlüssel signiert.

Wenn Sie CallManager.pem neu generieren und den TVS- und TFTP-Dienst neu starten, geschieht dies beim Starten eines Telefons.

1. Das Telefon versucht, die neue ITL-Datei, die vom neuen CCM+TFTP signiert wurde, vom TFTP-Server herunterzuladen. Das Telefon verfügt zu diesem Zeitpunkt nur über die alte ITL-Datei, und die neuen Schlüssel befinden sich nicht in der ITL-Datei, die auf dem Telefon vorhanden ist.
2. Da das Telefon die neue CCM+TFTP-Signatur in der alten ITL nicht finden konnte, versucht es, den TVS-Dienst zu kontaktieren.
   

   Hinweis: Dieser Teil ist extrem wichtig. Das TVS-Zertifikat aus der alten ITL-Datei muss weiterhin übereinstimmen. Wenn sowohl CallManager.pem als auch TVS.pem genau zur gleichen Zeit neu generiert werden, können die Telefone keine neuen Dateien herunterladen, ohne die ITL manuell vom Telefon zu löschen.

3. Wenn das Telefon TVS kontaktiert, verfügt der CUCM-Server, auf dem TVS ausgeführt wird, über das neue Zertifikat CallManager.pem im Zertifikatspeicher des Betriebssystems.
4. Der TVS-Server kehrt zum Erfolg zurück, und das Telefon lädt die neue ITL-Datei in den Speicher.
5. Das Telefon versucht nun, eine Konfigurationsdatei herunterzuladen, die mit dem neuen Schlüssel CallManager.pem signiert wurde.
6. Nachdem die neue ITL geladen wurde, wird die neu signierte Konfigurationsdatei vom ITL im Speicher erfolgreich überprüft.

Wichtigste Punkte:

• Generieren Sie niemals gleichzeitig die Zertifikate CallManager.pem und TVS.pem neu.
• Wenn entweder TVS.pem oder CallManager.pem neu generiert wird, müssen TVS und TFTP neu gestartet und die Telefone zurückgesetzt werden, um die neuen ITL-Dateien zu erhalten.
• Neuere Versionen von CUCM verarbeiten dieses Telefon automatisch und warnen den Benutzer bei der Zertifikaterneuerung.
• Wenn mehr als ein TVS-Server vorhanden ist (mehr als ein Server in der CallManager-Gruppe), können die zusätzlichen Server das neue Zertifikat CallManager.pem authentifizieren.                          

Verschieben von Telefonen zwischen Clustern

Wenn Sie Telefone mit vorhandenen ITLs von einem Cluster in einen anderen verschieben, müssen der private ITL- und TFTP-Schlüssel berücksichtigt werden.

Jede neue Konfigurationsdatei, die dem Telefon präsentiert wird, MUSS mit einer Signatur in CTL, ITL oder einer Signatur im aktuellen TVS-Telefondienst übereinstimmen.

In diesem Dokument wird erläutert, wie Sie sicherstellen, dass die neue Cluster-ITL-Datei und die Konfigurationsdateien von der aktuellen ITL-Datei auf dem Telefon als vertrauenswürdig eingestuft werden können. https://supportforums.cisco.com/docs/DOC-15799.

Sicherung und Wiederherstellung

Das Zertifikat "CallManager.pem" und der private Schlüssel werden über das Disaster Recovery System (DRS) gesichert. Wenn ein TFTP-Server neu erstellt wird, MUSS er aus dem Backup wiederhergestellt werden, damit der private Schlüssel wiederhergestellt werden kann.

Ohne den privaten Schlüssel CallManager.pem auf dem Server vertrauen Telefone mit aktuellen ITLs, die den alten Schlüssel verwenden, nicht den signierten Konfigurationsdateien.

Wenn ein Cluster neu erstellt und nicht aus der Sicherung wiederhergestellt wird, entspricht dies genau dem Dokument "Telefone zwischen Clustern verschieben". Dies liegt daran, dass ein Cluster mit einem neuen Schlüssel für die Telefone ein anderer Cluster ist.

Es liegt ein schwerwiegender Fehler bei Backup und Wiederherstellung vor. Wenn ein Cluster für die Cisco Bug-ID CSCtn50405 empfänglich ist, enthalten die DRS-Sicherungen nicht das Zertifikat CallManager.pem.

Dadurch erzeugt jeder aus dieser Sicherung wiederhergestellte Server beschädigte ITL-Dateien, bis eine neue CallManager.pem-Datei generiert wird.

Wenn es keine anderen funktionalen TFTP-Server gibt, die den Sicherungs- und Wiederherstellungsvorgang nicht durchlaufen haben, bedeutet dies möglicherweise, dass alle ITL-Dateien von den Telefonen gelöscht werden müssen.

Um zu überprüfen, ob Ihre Datei CallManager.pem neu generiert werden muss, geben Sie den Befehl show itl gefolgt von:

run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from  
certificate as c, certificatetrustrolemap as r, typetrustrole as t where  c.pkid =
r.fkcertificate and t.enum = r.tktrustrole 

In der ITL-Ausgabe sind folgende Hauptfehler zu suchen:

This etoken was not used to sign the ITL file.

und

Verification of the ITL file failed.
Error parsing the ITL file!!

Die vorherige SQL-Abfrage (Structured Query Language) sucht nach Zertifikaten, die die Rolle "Authentication and Authorization" haben.

Das Zertifikat "CallManager.pem" in der vorherigen Datenbankabfrage, das die Rolle "Authentication and Authorization" (Authentifizierung und Autorisierung) hat, muss auch auf der Webseite "OS Administration Certificate Management" (Zertifikatsverwaltung für die Betriebssystemverwaltung) vorhanden sein.

Wenn der vorherige Fehler auftritt, besteht eine Diskrepanz zwischen den Zertifikaten von CallManager.pem in der Abfrage und auf der Betriebssystem-Webseite.

Ändern von Host- oder Domänennamen

Wenn Sie den Hostnamen oder den Domänennamen eines CUCM-Servers ändern, werden alle Zertifikate auf diesem Server auf einmal neu generiert. Im Abschnitt zur Zertifikaterneuerung wurde erklärt, dass die Regeneration sowohl von TVS.pem als auch von CallManager.pem eine "schlechte Sache" ist.

Es gibt einige Szenarien, in denen eine Änderung des Hostnamens fehlschlägt, und einige, in denen sie problemlos funktioniert. In diesem Abschnitt werden alle Aspekte behandelt und sie mit dem verknüpft, was Ihnen bereits aus diesem Dokument über TVS und ITL bekannt ist.

Cluster mit einem Knoten und nur ITL (Vorsicht, keine Vorbereitung)

• Bei einem Business Edition-Server oder einer reinen Publisher-Bereitstellung werden CallManager.pem und TVS.pem gleichzeitig neu generiert, wenn Sie die Hostnamen ändern.
• Wenn der Hostname in einem Cluster mit einem Knoten geändert wird, ohne zuerst den hier beschriebenen Rollback Enterprise-Parameter zu verwenden, können die Telefone die neue ITL-Datei oder die Konfigurationsdateien nicht mit der aktuellen ITL-Datei vergleichen.
• Die Telefone können keine Verbindung mit dem TVS herstellen, da das TVS-Zertifikat ebenfalls nicht mehr vertrauenswürdig ist.
• Die Telefone zeigen einen Fehler bezüglich der "Überprüfung der Vertrauensliste fehlgeschlagen" an, es treten keine neuen Konfigurationsänderungen in Kraft, und die URLs der sicheren Dienste schlagen fehl.
• Wenn die Vorsichtsmaßnahme in Schritt 2 nicht getroffen wird, löschen Sie die ITL manuell von jedem Telefon.

Cluster mit einem Knoten und CTL und ITL (kann vorübergehend unterbrochen, aber leicht behoben werden)

• Nachdem Sie die Server-Umbenennung durchgeführt haben, führen Sie den CTL-Client erneut aus. Dadurch wird das neue Zertifikat CallManager.pem in der CTL-Datei abgelegt, die vom Telefon heruntergeladen wird.
• Neue Konfigurationsdateien, die die neuen ITL-Dateien enthalten, können basierend auf der CCM+TFTP-Funktion in der CTL-Datei als vertrauenswürdig eingestuft werden.
• Dies funktioniert, da die aktualisierte CTL-Datei auf der Grundlage eines privaten USB-eToken-Schlüssels, der unverändert bleibt, vertrauenswürdig ist.

Cluster mit mehreren Knoten und nur ITL (dies funktioniert in der Regel, kann jedoch bei übereiltem Betrieb dauerhaft unterbrochen werden)

• Da ein Cluster mit mehreren Knoten über mehrere TVS-Server verfügt, können die Zertifikate jedes einzelnen Servers problemlos neu generiert werden. Wenn das Telefon mit dieser neuen, unbekannten Signatur angezeigt wird, fordert es einen anderen TVS-Server auf, das neue Serverzertifikat zu überprüfen.
• Es gibt zwei Hauptprobleme, die einen Fehler verursachen können:
  
  • Wenn alle Server gleichzeitig umbenannt und neu gestartet werden, ist keiner der TVS-Server mit bekannten Zertifikaten erreichbar, wenn die Server und Telefone wieder verfügbar sind.
  • Wenn ein Telefon nur einen einzigen Server in der CallManager-Gruppe hat, machen die zusätzlichen TVS-Server keinen Unterschied. Sehen Sie sich das Szenario "Single Node Cluster" an, um dieses Problem zu beheben, oder fügen Sie der CallManager-Gruppe einen weiteren Server hinzu.

Multi-Node-Cluster mit CTL und ITL (kann nicht dauerhaft unterbrochen werden)

• Nachdem Sie die Umbenennungen durchgeführt haben, authentifiziert der TVS-Dienst die neuen Zertifikate.
• Auch wenn aus irgendeinem Grund nicht alle TVS-Server verfügbar sind, kann der CTL-Client verwendet werden, um die Telefone mit den neuen CallManager.pem CCM+TFTP-Zertifikaten zu aktualisieren.

Zentrales TFTP

Beim Start eines Telefons mit einer ITL werden folgende Dateien angefordert: CTLSEP<MAC-Adresse>.tlv, ITLSEP<MAC-Adresse>.tlv und SEP<MAC-Adresse>.cnf.xml.sgn.

Wenn das Telefon diese Dateien nicht finden kann, fordert es ITLFile.tlv und CTLFile.tlv an, die ein zentralisierter TFTP-Server für jedes Telefon bereitstellt, das diese anfordert.

Mit zentralisiertem TFTP gibt es einen einzelnen TFTP-Cluster, der auf eine Reihe anderer untergeordneter Cluster verweist.

Häufig geschieht dies, weil Telefone auf mehreren CUCM-Clustern denselben DHCP-Bereich nutzen und daher über denselben TFTP-Server mit der DHCP-Option 150 verfügen müssen.

Alle IP-Telefone verweisen auf den zentralen TFTP-Cluster, auch wenn sie bei anderen Clustern registriert sind. Dieser zentrale TFTP-Server fragt die Remote-TFTP-Server ab, wenn eine Anforderung für eine nicht auffindbare Datei eingeht.

Aufgrund dieses Vorgangs funktioniert das zentralisierte TFTP nur in einer homogenen ITL-Umgebung.

Auf allen Servern muss CUCM Version 8.x oder höher ausgeführt werden, oder auf allen Servern müssen Versionen vor Version 8.x ausgeführt werden.

Wenn eine Datei ITLFile.tlv vom zentralen TFTP-Server angezeigt wird, vertrauen die Telefone den Dateien vom Remote-TFTP-Server nicht, da die Signaturen nicht übereinstimmen.

Dies geschieht in einer heterogenen Mischung. In einer homogenen Mischung fordert das Telefon ITLSEP<MAC>.tlv an, das aus dem richtigen Remote-Cluster abgerufen wird.

In einer heterogenen Umgebung mit einer Mischung aus Clustern vor Version 8.x und Version 8.x muss "Cluster für Rollback auf Pre 8.0 vorbereiten" auf dem Cluster vor Version 8.x aktiviert werden, wie in Cisco Bug-ID CSCto87262 beschrieben.

Konfigurieren Sie die Parameter für die sichere Telefon-URL mit HTTP anstelle von HTTPS. Dadurch werden die ITL-Funktionen auf dem Telefon deaktiviert.

Häufig gestellte Fragen

Kann ich SBD ausschalten?

Sie können SBD nur deaktivieren, wenn SBD und ITL derzeit funktionieren.

SBD kann auf Telefonen mit dem Enterprise-Parameter "Prepare Cluster for Rollback to pre 8.0" (Cluster für Rollback auf vor 8.0 vorbereiten) vorübergehend deaktiviert werden, und indem die "Secured Phone URL Parameters" (Sichere Telefon-URL-Parameter) mit HTTP anstelle von HTTPS konfiguriert werden.

Wenn Sie den Rollback-Parameter festlegen, wird eine signierte ITL-Datei mit leeren Funktionseinträgen erstellt.

Die "leere" ITL-Datei ist noch signiert, daher muss sich der Cluster in einem voll funktionsfähigen Sicherheitsstatus befinden, bevor dieser Parameter aktiviert werden kann.

Nachdem dieser Parameter aktiviert und die neue ITL-Datei mit leeren Einträgen heruntergeladen und verifiziert wurde, akzeptieren die Telefone alle Konfigurationsdateien, unabhängig davon, wer sie signiert hat.

Es wird nicht empfohlen, den Cluster in diesem Zustand zu belassen, da keine der drei zuvor genannten Funktionen (authentifizierte Konfigurationsdateien, verschlüsselte Konfigurationsdateien und HTTPS-URLs) verfügbar sind.

Kann ich die ITL-Datei einfach von allen Telefonen löschen, wenn CallManager.pem verloren geht?

Derzeit gibt es keine Methode, alle ITLs von einem von Cisco remote bereitgestellten Telefon zu löschen. Aus diesem Grund sind die in diesem Dokument beschriebenen Verfahren und Wechselwirkungen so wichtig zu berücksichtigen.

Eine Erweiterung der Cisco Bug-ID CSCto47052 wurde noch nicht behoben. Für diese Funktion ist jedoch noch keine Implementierung erfolgt.

In der Zwischenzeit wurde eine neue Funktion über die Cisco Bug-ID CSCts01319 hinzugefügt, die es dem Cisco Technical Assistance Center (TAC) ermöglicht, auf die zuvor vertrauenswürdige ITL zurückzugreifen, wenn diese auf dem Server weiterhin verfügbar ist.

Dies funktioniert nur in bestimmten Fällen, in denen sich der Cluster in einer Version mit diesem Defektfix befindet und in denen die vorherige ITL in einer Sicherung vorhanden ist, die an einem speziellen Speicherort auf dem Server gespeichert ist.

Sehen Sie sich den Fehler an, um zu sehen, ob Ihre Version die Lösung enthält. Wenden Sie sich an Cisco TAC, um das im Defekt beschriebene potenzielle Wiederherstellungsverfahren durchzuführen.

Wenn das vorherige Verfahren nicht verfügbar ist, müssen die Telefontasten manuell auf das Telefon gedrückt werden, um die ITL-Datei zu löschen. Das ist der Kompromiss zwischen Sicherheit und Verwaltbarkeit. Damit die ITL-Datei wirklich sicher ist, darf sie nicht einfach per Fernzugriff entfernt werden.

Selbst bei per Skript ausgeführten Tastendrücken mit Simple Object Access Protocol (SOAP)-XML-Objekten kann die ITL nicht entfernt werden.

Dies liegt daran, dass der TVS-Zugriff (und damit der Secure Authentication URL-Zugriff zur Validierung eingehender SOAP XML-Push-Objekte) derzeit nicht funktioniert.

Wenn die Authentifizierungs-URL nicht als sicher konfiguriert ist, ist es möglich, ein Skript für die Tastendrücke auszuführen, um eine ITL zu löschen. Dieses Skript ist jedoch nicht bei Cisco verfügbar.

Andere Methoden zur Skripterstellung für Remote-Tastendrücke ohne Verwendung der Authentifizierungs-URL sind möglicherweise von einem Drittanbieter erhältlich, diese Anwendungen werden jedoch nicht von Cisco bereitgestellt.

Die am häufigsten verwendete Methode zum Löschen der ITL ist eine E-Mail-Übertragung an alle Telefonbenutzer, die sie über die Tastenfolge informiert.

Wenn der Einstellungszugriff auf Eingeschränkt oder Deaktiviert eingestellt ist, muss das Telefon auf die Werkseinstellungen zurückgesetzt werden, da die Benutzer keinen Zugriff auf das Einstellungsmenü des Telefons haben.