تكوين LSC على هاتف IP باستخدام CUCM

المقدمة

يوضح هذا المستند كيفية تثبيت شهادة ذات قيمة محلية (LSC) على هاتف بروتوكول الإنترنت (هاتف بروتوكول الإنترنت من Cisco).

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• خيارات وضع أمان المجموعة Cisco Unified Communications Manager (CUCM)
• شهادات X.509
• الشهادات المثبتة الخاصة بالتصنيع (MICs)
• إل إس إس
• عمليات شهادة وظيفة وكيل جهة الترخيص (CAPF)
• الأمان بشكل افتراضي (SBD)
• ملفات قائمة الثقة الأولية (ITL)

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات CUCM التي تدعم SBD، وهي CUCM 8.0(1) وما فوقها.

ملاحظة: يتعلق فقط بالهواتف التي تدعم الأمان بشكل افتراضي (SBD). على سبيل المثال، هواتف 7940 و 7960 لا تدعم هواتف SBD، ولا هواتف المؤتمرات 7935 و 7936 و 7937. للحصول على قائمة بالأجهزة التي تدعم SBD في إصدارك من CUCM، انتقل إلى Cisco Unified Reporting > System Reports (تقارير النظام) > قائمة ميزات هاتف CM الموحد وقم بتشغيل تقرير عن الميزة: الأمان بشكل افتراضي.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

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

MICs مقابل LSCs

إذا كنت تستخدم المصادقة المستندة إلى الشهادة ل 802.1X أو AnyConnect Phone VPN، فمن المهم فهم الفرق بين بطاقات MICs و LSCs.

يأتي كل هاتف من Cisco مزودا بميكروفون مثبت مسبقا في المصنع. يتم توقيع هذه الشهادة بواسطة إحدى شهادات Cisco Manufacturing CA، إما بواسطة شهادة Cisco Manufacturing CA أو Cisco Manufacturing CA SHA2 أو CAP-RTP-001 أو CAP-RTP-002. عندما يقدم الهاتف هذه الشهادة، فإنه يثبت أنه هاتف Cisco صالح، ولكن هذا لا يثبت أن الهاتف ينتمي إلى عميل معين أو مجموعة CUCM. من المحتمل أن يكون هاتفا مخادعا تم شراؤه من السوق المفتوح أو تم جلبه من موقع مختلف.

ومن ناحية أخرى، يتم تثبيت قوائم التحكم في الوصول الخاصة بالمنفذ (LSC) عمدا على الهواتف بواسطة مسؤول، ويتم توقيعها بواسطة شهادة CAPF الخاصة بناشر CUCM. يمكنك تكوين شبكة 802.1X أو AnyConnect VPN للثقة فقط في قوائم التحكم في الوصول الخاصة (LSCs) التي يتم إصدارها بواسطة المراجع المعروفة لشهادات CAPF. يوفر لك إنشاء مصادقة الشهادة على بطاقات LSCs بدلا من بطاقات MIC تحكما أكثر دقة بكثير حول أي أجهزة الهاتف موثوق بها.

التكوين

طوبولوجيا الشبكة

تم إستخدام خوادم CUCM lab هذه لهذا المستند:

• ao115pub - 10.122.138.102 - برنامج ناشر CUCM وخادم TFTP
• ao115sub - 10.122.138.103 - مشترك CUCM وخادم TFTP 

تحقق من عدم انتهاء صلاحية شهادة CAPF، أو أنها على وشك الانتهاء في المستقبل القريب. انتقل إلى إدارة نظام التشغيل الموحدة من Cisco > الأمان > إدارة الشهادات، ثم ابحث عن قائمة الشهادات حيث تكون الشهادة CAPF بالضبط كما هو موضح في الصورة.

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

إذا انتهت صلاحية شهادة CAPF أو توشك على الانتهاء، أعد إنشاء هذه الشهادة. لا تتحرك للأمام مع عملية تثبيت LSC بشهادة CAPF منتهية الصلاحية أو ستنتهي صلاحيتها قريبا. يتجنب هذا الحاجة إلى إعادة إصدار قوائم التحكم في الوصول (LSCs) في المستقبل القريب بسبب انتهاء صلاحية شهادة CAPF. للحصول على معلومات حول كيفية إعادة إنشاء شهادة CAPF، راجع مقالة تجديد/عملية تجديد/شهادة CUCM.

وبالمثل، إذا كنت بحاجة إلى توقيع شهادة CAPF الخاصة بك من قبل جهة خارجية، فلديك خيار في هذه المرحلة. قم إما بإكمال إنشاء ملف طلب توقيع الشهادة (CSR) واستيراد شهادة CAPF الموقعة الآن، أو واصل التكوين باستخدام LSC موقعة ذاتيا لإجراء إختبار أولي. إذا احتجت إلى شهادة CAPF موقعة من طرف ثالث، فمن المعقول بشكل عام تكوين هذه الميزة أولا باستخدام شهادة CAPF موقعة ذاتيا، والاختبار والتحقق، ثم إعادة نشر قوائم التحكم في الوصول الخاصة (LSCs) الموقعة من قبل شهادة CAPF موقعة من طرف ثالث. يؤدي هذا إلى تبسيط عملية أستكشاف الأخطاء وإصلاحها لاحقا، في حالة فشل الاختبارات التي تم إجراؤها باستخدام شهادة CAPF الموقعة من قبل الطرف الثالث.

تحذير: إذا قمت بإعادة إنشاء شهادة CAPF أو إستيراد شهادة CAPF موقعة من طرف خارجي أثناء تنشيط خدمة CAPF وبدء تشغيلها، فإنه يتم إعادة ضبط الهواتف تلقائيا بواسطة CUCM. أكمل هذه الإجراءات في نافذة صيانة عندما يكون من المقبول إعادة تعيين الهواتف. للمرجع، راجع معرف تصحيح الأخطاء من Cisco CSCue55353 - إضافة تحذير عند إعادة إنشاء شهادة TVS/CCM/CAPF التي تعيد ضبط الهواتف

ملاحظة: إذا كان إصدار CUCM الخاص بك يدعم SBD، فإن إجراء تثبيت LSC هذا يطبق بغض النظر عن ما إذا كان مجموعة CUCM الخاصة بك معينة إلى الوضع المختلط أو لا. SBD هو جزء من CUCM الإصدار 8.0(1) والإصدارات اللاحقة. في هذه الإصدارات من CUCM، تحتوي ملفات ITL على شهادة خدمة CAPF في ناشر CUCM. وهذا يسمح للهواتف بالاتصال بخدمة CAPF لدعم عمليات الشهادات مثل "التثبيت/الترقية" واستكشاف الأخطاء وإصلاحها.

في الإصدارات السابقة من CUCM، كان من الضروري تكوين نظام المجموعة للوضع المختلط لدعم عمليات الشهادات. ونظرا لأن هذا لم يعد ضروريا، فإن ذلك يقلل من الحواجز التي تعترض إستخدام قوائم التحكم في الوصول إلى الشبكة (LSCs) كشهادات هوية هاتف لمصادقة 802.1X أو لمصادقة عميل AnyConnect VPN.

قم بتشغيل الأمر show itl على جميع خوادم TFTP في مجموعة CUCM. لاحظ أن ملف ITL يحتوي على شهادة CAPF.

على سبيل المثال، هنا مقتطف من إخراج show itl من مشترك CUCM في المختبر AO115sub.

ملاحظة: يوجد إدخال سجل ITL في هذا الملف بوظيفة CAPF.

ملاحظة: إذا لم يكن لملف ITL الخاص بك إدخال CAPF، فقم بتسجيل الدخول إلى ناشر CUCM وتأكيد تنشيط خدمة CAPF. لتأكيد هذا، انتقل إلى Cisco Unified ServiceAbility > Tools > Service Activation (تنشيط الخدمة) > CUCM Publisher > Security، ثم قم بتنشيط خدمة وظيفة وكيل مرجع شهادات Cisco. إذا تم إلغاء تنشيط الخدمة وقمت بتنشيطها فقط، فانتقل إلى Cisco Unified ServiceAbility > Tools > Control Center - Feature Services > Server > CM Services، ثم أعد تشغيل خدمة Cisco TFTP على جميع خوادم TFTP في مجموعة CUCM لإعادة إنشاء ملف ITL. أيضا، ضمنت أن أنت لا يضرب cisco بق id CSCuj78330.

ملاحظة: بعد الانتهاء، قم بتشغيل الأمر show itl على جميع خوادم TFTP في مجموعة CUCM للتحقق من تضمين شهادة CAPF الخاصة بناشر CUCM حاليا في الملف.

 ITL Record #:1
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null

 ITL Record #:2
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null

 ITL Record #:3
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

 ITL Record #:4
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null

 ITL Record #:5
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

 ITL Record #:6
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)

 ITL Record #:7
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)

The ITL file was verified successfully.

مع تأكيد إدخال CAPF كإدخال في ITL، يمكنك إكمال عملية شهادة على الهاتف. في هذا المثال، يتم تثبيت شهادة RSA من نوع 2048 بت باستخدام مصادقة السلسلة الفارغة.

على الهاتف، تحقق من عدم تثبيت LSC بعد كما هو موضح في الصورة. على سبيل المثال، على هاتف من السلسلة 79xx، انتقل إلى الإعدادات > 4 - تكوين الأمان > 4 - LSC.

افتح صفحة تكوين الهاتف لهاتفك. انتقل إلى إدارة Cisco Unified CM > Device > Phone.

أدخل هذه التفاصيل إلى قسم معلومات CAPF في تكوين الهاتف، كما هو موضح في الصورة:

• لتشغيل الشهادة، أختر تثبيت/ترقية
• لوضع المصادقة، أختر حسب سلسلة فارغة
• على سبيل المثال، أترك ترتيب المفاتيح وحجم مفتاح RSA (BITS) وحجم مفتاح EC (BITS) مضبوطا على إعدادات النظام الافتراضية.
• لإتمام العملية حسب، أدخل تاريخا وزمن لمدة ساعة واحدة على الأقل في المستقبل.

احفظ تغييرات التكوين، ثم قم بتطبيق التكوين.

تتغير حالة LSC على الهاتف إلى معلق كما هو موضح في الصورة.

يولد الهاتف المفاتيح كما هو موضح في الصورة.

تقوم بإعادة ضبط الهاتف، وعندما تكتمل إعادة التعيين، تتغير حالة LSC للهاتف إلى مثبتة كما هو موضح في الصورة.

وهذا يظهر أيضا تحت رسائل الحالة في الهاتف كما هو موضح في الصورة.

التحقق من الصحة

استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.

للتحقق من تثبيت شهادة LSC على هواتف متعددة، ارجع إلى قسم إنشاء تقرير CAPF في دليل الأمان ل Cisco Unified Communications Manager، الإصدار 11.0(1). بدلا من ذلك، يمكنك عرض نفس البيانات ضمن واجهة ويب إدارة CUCM باستخدام إجراء البحث عن الهواتف حسب حالة LSC أو إجراء سلسلة المصادقة.

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

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

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

لا يوجد خادم CAPF صالح

فشل تثبيت LSC. تظهر رسائل حالة الهاتف عدم وجود خادم CAPF صالح. وهذا يشير إلى عدم وجود إدخال CAPF في ملف ITL. تحقق من تنشيط خدمة CAPF، ثم أعد تشغيل خدمة TFTP. تحقق من أن ملف ITL يحتوي على شهادة CAPF بعد إعادة التشغيل، ثم أعد تعيين الهاتف لالتقاط أحدث ملف ITL، ثم أعد محاولة إجراء عملية الشهادة. إذا عرض إدخال خادم CAPF في قائمة إعدادات الأمان للهاتف كاسم المضيف أو اسم المجال المؤهل بالكامل، فأكد أن الهاتف قادر على حل الإدخال إلى عنوان IP.

LSC: فشل الاتصال

فشل تثبيت LSC. تظهر رسائل حالة الهاتف LSC: فشل الاتصال. يمكن أن يشير ذلك إلى أحد الشروط التالية:

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

تحقق من تنشيط خدمة CAPF، ثم أعد تشغيل خدمة CAPF، ثم أعد تشغيل خدمات TFTP على نطاق واسع، وأعد ضبط الهاتف لالتقاط أحدث ملف ITL، ثم أعد محاولة إجراء عملية الشهادة. إذا إستمرت المشكلة، فعليك التقاط حزمة من الهاتف وناشر CUCM وتحليلها لمعرفة ما إذا كان هناك اتصال ثنائي الإتجاه على المنفذ 3804، وهو منفذ خدمة CAPF الافتراضي. إذا لم تكن هناك شبكة مشكلة.

LSC: فشل

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

LSC: العملية معلقة

فشل تثبيت LSC. تظهر رسائل حالة الهاتف LSC: فشل الاتصال. تظهر صفحة تكوين الهاتف حالة عملية الشهادة: العملية معلقة. هناك أسباب مختلفة تمكن المرء من رؤية حالة عملية الشهادة: حالة تعليق العملية. ويمكن أن يشمل بعضها ما يلي:

• إن ITL على الهاتف مختلف عن ذلك المستخدم حاليا على خوادم TFTP المضمنة.
• مشاكل مع ITL فاسد. عند حدوث ذلك، تفقد الأجهزة حالتها الموثوق بها ويلزم تشغيل الأمر لإعادة تعيين مفتاح الإعدادات المحلية من ناشر CUCM لإجبار الهواتف على إستخدام شهادة ITLRecovery الآن. إذا كان نظام المجموعة في الوضع المختلط، فأنت بحاجة إلى إستخدام الأمر من خلال إعادة تعيين LOCALKEY. بعد ذلك، ترى مثالا لما يمكنك رؤيته عند محاولة عرض ITL فاسد من واجهة سطر الأوامر (CLI) الخاصة ب CUCM. إذا كان هناك خطأ عند محاولة عرض ITL ومحاولة تشغيل الأمر utils reset localkey، ولكن ترى الخطأ الثاني، وهذا يمكن أن يكون عيبا في معرف تصحيح الأخطاء من Cisco CSCus33755. تأكيد ما إذا كان إصدار CUCM يتأثر.

• فشلت الهواتف في مصادقة LSC الجديد بسبب فشل أجهزة التلفزيون.
• يستخدم الهاتف شهادة MIC ولكن قسم معلومات وظيفة وكيل المرجع المصدق (CAPF) في صفحة تكوين الهواتف له وضع المصادقة المعين بواسطة الشهادة الموجودة (أسبقية LSC).
• تعذر على الهاتف حل FQDN ل CUCM.

للسيناريو الأخير، يتم إعداد بيئة معملية لمحاكاة ما ستراه في السجلات إذا لم يتمكن الهاتف من حل FQDN الخاص ب CUCM. حاليا، يتم إعداد المختبر مع هذه الخوادم:

• برنامج ناشر ومشترك CUCM اللذين يشغلان الإصدار 11.5.1.15038-2
• إعداد خادم Windows 2016 كخادم DNS الخاص بي

للاختبار، لا يوجد إدخال DNS لخادم PUB11 CUCM الذي تم تكوينه.

حاولت دفع LSC إلى واحد من الهواتف (8845) في المختبر. راجع أنه لا يزال يظهر حالة عملية الشهادة: العملية معلقة.

في سجلات وحدة التحكم في الهاتف، راجع محاولات الهاتف للاستعلام عن ذاكرة التخزين المؤقت المحلية (127.0.0.1)، قبل إعادة توجيه الاستعلام إلى عنوان خادم DNS الذي تم تكوينه.

0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab

++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.

0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab

++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11. 

0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed

++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.

4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab

انظر في رسائل حالة الهاتف أدناه، أن الهاتف غير قادر على حل PUB11.BRIANW2.lab. رأيت بعد ذلك ال lsc: توصيل failed رسالة.

العيوب التي يجب أخذها بعين الاعتبار:

معرف تصحيح الأخطاء من Cisco CSCub62243 - يفشل تثبيت LSC بشكل متقطع وبعد ذلك يجمد CAPF SRVR

نقص في التعزيز للأخذ في الاعتبار:

معرف تصحيح الأخطاء من Cisco CSCuz18034 - يلزم إعداد تقارير لنقاط النهاية المثبتة ل LSC مع حالة انتهاء الصلاحية

معلومات ذات صلة

توفر هذه المستندات مزيد من المعلومات حول إستخدام قوائم التحكم في الوصول (LSCs) في سياق مصادقة عميل AnyConnect VPN ومصادقة 802.1X.

• أستكشاف أخطاء هاتف AnyConnect VPN - هواتف IP و ASA و CUCM وإصلاحها
• خدمات الشبكة المستندة إلى الهوية: مهاتفة IP في دليل تكوين ونشر الشبكات التي تم تمكينها باستخدام IEEE 802.1X

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

للحصول على تفاصيل، ارجع إلى: مثال تكوين إستيراد وإنشاء LSCs الموقع على CUCM من قبل CA الطرف الثالث

• الدعم التقني والمستندات - Cisco Systems