نناقش في هذه الورقة كيف يمكن استخدام خادم مركزي للمصادقة على الهويات مثل ACS والبروتوكولات التي يستخدمها في التعامل مع عملاؤه والذين يمثلون أجهزة التوجيه (Routers) والتبديل (Switches).
تستخدم معظم المؤسسات المتوسطة والكبيرة التي تتعامل مع أجهزة سيسكو خوادم ACS وذلك حتى تتمكن من إدارة المستخدمين مركزيا والتحكم فيما يؤذن لهؤلاء المستخدمين أن يقوموا به. فمن خلال الإعداد وإضافة المستخدمين محليا على خادم ACS ومن ثم إعداد العشرات أو المئات من أجهزة التوجيه والتبديل من العمل كعملاء لخادم ACS والذي يقوم بدور مركز للمصادقة على هويات وصلاحيات المستخدمين. فبهذه الطريقة يمكن إنشاء حساب مستخدم مرة واحدة على خادم ACS وإعداد أجهزة التوجيه والتبديل لاستخدام هذا الخادم لأيٍ من المستخدمين سواء كان مسؤولا يحاول الوصول إلى جهاز التوجيه من أجل الإعدادات أو مستخدما عادياً يحتاج فقط إلى الوصول من خلال جهاز توجيه لبعض تطبيقات الشبكة أو الخدمات مثل تصفح الويب. إذا كانت جميع أجهزة الشبكة تستخدم نفس خادم ACS فهذا يعني عدم الحاجة إلى إنشاء حساب المستخدم نفسه على كل قاعدة بيانات محلية من أجهزة التوجيه والتبديل الفردية.
معظم المؤسسات التي تستخدم خوادم ACS لديها العديد من المستخدمين وبطبيعة الحال سيستغرق إنشاء حسابات لجميع المستخدمين بشكل يدوي في خادم ACS الكثير من الوقت والجهد ولذلك تتمثل إحدى الميزات المريحة لخادم ACS في أنه يمكن الاستغناء عن الاعداد المحلي على خادم ACS وبدلا من ذلك يمكن استخدام قاعدة بيانات خارجية موجودة بالفعل وتحتوي على أسماء المستخدمين وكلمات مرورهم مثل Microsoft Active Directory والتي تحوي بالفعل جميع المستخدمين وبياناتهم. وتسير سلسلة الأحداث على شيئ من هذا القبيل: يتصل المستخدم بجهاز توجيه ويطلب جهاز التوجيه منه بيانات المصادقة فلو افترضنا أن المستخدم هذا هو مسؤول الشبكة ويريد الوصول إلى واجهة سطر الأوامر CLI في جهاز التوجيه هنا سيطلب جهاز التوجيه والذي تم إعداده لاستخدام خادم ACS من هذا المستخدم (المسؤول) اسم المستخدم وكلمة المرور الخاصة به وبعد الحصول عليهما يرسل جهاز التوجيه هذه البيانات إلى خادم ACS وينتظر الرد. في خادم ACS إذا كان الإعداد تم لاستخدام قاعدة بيانات خارجية مثل Microsoft Active Directory فسيقوم خادم ACS بطلب الاستفسار من Active Directory للتحقق مما إذا كان اسم المستخدم وكلمة المرور التي قدمها المستخدم صحيحة ودقيقة. فإذا كانت كذلك يمكن أن يشير الـ Active Directory إلى خادم ACS بصحة البيانات ومن ثم يشير خادم ACS بدوره إلى جهاز التوجيه بأن بيانات الاعتماد صحيحة ، ومن ثم يمكن لجهاز التوجيه إعداد وصول المستخدم. أما إذا لم يكن هناك Active Directory فإن خادم ACS سيدقق الإعدادات المحلية الخاص به للتحقق من اسم المستخدم وكلمة المرور بدلا من تسليمهما إلى Active Directory وهذا هو كل شيء باختصار.
على أي منصة تعمل ACS؟
لدى خوادم ACS العديد من الصور المختلفة فهناك الإصدارات القديمة والتي يمكن تثبيتها في خادم ويندوز الموجود، كما يمكن شراء جهاز مادي مخصص من Cisco يتم تثبيته في موقع العميل يحوي برنامج ACS مثبت مسبقا، والخيار الأكثر شعبية حالياً هو تثبيت خادم ACS في بيئة VMware مثل خادم ESXi. بغض النظر عن الخيار المتبع إلا أن الوظيفة الأساسية لوجود قاعدة بيانات مركزية للمستخدمين وقواعد الترخيص بشأن ما يسمح للمستخدمين بالقيام به هي الهدف الأساسي لـ ACS.
ما هو ISE؟
منتج محرك خدمات الهوية (Identity Services Engine) يعتبر منصة لسياسة التحكم في الهوية والوصول بحيث يمكنها التحقق من أن الكمبيوتر يلبي متطلبات سياسة المؤسسة وذلك قبل السماح للجهاز بالوجود على الشبكة. يستفيد هذا الحل من العديد من الميزات الشبيهة ب AAA (المصادقة (Authentication) والتفويض (Authorization) والمحاسبة (Accounting))، ولكنه ليس بديل تماماً عن ACS.
البروتوكولات المستخدمة بين خادم ACS وجهاز التوجيه
هناك بروتوكولين رئيسيين يستخدمان بين خادم ACS وعميله (مثل جهاز التوجيه) وهما TACACS+ و RADIUS
كانت هناك إصدارات سابقة من TACACS+ وكان لها أسماء مختلفة قليلا مثل XTACACS وTACACS (بدون +). وأما الآن فإن الإصدار الوحيد المستخدم هو TACACS+ والذي يعتبر ملكية خاصة لشركة Cisco مما يعني أنه من المرجح أن ينظر إلى استخدامها الأساسي على أنه بروتوكول يستخدم بين جهاز Cisco وخادم Cisco ACS. إذا تم إعداد جهاز التوجيه وخادم ACS لاستخدام TACACS+ فإن جميع حزم AAA التي يتم إرسالها بين جهاز التوجيه وخادم ACS تستخدم بروتوكول TACACS+ والذي يقوم بتشفير كل حزمة قبل إرسالها على الشبكة. أما البروتوكول الآخر الذي يمكن استخدامه بين جهاز التوجيه وخادم ACS لغرض خدمات AAA هو RADIUS وهو معيار مفتوح مما يعني أنه مدعوم من قبل تطبيقات البائعين الآخرين لـ AAA وخوادمهم (مثل Microsoft) يمكن أن تدعم الاتصالات مع عميل (مثل جهاز التوجيه) باستخدام هذا البروتوكول. يقوم RADIUS بتشفير كلمات المرور فقط ولكن ليس الحزمة بأكملها التي يتم إرسالها بين خادم ACS وجهاز الشبكة.
خيارات البروتوكول بين خادم ACS والعميل (جهاز التوجيه)
من الممارسات الشائعة في حال القيام بالمصادقة والإذن للمسؤولين بالوصول إلى سطر الأوامر فمن المحتمل أن تقوم بإعداد TACACS+ على كل من خادم ACS وجهاز التوجيه لتواصلهما مع بعضهما البعض. ويرجع سبب ذلك هو أن TACACS+ قد حددت بوضوح التقنيات والإعدادات لكل جانب من جوانب AAA. على سبيل المثال عند الرغبة في جعل جهاز التوجيه يقوم بالتحقق من التفويض لكل أمر من الأوامر قبل السماح للمسؤول بتنفيذه وإعطاء المسؤول مجموعة فرعية فقط من الأوامر، فإن TACACS+ يسمح بالتحكم الشديد في توصيل الأوامر التي سيتم السماح بها بينما لا يحتوي RADIUS على نفس مستوى التحكم هذا. إذا كنت تقوم بالمصادقة على المستخدمين النهائيين الذين يريدون فقط أن تمر حزمهم عبر جهاز الشبكة (عند الحاجة إلى المصادقة والتفويض) فقد يكون الخيار المناسب هو استخدام RADIUS كطريقة اتصال بين خادم ACS على جهاز التوجيه. يمكنك تكوين جهاز التوجيه وخادم ACS لاستخدام كل من TACACS+ وRADIUS في وقت واحد بين خادم ACS وعميله، جهاز التوجيه.
| TACACS+ | RADIUS |
الوظيفة | يفصل AAA عن بعضها البعض فالمصادقة منفصلة عن التفويض وكلاهما منفصل عن المحاسبة. | يجمع بين العديد من وظائف المصادقة والتفويض. ولديه قدرة عالية ومفصلة في جانب المحاسبة. |
المعيار | مملوكة لـ Cisco | معيار مفتوح ومدعوم من قبل جميع البائعين تقريبا |
بروتوكول الطبقة الرابعة | TCP | UDP |
السرية | يتم تشفير جميع الحزم بين الخادم وجهاز التوجيه | يتم تشفير كلمة المرور فقط فيما يتعلق بالحزم المرسلة ذهابا وإيابا بين الخادم وجهاز التوجيه. |
التحكم على مستوى أمر دقيق فيما يخص التفويض | مدعوم، ويتم تعريف القواعد على خادم ACS حول الأوامر المسموح بها أو غير المسموح بها. | لا يمكن تنفيذ قواعد صريحة للتحقق من تفويض الأوامر. |
المحاسبة | يوفر الدعم للمحاسبة | يوفر الدعم للمحاسبة بشكل أكثر تفصيلا أو شمولا |
إعداد أجهزة التوجيه للتعامل مع خادم ACS
يغطي هذا الجزء الأوامر التفصيلية المطلوبة لجهاز التوجيه ليكون قادر على التعامل مع خادم مصادقة مركزي مثل ACS. فمما سبق عرفنا أنه يجب القيام بالإعدادات اللازمة لكل من خادم ACS الذي سيكون لديه أسماء المستخدمين وكلمات مرورهم وجهاز التوجيه الذي سيتواصل معه. والحديث هنا سيكون منصب على جهاز التوجيه. من المهم تذكر أن جهاز التوجيه يمكنه استخدام قاعدة بياناته المحلية للتحقق من اسم المستخدم وكلمة المرور أو يمكنه الاستفادة من خادم ACS للتحقق من صحة اسم المستخدم وكلمة المرور. ولإكمال الإعدادات على جهاز التوجيه يمكن استخدام CLI أو Cisco Configuration Professional (CCP). ونظرا زننا قد نحتاج إلى كليهما اعتمادا على بيئة العمل فسيتم تغطية كلتا الطريقتين هنا بمشيئة الله تعالى. سنتعرف أولا على العمل مع الـ CLI ومن ثم الـ CCP.
كالعادة هناك عنصر رئيسي مهم في أي مشروع وهو وجود خطة قبل البدء في إعداد جهاز التوجيه فما هي الخطة هنا؟ نريد أن ينفذ جهاز التوجيه ما يلي:
■ بالنسبة للمسؤولين/ المستخدمين الذين يصلون إلى جهاز التوجيه عن بعد عبر الـ vty وبغض النظر عما إذا كانوا يستخدمون Telnet أو SSH يجب على جهاز التوجيه التحقق من خادم TACACS+ (خادم ACS الذي يستخدم TACACS+ للتواصل مع جهاز التوجيه هذا) لأغراض المصادقة (اسم المستخدم / كلمة المرور).
■ يجب أن يؤذن للمستخدمين المصادق عليهم بالوصول إلى جلسة واجهة سطر الأوامر CLI بما في ذلك مستوى الامتياز الذي ينبغي وضعهم فيه ويجب أيضاً إجراء فحص تفويض الصلاحيات بواسطة جهاز التوجيه
يتيح الأمر أدناه تمكين إعداد الـ AAA إذا كان في الإعدادات الافتراضية لجهاز التوجيه ممكن فلا داعي لكتابة مع ضرورة ملاحظة أنه في معظم أنظمة IOS يتم تعطيله بشكل افتراضي.
R1(config)# aaa new-model
طريقة المصادقة أدناه عند تطبيقها على الـ VTY فهي بمثابة الطلب من جهاز التوجيه للقيام بمطالبة المستخدم الذي يريد الوصول تقديم اسم مستخدم وكلمة مرور حتى يتمكن هذا المستخدم من تسجيل الدخول وعندما يقدمها المستخدم سيرسل جهاز التوجيه هذه البيانات إلى خادم TACACS+ الذي تم إعداده مسبقاً وبعد ذلك يقوم الخادم بالرد سواء بالموافقة أو الرفض. يشير هذا الأمر إلى أن الـ “group tacacs+” هي الطريقة الأولى بمعنى أنه يمكن أن يكون هناك أكثر من خادم واحد تم إعداده مسبقاً. وعليه سيبدأ جهاز التوجيه بالمحاولة مع الطريقة الأولى فإذا لم يكن هناك خادم ACS يستجيب وبعد مهلة قصيرة سيجرب جهاز التوجيه الطريقة الثانية في قائمة الطرق التي هي في مثالنا هذا “ local” مما يعني أن جهاز التوجيه سيتحقق بعد ذلك من إعداداته المحلية لمعرفة ما إذا كان هناك اسم مستخدم وكلمة مرور مطابقة.
R1(config)# aaa authentication login AUTHEN_via_TACACS group tacacs+ local
في الأمر أدناه ستؤدي قائمة طرق تفويض الصلاحيات عند تطبيقها إلى قيام جهاز التوجيه بالتحقق من خادم AAA للتأكد من كون المستخدم مخول للوصول إلى CLI وليس ذلك فقط بل يمكن كذلك معرفة مستوى الامتياز المعطى للمستخدم والذي يجب وضعه فيه. طبعاً من الواضح أنه يجب مسبقاً إعداد كل من اسم المستخدم وكلمة المرور على خادم ACS حتى تتم المصادقة ويجب كذلك مسبقاً إعداد ما يخص التفويض على نفس الخادم. ستستخدم قائمة التفويض في الأمر أدناه واحد أو أكثر من خوادم ACS التي تم إعدادها وإذا لم تكن هناك خوادم تستجيب فإن جهاز التوجيه سيقوم بالتحقق محليا فيما إذا كان الأمر مصرحا به لهذا الغرض وفق مستوى امتياز المستخدم.
R1(config)# aaa authorization exec Author-Exec_via_TACACS group tacacs+ local
من المهم جداً ملاحظة أنه قبل تطبيق أي من الأوامر السابقة على الـ VTY يجب أن ننشئ حساب لمستخدم محلي واحدا على الأقل كخطوة احتياطية في حالة عدم التمكن من الوصول إلى خادم ACS أو حال عدم إعداد الخادم بعد. في المثال أدناه تم إنشاء مستخدم على قاعدة البيانات المحلية لجهاز التوجيه تحوي اسم المستخدم وكلمة المرور بالإضافة إلى مستوى الامتياز لهذا المستخدم. طبعاً لا تنسَ أهمية استخدام كلمات مرور قوية عند إعداد حساب لأي مستخدم.
R1(config)# username admin privilege 15 secret cisco
نحتاج بعد ذلك إلى الأمر أدناه والذي يشير إلى وجود خادم ACS واحد على الأقل والذي يجب أن يحاول جهاز التوجيه استخدامه عبر TACACS+ وكما هو واضح يحوي الأمر كلمة مرور والتي يتم استخدامها كجزء من تشفير الحزم وأيًا كانت كلمة المرور التي نقوم بوضعها هنا يجب أن يتم وضعها أيضاً على خادم ACS
R1(config)# tacacs-server host 192.168.1.252 key cisco123
يعد التحقق من إمكانية الوصول إلى عناوين IP بمثابة اختبار يمكن إجراؤه حتى قبل اكتمال تكوين ACS الكامل على خادم AAA
R1(config)# do ping 192.168.1.252
بعد ذلك ولكي يتم استخدام قائمة طرق المصادقة وقائمة طرق التفويض يجب إعطاء أمر التطبيق وفي المثال أدناه سنقوم بالتطبيق على أول خمسة خطوط من الـ VTY
R1(config)# line vty 0 4
R1(config-line)# authorization exec Author-Exec_via_TACACS
R1(config-line)# login authentication AUTHEN_via_TACACS
سيخضع المستخدمون المتصلون بخطوط vty هذه الآن لكلٍ من المصادقة والتفويض وذلك استنادا إلى الأوامر التي تم تطبيقها على هذه الخطوط.
الآن وعند محاولة تسجيل الدخول من خلال أحد خطوط الـ vty الخمسة هذا ما يجب أن تتوقعه: ستتم مطالبتك باسم المستخدم وكلمة المرور ويجب ألا يكون جهاز التوجيه قادرا على إتمام ذلك بسبب بسيط هو لأنك لم تقم بعد بإعداد الجزء الخاص بخادم ACS، ثم بعد مهلة قصيرة سيستخدم جهاز التوجيه الطريقة الثانية في كل من قوائمه (قوائم المصادقة وقوائم التفويض للصلاحيات)، مما يشير إلى أنه سيستخدم قاعدة البيانات المحلية الخاصة به للمصادقة والتفويض ونظرا لأن لديك مستخدماً محلياً لديه كلمة مرور ومستوى امتياز مخصص يجب أن يعمل.
وعليه فإن ما حدث حتى الآن يمكن اختصاره في الجدول أدناه:
المهمة | كيفية القيام بها |
تحديد السياسة (مثلاً أي خطوط vty يجب أن تتطلب المصادقة/الإذن) وأي الطرق يجب استخدامها (خادم ACS، البيانات المحلية، لا شيء). | تتم هذه الخطوة قبل أن تبدأ في إعداد جهاز التوجيه وتستند بالدرجة الأولى إلى سياستك الأمنية للشبكة. |
تمكين القدرة على إعداد AAA | aaa new-model غير مفعلة افتراضيا. إذا كنت ترغب في استخدام خدمات ACS فيجب تمكين الـ AAA كخطوة أولى للإعداد على جهاز توجيه جديد. |
حدد عنوان خادم ACS لاستخدامه | استخدم الأمر tacacs-server host، مدرجاً به عنوان IP لخادم ACS وكلمة المرور. |
قم بإنشاء قائمة مسماة للطرق المرادة للمصادقة وأخرى للطرق المرادة للتفويض بناء على سياستك. | يتم إنشاء كل قائمة طريقة في وضع التكوين العام، مع تحديد الطرق التي تستخدمها هذه القائمة، بالترتيب، من اليسار إلى اليمين |
قم بتطبيق قوائم الطرق على الموقع الذي يجب أن يستخدمها. | في وضع تكوين خطوط الـ vty، حدد قوائم طرق المصادقة والتفويض التي قمت بإنشائها في الخطوة السابقة |
الآن وبعد الانتهاء من الإعدادات باستخدام CLI، سنلقي نظرة على تنفيذ ما قمنا به سابقاً ولكن باستخدام CCP.
بالنسبة لهذه الاعدادات، قمنا بإزالة كافة الأوامر المرتبطة بـ AAA ماعدا الأمر aaa new-model كنقطة بداية والغرض من الاعداد باستخدام CCP هو التعرف على واجهة المستخدم الرسومية (GUI) لمعرفة كيفية إعداد قوائم المصادقة والتفويض وكيفية تطبيقها على خطوط vty.
في جزء CCP وبعد تحديد جهاز التوجيه الذي نريد إعداده نقوم بالتالي :
انتقل إلى Configure> Router> AAA> AAA Servers and Groups> Servers ثم النقر على Add وتقديم المعلومات ذات الصلة بخادم ACS كما هو موضح أدناه :
ثم النقر فوق OK وأي متطلبات تأكيد أخرى يتم تقديمها لتطبيق الإعداد على جهاز التوجيه. والآن وبعد أن عرف جهاز التوجيه عنوان IP لخادم ACS والبروتوكول الذي يجب استخدامه وكلمة المرور المستخدمة لتشفير الحزم التي ترسل إلى الخادم تأتي الخطوة التالية وهي إنشاء قوائم الطرق المراد استخدامها تماماً كما كان الحال في CLI نقوم بإنشاء قائمة طرق للمصادقة على تسجيلات الدخول وقائمة أخرى لطرق لتفويض صلاحيات المستخدم. تحدد كل قائمة طرق ضرورة استخدام خادم ACS أولا وفي حال فشل خادم ACS لأي سبب من الأسباب فإن الطريقة الثانية التي يجب أن يستخدمها جهاز التوجيه هي الالتفات للاإعدادات المحلية. ولإنشاء قائمة الطرق للمصادقة في CCP نقوم بالتالي :
انتقل إلى Configure> Router> AAA> Authentication Policies> Login، والنقر فوق Add ، وتحديد تفاصيل قائمة طرق المصادقة بما في ذلك اسمها والطرق من البداية إلى النهاية التي ستستدعيها قائمة الطرق هذه. يبدو مربع الحوار مشابها لما هو موضح في الشكل أدناه فمن داخل النافذة المنبثقة يمكن زر Add من إضافة الطرق التي ستستخدمها القائمة هذه. هناك أيضا خيار نقل الطرق لأعلى أو لأسفل بناء على الترتيب الذي تريده في قائمة الطرق هذه. كما هو سابقاً يمكن النقر فوق زر OK وأي متطلبات تأكيد أخرى حتى يتم إعطاء الإعداد مكتملاً إلى جهاز التوجيه.
الآن وبعد إنشاء قائمة طرق المصادقة المرادة يمكن رؤية هذه القائمة وأي قوائم مصادقة أخرى تم إنشاؤها على نفس الشاشة كما هو موضح في الشكل المجاور وهذا يشمل الطرق بالترتيب من اليسار إلى اليمين.
والآن وبعد إنشاء قائمة طرق المصادقة نحتاج أيضا إلى إنشاء قائمة طرق التفويض وذلك استناداً إلى سياسة الشبكة التي نريد تطبيقها. مرة أخرى بالنسبة لهذا المثال فنحن ننفذ نفس السياسة السابقة التي نفذناها سابقاً باستخدام سطر الأوامر CLI. فلإنشاء قائمة طرق التفويض نقوم بالتالي :
انتقل إلى Configure> Router> AAA> Authorization Policies> EXEC Command Mode، وانقر فوق Add ، كما هو موضح في الشكل المجاور:
باستخدام عملية مماثلة لما تم مع قائمة الطرق الأولى نقوم باختيار User Defined (بمعنى أننا لن نقوم بجعل هذه الطرق كإعداد افتراضي عام ولكن جعلها محددة مثل أن تكون خاصة فقط بخطوط الـ vty). بالإضافة إلى تسمية قائمة طرق تفويض الصلاحيات يمكنك أيضا النقر فوق الزر ADD من هذه النافذة المنبثقة لتحديد الطرق التي يراد استخدامها وكما سبق النقر فوق الزر OK وأي متطلبات أخرى حتى يقوم CCP في النهاية بتسليم هذه الإعدادات إلى جهاز التوجيه وعند هذه النقطة يمكنك رؤية ملخص لقائمة طرق التفويض المعدة، كما هو موضح في الشكل المجاور.
في هذه المرحلة وبعد إعداد قائمة طرق للمصادقة وقائمة طريقة أخرى للتفويض حان الوقت لإعداد هذه القوائم من العمل. إلى هذه اللحظة تمثل هذه القوائم للطرق مجرد معلومات تستنزف مساحة في ذاكرة الجهاز فقط وإذا أردنا استخدامها فيجب أن نقوم بتطبيق هذه القوائم. الآن واستناداً إلى سياسة إدارة الشبكة نريد تطبيق قائمة الطرق للمصادقة وقائمة الطرق للتفويض على خطوط vty لجهاز التوجيه. ولتطبيق قوائم الطرق نترك قسم AAA وننتقل إلى Configure> Router> Router Access> VTY. ومن هناك انقر فوق Edit واستخدم المربع المنسدل لتحديد قوائم الطرق المراد استخدامها. قوائم الطرق الوحيدة الموجودة للمصادقة والتفويض هي تلك التي سبق إنشائها. وفي هذه الحالة نختار قوائم طرق المصادقة والتفويض التي أنشأناها سابقا كما هو موضح في الشكل المجاور:
انقر فوق OK وأي متطلبات أخرى حتى يقوم CCP بتصدير الإعداد إلى جهاز التوجيه. وبمجرد أن يتم ذلك فإنه يعرض ملخص لكيفية عمل خطوط vty كما هو موضح في الشكل المجاور:
في هذه المرحلة من الإعداد قد نتسبب لشيء من التعب إذا قمنا بتسجيل الخروج عن طريق الخطأ. إذا كنا متصلين عبر منفذ وحدة التحكم (Console) ، فقد الأمر أهون لأننا لم نقم بتطبيق تلك القوائم للطرق على منفذ الـ Console. ولكن لو كنا متصلين عن بعد باستخدام Telnet أو SSH، وكلاهما كما هو معروف يستخدم خطوط vty ، فقد لا نتمكن من إعادة الاتصال إذا تعذر الوصول لخادم ACS لأنه لم يتم إعداده بعد وحينها يتراجع جهاز التوجيه للبحث في الإعدادات المحلية له والتي لم نقم بعد بإنشائها فلا يوجد بعد مستخدم في قاعدة البيانات المحلية. والنصيحة المهمة والخطيرة هنا هي ضرورة التأكد من وجود حساب لمستخدم واحد على الأقل تم الإعداد المحلي لديه امتيازات إدارية عالية (privilege level 15) بحيث نستطيع دائماً الوصول إلى جهاز التوجيه. مر بنا سابقاً كيفية إنشاء حساب مستخدم من واجهة سطر الأوامر (CLI) ويجب معرفة القيام بذلك أيضاً هنا في CCP. فلإنشاء مستخدم محلي نقوم بما يلي:
انتقل إلى Configure> Router> Router Access> User Accounts/View وانقر فوق ADD ، كما هو موضح في الشكل المجاور.
يجب أن يحتوي حساب المستخدم هذا على كلمة مرور قوية وغير قابلة للتخمين. وبعد إضافة المعلومات بما في ذلك مستوى الامتياز 15، انقر فوق “OK” وأي متطلبات أخرى منبثقة للتأكيد حتى يقوم CCP بتسليم هذا الإعداد إلى جهاز التوجيه.
إعداد خادم ACS للتفاعل مع جهاز التوجيه
يغطي هذا القسم واجهة المستخدم الرسومية (GUI) الموجودة على خادم ACS، والتي تمكنه من الاتصال بالعملاء مثل جهاز التوجيه.
قبل فحص إعدادات خادم ACS نفسه لنراجع بعض الأشياء. يحتوي خادم ACS فعليًا على آلاف المنبهات والخيارات التي يمكن تهيئتها وضبطها والهدف هنا هو التأكد من وضوح المفهوم الأساسي المتمثل في أن خادم ACS يمكن أن يكون الخيار المركزي للمصادقة وللتفويض للمستخدمين ومستودع أيضاً للسجلات المحاسبية لما فعله هؤلاء المستخدمون بالفعل ويتضمن ذلك أي مسؤول أصدر الأوامر على أي جهاز.
أحد التحديات التي تواجهها المؤسسات الكبيرة هو وجود العديد من المسؤولين لكل منهم مجال مسؤولية مختلف عن الآخر. فقد يكون أحدهم مسؤولاً عن أجهزة التوجيه المحيطة التي تقوم بتشغيل zone-based firewall. قد يكون هناك مسؤول مختلف آخر عن أجهزة التوجيه التي توفر خدمات الـ (VPN) والقائمة تطول. وفي مثل هذه الظروف ليس من الحكمة منح كل مسؤول الحقوق الإدارية الكاملة لكل جهاز توجيه على حدة وإنما يفترض فقط توفير الوصول المحدود إلى الأفراد الذين يحتاجون إليه. فعلى سبيل المثال لا ينبغي أن يتمتع المسؤولون الذين يديرون أجهزة التوجيه المحيطة بكامل إمكانية الوصول إلى أجهزة الـ VPN التي لا يديرونها. وتحقيقاً لذلك يمكن لـ ACS تجميع أجهزة التوجيه في مجموعات منطقية تسمى مجموعات الأجهزة (device groups). وبهذه الطريقة يمكن وضع أجهزة توجيه معينة في مجموعة ثم عن طريق الـ ACS يمكن وضع المسؤولين عن أجهزة التوجيه في مجموعة مستخدمين (user group) ثم بعد ذلك نقوم بإسناد التفويضات المتضمنة للحقوق الإدارية للوصول لهذه المجموعة المحددة من أجهزة التوجيه. يتطلب هذا السيناريو بذل المزيد من الجهد للإعداد الأولي لـ ACS، ولكن بعد إعداده يمكن فقط إضافة مسؤولين جدد ووضعهم في مجموعات محددة داخل ACS وسيحصلون تلقائيًا على الحقوق ومستويات الوصول التي يحتاجون إليها.
المكونات الأساسية لإعداد ACS
مكون ACS | كيفية القيام بها |
مجموعات أجهزة الشبكة | مجموعات من أجهزة الشبكة، تعتمد عادة على أجهزة التوجيه أو التبديل والتي لها نفس الوظائف أو الأجهزة المماثلة والتي يديرها نفس المسؤولين. |
أجهزة الشبكة أو عملاء ACS (أجهزة التوجيه/التبديل) | أجهزة الشبكة الفردية والتي تدخل في مجموعات الأجهزة |
مجموعات الهوية (المستخدمين أو المسؤولين) | مجموعات من المسؤولين، تعتمد عادة على المستخدمين الذين سيحتاجون إلى حقوق مماثلة والوصول إلى مجموعات محددة من أجهزة الشبكة. |
حسابات المستخدمين | حسابات المستخدمين أو المسؤولين الفردية التي يتم وضعها في مجموعات الهوية. |
ملفات تعريف التفويض | تتحكم هذه الملفات في الحقوق المسموح بها. يرتبط الملف الشخصي بمجموعة أجهزة الشبكة ومجموعة هوية المستخدم/المسؤول. |
للتوضيح نقوم بإنشاء ما يلي:
■ (مجموعة الأجهزة) لأجهزة التوجيه الحدودية
■ (جهاز توجيه واحد) ينتمي إلى مجموعة الأجهزة
■ (مجموعتان) مجموعة الإدارة ومجموعة المراقبة
■ (مستخدمان) مسؤول ينتمي إلى مجموعة الإدارة ومستخدم لمكتب المساعدة ينتمي إلى مجموعة المراقبة
■ (سياستان للتفويض) الأولى معنية بأعضاء مجموعة الإدارة الذين يصلون إلى الأجهزة في مجموعة الأجهزة ويجب أن يحصلوا على امتياز الوصول الكامل أي المستوى 15، والسياسة الثانية معنية بالمستخدمين الأعضاء في مجموعة المراقبة وسيكون لديهم امتياز الوصول المستوى 1 فقط للأجهزة الموجودة في مجموعة الأجهزة
ومع وضع هذه السياسة في الاعتبار فإن أول شيء نقوم به هو الدخول على نافذة المتصفح من جهاز الحاسب المحلي الخاص إلى عنوان IP الخاص بخادم ACS. أو عنوان URL مثل https://a.b.c.d/acsadmin حيث a.b.c.d هو عنوان IP الفعلي للخدمات. عند التثبيت الجديد لـ ACS ستكون كلمة المرور الافتراضية هي default. وفي البداية يستخدم خادم ACS شهادة SSL موقعة ذاتياً وقد تحصل على نافذة منبثقة تسألك عما إذا كنت تريد تأكيد الجلسة على هذا الجهاز وعلى الرغم من أن متصفحك لا يثق في الشهادة إلا أنه يجب الموافقة والمتابعة لأجل إدارة خادم ACS.
يتطلب ACS المثبت حديثًا أيضاً الترخيص المناسب ويتم توفير معلومات الترخيص مع المنتج حين شراؤه.
الخطوة الأولى هي إنشاء مجموعة أجهزة. يمكنك القيام بذلك عن طريق الخطوات التالية:
Network Resources> Network Device Groups> Device Type والنقر فوق Create كما هو موضح في الشكل أدناه:
بعد إضافة معلومات هذه المجموعة انقر فوق Submit لتنفيذ مجموعة أجهزة الشبكة الجديدة. تكمن مشكلة مجموعة الأجهزة هذه في عدم وجود أجهزة شبكة فيها بشكل افتراضي ولمعالجة ذلك نضيف كمثال جهاز توجيه واحد (جهاز التوجيه الذي قمنا بإعداده مسبقاً) ليتم تضمينه في مجموعة أجهزة الشبكة هذه على خادم ACS. يتم ذلك عن طريق الانتقال إلى Network Resources> Network Devices and AAA Clients ومن ثم النقر فوق Create، كما هو موضح في الشكل المجاور:
في مربع الحوار هذا، انقر فوق الزر Select الموجود على يمين نوع الجهاز وحدد مجموعة الأجهزة التي تم إنشاؤها من الخطوة السابقة. بالإضافة إلى ذلك يمكن اختيار الاسم الذي سيتعرف خادم ACS على جهاز التوجيه من خلاله. ليس من الضروري أن يتطابق هذا الاسم مع الاسم الحقيقي لجهاز التوجيه ولكن من الجيد أن يتطابق حتى يتمكن أي شخص ينظر إلى إعدادات خادم ACS من معرفة العميل (جهاز التوجيه) الذي تتم الإشارة إليه. عنوان IP الخاص بهذا العميل (جهاز التوجيه) هو عنوان جهاز التوجيه الذي يمكن الوصول إليه من منظور خادم ACS. يؤدي النقر فوق المربع الموجود بجوار TACACS+ إلى السماح لـ ACS بمعرفة البروتوكول الذي يتوقعه من هذا العميل كما أن كلمة المرور الصحيحة التي تطابق كلمة المرور التي تم إعدادها مسبقاً على جهاز التوجيه مطلوب أيضاً لنجاح الاتصال. وبعد مراجعة المعلومات للتأكد من صحتها اضغط على Submit.
لقد قمنا بإنشاء مجموعة أجهزة شبكة (network device group) وأضفنا جهاز التوجيه R1 كأول جهاز شبكة (عميل ACS) في هذه المجموعة. الخطوة التالية هي إنشاء مجموعة مستخدمين (user group) ثم إنشاء بعض المستخدمين في تلك المجموعات. المجموعتان اللتان سنقوم بإنشائهما هما مجموعة الإدارة ومجموعة المراقبة. لإنشاء هذه المجموعات انتقل إلى Users and Identity Stores> Identity Groups وانقر على Create ، كما هو موضح في الشكل المجاور.
أكمل مربع الحوار بتقديم اسم المجموعة التي ستقوم بإنشائها ثم انقر فوق Submit . يمكنك تكرار هذه العملية لأي مجموعات إضافية أخرى. هنا تم إنشاء مجموعتين: إحداهما باسم Admin والأخرى باسم Monitor. بعد النقر فوق Submit ، يتم عرض ملخص لمجموعاتك الموجودة، كما هو موضح المجاور:
لا تحتوي هذه المجموعات الجديدة على أي مستخدمين بشكل افتراضي وليس لها أذونات خاصة بشكل افتراضي. وعليه فإن الخطوة الأولى الآن هي إنشاء حسابين لعدد اثنين من المستخدمين ووضع حساب مستخدم واحد على الأقل منهما في كل مجموعة. ولإنشاء مستخدمين نقوم بما يلي :
ننتقل إلى Users and Identity Stores> Internal Identity Stores> Users وانقر فوق Create ، كما هو موضح في الشكل المجاور:
بعد إدخال اسم المستخدم ووصفه (عند الرغبة في ذلك)، انقر فوق الزر Select من هذه النافذة المنبثقة لتحديد مجموعة المستخدمين التي تريد أن يكون هذا المستخدم عضواً فيها وكذلك تحديد كلمة المرور لهذا المسؤول ثم الضغط على Submit. في هذا المثال تم إنشاء مستخدم واحد باسم admin ينتمي إلى مجموعة الإدارة ومستخدم آخر يسمى help-desk والذي ينتمي إلى مجموعة المراقبة. وبعد النقر على Submit ، يتم عرض ملخص للمستخدمين الذين تم أعدادهم على خادم ACS كما هو موضح في الشكل المجاور:
والخطوة التالية هي وضع وإعداد سياسات التفويض التي تمنح الوصول الكامل للمستخدمين في مجموعة الإدارة الذين يحاولون الوصول إلى أجهزة التوجيه في مجموعة أجهزة الشبكة التي أنشأناها. كما نريد أيضاً منح وصول محدود للمستخدمين في مجموعة المراقبة الذين يحاولون الوصول إلى نفس هذه الأجهزة. يمكننا القيام بذلك من خلال سياسات التفويض. ولإنشاء السياسات نقوم بما يلي:
انتقل أولاً إلى Access Policies> Access Services> Default Device Admin> Authorization وانقر فوق Create ، كما هو موضح في الشكل المجاور
في مربع الحوار، قم بتحديد اسم هذه السياسة والتي تسمى في هذا المثال AdminRole وحدد المربع المجاور للشروط بجوار مجموعة الهوية (identity group) ، وانقر فوق الزر Select لاختيار مجموعة الإدارة التي تم إنشاؤها مسبقًا. استخدم نفس العملية، مع تحديد المربع الموجود بجوار نوع جهاز NDG بحيث يشير NDG إلى مجموعة أجهزة الشبكة (network device group) ثم استخدم الزر Select ، للإشارة إلى أن الجهاز ينتمي إلى مجموعة أجهزة التوجيه التي تم إنشاؤها مسبقاً.
يؤدي هذا الإعداد إلى إنشاء شرط هو أنه إذا كان مستخدم ما عضو في مجموعة الإدارة يحاول الوصول إلى جهاز ضمن مجموعة أجهزة توجيه معينة، فيمكن توفير وصول محدد ومقيد بناءً على ملف تعريف مخصص يمكن إعداده. وللقيام بذلك ننقر فوق الزر Select بجوار خيار ملف تعريف Shell، وستظهر الشاشة الموضحة أدناه. لاحظ أن ملفات تعريف Shell تُستخدم لأغراض التفويض وترتبط بسياسة التفويض (دور المسؤول في هذا المثال).
يمكن اختيار أحد ملفات التعريف التي تم تكوينها مسبقاً أو يمكن إنشاء ملف تعريف خاص وتعيينه لهذه المجموعة من المستخدمين. ولإنشاء ملف تعريف مخصص انقر فوق الزر Create، ومن النافذة الجديدة التي تظهر قم بتسمية ملف التعريف الجديد في مربع الحوار ، ثم قم بعرض علامة التبويب المهام الشائعة (Common Tasks) وقم بتغيير مستوى الامتياز الافتراضي إلى Static ، وقم بتعيين درجة مستوى الامتياز من 15، كما هو موضح في الشكل المجاور:
انقر فوق Submit، ثم قم بتأكيد أي مربعات حوار حتى يتم تطبيق الإعداد. باستخدام هذه الخطوات لن يتمكن أي مستخدم في مجموعة الإدارة يصل إلى أي من الأجهزة في مجموعة الأجهزة المحددة من المصادقة فقط، بل سيتم أيضًا السماح له بشكل تلقائي بأخذ صلاحيات مستوى الامتياز 15 بعد المصادقة بنجاح على أجهزة التوجيه هذه. نكرر هذه العملية لمجموعة المراقبة ونقوم بتعيين مستوى امتياز قدره 1.
بعد حفظ الإعدادات يمكن عرض ملخص لملفات تعريف التفويض. يوضح الشكل أدناه ملفي تعريف تفويض مخصصين يُطبّق أحدهما على المستخدمين الإداريين في مجموعة الإدارة والذين يصلون إلى الأجهزة في مجموعة أجهزة التوجيه ويُطبّق الآخر على مستخدمي help desk الذين هم أعضاء في مجموعة المراقبة والذين يصلون إلى نفس الأجهزة.
فيما سبق تم إنشاء مجموعات أجهزة وإضافة أجهزة توجيه إلى مجموعة الأجهزة تلك. وكذلك أنشاء مجموعات مستخدمين ووضع مستخدمين في تلك المجموعات. وبعد ذلك تم إنشاء ملفات تعريف مخصصة للتفويض تشير إلى الصلاحيات التي سيتم تطبيقها بناءً على المستخدمين والمجموعات التي تصل إلى الأجهزة. الجزء الأخير هو التحقق من أن كل شيء يعمل بشكل صحيح.
التحقق من خادم ACS واستكشاف الأخطاء وإصلاحها
نناقش هنا الأوامر التي تمكن من التحقق من استكشاف أخطاء AAA وإصلاحها عندما يستخدم جهاز التوجيه خادم ACS لمصادقة أو تفويض صلاحيات المستخدمين الذين يحاولون الاتصال بجهاز التوجيه.
إن فرص إعداد كل شيء بشكل مثالي من المرة الأولى على كل من جهاز التوجيه وخادم ACS للسماح لجهاز التوجيه باستدعاء خادم ACS لمصادقة المستخدمين وتفويض صلاحياتهم ليست متحققة دائماً إلا أن الممارسة ومهارات التوثيق الجيدة في إعدادات جهاز التوجيه وخادم ACS ستحسن الأداء.
بالعودة إلى جهاز التوجيه فإن أحد الأشياء الأولى التي قد ترغب في القيام بها إذا لم تكن قد قمت بذلك بالفعل هو التحقق من إمكانية الوصول بين جهاز التوجيه وخادم ACS وقد يتبادر إلى الذهن استخدام ping للتحقق من الاتصال كما هو موضح :
R1# ping 192.168.1.252
Sending 5, 100-byte ICMP Echos to 192.168.1.252, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/32 ms
R1#
إذا لم ينجح اختبار الاتصال فقد يكون ذلك بسبب تصفية التحكم في الوصول والتي تمنع بروتوكول رسائل التحكم في الإنترنت (ICMP) بين جهاز التوجيه وخادم ACS وقد يكون خادم ACS متوقف عن العمل فعليًا أو قد يكون قد تم فصل كابل الشبكة الخاص به أو قد يكون خادم ACS متصل بمنفذ جهاز مبدل تم إعداده بشكل خاطئ وهو موجود في شبكة VLAN غير صحيحة أو قد تكون هناك مشكلة توجيه عامة. وعليه فيعد التحقق من التوجيه والاتصال بداية رائعة ومهمة، وبعد ذلك يأتي دور الأداة التالية والتي يجب استخدامها والتي تسمى الاختبار (test)
R1# test aaa group tacacs+ admin cisco123 legacy
Attempting authentication test to server-group tacacs+ using tacacs+ User was successfully authenticated.
في بناء جملة اختبار AAA السابقة تم تضمين المجموعة وفي هذه الحالة كانت مجموعة مكونة من خادم TACACS+ واحد واسم مستخدم وكلمة مرور لذلك المستخدم. تم أيضاً استخدام الكلمة legacy كجزء من بناء جملة الاختبار. تعتبر هذه الأداة أداة رائعة لأنها تمكن من التحقق من أن مكون مصادقة ACS لجهاز التوجيه يعمل وذلك قبل البدء باختبار قوائم المصادقة مع Telnet. شيء آخر مهم يجب القيام به عند استكشاف الأخطاء وإصلاحها هو الاطلاع على التقارير الموجودة على خادم ACS والتي قد تشير إلى سبب حدوث المشكلة. يمكن الوصول إلى هذه التقارير بالانتقال إلى Monitoring & Reports> Reports> Favorites. ويبين الشكل المجاور مثالاً.
من هنا انقر فوق رابط المصادقة TACACS – Today للحصول على معلومات ومؤشرات حول سبب حدوث الأخطاء كما هو موضح في الشكل المجاور
أحد الأحداث الشائعة هو أنه بعد الاطلاع على التقارير وملاحظة عدم وجود رسائل خطأ حول عميل ACS (جهاز التوجيه) الا انه لا يزال اختبار المصادقة لا يعمل. في مثل هذه الحالات يجب التحقق من عدم قيام أي مسببات التحكم في الوصول بتصفية وحظر حركة المرور من جهاز التوجيه إلى ACS والعكس والتحقق من أن جهاز التوجيه يمتلك عنوان IP الصحيح لخادم ACS. لأنه إذا لم يكن لدى جهاز التوجيه عنوان IP الصحيح لخادم ACS فلن تكون هناك أي سجلات على خادم ACS حول جهاز التوجيه الذي تم إعداده بشكل خاطئ.
الآن وبعد التأكد من وجود اتصال AAA بين جهاز التوجيه والخادم فلنختبر قوائم طرق المصادقة والتفويض التي وضعناها لخطوط الـ vty.
يمكن لاتصال Telnet بسيط لجهاز التوجيه هذا القيام بهذه المهمة فغالباً ما يكون من الأسهل البدء على جهاز التوجيه وربما من منفذ وحدة التحكم (console) وإعادة اتصال الـ telnet إلى جهاز التوجيه نفسه. يجب أن تؤدي جلسة Telnet وبغض النظر عن مصدرها إلى تشغيل المصادقة وباستخدام بعض أوامر الـ debug ، يمكن التحقق من أن ACS يعمل بشكل صحيح. في هذا المثال نستخدم تسجيل الدخول من مكان بعيد وننظر إلى رسائل الـ debug الموجودة على وحدة التحكم (console) الخاصة بجهاز التوجيه كما هو موضح في المثال أدناه:
R1# show debug
General OS:
TACACS access control debugging is on
AAA Authentication debugging is on
AAA Authorization debugging is on
R1#
AAA/BIND(00000083): Bind i/f
جاءت الجلسة على أحد خطوط VTY، مما أدى إلى تشغيل قوائم طرق المصادقة المرتبطة بهذا الخط
AAA/AUTHEN/LOGIN (00000083): Pick method list ‘Login_Authen_via_TACACS‘
TPLUS: Queuing AAA Authentication request 131 for processing
TPLUS: processing authentication start request id 131
TPLUS: Authentication start packet created for 131()
TPLUS: Using server 192.168.1.252
إرسال طلب TACACS+ للاتصال بالخادم
TPLUS(00000083)/0/NB_WAIT/68BD742C: Started 5 sec timeout
TPLUS(00000083)/0/NB_WAIT: socket event 2
TPLUS(00000083)/0/NB_WAIT: wrote entire 33 bytes request
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: Would block while reading
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 12 header bytes (expect 16 bytes data)
R1#
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 28 bytes response
تلقى جهاز التوجيه رسالة من ACS، وسيقوم جهاز التوجيه الآن بالمطالبة باسم المستخدم الخاص به
TPLUS(00000083)/0/68BD742C: Processing the reply packet
TPLUS: Received authen response status GET_USER (7)
R1#
TPLUS: Queuing AAA Authentication request 131 for processing
TPLUS: processing authentication continue request id 131
TPLUS: Authentication continue packet generated for 131
TPLUS(00000083)/0/WRITE/68BD742C: Started 5 sec timeout
TPLUS(00000083)/0/WRITE: wrote entire 22 bytes request
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 12 header bytes (expect 16 bytes data)
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 28 bytes response
TPLUS(00000083)/0/68BD742C: Processing the reply packet
سيطالب جهاز التوجيه الآن المستخدم بكلمة مروره
TPLUS: Received authen response status GET_PASSWORD (8)
R1#
TPLUS: Queuing AAA Authentication request 131 for processing
TPLUS: processing authentication continue request id 131
TPLUS: Authentication continue packet generated for 131
TPLUS(00000083)/0/WRITE/68BD742C: Started 5 sec timeout
TPLUS(00000083)/0/WRITE: wrote entire 25 bytes request
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 12 header bytes (expect 6 bytes data)
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 18 bytes response
TPLUS(00000083)/0/68BD742C: Processing the reply packet
رد خادم ACS بالإيجاب لـ اسم المستخدم/كلمة المرور.
TPLUS: Received authen response status PASS (2)
يبدأ جهاز التوجيه الآن بعملية التفويض للمستخدم باستخدام طرق التفويض الموجودة في القائمة المرتبطة بخطوط الـ VTY
AAA/AUTHOR (0x83): Pick method list ‘Exec_Authorization_via_TACACS‘
TPLUS: Queuing AAA Authorization request 131 for processing
TPLUS: processing authorization request id 131
TPLUS: Protocol set to None …..Skipping
TPLUS: Sending AV service=shell
TPLUS: Sending AV cmd*
TPLUS: Authorization request created for 131(admin)
TPLUS: using previously set server 192.168.1.252 from group tacacs+
TPLUS(00000083)/0/NB_WAIT/68BD742C: Started 5 sec timeout
TPLUS(00000083)/0/NB_WAIT: socket event 2
TPLUS(00000083)/0/NB_WAIT: wrote entire 57 bytes request
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: Would block while reading
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 12 header bytes (expect 18 bytes data)
TPLUS(00000083)/0/READ: socket event 1
TPLUS(00000083)/0/READ: read entire 30 bytes response
TPLUS(00000083)/0/68BD742C: Processing the reply packet
تم الحصول على رد من خادم ACS وفيه الموافقة على تفويض الصلاحيات وأنه يجب وضع المستخدم في مستوى الامتياز 15
TPLUS: Processed AV priv-lvl=15
TPLUS: received authorization response for 131: PASS
AAA/AUTHOR/EXEC(00000083): processing AV cmd=
AAA/AUTHOR/EXEC(00000083): processing AV priv-lvl=15
AAA/AUTHOR/EXEC(00000083): Authorization successful
R1#
R1# show users
Line User Host(s) Idle Location
2 vty 0 admin idle 00:00:51 10.0.0.25
يمكننا إجراء نفس الاختبار مرة أخرى لكن بتسجيل الدخول هذه باسم “ help-desk” الخاص بالمستخدم. ستكون النتائج متطابقة تقريباً باستثناء أنه سيتم تزويد المستخدم بسطر الأوامر فيه مستوى الامتياز 1
R1#
AAA/BIND(00000084): Bind i/f
AAA/AUTHEN/LOGIN (00000084): Pick method list ‘Login_Authen_via_TACACS‘
TPLUS: Queuing AAA Authentication request 132 for processing
TPLUS: processing authentication start request id 132
TPLUS: Authentication start packet created for 132()
TPLUS: Using server 192.168.1.252
TPLUS(00000084)/0/NB_WAIT/68793774: Started 5 sec timeout
TPLUS(00000084)/0/NB_WAIT: socket event 2
TPLUS(00000084)/0/NB_WAIT: wrote entire 33 bytes request
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: Would block while reading
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 12 header bytes (expect 16 bytes data)
R1#
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 28 bytes response
TPLUS(00000084)/0/68793774: Processing the reply packet
TPLUS: Received authen response status GET_USER (7)
R1#
TPLUS: Queuing AAA Authentication request 132 for processing
TPLUS: processing authentication continue request id 132
TPLUS: Authentication continue packet generated for 132
TPLUS(00000084)/0/WRITE/68793774: Started 5 sec timeout
TPLUS(00000084)/0/WRITE: wrote entire 26 bytes request
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 12 header bytes (expect 16 bytes data)
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 28 bytes response
TPLUS(00000084)/0/68793774: Processing the reply packet
TPLUS: Received authen response status GET_PASSWORD (8)
R1#
TPLUS: Queuing AAA Authentication request 132 for processing
TPLUS: processing authentication continue request id 132
TPLUS: Authentication continue packet generated for 132
TPLUS(00000084)/0/WRITE/68793774: Started 5 sec timeout
TPLUS(00000084)/0/WRITE: wrote entire 25 bytes request
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 12 header bytes (expect 6 bytes data)
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 18 bytes response
TPLUS(00000084)/0/68793774: Processing the reply packet
TPLUS: Received authen response status PASS (2)
AAA/AUTHOR (0x84): Pick method list ‘Exec_Authorization_via_TACACS‘
TPLUS: Queuing AAA Authorization request 132 for processing
TPLUS: processing authorization request id 132
TPLUS: Protocol set to None …..Skipping
TPLUS: Sending AV service=shell
TPLUS: Sending AV cmd*
TPLUS: Authorization request created for 132(help-desk)
TPLUS: using previously set server 192.168.1.252 from group tacacs+
TPLUS(00000084)/0/NB_WAIT/68793774: Started 5 sec timeout
TPLUS(00000084)/0/NB_WAIT: socket event 2
TPLUS(00000084)/0/NB_WAIT: wrote entire 61 bytes request
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: Would block while reading
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 12 header bytes (expect 17 bytes data)
TPLUS(00000084)/0/READ: socket event 1
TPLUS(00000084)/0/READ: read entire 29 bytes response
TPLUS(00000084)/0/68793774: Processing the reply packet
TPLUS: Processed AV priv-lvl=1
TPLUS: received authorization response for 132: PASS
AAA/AUTHOR/EXEC(00000084): processing AV cmd=
AAA/AUTHOR/EXEC(00000084): processing AV priv-lvl=1
AAA/AUTHOR/EXEC(00000084): Authorization successful
R1#
R1# show users
Line User Host(s) Idle Location
2 vty 0 help-desk idle 00:01:24 10.0.0.25
