أستكشاف أخطاء الوصول عن بعد وإصلاحها في بنية قائمة التحكم في الوصول (ACI)
المقدمة
يوضح هذا المستند كيفية التحقق من مشاكل الوصول عن بعد واستكشاف أخطائها وإصلاحها وحلها في بنية Cisco Application Centric Infrastructure (ACI). وهو يغطي الوصول الآمن عبر بروتوكولات طبقة الأمان (SSH) ونقل النص التشعبي الآمن (HTTPS) إلى واجهات برمجة التطبيقات (APIC) ومحولات البنية، والمصادقة عن بعد، والتخويل والمحاسبة (AAA) باستخدام نظام التحكم في الوصول إلى وحدة تحكم الوصول إلى المحطة الطرفية (TACACS+)، وخدمة مستخدم طلب الاتصال عن بعد (RADIUS)، وبروتوكول الوصول إلى الدليل خفيف الوزن (LDAP)، تفويض التحكم في الوصول المستند إلى الأدوار (RBAC). يتم تضمين شجرة قرارات فرز وسيناريوهات مفصلة لاستكشاف المشكلات وحلها لكل منطقة.
معلومات أساسية
تم توليف المواد الواردة من هذا المستند من دليل أستكشاف أخطاء إدارة قائمة التحكم في الوصول (ACI) وإصلاحها والخدمات الأساسية — دليل سياسات POD، دليل التكوين الأساسي لواجهة برمجة التطبيقات (APIC) من Cisco، الإصدار 6.1(x) — فصل الإدارة، ودليل تكوين أمان واجهة برمجة التطبيقات (APIC) من Cisco — فصل الوصول والمصادقة والمحاسبة.
نظرة عامة
يتضمن الوصول عن بعد إلى بنية قائمة التحكم في الوصول (ACI) ثلاث طبقات مختلفة، يجب أن يعمل كل منها للمهندس لتسجيل الدخول والتشغيل بنجاح:
- النقل — يجب أن يكون مسار شبكة الإدارة (OOB أو داخل النطاق الترددي) وخدمة البروتوكول (SSH أو HTTPS) قابلين للوصول والتمكين.
- المصادقة — يجب التحقق من بيانات اعتماد المستخدم، إما محليا على APIC أو مقابل خادم AAA بعيد (TACACS+ أو RADIUS أو LDAP).
- التفويض — يجب أن يتم تعيين أدوار RBAC الصحيحة ومجالات الأمان للمستخدم الذي تمت مصادقته لعرض كائنات ACI المقصودة وتعديلها.
والفشل في أي طبقة ينتج اعراضا مختلفة. يؤدي فشل النقل إلى منع الاتصال بالكامل. يرجع فشل المصادقة خطأ بيانات اعتماد. يسمح فشل التخويل بتسجيل الدخول ولكنه يقيد إمكانية الرؤية أو ينتج عن أخطاء "403 ممنوع" في واجهة برمجة التطبيقات.
سياسة الوصول إلى الإدارة
Management Access Policy (commPol) هو الكائن المركزي الذي يتحكم في أي بروتوكولات الوصول عن بعد يتم تمكينها على البنية. يوجد أسفل البنية > سياسات البنية > السياسات > Pod > الوصول إلى الإدارة > الافتراضي. يحتوي النهج على كائنات تابعة يتم تكوينها:
- SSH (
commSsh) — خوارزميات الحالة الإدارية والمنفذ والشفرات وتبادل المفاتيح (KEX) وأكواد مصادقة الرسائل (MACs) وخوارزميات مفاتيح المضيف. - HTTPS (
commHttps) — الحالة الإدارية، المنفذ، إصدار بروتوكول أمان طبقة النقل (TLS)، معدل الكبح، ومصادقة شهادة العميل. - Telnet (
commTelnet) — الدولة والمنفذ الإداريان. أعجزت Telnet افتراضيا و cisco يوصي هو يظل معأق.
إدارة خارج النطاق الترددي وداخل النطاق
تدعم عقد واجهة التحكم في الوصول (ACI) مسارين للوصول إلى الإدارة:
- خارج النطاق (OOB) — يستخدم منفذ الإدارة المخصص على APIC أو المحول. يتم تخصيص عناوين الإدارة خارج النطاق (OOB) من تجمع تحت مستأجر الإدارة وتخصيصها للعقد عبر
mgmtRsOoBStNode. في APIC، يتم فرض عقود OOB من خلالiptablesقواعد. إذا تم تطبيق عقد خارج النطاق (OOB)، يمكن لحركة مرور البيانات المسموح بها بشكل صريح بواسطة العقد فقط الوصول إلى واجهة إدارة APIC. - داخل النطاق (INB) — يستخدم مستوى بيانات البنية لحركة مرور الإدارة. تتطلب الإدارة داخل النطاق تعيين عنوان إدارة العقد والشبكة الفرعية (BD) ومجموعة نقاط النهاية (EPG) والعقد. لا يمكن الوصول إلى عناوين IP داخل النطاق من خارج البنية دون توجيه إضافي أو تكوين نهج.
بنية AAA
يستخدم ACI نموذج AAA من ثلاث طبقات:
- مجال تسجيل الدخول (
aaaLoginDomain) — مجموعات مزودي AAA ضمن نطاق مسمى. يحدد المستخدمون مجال تسجيل الدخول في شاشة تسجيل الدخول (على سبيل المثال،apic:TACACS-Domainأو عبر القائمة المنسدلة في واجهة المستخدم). يوجد دائما مجال إحتياطي خاص لتسجيل الدخول وخرائط للمصادقة المحلية. - مجموعة الموفر (
aaaTacacsPlusProviderGroup،aaaRadiusProviderGroup،aaaLdapProviderGroup) — تشير إلى خادم AAA واحد أو أكثر وتعرف الترتيب الذي تتم تجربته به. - الموفر (
aaaTacacsPlusProvider،aaaRadiusProvider،aaaLdapProvider) — يحدد الخادم IP أو المنفذ أو السر المشترك (أو Bind DN ل LDAP) أو المهلة أو عمليات إعادة المحاولة أو إدارة EPG أو مراقبة بيانات الاعتماد.
يحدد نطاق المصادقة الافتراضي (aaaDefaultAuth) أي مجال تسجيل الدخول يتم إستخدامه عندما لا يحدد المستخدم مجال تسجيل دخول. يتحكم نطاق مصادقة وحدة التحكم في مصادقة جلسات عمل وحدة التحكم.
ملفات سجل المصادقة والتفويض والمحاسبة (AAA) الأساسية
يتم تسجيل أحداث مصادقة AAA في العديد من الملفات على كل من محولات APIC و fabric. هذه السجلات هي الأداة الأساسية للتحقق من نتائج المصادقة وتحديد النطاق ومجموعة الموفر التي يتم إستخدامها وتشخيص حالات فشل تعيين الدور.
| ملف السجل | الموقع (APIC) | الموقع (المحولات) | الوصف |
|---|---|---|---|
| nginx.bin.log (APIC) nginx.log (محولات) |
/var/log/dme/log/nginx.bin.log |
/var/sysmgr/tmp_logs/dme_logs/nginx.log |
سجل AAA الأساسي. يحتوي على تدفق المصادقة الكامل: طلب PAM، تحديد النطاق، بحث الموفر، اتصال LDAP/TACACS+/RADIUS، تحليل زوج AV، تعيين المجال والدور، ونتيجة النجاح أو الرفض. يختلف اسم الملف بين الأنظمة الأساسية ولكن تنسيق المحتوى هو نفسه. |
| access.log | /var/log/dme/log/access.log |
/var/log/dme/log/access.log |
سجل طلب NGINX HTTP. سطر واحد لكل طلب واجهة برمجة تطبيقات. في APIC، يظهر aaaLogin وaaaRefresh مكالمة مع رموز حالة HTTP (200 = نجاح، 401 = رفض). في المحولات، تظهر طلبات واجهة برمجة تطبيقات DME الداخلية ومكالمات aaaRefresh. |
| pam.module.log | /var/log/dme/log/pam.module.log |
/var/log/dme/log/pam.module.log |
سجل وحدة PAM النمطية. يعرض نتيجة المصادقة لجلسات عمل SSH: المستخدم الذي تمت مصادقته و IP المصدر ومعرف مستخدم UNIX المعين. في المحولات، هذه هي الطريقة الأسرع لتأكيد ما إذا كان المستخدم قد تمت مصادقته أو رفضه. |
تتبع إدخالات AAA في سجل NGINX هذا التنسيق:
PID||TIMESTAMP||aaa||SEVERITY||CONTEXT||MESSAGE||SOURCE_FILE||LINE
تصفية إدخالات السجل المتعلقة ب AAA لتدفق مصادقة مستخدم معين:
! On the APIC: apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20 ! On a leaf or spine switch: leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'username' | tail -20
أو عرض كافة طلبات المصادقة والنتائج الأخيرة:
! On the APIC: apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'PAM authenticate\|was denied\|Unauthorized\|DENIED' | tail -20 ! On a leaf or spine switch: leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'PAM authenticate\|was denied\|Unauthorized\|DENIED' | tail -20
يبدي تدفق المصادقة النموذجي الناجح هذه الرسائل الأساسية بالترتيب:
تم تلقي طلب مصادقة PAM من NGINX لاسم المستخدم:<user>— تم تلقي طلب تسجيل الدخول.يحدد DefaultAuthMo المجال <N>.مجموعة الموفر <name> !— تم تحديد النطاق (0=إحتياطي/محلي، 2=TACACS+، 3=ldap).- رسائل خاصة بالمزود (ربط LDAP أو بحث موفر TACACS+ أو طلب RADIUS).
تم العثور على UserDomain <domain> تحت اسم المستخدم البعيد:<user>— تعيين المجال من إستجابة AAA.اسم المستخدم الذي تم العثور عليه:مسؤول لديه امتيازات كتابة مسؤول ضمن UserDomain all - مستخدم مستخدم مسؤول— تم تمرير التحقق من الدور.
سجل مصادقة فاشل:
تم رفض المستخدم <user> أثناء مصادقة AAAخطأ <user> مستخدم غير مصرح به: تم رفض مصادقة خادم AAA
! On the APIC: apic1# zegrep '||aaa||' /var/log/dme/log/nginx.bin.log.*.gz | grep 'PAM authenticate' ! On a leaf or spine switch: leaf101# zegrep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log.*.gz | grep 'PAM authenticate'
نموذج RBAC
تتحكم ACI RBAC في ما يمكن للمستخدم الذي تمت مصادقة بياناته أن يراه ويفعله. يحتوي النموذج على ثلاثة مكونات:
- مجال الأمان (
aaaDomain) — محدد النطاق الذي يقوم بالتعيين إلى كائنات ACI (المستأجرين، سياسات الوصول، سياسات البنية). المجالات المضمنة جميعها، الشائعة، وmgmt موجودة دائما. تقيد المجالات المخصصة إمكانية رؤية المستخدم على مستأجرين أو مناطق نهج معينة. - الدور (
aaaRole) — يحدد مجموعة من الامتيازات. تتضمن الأدوار التي تم إنشاؤها مسبقا المسؤول، aaa، والمستأجر-admin، و tenant-ext-admin، و read-all، و access-admin، و fabric-admin، و ops، و nw-svc-admin. - امتياز — كل دور يمنح إما قراءة أو كتابة (مما يعني قراءة) الوصول إلى منطقة وظيفية معينة.
تم تعيين حساب مستخدم واحد أو أكثر من أزواج أدوار ومجال أمان. بالنسبة للمستخدمين البعيدين الذين تمت مصادقتهم عبر بروتوكول TACACS+ أو RADIUS أو LDAP، يتم تسليم تعيين الدور عبر السمات الخاصة بالمورد في إستجابة المصادقة والتفويض والمحاسبة (AAA) (على سبيل المثال، cisco-av-pair السمة).
شجرة قرارات الفرز
أستخدم شجرة القرارات هذه عندما يبلغ المستخدم عن عدم قدرته على الوصول إلى بنية واجهة التحكم في الوصول (ACI) عن بعد:
- هل يمكنك إختبار اتصال APIC أو IP لإدارة المحول؟
- لا → أستكشاف أخطاء مسار شبكة الإدارة وإصلاحها. يرجى الرجوع إلى قسم "أستكشاف أخطاء النشر خارج النطاق (OOB) وإدارتها داخل النطاق وإصلاحها".
- نعم → متابعة.
- هل يمكنك إنشاء اتصال SSH أو HTTPS (هل الاتصال مفتوح على الإطلاق)؟
- لا → يمكن تعطيل خدمة البروتوكول، أو يمكن تصفية المنفذ، أو يمكن وجود عدم تطابق تشفير. يرجى الإشارة إلى الأقسام "أستكشاف أخطاء وصول SSH وإصلاحها" أو "أستكشاف أخطاء وصول HTTPS وإصلاحها".
- نعم → متابعة.
- هل تظهر شاشة تسجيل الدخول (HTTPS) أو هل اكتملت مصافحة SSH وتطلب بيانات الاعتماد؟
- لا يوجد → فشل في تبادل مفتاح SSH أو مصافحة TLS. يرجى الإشارة إلى قسم "أستكشاف أخطاء أخطاء الوصول إلى SSH وإصلاحها" لتشفير KEX.
- نعم → متابعة.
- هل فشلت بيانات الاعتماد مع "فشل المصادقة" أو ما شابه؟
- نعم → مشكلة في المصادقة. الرجاء الإشارة إلى أقسام "أستكشاف أخطاء مصادقة AAA وإصلاحها" (TACACS+ أو RADIUS أو LDAP وفقا لمجال تسجيل الدخول قيد الاستخدام).
- لا → متابعة.
- هل يقوم المستخدم بتسجيل الدخول ولكن لا يمكنه رؤية الكائنات المتوقعة، أو يستلم أخطاء "403 ممنوع"؟
- نعم → إصدار التخويل أو RBAC. يرجى الرجوع إلى قسم "أستكشاف أخطاء RBAC وامتيازات المستخدم وإصلاحها".
- لا → يعمل أي وصول. تحقق من المشكلة المحددة التي يواجهها المستخدم.
التحقق من التكوين
قبل أستكشاف أخطاء حالة التشغيل وإصلاحها، تحقق من اكتمال سلسلة التكوين. يعد التكوين الخاطئ هو السبب الجذري الأكثر شيوعا لمشاكل الوصول عن بعد.
التحقق من سياسة الوصول إلى الإدارة (SSH و HTTPS)
انتقل إلى البنية > سياسات البنية > السياسات > Pod > الوصول إلى الإدارة > الافتراضي.
تأكيد إعدادات SSH التالية:
- حالة المسؤول — يجب تمكينها.
- المنفذ — الافتراضي 22. إذا تم التغيير، يجب أن يستخدم عميل SSH المنفذ المخصص.
- مصادقة كلمة المرور — ممكنة (ما لم تكن المصادقة على الشهادة فقط معدة).
- يجب أن تتضمن شفرة SSH — على الأقل شفرة واحدة يدعمها عميل SSH.
- خوارزميات KEX — يجب أن تتضمن على الأقل خوارزمية واحدة يدعمها عميل SSH.
- عناوين MAC عبر بروتوكول SSH — يجب أن تتضمن على الأقل أحد عناوين MAC المدعومة من قبل عميل SSH.
الاستعلام عن الكائن المدار بواسطة SSH عبر واجهة برمجة التطبيقات:
apic1# moquery -c commSsh dn : uni/fabric/comm-default/ssh adminSt : enabled <--- must be enabled port : 22 passwordAuth : enabled sshCiphers : aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com kexAlgos : curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 sshMacs : hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512 hostkeyAlgos : rsa-sha2-256,rsa-sha2-512,ssh-ed25519
تأكيد إعدادات HTTPS التالية:
- حالة المسؤول — يجب تمكينها.
- ميناء — تقصير 443.
- بروتوكولات SSL — TLSv1.2 (الافتراضي). قد يتطلب العملاء الأقدم إضافة TLSv1.1 بشكل صريح.
- حالة الكبح — في حالة التمكين، يحد معدل الكبح عدد الطلبات في الثانية لكل مستخدم. قد تتسبب القيمة المنخفضة جدا في حدوث أخطاء في مهلة واجهة برمجة التطبيقات.
apic1# moquery -c commHttps dn : uni/fabric/comm-default/https adminSt : enabled <--- must be enabled port : 443 sslProtocols : TLSv1.2 throttleSt : enabled throttleRate : 2
أخطاء تكوين شائعة
- تم تقييد شفرة SSH بشكل مفرط — في الإصدار 5.2(1) من واجهة التحكم في الوصول (ACI) والإصدارات الأحدث، تم تقوية شفرة SSH الافتراضية. يمكن لعملاء SSH الأقدم (على سبيل المثال، إصدارات PuTTY قبل 0.75، أو إصدارات OpenSSH التي توفر فقط)
diffie-hellman-group14-sha1فشل تبادل المفاتيح. يعرض عميل SSH "لم يتم العثور على تشفير مطابق" أو "لم يتم العثور على أسلوب تبادل مفاتيح مطابق". - يتم تعطيل مصادقة كلمة المرور — إذا تم
passwordAuthتعيينها على معطل، يتم السماح بالمصادقة المستندة إلى مفتاح SSH فقط. سيرى المستخدمون الذين يتصلون بكلمات المرور "تم رفض الإذن (publicKey)". - منفذ SSH المخصص دون وعي العميل — إذا تم تغيير منفذ SSH من 22، فيجب أن يحدد عميل SSH المنفذ الجديد (على سبيل المثال،
ssh -p 2222 admin@10.1.1.1).
التحقق من عناوين إدارة OOB
انتقل إلى المستأجرين > الإدارة > عناوين إدارة العقد.
تأكد من أن كل عقدة APIC والمحول تحتوي على عنوان IP لإدارة OOB معين مع بوابة صالحة. لن يمكن الوصول إلى العقد التي لا تحتوي على عناوين إدارة عبر شبكة الإدارة.
الاستعلام عن تعيينات العقدة الثابتة OOB عبر واجهة برمجة التطبيقات (API):
apic1# moquery -c mgmtRsOoBStNode # Example output for one node: dn : uni/tn-mgmt/mgmtp-default/oob-default/rsooBStNode-[topology/pod-1/node-201] addr : 10.1.1.104/27 <--- OOB IP assigned gw : 10.1.1.97 <--- gateway for the OOB subnet tDn : topology/pod-1/node-201 <--- target node
أخطاء تكوين شائعة
- تعيين عنوان OOB مفقود — لا يحتوي المحول على إدخال أسفل
mgmtRsOoBStNode. لن تحتوي العقدة على بروتوكول IP للإدارة ولن تستجيب إلى SSH أو HTTPS على الواجهة خارج النطاق (OOB). - عبارة غير صحيحة — لا يتطابق عنوان البوابة مع البوابة الفعلية على شبكة إدارة OOB. يمكن للعقدة تلقي الحزم ولكن لا يمكنها إرسال حركة مرور الإرجاع.
- عدم تطابق قناع الشبكة الفرعية — لا يتطابق قناع الشبكة الفرعية OOB مع شبكة الإدارة المادية. قد يتسبب ذلك في اعتقاد العقدة بأن محطة الإدارة موجودة على شبكة فرعية مختلفة وحركة مرور المسار عبر بوابة غير موجودة أو غير صحيحة.
التحقق من عقود خارج النطاق الترددي
انتقل إلى المستأجرين > الإدارة > العقود.
إذا تم تطبيق عقد OOB على EPG الخاص بالإدارة OOB، فإن حركة المرور المسموح بها بشكل صريح بواسطة هذا العقد هي فقط التي ستصل إلى واجهة إدارة APIC. في APIC، يتم فرض عقود OOB من خلال iptables قواعد.
الاستعلام عن العقود التي قدمها EPG OOB:
apic1# moquery -c mgmtRsOoBProv -x 'query-target-filter=wcard(mgmtRsOoBProv.dn,"oob-default")'
في حالة إرجاع الاستعلام للنتائج، يتم تطبيق العقود. التحقق من أن مواضيع العقد وعوامل التصفية تسمح بالبروتوكولات المطلوبة:
- SSH — منفذ TCP 22 (أو منفذ مخصص)
- HTTPS — منفذ TCP رقم 443 (أو منفذ مخصص)
- ICMP — للتحقق من إختبار الاتصال
أخطاء تكوين شائعة
- لا يتضمن عقد OOB بروتوكول SSH أو HTTPS — يمكن للمهندس إختبار اتصال APIC ولكن لا يمكنه الاتصال عبر SSH أو HTTPS. تسقط قواعد
iptablesAPIC حركة المرور بصمت. - تقييد IP المصدر في عامل تصفية عقد خارج النطاق — يحد عامل تصفية العقد من الوصول إلى شبكات فرعية مصدر معينة. لا يمكن للمهندسين خارج هذه الشبكة الفرعية الاتصال.
التحقق من تكوين AAA
انتقل إلى admin > AAA > المصادقة > AAA.
تأكيد ما يلي:
- نطاق المصادقة الافتراضي — يحدد أي مجال تسجيل الدخول يتم إستخدامه عندما لا يحدد المستخدم مجال تسجيل دخول. إذا تم تعيينها على مجال تسجيل دخول AAA بعيد، فيجب أن يكون الخادم المتوافق قابلا للوصول.
- نطاق مصادقة وحدة التحكم — للتحكم في الوصول إلى وحدة التحكم. في حالة التعيين إلى محلي، يستخدم تسجيل الدخول إلى وحدة التحكم بيانات الاعتماد المحلية دائما (مستحسن).
التحقق من مجالات تسجيل الدخول
انتقل إلى Admin > AAA > المصادقة > مجالات تسجيل الدخول.
apic1# moquery -c aaaLoginDomain # Example output: dn : uni/userext/logindomain-TACACS-Domain name : TACACS-Domain dn : uni/userext/logindomain-LOCAL name : LOCAL dn : uni/userext/logindomain-fallback name : fallback descr : Special login domain to allow fallback to local authentication
تحقق من وجود مجال تسجيل الدخول المستخدم للمصادقة ومن أنه يشير إلى مجموعة الموفر الصحيحة.
التحقق من موفري TACACS+
انتقل إلى admin > AAA > المصادقة > TACACS+ > موفري TACACS+.
apic1# moquery -c aaaTacacsPlusProvider dn : uni/userext/tacacsext/tacacsplusprovider-10.1.1.50 name : 10.1.1.50 authProtocol : pap port : 49 <--- default TACACS+ port monitorServer : disabled epgDn : uni/tn-mgmt/mgmtp-default/oob-default <--- management EPG
التحقق من موفري RADIUS
انتقل إلى Admin > AAA > المصادقة > RADIUS > موفرو RADIUS.
apic1# moquery -c aaaRadiusProvider dn : uni/userext/radiusext/radiusprovider-10.1.1.51 name : 10.1.1.51 authPort : 1812 <--- default RADIUS auth port authProtocol : pap retries : 1 timeout : 5 epgDn : uni/tn-mgmt/mgmtp-default/oob-default <--- management EPG
التحقق من موفري LDAP
انتقل إلى Admin > AAA > المصادقة > LDAP > موفري LDAP.
apic1# moquery -c aaaLdapProvider dn : uni/userext/ldapext/ldapprovider-10.1.1.52 name : 10.1.1.52 port : 389 <--- 389 for LDAP, 636 for LDAPS enableSSL : no rootdn : CN=binduser,CN=Users,DC=example,DC=com basedn : CN=Users,DC=example,DC=com filter : sAMAccountName=$userid attribute : memberOf <--- attribute used for group map epgDn : uni/tn-mgmt/mgmtp-default/oob-default <--- management EPG
أخطاء تكوين AAA الشائعة
- عدم تطابق سري مشترك — لا يتطابق المفتاح الذي تم تكوينه على ACI TACACS+ أو موفر RADIUS مع المفتاح الموجود على الخادم. تفشل المصادقة دون توقف.
- EPG إدارة خاطئة —
epgDnيكون الموفر فارغا أو يشير إلى EPG غير صحيح (على سبيل المثال، داخل النطاق الترددي عندما يكون الخادم على شبكة OOB). يتعذر على APIC الوصول إلى الخادم. - مجال تسجيل الدخول غير متطابق — يتم تكوين مجال تسجيل الدخول ك LDAP ولكن المستخدم يتوقع مصادقة TACACS+. يجب أن تشير مجالات تسجيل الدخول إلى نوع مجموعة الموفر الصحيح.
- DN ربط LDAP غير صحيح — ال
rootdn(bind DN) أوbasednخطأ. تفشل مصادقة LDAP مع حدوث خطأ ربط حتى عندما تكون بيانات اعتماد المستخدم صحيحة. - لا يتطابق عامل تصفية LDAP مع مخطط الدليل — ل Active Directory، أستخدم
sAMAccountName=$userid. ل OpenLDAP، أستخدمcn=$useridأوuid=$userid.
التحقق من تكوين RBAC
انتقل إلى Admin > AAA > Users لعرض حسابات المستخدمين المحليين ومجال الأمان الخاص بهم وتعيينات الأدوار.
استعلام مجالات الأمان عبر واجهة برمجة التطبيقات:
apic1# moquery -c aaaDomain # Built-in domains: dn : uni/userext/domain-all name : all <--- full fabric access dn : uni/userext/domain-common name : common <--- access to tenant common dn : uni/userext/domain-mgmt name : mgmt <--- access to tenant mgmt
يتمتع المستخدم المعين للمجال all with role admin بحق الوصول الكامل للقراءة والكتابة إلى البنية بأكملها. يمكن لمستخدم تم تعيينه إلى مجال أمان مخصص له دور Tenant-admin إدارة المستأجرين المقترنين بذلك المجال فقط.
التكوينات الخاطئة RBAC الشائعة
- المستخدم الذي تم إنشاؤه بدون مجال أمان — يمكن للمستخدم تسجيل الدخول ولكن لا يرى مستأجرين ويستلم "403 ممنوع" على مكالمات API. يجب تعيين مجال أمان واحد على الأقل.
- تم تعيين دور للقراءة فقط عند الحاجة إلى الوصول للكتابة — يمكن للمستخدم عرض الكائنات ولكن لا يمكنه إرسال التغييرات. تحقق من تعيين امتياز الدور إلى writePriv.
- تعيين دور المستخدم البعيد مفقود من خادم AAA — لا يرجع خادم TACACS+ أو RADIUS
cisco-av-pairالسمة التي تحتوي علىshell:domains=all/admin/. تتم مصادقة المستخدم بنجاح ولكن ليس له أدوار ولا يمكنه رؤية أي شيء في البنية.
أستكشاف أخطاء التشغيل خارج النطاق والإدارة داخل النطاق وإصلاحها
إذا لم يكن APIC أو IP الخاص بإدارة المحول يمكن الوصول إليه على الشبكة، فعليك أستكشاف أخطاء مسار الإدارة وإصلاحها قبل التحقق من SSH أو HTTPS أو AAA.
السيناريو: يتعذر إختبار اتصال APIC OOB IP
المشكلة: يتعذر على محطة الإدارة إختبار اتصال عنوان IP الخاص بإدارة APIC OOB.
خطوات التحقق:
- تحقق من أن منفذ إدارة APIC متصل ماديا وأن الارتباط قيد التشغيل.
- تحقق من أن محطة الإدارة موجودة على نفس مقطع L2 أو أنها تحتوي على مسار إلى الشبكة الفرعية OOB.
- تحقق من تعيين IP الخاص بإدارة OOB بشكل صحيح:
apic1# ifconfig oobmgmt oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.1.1.1 netmask 255.255.255.224 broadcast 10.1.1.31 - دققت التقصير مدخل reachable:
apic1# netstat -rn | grep oobmgmt 0.0.0.0 10.1.1.97 0.0.0.0 UG 0 0 0 oobmgmt 10.1.1.96 0.0.0.0 255.255.255.224 U 0 0 0 oobmgmt
- إذا تم تطبيق عقد خارج المكتب، فتحقق من أنه يسمح بالبروتوكولات المطلوبة. استعلم من OOB EPG الذي قدم العقود كما هو موضح في قسم "التحقق من العقود خارج النطاق". يتم فرض عقود OOB كقواعد
iptablesعلى APIC. يمكنك عرض القواعد المحفوظة من طبقة APIC:apic1# cat /etc/sysconfig/iptables | grep -A 20 "filter"
إذا كان نهج الإدخال هو DROP ولا توجد قاعدة ACCEPT للبروتوكول المطلوب، فإن العقد خارج النطاق (OOB) يقوم بتصفية حركة المرور.
السبب الجذري: عنوان إدارة OOB مفقود أو غير مكون بشكل صحيح أو عبارة غير صحيحة أو حركة مرور تصفية عقد OOB.
الحل: قم بتصحيح تعيين عنوان خارج النطاق (OOB) أو التحقق من مسار الشبكة الفعلي أو تحديث عقد خارج النطاق (OOB) للسماح بالبروتوكولات المطلوبة.
السيناريو: لا يمكن الوصول إلى IP لإدارة المحول
المشكلة: يمكن لمحطة الإدارة الوصول إلى APIC ولكن لا يمكنها الوصول إلى محول عبر OOB.
خطوات التحقق:
- تحقق من أن المحول يحتوي على عنوان OOB تم تعيينه:
apic1# moquery -c mgmtRsOoBStNode -x 'query-target-filter=eq(mgmtRsOoBStNode.tDn,"topology/pod-1/node-101")' dn : uni/tn-mgmt/mgmtp-default/oob-default/rsooBStNode-[topology/pod-1/node-101] addr : 10.1.1.101/27 gw : 10.1.1.97
- تحقق من أن واجهة إدارة المحول تحتوي على عنوان IP المعين:
leaf101# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 20:db:ea:14:42:54 inet addr:10.1.1.101 Bcast:10.1.1.127 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 - دققت الإدارة VRF تقصير ممر:
leaf101# ip route show default via 10.1.1.97 dev eth0 10.1.1.96/27 dev eth0 proto kernel scope link src 10.1.1.101
السبب الجذري: تعيين عنوان OOB مفقود، عبارة غير صحيحة، أو المنفذ المادي لإدارة المحول معطل.
الحل: قم بتعيين عنوان OOB تحت المستأجرين > الإدارة > عناوين إدارة العقد. تحقق من أن إرتباط الإدارة الفعلية قيد التشغيل.
أستكشاف أخطاء وصول SSH وإصلاحها
يغطي هذا القسم السيناريوهات التي يمكن فيها الوصول إلى عنوان IP الخاص بالإدارة (ينجح إختبار الاتصال) ولكن فشل جلسة SSH في إنشاء أو مصادقة.
السيناريو: تم رفض اتصال SSH
المشكلة: يبلغ عميل SSH عن "رفض الاتصال" عند الاتصال ب APIC أو المحول.
خطوات التحقق:
- تحقق من تمكين بروتوكول SSH في نهج الوصول إلى الإدارة:
apic1# moquery -c commSsh -x 'query-target-filter=eq(commSsh.adminSt,"enabled")' dn : uni/fabric/comm-default/ssh adminSt : enabled port : 22
إذا تم
adminStتعطيل إتصالات SSH، فسيتم رفض إتصالات SSH. - تحقق من إستخدام المنفذ الصحيح. إذا تم تغيير منفذ SSH من 22:
$ ssh -p custom-port admin@10.1.1.1
- تحقق من أن عقد OOB يسمح ب TCP على منفذ SSH. يرجى الرجوع إلى قسم "التحقق من العقود خارج النطاق".
السبب الجذري: تم تعطيل SSH في نهج الوصول إلى الإدارة أو المنفذ المخصص غير المعروف للعميل أو تصفية العقد خارج النطاق (OOB).
الحل: قم بتمكين SSH في سياسة الوصول إلى الإدارة أو أستخدم المنفذ الصحيح.
السيناريو: فشل تبادل مفتاح SSH (تشفير أو عدم تطابق KEX)
المشكلة: يفشل عميل SSH مع "لم يتم العثور على تشفير مطابق"، أو "لم يتم العثور على طريقة تبادل مفاتيح مطابقة"، أو "لم يتم العثور على MAC مطابق".
خطوات التحقق:
- تحقق من إخراج المطبعة الاحتياطية لعميل SSH لتحديد الخوارزميات التي يقدمها العميل:
$ ssh -vv admin@10.1.1.1 debug2: KEX algorithms: curve25519-sha256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ssh-ed25519,rsa-sha2-512,rsa-sha2-256 debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr debug2: MACs ctos: hmac-sha2-256,hmac-sha1
- قارن بين الخوارزميات التي يقدمها العميل والخوارزميات التي يتم تكوينها بواسطة APIC:
apic1# moquery -c commSsh sshCiphers : aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com kexAlgos : curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 sshMacs : hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512 hostkeyAlgos : rsa-sha2-256,rsa-sha2-512,ssh-ed25519
- تعرف على التقاطع. في حالة عدم وجود خوارزمية شائعة في أي فئة، تفشل المصافحة.
السبب الجذري: لا يوجد تشفير مشترك أو خوارزمية KEX أو MAC بين عميل SSH و APIC بعد ترقية ACI أو تقوية التشفير.
الحل: قم بتحديث عميل SSH لدعم الخوارزميات الحديثة، أو إعادة إضافة الخوارزمية القديمة المطلوبة إلى نهج الوصول إلى الإدارة. إن إعادة إضافة الخوارزميات القديمة تشكل خطرا على الأمان ولا يوصى بها على المدى البعيد.
السيناريو: يتصل SSH ولكن تفشل المصادقة للمستخدمين المحليين
المشكلة: ينجح تأكيد اتصال SSH (تظهر مطالبة كلمة المرور) ولكن يتم رفض كلمة المرور للمستخدم المحلي.
خطوات التحقق:
- تحقق من وجود المستخدم محليا:
apic1# moquery -c aaaUser -x 'query-target-filter=eq(aaaUser.name,"admin")' dn : uni/userext/user-admin name : admin accountStatus : active <--- must be active, not inactive or locked
- التحقق من تأمين الحساب بسبب محاولات تسجيل الدخول الفاشلة الزائدة:
apic1# moquery -c aaaUserEp dn : uni/userext pwdStrengthCheck : no
تحقق من سياسة تأمين مجال تسجيل الدخول تحت Admin > AAA > إدارة الأمان > سياسة التأمين.
- تحقق من تسجيل دخول المستخدم باستخدام مجال تسجيل الدخول الصحيح. إذا تم تعيين نطاق المصادقة الافتراضي على مجال تسجيل دخول AAA بعيد، فيجب على المستخدم الإعداد
apic:LOCAL\\usernameأوapic:fallback\\usernameمن أجل فرض المصادقة المحلية. - التحقق من صحة نتيجة المصادقة في السجلات. تحقق
nginx.bin.logمن APIC لحدث تسجيل الدخول:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'admin' | tail -20
ابحث عن النطاق ومجموعة الموفر التي تم تعيينها لمحاولة تسجيل الدخول:
! Working — Successful local authentication via the fallback domain (Realm 0 = fallback/local): ||aaa||INFO||Received PAM authenticate request from nginx for Username: apic#fallback\\admin ||aaa||INFO||auth-domain realm = local, LocalUser admin ||aaa||DBG4||Decoded username string to Domain: fallback Username: admin Realm 0, PG ||aaa||DBG4||Found password for local Username: apic#fallback\\admin ||aaa||DBG4||Calling UpdateLastLogin method for user: apic#fallback\\admin ! Not Working — Login was sent to the LDAP realm because the Default Authentication Realm is set to LDAP. ! The admin user does not exist in the LDAP directory, so the LDAP search returns empty and the login is denied: ||aaa||INFO||Received PAM authenticate request from nginx for Username: apic#LDAP-Domain\\admin ||aaa||DBG4||Decoded username string to Domain: LDAP-Domain Username: admin Realm 3, PG LDAP-Domain ||aaa||DBG4||Adding LdapProvider ldap-server.example.com to the list, order 1 ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=admin ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=admin returned empty set ||aaa||INFO||User apic#LDAP-Domain\\admin was denied during AAA authentication ||aaa||DBG4||Setting error LDAP/AD Server Authentication DENIED ||aaa||ERROR||Unauthorized Username: admin error: LDAP/AD Server Authentication DENIED
إذا لم يكن النطاق 0 (إحتياطي/محلي)، فسيتم إرسال تسجيل الدخول إلى خادم AAA بعيد بدلا من قاعدة البيانات المحلية. يجب أن يقوم المستخدم بالإعداد
apic:fallback\\usernameأوapic:LOCAL\\usernameلفرض المصادقة المحلية.
السبب الجذري: يتم إرسال كلمة مرور غير صحيحة أو حساب مؤمن أو محاولة تسجيل الدخول إلى خادم AAA بعيد بدلا من قاعدة البيانات المحلية.
الحل: قم بإعادة تعيين كلمة المرور أو إلغاء تأمين الحساب أو أستخدم بادئة مجال تسجيل الدخول الصحيحة.
أستكشاف أخطاء وصول HTTPS وإصلاحها
يغطي هذا القسم السيناريوهات التي يتعذر فيها الوصول إلى واجهة برمجة تطبيقات نقل الحالة (REST) الخاصة ب APIC على ويب أو واجهة برمجة تطبيقات نقل الحالة التمثيلية (REST) عبر HTTPS.
السيناريو: انتهت مهلة اتصال HTTPS
المشكلة: يعرض المستعرض "err_connection_timed_out" أو توقف إستدعاء API عند الاتصال ب APIC على المنفذ 443.
خطوات التحقق:
- تحقق من تمكين HTTPS:
apic1# moquery -c commHttps -x 'query-target-filter=eq(commHttps.adminSt,"enabled")' dn : uni/fabric/comm-default/https adminSt : enabled port : 443
- تحقق من أن عقد OOB يسمح ب TCP 443. الرجاء الإشارة إلى القسم "التحقق من العقود غير المحمية (OOB)".
- إختبار من APIC نفسه لتأكيد عملية HTTPS هو الاستماع:
apic1# ss -tlnp | grep 443 LISTEN 0 128 *:443 *:* users:(("nginx",pid=12345,fd=6))
السبب الجذري: HTTPS معطل، OOB عقد ييصفي TCP 443، أو ال nginx عملية على ال APIC تحطمت.
الحل: قم بتمكين HTTPS في نهج الوصول إلى الإدارة أو تحديث عقد OOB أو إعادة تشغيل خدمة ويب على APIC.
السيناريو: يعرض المستعرض خطأ مصافحة TLS
المشكلة: يعرض المستعرض "err_ssl_version_or_cipher_mismatch" أو خطأ TLS مماثلا.
خطوات التحقق:
- تحقق من إصدار بروتوكول TLS الذي تم تكوينه على APIC:
apic1# moquery -c commHttps sslProtocols : TLSv1.2
- تحقق من دعم المستعرض ل TLSv1.2. لا تدعم المستعرضات القديمة جدا (على سبيل المثال، Internet Explorer 10 وما قبله) TLSv1.2 بشكل افتراضي.
السبب الجذري: تعرض APIC TLSv1.2 (الافتراضي) فقط ويدعم المستعرض أو عميل API إصدارات TLS القديمة فقط.
الحل: قم بتحديث المستعرض أو العميل. إذا كان يجب عليك دعم العملاء الأقدم مؤقتا، فقم بإضافة TLSv1.1 إلى نهج الوصول للإدارة، ولكن هذا يقدم مخاطر أمنية.
السيناريو: تقييد تقييد تقييد تقييد تقييد واجهة برمجة التطبيقات
المشكلة: فشل مكالمات REST API بشكل متقطع مع أخطاء HTTP 503 أو تصبح واجهة مستخدم الويب بطيئة أثناء التشغيل التلقائي المكثف.
خطوات التحقق:
apic1# moquery -c commHttps throttleSt : enabled throttleRate : 2 <--- requests per second per user
إذا كان معدل الكبح منخفضا جدا وكانت البرامج النصية للأتمتة ترسل العديد من الطلبات في الثانية، فإن APIC يرفض الطلبات الزائدة.
السبب الجذري: معدل الكبح لكل مستخدم منخفض جدا لأعباء عمل التشغيل التلقائي.
الحل: قم بزيادة معدل الكبح بموجب نهج الوصول للإدارة، أو قم بتحسين برامج التشغيل التلقائي النصية من أجل تقليل تكرار الطلب. بدلا من ذلك، قم بتعطيل التحكم في حالة عدم مشاركة البنية.
أستكشاف أخطاء المصادقة والتفويض والمحاسبة (AAA) وإصلاحها — TACACS+
يغطي هذا القسم حالات فشل مصادقة TACACS+. تتصل APIC بخادم TACACS+ عبر منفذ TCP رقم 49.
التحقق العملي
لا تدعم محولات ACI الأمر test aaa المتوفر على NX-OS المستقل. للتحقق من عملية TACACS+، أستخدم واجهة برمجة التطبيقات (APIC) للتحقق من حالة الموفر والأخطاء ومحفوظات جلسات تسجيل الدخول.
تحقق من وجود أخطاء نشطة في موفر TACACS+:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'
إذا لم يتم إرجاع أية أخطاء، فإن APIC يعتبر الموفر قابلا للوصول إليه. إذا كانت الأخطاء موجودة، فإن الإخراج يتضمن أكواد الأعطال مثل F1773 (يتعذر الوصول إلى الموفر) أو F1774 (فشل المصادقة).
تحقق من تكوين موفر TACACS+:
apic1# moquery -c aaaTacacsPlusProvider dn : uni/userext/tacacsext/tacacsplusprovider-10.1.1.50 name : 10.1.1.50 authProtocol : pap port : 49 epgDn : uni/tn-mgmt/mgmtp-default/oob-default
تحقق من إمكانية الوصول إلى الشبكة الأساسية من APIC إلى خادم TACACS+:
apic1# ping 10.1.1.50 PING 10.1.1.50 (10.1.1.50): 56 data bytes 64 bytes from 10.1.1.50: icmp_seq=0 ttl=64 time=0.5 ms
حاول تسجيل الدخول إلى APIC باستخدام مجال تسجيل الدخول إلى TACACS+ وحدد نتيجة جلسة العمل:
apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5
ابحث في descr الحقل لتحديد ما إذا كان الفشل بسبب رفض المصادقة أو مشكلة في الاتصال.
تحقق من صحة تدفق مصادقة TACACS+ في سجلات APIC. تصفية اسم المستخدم المعني:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
تتبع عمليات تسجيل دخول TACACS+ نفس تدفق nginx.bin.log المصادقة مثل LDAP (راجع قسم التحقق من تشغيل LDAP للحصول على أمثلة كاملة للسجل الحقيقي). فيما يلي الفروق الرئيسية ل TACACS+:
يحدد DefaultAuthMo النطاق 2— المجال 2 يشير إلى TACACS+ (مقابل النطاق 3 ل LDAP).إضافة <ip> TacacsProvider إلى القائمة— يحدد خادم TACACS+ الذي يتم الاتصال به (مقابلLdapProviderل LDAP).TACACS+ Cisco-avpair (shell:domains=all/admin/)— يتم إرجاع زوج AV مباشرة بواسطة خادم TACACS+ (مقابل يتم تحويله من خريطة مجموعة LDAP).
يظهر تسجيل دخول TACACS+ ناجح نفس التقدم: تحديد نطاق طلب → PAM → الموفر بحث → تحليل زوج AV → المستخدم → UserDomain وتعيين الدور → امتيازات كتابة المسؤول.
ينتهي تسجيل دخول TACACS+ الفاشل ب <username> المستخدم أثناء مصادقة AAA وغير المصرح به ... الخطأ: تم رفض مصادقة خادم AAA، وهو نفس نمط رفض LDAP.
السيناريو: فشلت مصادقة TACACS+
المشكلة: يفشل تسجيل الدخول مع "فشل المصادقة" عندما يحدد المستخدم مجال تسجيل دخول TACACS+.
خطوات التحقق:
- تحقق من وجود أخطاء نشطة في موفر TACACS+:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'
يشير الخطأ F1773 إلى وجود مشكلة في الاتصال. يشير الخطأ F1774 إلى رفض المصادقة.
- تحقق من إمكانية الوصول إلى الشبكة من APIC إلى خادم TACACS+:
apic1# ping 10.1.1.50 PING 10.1.1.50 (10.1.1.50): 56 data bytes 64 bytes from 10.1.1.50: icmp_seq=0 ttl=64 time=0.5 ms
- إذا نجح إختبار الاتصال ولكن فشلت المصادقة، فتحقق من التطابقات السرية المشتركة على كل من تكوين موفر APIC وتكوين خادم TACACS+.
- تحقق من أحدث جلسات عمل تسجيل الدخول للاطلاع على تفاصيل الفشل:
apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5
- تحقق من سجلات خادم TACACS+ لإجراء محاولة المصادقة. تشير محاولة ناجحة تم تسجيلها على الخادم ولكن تم رفضها إلى وجود مشكلة في تكوين المستخدم على جانب الخادم (على سبيل المثال، عدم تطابق كلمة المرور أو فقدان حساب المستخدم).
- تحقق من APIC
nginx.bin.logللحصول على تدفق المصادقة الكامل. التصفية حسب اسم المستخدم بدلا من كلمات أساسية محددة حتى لا يتم فقد الرسائل الوسيطة:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'tacuser1' | tail -20
قارن الناتج بالنماذج العملية وغير العاملة في قسم التحقق التشغيلي أعلاه. المؤشرات الرئيسية:
تم رفضهأورفضه— تم الوصول إلى خادم TACACS+ ولكنه رفض بيانات الاعتماد. تحقق من وجود المستخدم على الخادم ومن تطابق كلمة المرور.- لا توجد رسائل خاصة بالمزود بعد
إضافة TacacsProvider— يتعذر الوصول إلى الخادم أو انتهت مهلته. تحقق من قابلية الوصول إلى الشبكة و EPG للإدارة. تم إكمال عملية حقن المستخدم البعيدمتبوعة بخطوط فحص الدور — نجحت المصادقة ولكن يمكن أن تكون المشكلة مع تعيين الدور (راجع قسم زوج AV أدناه).
TACACS+ زوج-AV من Cisco ل RBAC
بالنسبة للمستخدمين البعيدين الذين تمت مصادقتهم عبر TACACS+، يجب على الخادم إرجاع cisco-av-pair السمة في إستجابة التخويل. تقوم هذه السمة بتعيين المستخدم إلى مجالات أمان ACI وأدواره.
التنسيق:
shell:domains=domain/role/
الأمثلة:
- المسؤول الكامل:
shell:domains=all/admin/ - للقراءة فقط للجميع:
shell:domains=all/read-all/ - مسؤول المستأجر لمجال محدد:
shell:domains=TenantA/tenant-admin/ - مجالات متعددة:
shell:domains=all/admin/,TenantA/tenant-admin/
إذا كانت هذه السمة مفقودة أو غير مكونة بشكل صحيح، تتم مصادقة المستخدم بنجاح ولكن ليس له أي أدوار ولا يمكنه رؤية أي كائنات في واجهة مستخدم APIC.
تحقق من صحة زوج AV الذي تم إستلامه عن طريق التحقق nginx.bin.log. التصفية حسب اسم المستخدم لعرض تدفق حقن الدور بالكامل:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
بالنسبة إلى TACACS+، يتم تسجيل زوج AV ك TACACS+ Cisco-avpair (shell:domain=..). تظهر عملية حقن ناجحة أن حقن المستخدم البعيد <username> تم إكماله متبوعا Found UserDomain وAdmin write privileges lines (راجع قسم التحقق من تشغيل LDAP للحصول على أمثلة كاملة من هذا التدفق مع إخراج سجل حقيقي).
إذا كان تنسيق زوج AV غير صالح، فسيعرض السجل عملية حقن بيانات <username> للمستخدم البعيد التي فشلت - رسالة الخطأ هي shell:domain string غير صالحة. إذا قام المستخدم بالمصادقة باستخدام دور غير مسؤول، يتم رفض SSH إلى المحولات مع تسجيل دخول غير مسؤول على المحول.
السبب الجذري: عدم تطابق سري مشترك أو خادم يتعذر الوصول إليه من شبكة الإدارة أو أن المستخدم غير موجود على خادم TACACS+ أو أن EPG الخاص بالإدارة على الموفر غير صحيح.
الحل: قم بتصحيح السر المشترك أو إصلاح إمكانية الوصول أو إنشاء المستخدم على خادم TACACS+.
التحقق من صحة سجلات مصادقة محول الورق
في محولات الورقة والعمود الرئيسي، يتم تسجيل أحداث تسجيل دخول SSH في كل من pam.module.log و nginx.log. تعرض pam.module.log نتيجة مصادقة PAM (قبول أو رفض). يحتوي nginx.log على تدفق AAA الكامل — تحديد النطاق، بحث الموفر، اتصال LDAP/TACACS+/RADIUS، تحليل زوج AV، وتعيين الدور — مطابق nginx.bin.log لما هو موجود في APIC. تنطبق هذه السجلات على جميع أنواع AAA البعيدة (TACACS+، RADIUS، LDAP).
التحقق pam.module.log من نتيجة المصادقة:
leaf101# cat /var/sysmgr/tmp_logs/pam.module.log | tail -30
العمل — مصادقة عن بعد ناجحة على المحول:
||pam||INFO||Received pamauth request for jsmith ||pam||INFO||User: jsmith, rhost: 10.1.1.50, tty: ssh ||pam||INFO||Connecting to default PAM socket path /var/run/mgmt/socket/pam ||pam||INFO||Securitymgr is ALIVE ||pam||INFO||Connection successful - attempting to authenticate user jsmith client ssh ||pam||INFO||Sent authentication credentials (total pkt len 58) ||pam||INFO||Received authentication response from PAM server ||pam||INFO||User jsmith from 10.1.1.50 authenticated by securitymgrAG with UNIX user id 16004 ||pam||INFO||pam_putenv username=jsmith ||pam||INFO||pam_putenv remote=1 ||pam||INFO||pam_putenv unix_user_id=16004 ||pam||INFO||pam_putenv groupuid=15374 ||pam||INFO||returning success
remote=1 تؤكد العلامة أن المستخدم قد تمت مصادقته من قبل خادم AAA بعيد.
لا يعمل — تم رفض المستخدم. ينكر ال securityMgrAG المستعمل والمفتاح يحاول محلي مستعمل بحث كإحتياطي نهائي:
||pam||INFO||Received pamauth request for baduser ||pam||INFO||User: baduser, rhost: 10.1.1.50, tty: ssh ||pam||INFO||Connection successful - attempting to authenticate user baduser client ssh ||pam||INFO||ERROR: securitymgrAG rejected user baduser from 10.1.1.50 ||pam||INFO||You entered user baduser ...attempting to match against local users ||pam||INFO||Username baduser is not a special local auth user
إذا لم تظهر أية إدخالات PAM للمستخدم على الإطلاق، فمن المحتمل أن يكون اتصال SSH قد تم رفضه قبل الوصول إلى مرحلة PAM (على سبيل المثال، بسبب عدم تطابق التشفير أو قيام المستخدم بإلغاء الاتصال).
للحصول على عرض أكثر تفصيلا لتدفق المصادقة على المحول، تحقق nginx.log. يحتوي هذا السجل على سلسلة قرارات AAA الكاملة — نفس التنسيق والرسائل الموجودة nginx.bin.log في APIC:
leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'username' | tail -20
العمل — مصادقة LDAP الناجحة على محول ما (مقارنة بأمثلة APIC LDAP في قسم التحقق من تشغيل LDAP — الرسائل هي نفسها):
||aaa||INFO||Received PAM authenticate request from nginx for Username: jsmith ||aaa||DBG4||Decoded username string to Domain: Username: jsmith Realm 3, PG LDAP-Domain ||aaa||DBG4||Username: jsmith does not exist locally ||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of jsmith (address 10.1.1.100, hostname ssh) ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=jsmith ||aaa||INFO||LDAP Record DN : CN=jsmith,CN=Users,DC=example,DC=com ||aaa||DBG4||Bind to UserDN CN=jsmith,CN=Users,DC=example,DC=com using user password successful ||aaa||INFO||User AAA authentication was successful ||aaa||DBG4||Injection of remote user jsmith was completed ||aaa||DBG4||Checking all UserDomains under remote Username: jsmith ||aaa||DBG4||Found UserDomain all under remote Username: jsmith ||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user
يكون المحول nginx.log مفيدا بشكل خاص عند pam.module.log إظهار رفض ولكنه لا يشرح السبب. يكشف nginx.log عن سبب فشل AAA والمزود ومحدد (على سبيل المثال، أرجع بحث LDAP قيمة فارغة، مهلة TACACS+، أو فشل حقن زوج AV).
أستكشاف أخطاء AAA وإصلاحها — RADIUS
يغطي هذا القسم حالات فشل مصادقة RADIUS. تتصل APIC بخادم RADIUS عبر منفذ UDP 1812 (المصادقة) ومنفذ UDP 1813 (المحاسبة) إختياريا.
التحقق العملي
لا تدعم محولات ACI الأمر test aaa المتوفر على NX-OS المستقل. أستخدم الطرق التالية للتحقق من عملية RADIUS.
تحقق من إحصائيات تكوين خادم RADIUS وإمكانية الوصول إليه من محول طرفي:
leaf101# show radius-server
timeout value:5
retransmission count:3
deadtime value:0
source interface:any available
total number of servers:1
following RADIUS servers are configured:
10.1.1.51:
available for authentication on port: 1812
Radius shared secret:********
timeout:5
retries:1
السيناريو: فشلت مصادقة RADIUS
المشكلة: يفشل تسجيل الدخول عندما يحدد المستخدم مجال تسجيل الدخول إلى RADIUS.
خطوات التحقق:
- تحقق من إحصائيات خادم RADIUS من المحول للتعرف على علامات انتهاء المهلة أو الفشل:
leaf101# show radius-server statistics 10.1.1.51 Authentication Statistics failed transactions: 0 sucessfull transactions: 5 requests sent: 5 requests timed out: 0
يشير العدد الكبير تحت الطلبات التي انتهت مهلتها إلى أن خادم RADIUS غير قابل للوصول أو أن السر المشترك غير مطابق (يقوم RADIUS بإسقاط الحزم بصمت على عدم تطابق سري مشترك).
- تحقق من إمكانية الوصول إلى الشبكة إلى خادم RADIUS:
apic1# ping 10.1.1.51 PING 10.1.1.51 (10.1.1.51): 56 data bytes 64 bytes from 10.1.1.51: icmp_seq=0 ttl=64 time=0.5 ms
- تحقق من التطابقات السرية المشتركة بين APIC وخادم RADIUS. وعلى عكس TACACS+ الذي يستخدم بروتوكول TCP ويبلغ عن حالات فشل الاتصال، يستخدم RADIUS بروتوكول UDP ويقوم بإسقاط الحزم بصمت عندما يكون السر المشترك غير متطابق. العرض الوحيد هو المهلة.
- تحقق من سجلات خادم RADIUS. يعرض FreeRADIUS في وضع تصحيح الأخطاء (
radiusd -X) كل طلب ويشير إلى ما إذا كان قد تم قبوله أو رفضه أو لديه عدم تطابق سري مشترك. - تحقق من
nginx.bin.logAPIC لتدفق مصادقة RADIUS. التصفية حسب اسم المستخدم:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
تتبع عمليات تسجيل الدخول إلى RADIUS نفس
nginx.bin.logتدفق المصادقة مثل LDAP و TACACS+ (راجع قسم التحقق من تشغيل LDAP للحصول على أمثلة كاملة على السجل الحقيقي). فيما يلي الفروق الأساسية ل RADIUS:إضافة RadiusProvider <IP> إلى القائمة— يحدد خادم RADIUS (مقابلTacacsProviderأوLdapProvider).- يختلف رقم النطاق ل RADIUS حسب التكوين.
ينتهي تسجيل الدخول الناجح إلى RADIUS
بحقن المستخدم البعيد ... وقد تمإكمالامتيازات الكتابة للمسؤول.ينتهي تسجيل دخول RADIUS الفاشل
مع رفض أثناء مصادقة AAAورفض.إذا لم تظهر أي رسائل خاصة ب RADIUS بعد سطر
إضافة RadiusProvider، تكون مهلة الخادم منتهية. وعلى عكس TACACS+ الذي يستخدم بروتوكول TCP ويبلغ عن حالات فشل الاتصال، يستخدم RADIUS بروتوكول UDP ويقوم بإسقاط الحزم بصمت عندما يكون السر المشترك غير متطابق. والعرض الوحيد هو المهلة التي يتبعها الإنكار. - التحقق من وجود أخطاء نشطة في موفر RADIUS:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"radiusprovider")'
زوج RADIUS Cisco-AV ل RBAC
يستخدم RADIUS نفس cisco-av-pair سمة TACACS+ لتعيين دور RBAC. يجب أن يرجع خادم RADIUS هذه السمة في إستجابة قبول الوصول:
# FreeRADIUS users file entry:
labadmin Cleartext-Password := "password"
Cisco-AVPair = "shell:domains=all/admin/"
في FreeRADIUS، يتم تكوين هذا في الملف أو users الخلفية LDAP. بالنسبة إلى ISE، يتم تكوينها ضمن ملف تعريف التخويل كسمة متقدمة.
السبب الجذري: عدم تطابق سري مشترك (الأكثر شيوعا مع RADIUS — يتسبب في حالات انتهاء المهلة الصامتة)، أو يتعذر الوصول إلى الخادم، أو منفذ مصادقة غير صحيح، أو يفتقد حساب المستخدم على خادم RADIUS.
الحل: صححت ال يشارك سر، دققت udp 1812 reachability، أو شكلت المستعمل على ال RADIUS نادل.
أستكشاف أخطاء AAA وإصلاحها — LDAP
يغطي هذا القسم حالات فشل مصادقة LDAP. يتصل APIC بخادم LDAP عبر TCP منفذ 389 (LDAP) أو منفذ TCP 636 (LDAPs مع SSL).
التحقق العملي
لا تدعم محولات ACI الأمر test aaa المتوفر على NX-OS المستقل. للتحقق من عملية LDAP، تحقق من أخطاء الموفر والتكوين من APIC.
التحقق من وجود أخطاء نشطة في موفر LDAP:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'
يشير العطل F1777 إلى وجود مشكلة في الاتصال. يشير الخطأ F1778 إلى المصادقة أو فشل الربط. إذا لم يتم إرجاع أية أخطاء، فإن APIC يعتبر الموفر قابلا للوصول إليه.
التحقق من إمكانية الوصول إلى الشبكة الأساسية لخادم LDAP:
apic1# ping 10.1.1.52 PING 10.1.1.52 (10.1.1.52): 56 data bytes 64 bytes from 10.1.1.52: icmp_seq=0 ttl=64 time=0.5 ms
بالنسبة ل LDAP، تحقق أيضا من اتصال TCP بالمنفذ 389 (أو 636 ل LDAPs). إذا كان بإمكان APIC إختبار اتصال الخادم مع إستمرار أخطاء LDAP، فإن المشكلة تكون عادة DN ربط غير صحيح أو كلمة مرور خاطئة أو جدار حماية يمنع منفذ LDAP.
تحقق من صحة تدفق مصادقة LDAP في سجلات APIC. التصفية حسب اسم المستخدم:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
العمل — يظهر تسجيل دخول LDAP بنجاح تدفق البحث الكامل والربط وتعيين الأدوار:
||aaa||INFO||Received PAM authenticate request from nginx for Username: jsmith ||aaa||DBG4||DefaultAuthMo specifies realm 3. Provider Group LDAP-Domain ! ||aaa||DBG4||Decoded username string to Domain: Username: jsmith Realm 3, PG LDAP-Domain ||aaa||DBG4||Username: jsmith does not exist locally ||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of jsmith (address 10.1.1.50, hostname ssh) ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=jsmith ||aaa||INFO||LDAP Record DN : CN=jsmith,CN=Users,DC=example,DC=com ||aaa||DBG4||Bind to UserDN CN=jsmith,CN=Users,DC=example,DC=com using user password successful ||aaa||DBG4|| Adding WriteRole: admin ||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/ ||aaa||DBG4||Injection of remote user jsmith was completed ||aaa||DBG4||Checking all UserDomains under remote Username: jsmith ||aaa||DBG4||Found UserDomain all under remote Username: jsmith ||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user
لا يعمل — لم يتم العثور على المستخدم في دليل LDAP (يقوم البحث بإرجاع مجموعة فارغة):
||aaa||INFO||Received PAM authenticate request from nginx for Username: baduser ||aaa||DBG4||Decoded username string to Domain: Username: baduser Realm 3, PG LDAP-Domain ||aaa||DBG4||Username: baduser does not exist locally ||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of baduser (address 10.1.1.50, hostname REST) ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser returned empty set ||aaa||INFO||User baduser was denied during AAA authentication ||aaa||ERROR||Unauthorized Username: baduser error: LDAP/AD Server Authentication DENIED
السيناريو: فشلت مصادقة LDAP
المشكلة: يفشل تسجيل الدخول عندما يحدد المستخدم مجال تسجيل دخول LDAP.
خطوات التحقق:
- التحقق من إمكانية الوصول إلى خادم LDAP من APIC:
apic1# ping 10.1.1.52 PING 10.1.1.52 (10.1.1.52): 56 data bytes 64 bytes from 10.1.1.52: icmp_seq=0 ttl=64 time=0.5 ms
- التحقق من وجود أخطاء نشطة في موفر LDAP:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'
- التحقق من تكوين موفر LDAP:
apic1# moquery -c aaaLdapProvider -x 'query-target-filter=eq(aaaLdapProvider.name,"10.1.1.52")' rootdn : CN=binduser,CN=Users,DC=example,DC=com <--- bind DN basedn : CN=Users,DC=example,DC=com <--- search base filter : sAMAccountName=$userid <--- search filter attribute : memberOf <--- group mapping attribute enableSSL : no <--- LDAP vs LDAPS port : 389
- تحقق من وجود المستخدم في دليل LDAP ضمن DN الأساسي الذي تم تكوينه وتطابق عامل التصفية. بالنسبة لخدمة Active Directory، يجب أن تتطابق
sAMAccountNameسمة المستخدم مع اسم المستخدم الذي تم إدخاله عند تسجيل الدخول. بالنسبة ل OpenLDAP، يجب أن تكون السمةcnأوuidمطابقة. - إذا كنت تستخدم LDAPs (منفذ 636)، فتحقق من سلسلة شهادات SSL. إذا تم
SSLValidationLevelتعيينها على مقيد، سترفض APIC الاتصال إذا لم تكن شهادة الخادم موثوق بها أو انتهت صلاحيتها. - تحقق من APIC
nginx.bin.logللحصول على تدفق مصادقة LDAP الكامل. التصفية حسب اسم المستخدم حتى لا يتم فقد الرسائل الوسيطة:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
قارن الناتج بالنماذج العملية وغير العاملة في قسم التحقق التشغيلي أعلاه. يمكن العثور على أنماط فشل إضافية خاصة ب LDAP من خلال البحث في السجل بشكل عام:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'LDAP\|ldap' | tail -20
الأنماط الشائعة غير العاملة (قارن بأمثلة التحقق من العمليات الواردة أعلاه للتدفق الكامل):
! Not Working — User not found (wrong baseDn, wrong filter, or user does not exist). ! Real example — "baduser" does not exist in the LDAP directory: ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser ||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser returned empty set ||aaa||INFO||User baduser was denied during AAA authentication ||aaa||ERROR||Unauthorized Username: baduser error: LDAP/AD Server Authentication DENIED
أنماط فشل LDAP الأخرى للبحث عنها:
- انتهت مهلة بحث LDAP (منفذ حظر جدار الحماية أو المنفذ غير القابل للوصول إلى الخادم أو بطيء أو 389/636) —
فشلالبحث عنLDAP:رمز الإرجاع ل ldap_search_ext_s:-5:انتهت المهلة - فشل الربط (اسم مصدر أو كلمة مرور ربط غير صحيحة، أو رفض الخادم الاتصال) —
فشلالبحث عنLDAP:رمز الإرجاع ل ldap_search_ext_s:-1:يتعذر الاتصال بخادم LDAP - تم العثور على المستخدم ولكن كلمة المرور غير صحيحة (الربط مع فشل كلمة مرور المستخدم) — يظهر السجل سطر
LDAP Record DNولكن يتبعه رسالة مرفوضة بدونربط ب UserDN..سطرناجح.
- انتهت مهلة بحث LDAP (منفذ حظر جدار الحماية أو المنفذ غير القابل للوصول إلى الخادم أو بطيء أو 389/636) —
خريطة مجموعة LDAP ل RBAC
يستخدم LDAP خرائط المجموعة بدلا من cisco-av-pair السمة. يحدد حقل موفر LDAP attribute سمة LDAP التي تحتوي على معلومات المجموعة. بالنسبة لخدمة Active Directory، يكون هذا عادة memberOf.
يتطابق APIC مع DN المجموعة التي تم إرجاعها مقابل قواعد خريطة مجموعة LDAP التي تم تكوينها (aaaLdapGroupMapRule) لتعيين مجال الأمان والدور المناسبين. في حالة عدم تطابق قاعدة تعيين مجموعة، يقوم المستخدم بمصادقة ولكن ليس لديه أدوار.
بدلا من ذلك، يمكنك ضبط attribute القيمة إلى CiscoAVPair وتخزين shell:domains=all/admin/ مباشرة في سمات LDAP الخاصة بالمستخدم، والتي تتبع نفس تنسيق TACACS+ و RADIUS.
السبب الجذري: DN أو كلمة مرور الربط غير صحيحة، ولا يحتوي DN الأساسي على المستخدم، ولا يتطابق عامل تصفية البحث مع مخطط الدليل، أو فشل التحقق من صحة شهادة LDAP، أو قواعد تعيين المجموعة المفقودة.
الحل: قم بتصحيح تكوين الموفر (ربط DN و DN الأساسي و عامل التصفية و SSL). بالنسبة لمشاكل RBAC، تحقق من مطابقة قواعد خريطة المجموعة لمجموعات LDAP التي ينتمي إليها المستخدم.
أستكشاف أخطاء RBAC وامتيازات المستخدم وإصلاحها
يغطي هذا القسم السيناريوهات التي يقوم فيها المستخدم بالمصادقة بنجاح ولكنه لا يملك مستوى الوصول المتوقع.
السيناريو: المستخدم الذي قام بتسجيل الدخول ولكنه لا يرى أي مستأجرين
المشكلة: يقوم المستخدم البعيد بتسجيل الدخول عبر بروتوكول TACACS+ أو RADIUS أو LDAP. ينجح تسجيل الدخول، ولكن المستخدم لا يرى أي مستأجرين في مكالمات واجهة المستخدم وواجهة برمجة التطبيقات يعيدون نتائج فارغة أو "403 ممنوع".
خطوات التحقق:
- تحقق من جلسة عمل المستخدم لمعرفة الأدوار التي تم تعيينها عند تسجيل الدخول:
apic1# moquery -c aaaSessionLR -x 'query-target-filter=wcard(aaaSessionLR.descr,"jsmith")' -x 'order-by=aaaSessionLR.created|desc' -x page-size=1 dn : subj-[uni/userext/remoteuser-jsmith]/sess-123456789 descr : [user jsmith] From-10.1.1.100-client-type-https-Success
يعرض
descrالحقل نتيجة تسجيل الدخول. إذا تمت مصادقة المستخدم بنجاح ولكن ليس لديه أدوار RBAC، فإن خادم AAA لم يرجع تطابق خريطة مجموعة LDAP صالحcisco-av-pairأو LDAP. - تحقق من APIC
nginx.bin.logللاطلاع على زوج AV وتعيين الدور أثناء تسجيل الدخول. التصفية حسب اسم المستخدم:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
ابحث عن رسائل حقن الدور وتعيين المجال:
العمل — زوج AV محول من خريطة مجموعة LDAP، يحصل المستخدم على دور المسؤول:
||aaa||DBG4|| Adding WriteRole: admin ||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/ ||aaa||DBG4||Injection of remote user jsmith was completed ||aaa||DBG4||Checking all UserDomains under remote Username: jsmith ||aaa||DBG4||Found UserDomain all under remote Username: jsmith ||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user
لا يعمل — إذا لم يظهر سطر
Cisco-avpairأوConverted to CiscoAVPairفي التدفق، فإن خادم AAA لم يرجع السمة ولم تتطابق قاعدة خريطة مجموعة LDAP. ابحث عنهاChecking all UserDomainsبدونFound UserDomainبنود تتابعها — تمت مصادقة المستخدم ولكن ليس لديه تعيينات أدوار. إذا ظهرتInjection ... data FAILEDرسالة، فإن تنسيق سلسلة زوج AV غير صحيح. - تحقق من إرجاع خادم AAA
cisco-av-pairللسمة (ل TACACS+ أو RADIUS) أو عضوية مجموعة LDAP الصحيحة (ل LDAP). تحقق من تكوين خادم AAA:- TACACS+: تحقق من تضمين ملف تعريف المستخدم
cisco-av-pairبالتنسيقshell:domains=all/admin/. - RADIUS: تحقق من مرتجعات ملف تعريف المستخدم
Cisco-AVPair = "shell:domains=all/admin/"في Access-Accept. - LDAP: تحقق من أن المستخدم عضو في مجموعة LDAP التي تطابق قاعدة خريطة مجموعة LDAP (
aaaLdapGroupMapRule) التي تم تكوينها.
- TACACS+: تحقق من تضمين ملف تعريف المستخدم
- إذا كانت السمة موجودة ولكن لا يزال المستخدم لا يملك حق الوصول، تحقق من مطابقة اسم مجال الأمان في السمة لمجال أمان موجود على APIC:
apic1# moquery -c aaaDomain
إذا كانت المراجع
cisco-av-pairتشير إلى مجال غير موجود (على سبيل المثال،shell:domains=NonExistentDomain/admin/)، فإن تعيين الدور يفشل بصمت.
السبب الجذري: لا يرجع خادم AAA سمات تعيين RBAC، أو تنسيق السمة غير صحيح، أو أن مجال الأمان المشار إليه في السمة غير موجود على APIC.
الحل: قم بتكوين خادم AAA لإرجاع تعيين المجموعة cisco-av-pair أو الصحيح. تحقق من وجود مجال الأمان على APIC.
السيناريو: يمكن للمستخدم عرض التكوين ولكن لا يمكنه تعديله
المشكلة: يمكن للمستخدم تسجيل الدخول وتصفح الكائنات ولكنه يستلم خطأ عند محاولة إرسال التغييرات.
خطوات التحقق:
- تحقق من تعيينات دور المستخدم:
apic1# moquery -c aaaUserRole -x 'query-target-filter=wcard(aaaUserRole.dn,"user-jsmith")' dn : uni/userext/user-jsmith/userdomain-all/role-read-all name : read-all privType : readPriv <--- read only, no write privilege
- إذا كان المستخدم بحاجة إلى وصول للكتابة، يجب منح الدور
writePriv. تتضمن الأدوار المشتركة ذات امتيازات الكتابة admin وtenant-admin وaccess-admin وfabric-admin. - التحقق من صحة تعيين الدور في سجلات APIC. التصفية حسب اسم المستخدم:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
ابحث عن رسائل تعيين الدور بالقرب من نهاية تدفق المصادقة:
العمل — للمستخدم دور الكتابة للمسؤول (من تسجيل دخول LDAP حقيقي):
||aaa||DBG4||Checking all UserDomains under remote Username: jsmith ||aaa||DBG4||Found UserDomain all under remote Username: jsmith ||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user
لا يعمل — إذا كان السجل يظهر
UserRole غير المسؤولبامتيازاتالقراءةبدلا منامتيازات الكتابة للمسؤول، فإن المستخدم لديه دور للقراءة فقط ولا يمكنه تعديل التكوين. ابحث عن سطور مثل:||aaa||DBG4||Found non-admin UserRole read-all (read privileges) under UserDomain all
إذا كان السجل يظهر
امتيازات القراءةفقط وبدونامتيازات الكتابة، فقم بتحديث دور المستخدم أو زوج الصوت/الفيديو على خادم AAA.
السبب الجذري: للمستخدم دور للقراءة فقط (على سبيل المثال، read-all أو ops) بدلا من دور يمكنه الكتابة.
الحل: قم بتحديث تعيين دور المستخدم على APIC (للمستخدمين المحليين) أو قم بتحديث خادم AAA cisco-av-pair (للمستخدمين البعيدين) لتضمين دور له امتيازات الكتابة.
السيناريو: يستطيع المستخدم الوصول إلى بعض المستأجرين دون الآخرين
المشكلة: يستطيع المستخدم رؤية مستأجر واحد وإدارته ولكنه لا يستطيع رؤية المستأجرين الآخرين، حتى ولو كانوا بحاجة إلى الوصول.
خطوات التحقق:
- تحقق من تعيين مجال أمان المستخدم:
apic1# moquery -c aaaUserDomain -x 'query-target-filter=wcard(aaaUserDomain.dn,"user-jsmith")' dn : uni/userext/user-jsmith/userdomain-TenantA name : TenantA <--- only has access to TenantA
- تعيين مجالات الأمان إلى المستأجرين. إذا كان المستخدم بحاجة إلى الوصول إلى TenantB، فيجب أيضا تعيينه إلى مجال الأمان المقترن ب TenantB، أو تعيينه إلى مجال all.
- بالنسبة للمستخدمين عن بعد، قم بتأكيد زوج AV أو خريطة مجموعة LDAP التي تقوم بتعيين المجالات الصحيحة. تحقق من APIC
nginx.bin.logلتعيين المجال عند تسجيل الدخول. التصفية حسب اسم المستخدم:apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
العمل — يتلقى المستخدم المجال بأكمله (إمكانية الرؤية الكاملة)، من تسجيل دخول LDAP الحقيقي:
||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/ ||aaa||DBG4||Injection of remote user jsmith was completed ||aaa||DBG4||Found UserDomain all under remote Username: jsmith ||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user
لا يعمل — إذا كان لدى المستخدم مجال مستأجر واحد فقط، يظهر هذا المجال فقط في
Found UserDomainالرسائل بدلا من الكل. على سبيل المثال،Found UserDomain TenantAيعني أن المستخدم يمكنه فقط رؤية TenantA. يحتاج المستخدم مجالات إضافية تمت إضافتها إلى زوج AV على خادم AAA، أو مجال all للوصول الكامل.
السبب الجذري: يتم تعيين المستخدم إلى مجال أمان مقيد يغطي مستأجرين محددين فقط.
الحل: قم بإضافة مجالات الأمان المطلوبة إلى تكوين المستخدم، أو أستخدم مجال all للوصول الكامل.
إسترداد كلمة المرور والوصول إلى الطوارئ
إذا تم تأمين جميع حسابات المسؤولين أو كان خادم AAA البعيد غير قابل للوصول وتم تغيير النطاق الافتراضي، فاستخدم أحد أساليب الاسترداد التالية:
مجال تسجيل الدخول الاحتياطي
توفر واجهة التحكم في الوصول (ACI) مجال تسجيل دخول إحتياطي مضمن يستخدم المصادقة المحلية دائما، بغض النظر عن نطاق المصادقة الافتراضي. لاستعمالها:
- بروتوكول النقل الآمن (SSH): قم بتسجيل الدخول باسم
apic:fallback\\admin(أوapic#fallback\\adminحسب الإصدار). - GUI: في القائمة المنسدلة المجال على شاشة تسجيل الدخول، حدد إحتياطي واستخدم بيانات الاعتماد المحلية.
الوصول إلى وحدة التحكم
إذا تم تعيين نطاق مصادقة وحدة التحكم على محلي (الافتراضي)، يمكنك دائما تسجيل الدخول عبر منفذ وحدة تحكم APIC باستخدام بيانات الاعتماد المحلية. إذا كانت كلمة مرور المسؤول المحلي غير معروفة، يمكن إعادة ضبط كلمة المرور من خلال وحدة التحكم في الإدارة المتكاملة (CIMC) من Cisco (لواجهات برمجة التطبيقات المادية) أو وحدة تحكم برنامج hypervisor (لواجهات برمجة التطبيقات الظاهرية).
مرجع الأخطاء الشائعة
عادة ما تكون أخطاء قائمة التحكم في الوصول (ACI) التالية مرتبطة بالوصول عن بعد ومشكلات AAA:
- F1773 — مشكلة في اتصال موفر TACACS+. يتعذر على APIC الوصول إلى خادم TACACS+.
- F1774 — فشل مصادقة TACACS+. يمكن الوصول إلى الخادم ولكنه رفض محاولة المصادقة.
- F1775 — مشكلة في اتصال موفر RADIUS.
- F1776 — فشل مصادقة RADIUS.
- F1777 — مشكلة في اتصال موفر LDAP.
- F1778 — فشل مصادقة LDAP.
- F0532 — لم يتم تكوين الشبكة الفرعية للإدارة لعقدة.
الاستعلام عن أخطاء AAA النشطة:
apic1# moquery -c faultInst -x 'query-target-filter=or(wcard(faultInst.dn,"tacacsplusprovider"),wcard(faultInst.dn,"radiusprovider"),wcard(faultInst.dn,"ldapprovider"))'
المراجع
- أستكشاف أخطاء إدارة قائمة التحكم في الوصول (ACI) والخدمات الأساسية وإصلاحها — سياسات POD
- دليل التكوين الأساسي ل Cisco APIC، الإصدار 6.1(x) — الإدارة
- دليل تكوين أمان واجهة برمجة التطبيقات من Cisco — الوصول والمصادقة والمحاسبة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
09-Apr-2026
|
الإصدار الأولي |
التعليقات