فهم أمان CUCM بشكل افتراضي وعملية ITL واستكشاف الأخطاء وإصلاحها

المقدمة

يصف هذا المستند ميزة "الأمان" (SBD) الافتراضية لإصدارات 8.0 من Cisco Unified Communications Manager (CUCM) والإصدارات الأحدث.

معلومات أساسية

يقدم CUCM الإصدار 8.0 والإصدارات الأحدث ميزة SBD، والتي تتكون من ملفات قائمة التحقق من الهوية (ITL) وخدمة التحقق من الثقة (TVS).

يستخدم الآن كل مجموعة CUCM الأمان القائم على ITL تلقائيا. هناك مفاضلة بين الأمان وسهولة الاستخدام/سهولة الإدارة يجب على المسؤولين الإداريين أن يكونوا على دراية بها قبل إجراء بعض التغييرات على مجموعة الإصدار 8.0 من CUCM.

يعمل هذا المستند كملحق للأمان الرسمي من خلال المستندات الافتراضية، كما يوفر معلومات التشغيل وإرشادات أستكشاف الأخطاء وإصلاحها لمساعدة المسؤولين وتسهيل عملية أستكشاف الأخطاء وإصلاحها.

إنها لفكرة جيدة أن تصبح على دراية بتلك المفاهيم الأساسية ل SBD: تشفير المفاتيح غير المتماثلة مقال ويكيبيديا و البنية التحتية للمفتاح العام مقال ويكيبيديا.

نظرة عامة على SBD

يوفر هذا القسم نظرة عامة سريعة على ما توفره الخدمة الافتراضية الخاصة (SBD) بالضبط. للحصول على التفاصيل الفنية الكاملة لكل وظيفة، راجع قسم تفاصيل SBD ومعلومات أستكشاف الأخطاء وإصلاحها.

توفر SBD هذه الوظائف الثلاث لهواتف بروتوكول الإنترنت (IP) المدعومة:

• المصادقة الافتراضية للملفات التي تم تنزيلها من TFTP (التكوين، الإعدادات المحلية، قائمة الحلقات) التي تستخدم مفتاح توقيع
• تشفير إختياري لملفات تكوين TFTP التي تستخدم مفتاح توقيع
• التحقق من الشهادة لاتصالات HTTPS التي يتم فتحها عبر الهاتف والتي تستخدم مخزن الشهادات الموثوق به عن بعد على CUCM (TVS)

يوفر هذا المستند نظرة عامة على كل من هذه الوظائف.

مصادقة تنزيل TFTP

عند وجود قائمة الشهادات الموثوق بها (CTL) أو ملف ITL، يطلب هاتف IP ملف تكوين TFTP موقع من خادم CUCM TFTP.

يسمح هذا الملف للهاتف بالتحقق من أن ملف التكوين جاء من مصدر موثوق به. مع وجود ملفات CTL/ITL على الهواتف، يجب توقيع ملفات التكوين بواسطة خادم TFTP موثوق به.

يكون الملف نصا عاديا على الشبكة أثناء إرساله، ولكنه يأتي مع توقيع تحقق خاص.

يطلب الهاتف SEP<MAC Address>.cnf.xml.sgn لاستلام ملف التكوين باستخدام التوقيع الخاص.

يتم توقيع ملف التكوين هذا بواسطة المفتاح الخاص TFTP الذي يتوافق مع CallManager.pem في صفحة إدارة شهادات نظام التشغيل (OS).

يحتوي الملف الموقع على توقيع في الأعلى لمصادقة الملف، لكن بخلاف ذلك في XML نص عادي.

توضح الصورة أدناه أن الموقع الخاص بملف التكوين هو CN=CUCM8-Publisher.bbbburns.lab الذي تم توقيعه بدوره من قبل CN=Jasburns-AD.

وهذا يعني أن الهاتف يحتاج إلى التحقق من توقيع CUCM8-Publisher.bbbburns.lab مقابل ملف ITL قبل قبول ملف التكوين هذا.

هنا رسم بياني يوضح كيف يتم إستخدام المفتاح الخاص مع خوارزمية ملخص الرسالة (MD)5 أو دالة تجزئة خوارزمية التجزئة الآمنة (SHA)1 لإنشاء الملف الموقع.

يعكس التحقق من التوقيع هذه العملية من خلال إستخدام المفتاح العام الذي يتطابق من أجل فك تشفير التجزئة. إذا تطابقت التجزئة، فإنها تظهر:

• لم يتم تعديل هذا الملف أثناء النقل.
• يأتي هذا الملف من الطرف المدرج في التوقيع، لأن أي شيء تم فك تشفيره بنجاح باستخدام المفتاح العام يجب أن يكون قد تم تشفيره باستخدام المفتاح الخاص.

تشفير ملف تكوين TFTP

في حال تمكين تشفير تكوين TFTP الاختياري في ملف تعريف أمان الهاتف المقترن، يطلب الهاتف ملف تكوين مشفر.

يتم توقيع هذا الملف باستخدام المفتاح الخاص TFTP ويتم تشفيره باستخدام مفتاح متماثل يتم تبادله بين الهاتف و CUCM (راجع دليل أمان مدير الاتصالات الموحدة من Cisco، الإصدار 8.5(1) للحصول على التفاصيل الكاملة).

لا يمكن قراءة محتوياته باستخدام sniffer على الشبكة إلا إذا كان لدى المراقب المفاتيح الضرورية.

يطلب الهاتف sep<mac address>.cnf.xml.enc.sgn للحصول على الملف المشفر الموقع.

يحتوي ملف التكوين المشفر على التوقيع في البداية أيضا، ولكن لا توجد بيانات نصية عادية بعد ذلك، فقط بيانات مشفرة (حروف ثنائية مضبوطة في محرر النص هذا).

توضح الصورة أن الموقع هو نفسه كما في المثال السابق، لذلك يجب أن يكون هذا الموقع موجودا في ملف ITL قبل أن يقبل الهاتف الملف.

بالإضافة إلى ذلك، يجب أن تكون مفاتيح فك التشفير صحيحة قبل أن يتمكن الهاتف من قراءة محتويات الملف.

خدمة التحقق من الثقة (الشهادة عن بعد والتحقق من التوقيع)

تحتوي هواتف بروتوكول الإنترنت (IP) على قدر محدود من الذاكرة، كما يمكن أن يكون هناك عدد كبير من الهواتف لإدارتها في الشبكة.

يعمل CUCM كمخزن ثقة عن بعد عبر أجهزة التلفزيون بحيث لا يلزم وضع مخزن الشهادات الموثوق بها بالكامل على كل هاتف من هواتف بروتوكول الإنترنت (IP).

في أي وقت لا يستطيع الهاتف التحقق من توقيع أو شهادة من خلال ملفات CTL أو ITL، فإنه يطلب من خادم TVS التحقق.

يمكن إدارة مخزن الثقة المركزي هذا بشكل أسهل مما لو كان مخزن الثقة موجودا على جميع هواتف IP.

تفاصيل SBD ومعلومات أستكشاف الأخطاء وإصلاحها

يوضح هذا القسم تفاصيل عملية SBD.

ملفات ITL والشهادات الموجودة على CUCM

أولا، هناك عدد من الملفات التي يجب أن تكون موجودة على خادم CUCM نفسه. أهم قطعة هي شهادة TFTP ومفتاح TFTP الخاص.

توجد شهادة TFTP تحت إدارة نظام التشغيل > التأمين > إدارة الشهادات > CallManager.pem.

يستخدم خادم CUCM المفاتيح الخاصة والعامة لشهادة CallManager.pem لخدمة TFTP (وكذلك لخدمة مدير المكالمات (CCM) من Cisco).

تظهر الصورة أن شهادة CallManager.pem تم إصدارها إلى CUCM8-publisher.bbbburns.lab وموقعة من Jasburns-AD. يتم توقيع جميع ملفات تكوين TFTP بواسطة المفتاح الخاص أدناه.

يمكن لجميع الهواتف إستخدام المفتاح العام TFTP في شهادة CallManager.pem لتشفير أي ملف مشفر باستخدام مفتاح TFTP الخاص، وكذلك للتحقق من أي ملف موقع باستخدام مفتاح TFTP الخاص.

بالإضافة إلى المفتاح الخاص بشهادة CallManager.pem، يقوم خادم CUCM أيضا بتخزين ملف ITL الذي يتم تقديمه إلى الهواتف.

يعرض الأمر show itl المحتويات الكاملة لملف ITL هذا عبر وصول Secure Shell (SSH) إلى واجهة سطر الأوامر (CLI) الخاصة بنظام تشغيل خادم CUCM.

ينقسم هذا القسم ملف ITL قطعة، لأن به عدد من المكونات الهامة التي يستخدمها الهاتف.

الجزء الأول هو معلومات التوقيع. حتى ملف ITL هو ملف موقع. يوضح هذا الإخراج أنه موقع بواسطة المفتاح الخاص TFTP المقترن بشهادة CallManager.pem السابقة.

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*

تحتوي كل من الأقسام التالية على الغرض الخاص بها داخل معلمة دالة خاصة. الوظيفة الأولى هي الرمز المميز لأمان مسؤول النظام. هذا هو توقيع المفتاح العام TFTP.

        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.

الوظيفة التالية هي CCM+TFTP. هذا مرة أخرى هو المفتاح العام TFTP الذي يعمل على مصادقة ملفات تكوين TFTP التي تم تنزيلها وفك تشفيرها.

        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)

الوظيفة التالية هي أجهزة التلفزيون. يوجد مدخل للمفتاح العام لكل خادم تليفزيونات يتصل به الهاتف.

وهذا يسمح للهاتف بإنشاء جلسة عمل لطبقة مآخذ التوصيل الآمنة (SSL) لخادم TVS.

        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

الوظيفة النهائية المضمنة في ملف ITL هي وظيفة وكيل المرجع المصدق (CAPF).

تسمح هذه الشهادة للهواتف بإنشاء اتصال آمن بخدمة CAPF على خادم CUCM حتى يمكن للهاتف تثبيت أو تحديث شهادة ذات أهمية محلية (LSC).

        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.

يغطي القسم التالي ما يحدث بالضبط عندما يجري جزمة الهاتف.

ITL الخاص بتنزيل الهاتف وملف التكوين

بعد تمهيد الهاتف والحصول على عنوان IP وعنوان خادم TFTP، يطلب ملفات CTL و ITL أولا.

يظهر التقاط الحزمة هذا طلب هاتف لملف ITL. إذا قمت بالتصفية على tftp.opcode == 1، سترى كل طلب قراءة TFTP من الهاتف:

نظرا لأن الهاتف تلقى ملفات CTL و ITL من TFTP بنجاح، يطلب الهاتف ملف تكوين موقع.

تتوفر سجلات وحدة تحكم الهاتف التي تظهر هذا السلوك من واجهة الويب للهاتف:

يطلب الهاتف أولا ملف CTL، والذي ينجح:

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

بعد ذلك الهاتف أيضا يطلب ملف ITL:

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 

يتحقق الهاتف من ITL وملف التكوين

بعد تنزيل ملف ITL، يجب التحقق من صحته. هناك عدد من الحالات التي يمكن أن يكون فيها الهاتف في هذه المرحلة، لذلك هذا المستند يغطي جميعها.

• لا يوجد في الهاتف ملف CTL أو ITL أو أن ITL فارغ بسبب إعداد نظام المجموعة للرجوع إلى المعلمة Pre 8.0. في هذه الحالة، يثق الهاتف ثقة عمياء في ملف CTL أو ITL التالي الذي تم تنزيله ويستخدم هذا التوقيع من الآن.
• يحتوي الهاتف على CTL ولكن لا يحتوي على ITL. في هذه الحالة، يثق الهاتف في ITL فقط إذا كان يمكن التحقق منه بواسطة وظيفة CCM+TFTP في ملف CTL.
• يحتوي الهاتف بالفعل على ملف CTL وملف ITL. في هذه الحالة، يتحقق الهاتف من أن الملفات التي تم تنزيلها مؤخرا تطابق التوقيع في خادم CTL أو ITL أو TVS.

فيما يلي مخطط تدفق يصف كيفية تحقق الهاتف من الملفات الموقعة وشهادات HTTPS:

وفي هذه الحالة، يمكن للهاتف التحقق من صحة التوقيع في ملفات ITL و CTL. يحتوي الهاتف بالفعل على كل من CTL و ITL، لذلك قام بالتحقق من خلالهما ووجد التوقيع الصحيح.

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

بما أن الهاتف قام بتنزيل ملفات CTL و ITL، فإنه من هذه النقطة عليه يطلب ملفات التكوين الموقعة فقط.

وهذا يوضح أن منطق الهاتف هو تحديد أن خادم TFTP آمن، استنادا إلى وجود CTL و ITL، ثم لطلب ملف موقع:

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 

بمجرد تنزيل ملف التكوين الموقع، يجب أن يصادق الهاتف عليه مقابل الدالة الخاصة ب CCM+TFTP داخل ITL:

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

جهات الاتصال الهاتفية TVS للحصول على شهادة غير معروفة

يوفر ملف ITL وظيفة TVS التي تحتوي على شهادة خدمة TVS التي تعمل على منفذ TCP لخادم CUCM 2445.

يتم تشغيل أجهزة التلفزيون على كافة الخوادم حيث يتم تنشيط خدمة CallManager. تستخدم خدمة CUCM TFTP مجموعة CallManager التي تم تكوينها لإنشاء قائمة بخوادم TVS التي يجب على الهاتف الاتصال بها على ملف تكوين الهاتف.

تستخدم بعض المختبرات خادم CUCM واحد فقط. في مجموعة CUCM متعددة العقد، يمكن أن يكون هناك ما يصل إلى ثلاثة إدخالات في أجهزة التلفزيون للهاتف، واحد لكل CUCM في مجموعة CUCM للهاتف.

يوضح هذا المثال ما يحدث عند ضغط زر الدلائل على هاتف IP. تم تكوين عنوان URL للأدلة ل HTTPS، لذلك يتم عرض الهاتف مع شهادة ويب Tomcat من خادم Directories.

لم يتم تحميل شهادة ويب Tomcat هذه (tomcat.pem في إدارة OS) في الهاتف، لذلك يجب أن يتصل الهاتف بالتلفاز لمصادقة الشهادة.

أحلت السابق TVS نظرة عامة رسم بياني لوصف من التفاعل. فيما يلي منظور سجل وحدة تحكم الهاتف:

أولا تجد عنوان 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

هذه جلسة HTTP آمنة ل SSL/Transport Layer Security (TLS) تتطلب التحقق.

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

يتحقق الهاتف أولا من أن الشهادة المقدمة من خادم SSL/TLS موجودة في CTL. ثم يفحص الهاتف الدالات الموجودة في ملف ITL لمعرفة ما إذا وجد تطابق.

تقول رسالة الخطأ هذه "لا يوجد HTTPS في CTL"، مما يعني "لا يمكن العثور على الشهادة في CTL أو ITL."

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>

بعد التحقق من المحتويات المباشرة لملف CTL و ITL للشهادة، فإن الشيء التالي الذي يتحقق منه الهاتف هو ذاكرة التخزين المؤقت للتلفزيون.

ويتم القيام بذلك لتقليل حركة مرور البيانات على الشبكة إذا كان الهاتف قد طلب مؤخرا من خادم TVS الحصول على نفس الشهادة.

إذا لم يتم العثور على شهادة HTTPS في ذاكرة التخزين المؤقت للهاتف، يمكنك إجراء اتصال TCP بخادم TVS نفسه.

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.

تذكر أن الاتصال بأجهزة التلفزيون نفسها هو SSL/TLS (HTTP الآمن، أو HTTPS)، وبالتالي فهو أيضا شهادة يلزم مصادقتها مقابل CTL إلى ITL.

إذا سار كل شيء بشكل صحيح، فإن شهادة خادم TVS يتم العثور عليها في وظيفة TVS الخاصة بملف ITL. راجع سجل ITL #3 في ملف ITL للمثال السابق.

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>

نجاح! الهاتف الآن لديه اتصال آمن بخادم TVS. الخطوة التالية هي أن تسأل خادم TVS "مرحبا، هل أثق بشهادة خادم Guides هذه؟ "

يوضح هذا المثال الإجابة على هذا السؤال - إجابة 0 تعني النجاح (لا خطأ).

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

ونظرا لوجود إستجابة ناجحة من أجهزة التلفزيون، يتم حفظ نتائج هذه الشهادة في ذاكرة التخزين المؤقت.

هذا يعني أنه إذا قمت بالضغط على زر الدلائل مرة أخرى خلال ال 86400 ثانية التالية، فلن تحتاج إلى الاتصال بخادم TVS للتحقق من الترخيص. يمكنك ببساطة الوصول إلى ذاكرة التخزين المؤقت المحلية.

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

أخيرا، تحقق من نجاح إتصالك بخادم الدلائل.

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

هنا مثال لما يحدث على خادم CUCM حيث تعمل أجهزة التلفزيون. يمكنك تجميع سجلات أجهزة التلفزيون باستخدام أداة مراقبة الوقت الفعلي الموحدة (RTMT) من Cisco.

تظهر سجلات CUCM TVS أن مصافحة SSL مع الهاتف، الهاتف يسأل أجهزة التلفزيون عن شهادة Tomcat، ثم يستجيب أجهزة التلفزيون لتشير إلى أن الشهادة مطابقة في مخزن شهادات TVS.

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

مخزن شهادات TVS هي قائمة بكافة الشهادات الموجودة في صفحة الويب إدارة نظام التشغيل > إدارة الشهادات.

التحقق يدويا من تطابق ITL للهاتف مع CUCM ITL 

هناك مفهوم خاطئ شائع يظهر أثناء أستكشاف المشكلات وإصلاحها يتعلق بالميل إلى حذف ملف ITL على أمل أن يحل مشكلة التحقق من الملف.

في بعض الأحيان يكون حذف ملف ITL مطلوبا، لكن ملف ITL يحتاج فقط إلى أن يتم حذفه عندما تكون جميع هذه الشروط مستوفاة.

• لا يتطابق توقيع ملف ITL على الهاتف مع توقيع ملف ITL على خادم CM TFTP.
• لا يتطابق توقيع TVS الموجود في ملف ITL مع الشهادة المقدمة من قبل TVS.
• يظهر الهاتف "فشل التحقق" عندما يحاول تنزيل ملف ITL أو ملفات التكوين.
• لا توجد نسخة إحتياطية من المفتاح الخاص ل TFTP القديم.

وإليكم كيف تتفحصون أول إثنين من هذه الحالات.

أولا، يمكنك مقارنة المجموع الاختباري لملف ITL الموجود على CUCM بملف المجموع الاختباري ITL للهاتف.

لا توجد حاليا طريقة للنظر إلى مجموع MD5الخاص بملف ITL على CUCM من CUCM نفسه حتى تقوم بتشغيل إصدار باستخدام الإصلاح الخاص بمعرف تصحيح الأخطاء هذا CSCto60209 من Cisco.

في الفترة الانتقالية، قم بتشغيل هذا باستخدام برامج واجهة المستخدم الرسومية (GUI) أو واجهة سطر الأوامر (CLI) المفضلة لديك:

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

هذا يوضح أن ال MD5sum من ال ITL مبرد في CUCM هو b61910bb01d8d3a1c1b36526cc9f2ddc.

الآن يمكنك النظر إلى الهاتف نفسه لتحديد تجزئة ملف ITL الذي تم تحميله هناك: الإعدادات > تكوين الأمان > قائمة الثقة.

وهذا يوضح أن مجموعات MD5SUMS متطابقة. وهذا يعني أن ملف ITL الموجود على الهاتف يطابق الملف الموجود على CUCM، وبالتالي لا يلزم حذفه.

إذا لم تتطابق مع الشهادة، يجب الانتقال إلى العملية التالية - تحديد ما إذا كانت شهادة TVS في ITL مطابقة للشهادة المقدمة من أجهزة التلفزيون أم لا. هذه العملية أكثر انخراطا.

أولا، راجع التقاط حزمة الهاتف الذي يتصل بخادم TVS على منفذ TCP 2445.

انقر بزر الماوس الأيمن فوق أي حزمة في هذا الدفق في Wireshark، ثم انقر فوق فك التشفير باسم، وحدد SSL. ابحث عن شهادة الخادم التي تبدو كما يلي:

انظر إلى ترخيص TVS الموجود ضمن ملف ITL السابق. بعد ذلك ترى مدخل مع الرقم التسلسلي 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

نجاح، يطابق TVS.pem الموجود داخل ملف ITL شهادة TVS المقدمة على الشبكة. لا تحتاج إلى حذف سجل المعاملات الدولي، وتقدم أجهزة التلفزيون الشهادة الصحيحة.

إذا إستمرت مصادقة الملف في الفشل، فتحقق من بقية مخطط التدفق السابق.

القيود والتفاعلات

إعادة إنشاء الشهادات / إعادة إنشاء نظام المجموعة / انتهاء صلاحية الشهادة

أهم شهادة الآن هي شهادة CallManager.pem. يتم إستخدام مفتاح الشهادة الخاص هذا لتوقيع جميع ملفات تكوين TFTP، والتي تتضمن ملف ITL.

في حالة إعادة إنشاء ملف CallManager.pem، يتم إنشاء شهادة CCM+TFTP جديدة باستخدام مفتاح خاص جديد. بالإضافة إلى ذلك، تم الآن توقيع ملف ITL بواسطة مفتاح CCM+TFTP الجديد هذا.

بعد إعادة إنشاء CallManager.pem وإعادة تشغيل خدمة TVS و TFTP، يحدث ذلك عند تمهيد الهاتف.

1. يحاول الهاتف تنزيل ملف ITL الجديد الموقع من قبل CCM+TFTP الجديد من خادم TFTP. يحتوي الهاتف على ملف ITL القديم فقط في هذه النقطة، والمفاتيح الجديدة ليست موجودة في ملف ITL الموجود على الهاتف.
2. وبما أن الهاتف لم يتمكن من العثور على توقيع CCM+TFTP الجديد في سجل المعاملات الدولي القديم، فإنه يحاول الاتصال بخدمة أجهزة التلفزيون.
   

   ملاحظة: هذا الجزء مهم للغاية. يجب أن تظل شهادة TVS من ملف ITL القديم متطابقة. في حالة إعادة إنشاء كل من CallManager.pem و TVS.pem في نفس الوقت بالضبط، يتعذر على الهواتف تنزيل أي ملفات جديدة دون حذف ITL من الهاتف يدويا.

3. عندما يتصل الهاتف بتليفزيونات TVS، فإن خادم CUCM الذي يشغل TVS لديه شهادة CallManager.pem جديدة في مخزن شهادات نظام التشغيل.
4. يقوم خادم TVS بإرجاع النجاح ويقوم الهاتف بتحميل ملف ITL الجديد في الذاكرة.
5. يحاول الهاتف الآن تنزيل ملف تكوين، تم توقيعه بواسطة المفتاح CallManager.pem الجديد.
6. منذ تحميل قائمة التحكم في الوصول (ITL) الجديدة، تم التحقق من ملف التكوين الموقع حديثا بواسطة قائمة التحكم في الوصول (ITL) في الذاكرة بنجاح.

النقاط الرئيسية:

• عدم إعادة إنشاء كل من شهادات CallManager.pem و TVS.pem في نفس الوقت.
• في حالة إعادة إنشاء TVS.PEM أو CallManager.pem، يجب إعادة تشغيل TVS و TFTP وإعادة ضبط الهواتف للحصول على ملفات ITL الجديدة.
• تعالج الإصدارات الأحدث من CUCM إعادة تعيين هذا الهاتف تلقائيا وتحذر المستخدم في وقت إعادة إنشاء الشهادة.
• في حالة وجود أكثر من خادم TVS واحد (أكثر من خادم واحد في مجموعة CallManager)، يمكن للخوادم الإضافية مصادقة شهادة CallManager.pem الجديدة.                          

نقل الهواتف بين المجموعات

عند نقل الهواتف من مجموعة إلى أخرى مع وجود قوائم التحكم في الوصول إلى النقل (ITL)، يجب أخذ المفتاح الخاص الخاص الخاص الخاص الخاص ب TFTP في الاعتبار.

يجب أن يتطابق أي ملف تكوين جديد مقدم إلى الهاتف مع توقيع في CTL أو ITL أو توقيع في خدمة الهاتف الحالية.

يشرح هذا المستند كيفية التأكد من إمكانية الوثوق بملف ITL لنظام المجموعة الجديد وملفات التكوين بواسطة ملف ITL الحالي على الهاتف. https://supportforums.cisco.com/docs/DOC-15799.

النسخ الاحتياطي والاستعادة

يتم إجراء نسخ إحتياطي لشهادة CallManager.pem والمفتاح الخاص عبر نظام إسترداد البيانات بعد الكوارث (DRS). إذا تم إعادة إنشاء خادم TFTP، فيجب استعادته من النسخة الاحتياطية حتى يمكن إستعادة المفتاح الخاص.

بدون المفتاح الخاص CallManager.pem على الخادم، لا تثق الهواتف التي تحتوي على قوائم التحكم في الوصول (ITL) الحالية التي تستخدم المفتاح القديم في ملفات التكوين الموقعة.

إذا تم إعادة إنشاء نظام مجموعة ولم تتم استعادته من النسخة الاحتياطية، فإنه يشبه مستند نقل الهواتف بين المجموعات". وذلك لأن المجموعة ذات المفتاح الجديد هي مجموعة مختلفة بقدر ما يتعلق الامر بالهواتف.

هناك عيب خطير واحد مرتبط بالنسخ الاحتياطي والاستعادة. إذا كان نظام مجموعة عرضة لمعرف تصحيح الأخطاء من Cisco CSCtn50405، فإن عمليات النسخ الاحتياطي ل DRS لا تحتوي على شهادة CallManager.pem.

وهذا يتسبب في قيام أي خادم تم استعادته من النسخة الاحتياطية هذه بإنشاء ملفات ITL تالفة حتى يتم إنشاء CallManager.pem جديد.

في حالة عدم وجود خوادم TFTP وظيفية أخرى لم تمر بعملية النسخ الاحتياطي والاستعادة، قد يعني ذلك أنه يجب حذف جميع ملفات ITL من الهواتف.

للتحقق مما إذا كان ملف CallManager.pem يحتاج إلى إعادة الإنشاء، أدخل الأمر show itl الذي يتبعه:

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 

في مخرجات ITL، تكون الأخطاء الأساسية التي يجب البحث عنها هي:

This etoken was not used to sign the ITL file.

و

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

يقوم الاستعلام للغة الاستعلام المنظمة (SQL) السابقة بالبحث عن الشهادات التي لها دور "المصادقة والتفويض."

يجب أن تكون شهادة CallManager.pem في استعلام قاعدة البيانات السابق الذي يشتمل على دور المصادقة والتفويض موجودة أيضا في صفحة ويب إدارة شهادات إدارة نظام التشغيل.

في حالة مواجهة العيب السابق، يكون هناك عدم تطابق بين شهادات CallManager.pem في الاستعلام وفي صفحة ويب لنظام التشغيل.

تغيير أسماء المضيف أو أسماء المجالات

إذا قمت بتغيير اسم المضيف أو اسم المجال لخادم CUCM، فإنه يعيد إنشاء كل الشهادات مرة واحدة على ذلك الخادم. شرح قسم تجديد الشهادات أن إعادة إنشاء كل من TVS.PEM و CallManager.PEM "أمر سيء".

هناك بعض السيناريوهات التي يفشل فيها تغيير اسم المضيف، و البعض الآخر يعمل دون مشاكل. يغطي هذا القسم كل هذه العناصر ويربطها مع ما تعرفه بالفعل عن التلفزيون و ITL من هذا المستند.

نظام مجموعة ذو عقدة واحدة مع ITL فقط (أستخدم الحذر، وهذا يكسر دون تحضير)

• باستخدام خادم إصدار Business أو النشر بواسطة الناشر فقط، يتم إعادة إنشاء كل من CallManager.pem و TVS.pem في نفس الوقت عند تغيير أسماء المضيف.
• إذا تم تغيير اسم المضيف على مجموعة واحدة من العقد دون إستخدام المعلمة BackLback Enterprise التي تغطيها هذه النقطة أولا، لن تتمكن الهواتف من التحقق من ملف ITL الجديد أو ملفات التكوين مقابل ملف ITL الحالي الخاص بها.
• يتعذر على الهواتف الاتصال بأجهزة التلفزيون لأن شهادة أجهزة التلفزيون لم تعد موثوق بها أيضا.
• تعرض الهواتف خطأ حول "فشل التحقق من قائمة الثقة"، ولم يتم تطبيق تغييرات تكوين جديدة، وفشل عناوين URL الخاصة بالخدمة الآمنة.
• الحل الوحيد إذا لم يتم إتخاذ الإجراء الوقائي في الخطوة 2 أولا هو حذف ITL يدويا من كل هاتف.

نظام مجموعة أحادي العقد مزود بكل من CTL و ITL (يمكن كسر هذا بشكل مؤقت، ولكن يمكن إصلاحه بسهولة)

• بعد التشغيل من خلال إعادة تسمية الخوادم، أعد تشغيل عميل CTL. وهذا يضع الشهادة الجديدة CallManager.pem في ملف CTL الذي يقوم الهاتف بتنزيله.
• يمكن الوثوق بملفات التكوين الجديدة، والتي تتضمن ملفات ITL الجديدة، بناء على وظيفة CCM+TFTP في ملف CTL.
• يعمل هذا الإجراء لأن ملف CTL المحدث موثوق به استنادا إلى مفتاح USB eToken خاص يظل كما هو.

نظام المجموعة متعدد العقد مع ITL فقط (يعمل هذا النظام بشكل عام، ولكنه يمكن تعطيله بشكل دائم إذا تم على عجل)

• نظرا لأن نظام المجموعة متعدد العقد يحتوي على خوادم TVS متعددة، يمكن لأي خادم واحد إعادة إنشاء الشهادات الخاصة به دون أي مشكلة. عند عرض الهاتف بهذا التوقيع الجديد غير المألوف، يطلب من خادم آخر في TVS التحقق من شهادة الخادم الجديدة.
• هناك مشكلتان رئيسيتان من الممكن أن تتسببا في فشل هذا:
  
  • في حالة إعادة تسمية جميع الخوادم وإعادة تشغيلها في نفس الوقت، فلن يكون من الممكن الوصول إلى أي من خوادم أجهزة التلفزيون باستخدام شهادات معروفة عند إعادة تشغيل الخوادم والهواتف.
  • إذا كان للهاتف خادم واحد فقط في مجموعة CallManager، فلن تحدث خوادم TVS الإضافية أي فرق. راجع سيناريو "نظام المجموعة أحادية العقدة" لحل هذه المشكلة، أو قم بإضافة خادم آخر إلى مجموعة CallManager للهاتف.

نظام مجموعة متعدد العقد مع كل من CTL و ITL (لا يمكن كسر هذا بشكل دائم)

• بعد تشغيل عملية إعادة التسمية، تقوم خدمة TVS بمصادقة الشهادات الجديدة.
• حتى في حالة عدم توفر جميع خوادم TVS لسبب ما، لا يزال يمكن إستخدام عميل CTL من أجل تحديث الهواتف باستخدام شهادات CallManager.pem CCM+TFTP الجديدة.

TFTP المركزي

عندما يجزمة هاتف مع ITL، فإنه يطلب هذه الملفات: CTLSEP<MAC Address>.tlv، ITLSEP<MAC Address>.tlv، وSEP<MAC Address>.cnf.xml.sgn.

إذا تعذر على الهاتف العثور على هذه الملفات، فإنه يطلب ITLFile.tlv وCTLFile.tlv، وهو ما يوفره خادم TFTP مركزي لأي هاتف يطلبه.

باستخدام بروتوكول TFTP المركزي، يوجد مجموعة TFTP واحدة تشير إلى عدد من المجموعات الفرعية الأخرى.

غالبا ما يتم القيام بذلك لأن الهواتف الموجودة على مجموعات CUCM المتعددة تشترك في نطاق DHCP نفسه، وبالتالي يجب أن يكون لها نفس خيار DHCP رقم 150 TFTP.

تشير جميع هواتف بروتوكول الإنترنت (IP) إلى مجموعة TFTP المركزية، حتى إذا كانت مسجلة في مجموعات أخرى. يستعلم خادم TFTP المركزي خوادم TFTP البعيدة عندما يستلم طلبا لملف لا يمكنه العثور عليه.

وبسبب هذه العملية، تعمل TFTP المركزية فقط في بيئة ITL المتجانسة.

يجب أن تقوم جميع الخوادم بتشغيل الإصدار 8.x من CUCM أو الإصدارات الأحدث، أو يجب أن تقوم جميع الخوادم بتشغيل الإصدارات قبل الإصدار 8.x.

إذا تم تقديم ITLFile.tlv من خادم TFTP المركزي، فإن الهواتف لا تثق في أي ملفات من خادم TFTP البعيد نظرا لعدم تطابق التوقيعات.

هذا يحدث في مزيج غير متجانس. في مزيج متجانس، يطلب الهاتف ITLSEP<MAC>.tlv الذي يتم سحبه من المجموعة البعيدة الصحيحة.

في بيئة غير متجانسة تحتوي على مزيج من مجموعات الإصدار 8.x والإصدار 8.x، يجب تمكين "مجموعة التحضير للرجوع إلى ما قبل 8.0" على مجموعة الإصدار 8.x كما هو موضح في معرف تصحيح الأخطاء من Cisco CSCto87262 .

قم بتكوين "معلمات عنوان URL للهاتف الآمن" باستخدام HTTP بدلا من HTTPS. يؤدي هذا إلى تعطيل وظائف ITL بشكل فعال على الهاتف.

الأسئلة المتكررة

هل يمكنني إيقاف تشغيل SBD؟

لا يمكنك إيقاف تشغيل SBD إلا إذا كانت SBD و ITL يعملان حاليا.

يمكن تعطيل SBD مؤقتا على الهواتف باستخدام مجموعة التحضير للرجوع إلى معلمة المؤسسة السابقة 8.0" ومن خلال تكوين "معلمات عنوان URL للهاتف الآمن" باستخدام HTTP بدلا من HTTPS.

عندما تقوم بضبط معلمة التراجع، فإنها تقوم بإنشاء ملف ITL موقع بإدخالات دالة فارغة.

لا يزال ملف ITL "الفارغ" موقعا، لذلك يجب أن يكون نظام المجموعة في حالة أمان وظيفية بالكامل قبل تمكين هذه المعلمة.

بعد تمكين هذه المعلمة وتنزيل ملف ITL الجديد بإدخالات فارغة والتحقق من صحتها، تقبل الهواتف أي ملف تكوين، بغض النظر عمن قام بتوقيعه.

لا يوصى بترك المجموعة في هذه الحالة، نظرا لعدم توفر أي من الوظائف الثلاث التي تمت الإشارة إليها مسبقا (ملفات التكوين المصادق عليها وملفات التكوين المشفرة وعناوين HTTPS URL).

هل يمكنني بسهولة حذف ملف ITL من جميع الهواتف بمجرد فقدان CallManager.pem؟

لا توجد حاليا طريقة لحذف جميع قوائم التحكم في الوصول إلى النقل (ITL) من هاتف تقدمه Cisco عن بعد. ولهذا السبب فإن الإجراءات والتفاعلات الموصوفة في هذا المستند مهمة للغاية لأخذها في الاعتبار.

هناك حاليا تحسين غير محلول ل Cisco CSCto47052 أن يطلب هذا وظيفة، غير أنه لم يتم تنفيذه بعد.

في الفترة الانتقالية، تمت إضافة ميزة جديدة عبر Cisco بق CSCts01319 التي قد تسمح لمركز المساعدة الفنية (TAC) من Cisco بالعودة إلى قائمة التحكم في الوصول (ITL) الموثوقة سابقا إذا كانت لا تزال متوفرة على الخادم.

ويعمل هذا فقط في حالات معينة حيث يكون نظام المجموعة على إصدار به إصلاح هذا الخلل، وحيث يوجد سجل المعاملات الدولي السابق في نسخة إحتياطية مخزنة في موقع خاص على الخادم.

قم بعرض العيب لمعرفة ما إذا كان الإصدار الخاص بك يحتوي على الإصلاح أم لا. اتصل ب cisco TAC in order to ركضت من خلال المحتمل إستعادة إجراء شرح في الخطأ.

إذا لم يكن الإجراء السابق متاحا، يجب دفع أزرار الهاتف يدويا على الهاتف لحذف ملف ITL. هذه هي المقايضة التي تتم بين الأمن وسهولة الإدارة. لكي يكون ملف ITL آمنا بالفعل، يجب ألا يتم إزالته بسهولة عن بعد.

حتى مع ضغطات الزر المفتوحة بالبرامج النصية التي تحتوي على كائنات XML لبروتوكول الوصول البسيط إلى الكائن (SOAP)، لا يمكن إزالة ITL عن بعد.

وذلك لأن الوصول إلى TVS (وبالتالي الوصول الآمن إلى URL للمصادقة للتحقق من صحة كائنات الضغط الواردة على زر SOAP XML) لا يعمل في هذه المرحلة.

إذا لم يتم تكوين عنوان URL للمصادقة على أنه آمن، فمن الممكن كتابة المطابع النصية لحذف ITL، ولكن لا يتوفر هذا البرنامج النصي من Cisco.

من الممكن أن تكون الطرق الأخرى لعمل نصوص لضغطات المفاتيح البعيدة بدون إستخدام عنوان URL للمصادقة متاحة من طرف ثالث، لكن هذه التطبيقات لا تقدمها Cisco.

وأكثر الطرق إستخداما لحذف سجل المعاملات الدولي هي بث بريد إلكتروني إلى جميع مستخدمي الهاتف يرشدهم إلى تسلسل المفاتيح.

في حالة تعيين الوصول إلى الإعدادات إلى Restricted أو Disabled، يجب إعادة ضبط الهاتف في المصنع، حيث لا يمكن للمستخدمين الوصول إلى قائمة "الإعدادات" الخاصة بالهاتف.