كيفية إصلاح حالات فشل مصادقة PAM على خادم SUSE Linux Enterprise

لا تعني رسالة "فشل مصادقة PAM" بالضرورة أن كلمة المرور خاطئة. في نظام SUSE Linux Enterprise Server (SLES)، تُشكّل وحدات المصادقة القابلة للتوصيل (PAM) مجموعةً متكاملةً تتحقق من الهوية، وصلاحيات الوصول إلى الحساب، وتغييرات كلمات المرور، وإعدادات الجلسة. قد ينجم الفشل عن خطأ إملائي أو حساب مُعطّل، أو ملف PAM تالف، أو خدمة LDAP أو Active Directory غير متاحة، أو مشكلة في ساعة Kerberos أو نظام أسماء النطاقات (DNS)، أو مشكلة في جلسة سطح المكتب تحدث بعد المصادقة.

أفضل حل هو تحديد الخدمة ومرحلة PAM التي تعطلت قبل تغيير الإعدادات. يعتمد هذا الدليل على وثائق SUSE Linux Enterprise Server 15 SP7 كمرجع. إذا كنت تستخدم حزمة خدمة SLES أخرى أو صورة جهاز متخصص، فراجع وثائق SUSE المطابقة وإصدارات الحزم المثبتة قبل تطبيق الأوامر.

أولاً، ما هو العطل: هل هو في خدمة واحدة أم في كل عملية تسجيل دخول؟

سجّل اسم المستخدم، والوقت الدقيق، والخادم، ونقطة الدخول التي حدث عندها العطل: SSH، أو وحدة تحكم نصية محلية، أو تسجيل دخول رسومي، suأو تطبيق. جرّب باستخدام حساب آخر معروف إن أمكن. إذا فشل SSH فقط بينما نجح تسجيل الدخول عبر وحدة التحكم، فركّز على /etc/pam.d/sshdخدمة SSH. إذا نجح تسجيل دخول المستخدمين المحليين بينما فشل تسجيل دخول مستخدمي الدليل، فابحث في SSSD، أو LDAP، أو Active Directory، أو Kerberos، أو DNS، أو سياسة التخويل الخاصة بالخادم. إذا نجح تسجيل الدخول عبر وحدة التحكم ولكن رفض سطح المكتب المستخدم أو عاد إلى شاشة تسجيل الدخول، فقد يكون العطل في الجلسة الرسومية أو الدليل الرئيسي وليس في مصادقة كلمة المرور.

أبقِ جلسة طرفية الجذر مفتوحة أثناء استكشاف الأخطاء وإصلاحها. إذا كنت متصلاً عن بُعد، فأبقِ جلسة SSH ثانية مفتوحة وتأكد من حصولك على صلاحية الوصول إلى وحدة التحكم أو وضع الإنقاذ قبل تعديل ملف PAM. قد يؤدي خطأ في بناء الجملة أو علامة التحكم في ملف PAM مشترك إلى منع تسجيل الدخول الجديد لخدمات متعددة.

1. اقرأ اليوميات المتعلقة بالمحاولة الفاشلة

يوصي دليل استكشاف الأخطاء وإصلاحها من SUSE بمراجعة سجل النظام بحثًا عن رسائل من عملية تسجيل الدخول وPAM. استعلم عن فترة زمنية قصيرة قريبة من وقت حدوث العطل حتى لا تحجب الرسائل غير ذات الصلة السبب.

sudo journalctl -b --since "15 minutes ago"

لحل مشكلة تتعلق بـ SSH فقط، قم بتضييق نطاق العرض ليقتصر على برنامج SSH الخفي:

sudo journalctl -b -u sshd --since "15 minutes ago"

ابحث عن اسم الخدمة، واسم خدمة PAM، واسم الوحدة، وما إذا كانت الرسالة تشير إلى [اسم الخدمة auth]، accountأو [اسم الخدمة] password، أو [اسم الوحدة]، أو [ اسم الوحدة session]. يتحقق نظام PAM authمن بيانات الاعتماد، accountويتحقق مما إذا كان مسموحًا للمستخدم بالوصول إلى تلك الخدمة، sessionويُهيئ بيئة المستخدم. يشير التحقق الناجح من كلمة المرور، متبوعًا برفض الحساب، إلى مشكلة مختلفة عن مشكلة المستخدم غير المعروف أو كلمة المرور الخاطئة. تجنب تفعيل وضع التصحيح المُفصّل على نظام الإنتاج إلا عند الضرورة؛ فقد تحتوي سجلات التشخيص على أسماء الحسابات ومعلومات حساسة أخرى.

راجع دليل استكشاف الأخطاء وإصلاحها الخاص بنظام SLES من SUSE للاطلاع على سير عمل المصادقة المحلية والشبكية.

2. تأكد من أن نظام SLES يستطيع العثور على المستخدم

قبل تغيير PAM، تحقق مما إذا كان بإمكان محول خدمة الأسماء الخاص بالنظام حل الحساب:

getent passwd user_name
id user_name

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

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

تُوثّق SUSE أن SSSD يوفر واجهتي NSS وPAM، وتُشير إلى قدرته على تخزين بيانات الهوية مؤقتًا. في حال أبلغ المستخدمون عن أعطال متقطعة، يُرجى مقارنة وقت النظام المحلي وحلّ DNS مع بيئة الدليل أو Kerberos. يعتمد Kerberos على مزامنة الوقت الصحيحة؛ ولا يضمن وجود اتصال شبكي سليم وحده نجاح عملية المصادقة.

تحقق أيضًا من تضارب الأسماء. تُشير SUSE إلى أن اسم المستخدم الموجود محليًا وفي مصدر هوية الشبكة يُعد سببًا محتملاً لمشاكل مصادقة الشبكة. تحقق من مصدر الهوية الذي يُفترض أن يمتلك الحساب قبل تعديل قواعد PAM الخاصة به.

3. افحص ملف خدمة PAM والمكدس المشترك

يحتفظ نظام SLES بملفات PAM الخاصة بكل خدمة في ملف /etc/pam.d. يتضمن ملف الخدمة /etc/pam.d/sshdعادةً ملفات مشتركة مثل common-auth، و common-account، common-passwordو ، و common-session. قد يؤثر سطر تالف في ملف مشترك على عدة خدمات؛ بينما قد يؤثر سطر تالف في ملف تطبيق واحد على ذلك التطبيق فقط.

اقرأ الملفات ذات الصلة وتحقق من روابطها قبل التحرير:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

تحقق من أسماء الوحدات النمطية المكتوبة بشكل خاطئ، وملفات الوحدات النمطية المفقودة، والخيارات غير الصحيحة، والترتيب غير المتوقع، والتغييرات التي أُجريت أثناء عملية نشر حزمة أو مصادقة حديثة. علامات التحكم مهمة: requiredفهي تسجل الفشل ولكنها تستمر عبر التسلسل الهرمي؛ requisiteويمكنها التوقف فورًا؛ sufficientويمكنها السماح بالنجاح بالعودة مبكرًا عندما لا تفشل أي وحدة نمطية مطلوبة سابقًا. لا تنسخ حزمة PAM من توزيعة أخرى أو إصدار SLES دون فهم وحداتها النمطية وتدفق التحكم الخاص بها.

قبل إجراء أي تغيير، قم بعمل نسخة احتياطية من الدليل الحالي باستخدام الجذر فقط، مع الحفاظ على الروابط الرمزية:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

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

4. في نظام SLES، تحقق مما إذا كان pam-config يدير الملفات المشتركة

توفر SUSE pam-configإمكانية صيانة ملفات PAM العامة وتكوينات التطبيقات المدعومة. وهي عمومًا أكثر أمانًا من التعديل اليدوي للمكدسات المشتركة المُنشأة عند إضافة أو إزالة طريقة مدعومة. ابدأ بفحص الوحدات النمطية المتاحة وتكامل SSSD الحالي.

sudo pam-config --list-modules
sudo pam-config --query --sss

إذا كان الخادم يستخدم SSSD عمدًا وكان التكامل مفقودًا، فإن وثائق SUSE sudo pam-config --add --sssتوضح طريقة إضافته. لا تقم بذلك إلا بعد التأكد من تصميم مصادقة الدليل، ومراجعة البنية الحالية، والاحتفاظ بنسخة احتياطية، والتأكد من وجود خطة استعادة. لا تستخدم هذه الطريقة كحل عام لكل "فشل مصادقة". استعلم عن التكوين مرة أخرى واختبر في جلسة ثانية.

يُعدّ الأمر `suse` من الأوامر الخطيرة للغاية pam-config --create. تُشير SUSE إلى أنه يُنشئ إعدادات مصادقة Unix بسيطة ويستبدل ملفات الإعدادات الموجودة التي لا يتم تحديثها بواسطة SUSE pam-config(مع الاحتفاظ بنسخ احتياطية تحمل لاحقة .pam-config-backup`suse`). لا يُعدّ هذا الأمر حلاً روتينياً لإصلاح خطأ تسجيل دخول واحد. استخدمه فقط عندما تنوي إعادة بناء الإعدادات عمداً ولديك خطة استعادة مُسبقة.

إذا كانت مؤسستك تُدير ملفات PAM يدويًا، فالتزم بهذا التصميم باستمرار. تُشير SUSE إلى أن التكوين اليدوي يتطلب تعطيل pam-configهذه الملفات. يجب أن تحتفظ الحزم المخصصة بوحدات الجلسة الضرورية، بما في ذلك pam_systemd.soكوحدة جلسة اختيارية عند الاقتضاء.

5. مشاكل منفصلة في SSH، والدليل، وسطح المكتب

لو أن SSH يرفض الحساب

قارن /etc/pam.d/sshdإعدادات SSH مع إعدادات SLES سليمة ومعروفة، وافحص سجلّات خادم SSH عند محاولة تسجيل الدخول الفاشلة. تأكد من أن الحساب مسموح به وفقًا لإعدادات SSH وضوابط الوصول، وكذلك وفقًا لـ PAM. لا تُضعف مصادقة SSH أو تُزيل عمليات التحقق من الحساب لمجرد إخفاء الخطأ.

إذا فشل مستخدمو الدليل فقط

تأكد من البحث عن الحساب getent، وتحقق من حالة SSSD وسجلاته، وتحقق من إمكانية الوصول إلى الدليل، ونظام أسماء النطاقات (DNS)، ومزامنة الوقت، وتسجيل المضيف، وسياسة وصول المستخدم. إذا نجح مستخدم دليل آخر، قارن مجموعات الحساب المتأثر، وواجهة سطر الأوامر، ودليل المستخدم الرئيسي، وقواعد الوصول الخاصة بالمضيف. يشرح دليل عميل المصادقة من SUSE خدمة SSSD المُدارة بواسطة YaST وعمليات التحقق من حالتها.

إذا نجح تسجيل الدخول إلى وحدة التحكم ولكن فشلت جلسة الواجهة الرسومية

تحقق من سجلات تسجيل الدخول والجلسات الرسومية، وتوفر مجلد المستخدم الرئيسي، وملكية المجلد، ومساحة القرص الحرة، وأي خطوة لفتح مجلد المستخدم الرئيسي المشفر. يُعد تسجيل الدخول الناجح عبر وحدة التحكم النصية دليلاً مفيدًا على صحة كلمة المرور ومسار المصادقة الأساسية؛ إذ يُوجه الانتباه نحو جلسة سطح المكتب أو بيئة المستخدم. تجنب حذف ملفات المستخدم كخطوة أولى. يُوصي دليل استكشاف الأخطاء وإصلاحها من SUSE بعزل مشكلات تكوين سطح المكتب بشكل منهجي.

6. تحقق من الإصلاح دون المخاطرة بإغلاق الباب

بعد إجراء التغيير، افتح جلسة اختبار جديدة مع بقاء واجهة الاسترداد متاحة. اختبر الخدمة المتأثرة باستخدام الحساب المتأثر، ثم اختبر حسابًا ثانيًا وحساب مسؤول محلي. بالنسبة لمصادقة الدليل، تأكد من البحث عن الحساب وسلامة الخدمة، بالإضافة إلى تسجيل الدخول بنجاح. راجع سجل النظام مرة أخرى بحثًا عن أخطاء PAM جديدة، وأزل أي إعدادات تصحيح مؤقتة ذات pam-config --deleteخيار مطابق عند اكتمال الاختبار.

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

متى يجب عليك التوقف واستخدام وضع الإنقاذ؟

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

للحصول على بنية ملف PAM الدقيقة، وعلامات الوحدة، pam-configوسلوكها، وخطوات الاسترداد، استخدم دليل SUSE SLES 15 SP7 PAM ودليل المشاكل الشائعة لنظام SUSE المتوافقين مع الإصدار . تُعدّ حزم PAM بمثابة سياسة أمنية؛ قم بإجراء أصغر تغيير مُبرر، ثم تحقق من كلٍ من الوصول والقيود.