FreeIPA: إدارة هويات وأجهزة Linux في المؤسسة

لنفرض أن قسم تقنية المعلومات في كلية أهلية بالدمام يدير قرابة ثمانين سيرفر Linux: مختبرات الطلاب في مبنى الحاسب، وسيرفرات الأبحاث التي يطلبها أعضاء هيئة التدريس، وخدمات الكلية الداخلية مثل البوابة والمكتبة. ويديرها ثلاثة مسؤولين، وكل باحث يحتاج حساباً على سيرفرين أو ثلاثة، وكل مساعد مختبر يحتاج صلاحية إعادة تشغيل خدمة واحدة على سيرفرات مختبره. والطريقة التي بدأ بها القسم هي الطريقة التي يبدأ بها الجميع: حساب محلي على كل سيرفر، ومفتاح SSH ينسخ إلى authorized_keys، وملف sudoers يكتب لكل سيرفر بيده. وبعد ثلاث سنوات اكتشف القسم أن باحثة انتقلت إلى جامعة أخرى ما زالت تملك حسابات على خمسة سيرفرات، وأن ملفات sudoers على سيرفرات المختبر الواحد مختلفة عن بعضها، وأن لا أحد يستطيع أن يجيب عن سؤال المراجع: من يستطيع أن يصبح root على سيرفر بيانات الطلاب؟

هذه المشكلة بالضبط هي ما بني له FreeIPA. وقد شرحنا في شرح LDAP ودليل المستخدمين الدليل وحده، وفي مقال Kanidm وLLDAP البدائل الخفيفة، أما هنا فنتحدث عن الحل الكامل لبيئة Linux: دليل، ودخول موحد على مستوى الشبكة بـ Kerberos، وجهة شهادات، وقواعد دخول وsudo مركزية، كلها في منتج واحد. وسوف نمشي مع قسم تقنية المعلومات في الكلية خطوة خطوة، من المشكلة إلى سيرفرين متماثلين في مبنيين.

وسوف نناقش في هذا المقال ما يلي:

• ما هو FreeIPA، وما المكونات التي يجمعها، ومتى يكون هو الاختيار الصحيح مقارنة بـ Active Directory وKanidm وLLDAP.
• المتطلبات، وما حدث عندما حاولنا تشغيله في Docker Desktop، ولماذا لم يعمل، وأين يعمل.
• التثبيت وتسجيل السيرفرات، وما الذي يتغير فعلاً في سيرفر Linux بعد ipa-client-install.
• Kerberos من الداخل: التذكرة الأولى TGT وتذاكر الخدمات، ولماذا يدخل الباحث إلى السيرفر دون كلمة مرور، ومدة التذاكر.
• قواعد الدخول HBAC وقواعد sudo المركزية، ومفاتيح SSH، وشهادات الخدمات الداخلية.
• النسخ المتماثلة Replicas، والثقة مع Active Directory، والدخول عبر مزود هوية خارجي.
• الضوابط الأساسية للأمن السيبراني، والملاحظات الأمنية، وجدول المقارنة.

ما هو FreeIPA؟

FreeIPA مشروع مفتوح المصدر بترخيص GPL-3.0 يجمع في سيرفر واحد ما تحتاجه إدارة الهوية في بيئة Linux، وهو الأساس الذي تبني عليه Red Hat منتجها Identity Management في RHEL. والاسم IPA اختصار Identity, Policy, Audit، أي الهوية والسياسات والتدقيق. ولا يكتب المشروع هذه المكونات من الصفر، وإنما يجمع مشاريع ناضجة معروفة ويجعلها تعمل معاً، وبحسب موقعه الرسمي فهو يجمع:

• الدليل 389 Directory Server: مخزن المستخدمين والمجموعات والأجهزة والقواعد، ويتحدث LDAP، وكل شيء آخر في FreeIPA مخزن فيه.
• MIT Kerberos: الدخول الموحد على مستوى الشبكة، فيحصل المستخدم على تذكرة Ticket مرة واحدة ويدخل بها إلى السيرفرات والخدمات دون كلمة مرور.
• جهة الشهادات Dogtag Certificate System: تصدر الشهادات للسيرفرات والخدمات داخل النطاق وتتابع تجديدها.
• DNS اختياري: عبر bind-dyndb-ldap، لتسجيل السيرفرات وسجلات Kerberos تلقائياً.
• SSSD على الأجهزة: البرنامج الذي يثبت على كل سيرفر Linux ويسأل FreeIPA عن المستخدمين والقواعد، ويحتفظ بنسخة مؤقتة منها.

والفكرة الأهم أنه ليس دليلاً فقط، وإنما يدير السياسات أيضاً: من يدخل إلى أي سيرفر، ومن ينفذ أي أمر بـ sudo، وما مفاتيح SSH لكل مستخدم، وما الشهادات التي تحملها كل خدمة، وكل ذلك من مكان واحد. والصورة التالية تبين المكونات وما يسأل عنه السيرفر عند الدخول:

وقبل FreeIPA كانت المؤسسات التي تريد دخولاً موحداً لسيرفرات Linux تجمع هذه القطع بنفسها: سيرفر LDAP للمستخدمين، وسيرفر Kerberos منفصل له قاعدة بياناته، وجهة شهادات ثالثة، ثم ملفات إعداد على كل جهاز تربطها ببعض، وكل قطعة لها نسخها الاحتياطية وتحديثاتها ومشكلاتها، وأي خطأ في الربط بينها يظهر كرسالة غامضة عند الدخول. وما يقدمه FreeIPA في الحقيقة ليس مكونات جديدة، وإنما التكامل نفسه: برنامج إعداد واحد يجهز القطع كلها بأسماء ومفاتيح متسقة، وواجهة واحدة تدير المستخدم في الدليل وفي Kerberos معاً، وبرنامج تسجيل واحد يجهز الكلاينت بكل ما يحتاجه. ولهذا السبب بالذات يفشل تشغيله في بيئة لا تسمح لـ systemd بإدارة هذه الخدمات كلها، كما رأينا في المختبر.

وقد يتساءل البعض: لماذا لا يكفي LDAP وحده، فتربط السيرفرات بـ OpenLDAP كما شرحنا في مقاله؟ والإجابة أن LDAP يجيب عن سؤال «من المستخدم وما كلمة مروره»، ولكنه لا يملك لغة لسؤال «هل يدخل هذا المستخدم إلى هذا السيرفر» ولا «ما الأوامر التي ينفذها بـ sudo هنا»، فتجد نفسك تكتب هذه القواعد في ملفات على كل سيرفر من جديد. وكلمة المرور في LDAP تمر عبر كل سيرفر تدخل إليه، أما Kerberos فيجعل السيرفر يتحقق من تذكرة دون أن يرى كلمة المرور أبداً. وFreeIPA يضيف هذين الجزأين فوق الدليل، ويجعل SSSD يطبقهما على كل سيرفر.

متى تختار FreeIPA؟

وقد يتساءل البعض: هل FreeIPA مزود هوية لتطبيقات الويب مثل authentik؟ والإجابة: ليس بشكل أساسي، فقوته في دخول أجهزة Linux وخدمات Kerberos، أما تطبيقات الويب فالأنسب أن تضع أمامها مزود هوية يقرأ المستخدمين من FreeIPA عبر LDAP، كما شرحنا في شرح الدخول الموحد. والكلية في قصتنا تحتاج الاثنين: FreeIPA لسيرفرات المختبرات والأبحاث، ومزود هوية لبوابة الطلاب، ويقرأ الثاني مستخدميه من الأول، فلا يوجد إلا مكان واحد ينشأ فيه الحساب ويغلق.

المتطلبات

بحسب دليل البداية السريعة الرسمي:

• الذاكرة RAM: 1.2 جيجابايت حد أدنى مطلق للتثبيت مع جهة الشهادات، و2 جيجابايت موصى بها لسيرفر تجربة. وفي الإنتاج خصص أكثر من ذلك، لأن الدليل وجهة الشهادات يعملان بـ Java وخدمات متعددة.
• اسم ثابت كامل FQDN: مثل ipa.example.test، ويجب أن يتحول إلى عنوان IP، وإذا وضعته في /etc/hosts فالاسم الكامل أولاً. والسبب أن Kerberos يعتمد على اسم السيرفر، فإذا تغير الاسم بعد التثبيت تتعطل المصادقة.
• نطاق خاص بك: لا تستخدم نطاقاً لا تملكه، ويفضل نطاق فرعي مخصص مثل ipa.example.com بدلاً من النطاق الرئيسي للمؤسسة، حتى لا يتعارض مع Active Directory أو مع DNS الخارجي.
• المنافذ: يفتح الأمر firewall-cmd --add-service=freeipa-ldap --add-service=freeipa-ldaps --permanent خدمات Kerberos وHTTP وHTTPS وLDAP، وتضيف DNS إذا فعلته.
• التوزيعة: Fedora أو RHEL وتوزيعاتها مثل AlmaLinux وRocky، وهي التي يختبر عليها المشروع.
• الساعة: Kerberos حساس للوقت، والتذكرة التي تصل من جهاز ساعته مختلفة كثيراً ترفض، لذلك شغل NTP على السيرفرات وعلى كل الأجهزة المسجلة.

ماذا حدث عندما حاولنا تشغيله في Docker؟

يوفر المشروع Image رسمية في freeipa-container، وآخر إصدار من FreeIPA عند الكتابة هو 4.13.4، وأصدرت له Images في 23 أكتوبر 2026، ومنها quay.io/freeipa/freeipa-server:fedora-44-4.13.4 بحجم 1.36 جيجابايت بعد التنزيل. فشغلناها كما يقول توثيق المشروع، مع الخيار الذي يطلبه لـ IPv6:

docker volume create ipa-data
docker run --name freeipa -t -h ipa.example.test --read-only \
  --sysctl net.ipv6.conf.all.disable_ipv6=0 \
  -v ipa-data:/data \
  quay.io/freeipa/freeipa-server:fedora-44-4.13.4 \
  ipa-server-install -U -r EXAMPLE.TEST -n example.test \
  --ds-password="$IPA_DS_PW" --admin-password="$IPA_ADMIN_PW" --no-ntp

في الأمر أعلاه لاحظ التالي: -h يعطي الـ Container الاسم الكامل الذي يشترطه Kerberos، و--read-only يجعل نظام ملفات الـ Image للقراءة فقط بينما تحفظ كل البيانات والإعدادات في /data، فتستطيع أن تحدث الـ Image دون أن تخسر شيئاً، و-U يجعل برنامج الإعداد يعمل دون أسئلة، و-r هو عالم Kerberos Realm بأحرف كبيرة، و-n هو النطاق. ولكن الـ Container توقف بعد ثوان بالرمز 255، ومع الخيار -e DEBUG_TRACE=1 ظهر السبب في آخر المخرج:

systemd 259.10-1.fc44 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +IPE +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
Detected virtualization wsl.
Detected architecture x86-64.
Found tmpfs on /sys/fs/cgroup/, assuming legacy hierarchy.
Detected cgroup v1 hierarchy at /sys/fs/cgroup/, which is no longer supported by current version of systemd.
Please instruct your initrd to mount cgroup v2 (unified) hierarchy,
possibly by removing any stale kernel command line options, such as:
  systemd.legacy_systemd_cgroup_controller=1
  systemd.unified_cgroup_hierarchy=0
[!!!!!!] Detected unsupported legacy cgroup hierarchy, refusing execution.
Exiting PID 1...

والسبب أن FreeIPA لا يعمل كبرنامج واحد، وإنما كمجموعة خدمات يديرها systemd داخل الـ Container: الدليل، ومركز توزيع المفاتيح، وجهة الشهادات، وخادم الويب، وغيرها، وsystemd 259 في Fedora 44 يرفض العمل على cgroups v1. وبيئة Docker التي جربنا عليها تعمل على cgroups v1، كما يقول docker info:

docker info --format '{{.KernelVersion}} {{.CgroupVersion}} {{.CgroupDriver}} {{.OperatingSystem}}'

5.15.167.4-microsoft-standard-WSL2 1 cgroupfs Docker Desktop

ويقترح توثيق المشروع في هذه الحالة أن تربط شجرة cgroup v2 الخاصة بالجهاز داخل الـ Container بصلاحية الكتابة، أو أن تفعل إعادة ربط المستخدمين userns-remap في إعدادات Docker نفسها ثم تعيد تشغيله. ولم نفعل أياً منهما، والسبب أن الأول يعطي systemd داخل الـ Container صلاحية الكتابة على cgroups كل الحاويات الأخرى على نفس الجهاز، والثاني يغير سلوك Docker لكل الحاويات. لذلك لم نشغل FreeIPA في هذه التجربة، وكل الأوامر في بقية المقال من التوثيق الرسمي وورشة FreeIPA، ولم نعرض لها مخرجات إلا ما ذكرته الورشة نفسها.

والكلية في قصتنا لا تحتاج Container أصلاً، فالأنسب لها آلتان افتراضيتان بنظام AlmaLinux في مبنيين مختلفين، لأن FreeIPA يصبح بعد التثبيت أهم خدمة في الحرم: إذا توقف لم يدخل أحد إلى أي سيرفر جديد، ولذلك يستحق آلة مخصصة لا يشاركها فيها شيء آخر.

التثبيت على سيرفر Fedora أو RHEL

على سيرفر جديد اسمه الكامل ثابت، يثبت التوثيق الحزمة ثم يشغل برنامج الإعداد التفاعلي، والإضافة freeipa-server-dns اختيارية إذا أردت أن يدير FreeIPA الـ DNS:

sudo dnf install freeipa-server
sudo dnf install freeipa-server-dns
sudo ipa-server-install

يسألك الإعداد عن اسم النطاق Domain وعالم Kerberos Realm، وهو عادة النطاق نفسه بأحرف كبيرة مثل EXAMPLE.TEST، وعن كلمة مرور مدير الدليل Directory Manager وكلمة مرور حساب admin. واحفظ الاثنتين في مدير كلمات المرور، فالأولى هي مفتاح الدليل كله ولا تستخدمها في العمل اليومي. وفي الوحدة الأولى من الورشة الرسمية يثبت السيرفر بالأمر التالي في بيئة التدريب:

sudo ipa-server-install --no-host-dns --mkhomedir

والخيار --no-host-dns هناك لأن بيئة الورشة لا تملك سجلات DNS عكسية، و--mkhomedir يجعل PAM ينشئ مجلد المستخدم عند أول دخول. والإعداد في الورشة يجهز DNS مدمجاً بـ BIND، ويسأل عن اسم السيرفر server.ipademo.local والنطاق ipademo.local والعالم IPADEMO.LOCAL، وينشئ جهة شهادات ذاتية التوقيع Self-signed CA، ويستغرق بضع دقائق. وبعد ذلك تحصل على تذكرة Kerberos لحساب المدير، وتبدأ بالأوامر، كما في ورشة إدارة المستخدمين:

kinit admin
ipa help topics
ipa user-add sara --first=Sara --last=Ali [email protected]
ipa passwd sara

والأمر الأخير يضع كلمة مرور مؤقتة يغيرها المستخدم عند أول دخول، فتقول الورشة إن أول kinit بعد وضع كلمة المرور أو إعادة تعيينها يعرض الرسالة Password expired. You must change it now.. وهذا تصميم مقصود، فالمسؤول الذي ينشئ الحساب لا يعرف كلمة المرور النهائية للمستخدم أبداً.

تسجيل سيرفرات Linux

على كل سيرفر Linux تريد أن يدار من FreeIPA تثبت حزمة الكلاينت ثم تشغل الأمر التالي من ورشة تثبيت الكلاينت، والخيار --mkhomedir ينشئ مجلد المستخدم عند أول دخول:

sudo ipa-client-install --mkhomedir

ومن تلك اللحظة يعرف السيرفر مستخدمي FreeIPA عبر SSSD، ويدخل إليه المستخدمون بحساباتهم المركزية، ويحتفظ SSSD بنسخة مؤقتة Cache حتى يستطيع من دخل سابقاً أن يدخل لو انقطع الاتصال بالسيرفر المركزي مؤقتاً. والصورة التالية تجمع ما يتغير في السيرفر:

وأهم ما في هذه التغييرات للكلية أن السيرفر نفسه صار له هوية في الدليل، أي مدخل Host ومفتاح في ملف keytab، وهذا يعني أن FreeIPA يعرف كل سيرفر في الحرم، ويستطيع أن يجمعها في مجموعات Host Groups مثل lab-cs وresearch-gpu، وكل القواعد التالية تكتب على هذه المجموعات وليس على أسماء سيرفرات مفردة. فعندما يضاف سيرفر جديد إلى مختبر الحاسب ويوضع في مجموعته، تطبق عليه كل قواعد المختبر دون أن يلمس أحد إعداده.

Kerberos: لماذا لا يكتب الباحث كلمة المرور على كل سيرفر؟

في الورشة يحصل المستخدم bob على تذكرته الأولى بالأمر kinit bob، ثم يدخل إلى السيرفر بالأمر ssh [email protected] دون أن يكتب كلمة مرور، وتقول الورشة إن Kerberos بروتوكول دخول موحد حقيقي. والصورة التالية تبين ما يحدث في الخلفية:

1. التذكرة الأولى TGT: عند kinit يتحقق مركز توزيع المفاتيح Key Distribution Center واختصاراً KDC من كلمة المرور، ويعطي المستخدم تذكرة اسمها Ticket-Granting Ticket، وتظهر في klist باسم krbtgt/IPADEMO.LOCAL.
2. تذكرة الخدمة Service Ticket: عندما يتصل المستخدم بسيرفر، يطلب برنامج ssh من KDC تذكرة لهذا السيرفر بالتحديد مقابل TGT، فتظهر في klist تذكرة ثانية باسم host/client.ipademo.local، كما تبين الورشة.
3. التحقق في السيرفر: السيرفر يملك مفتاحه في ملف keytab منذ التسجيل، فيتحقق من التذكرة وحده دون أن يسأل أحداً ودون أن يرى كلمة المرور.

والفرق العملي للكلية أن كلمة مرور الباحث لا تمر على أي سيرفر أبحاث، فلو اخترق سيرفر واحد لم يحصل المخترق على كلمات مرور من دخل إليه، بخلاف الدخول بكلمة المرور عبر LDAP. ومدة التذاكر سياسة مركزية، وتبين الوحدة 11 في الورشة أن القيمة الافتراضية يوم كامل للتذكرة 86400 ثانية، وسبعة أيام للتجديد 604800، وأنك تستطيع أن تقصرها للجميع أو لحساب محدد:

ipa krbtpolicy-show
ipa krbtpolicy-mod --maxlife=28800 --maxrenew=86400
ipa krbtpolicy-mod admin --maxlife=3600

والأمر الأخير يجعل تذكرة حساب المدير صالحة ساعة واحدة فقط، وهذا منطقي لأن تذكرة المدير المسروقة أخطر بكثير من تذكرة طالب. وتشرح نفس الوحدة مؤشرات المصادقة Authentication Indicators، وهي علامات يضعها KDC في التذكرة بحسب طريقة الدخول، مثل otp لكلمة المرور مع رمز لمرة واحدة، وpkinit للبطاقة الذكية أو الشهادة، وhardened عندما تكون المصادقة محمية بـ FAST أو SPAKE، وidp للدخول عبر مزود هوية خارجي. وتستطيع أن تجعل خدمة حساسة ترفض أي تذكرة لا تحمل المؤشر المطلوب بالأمر ipa service-mod --auth-ind، فيصبح سيرفر بيانات الطلاب مثلاً لا يقبل إلا من دخل بعامل ثان.

قواعد الدخول HBAC: من يدخل إلى أي سيرفر

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

وهذه أوامر القاعدة كما في ورشة HBAC:

ipa hbacrule-disable allow_all
ipa hbacrule-add sysadmin_webservers
ipa hbacrule-add-host sysadmin_webservers --hostgroup webservers
ipa hbacrule-add-user sysadmin_webservers --group sysadmin
ipa hbacrule-mod sysadmin_webservers --servicecat=all
ipa hbactest --host client.ipademo.local --service sshd --user bob

في الأوامر أعلاه لاحظ التالي:

• القاعدة لا تذكر أي مستخدم أو سيرفر بالاسم، وإنما مجموعة مستخدمين ومجموعة سيرفرات، فإضافة مسؤول جديد هي إضافته إلى مجموعة sysadmin فقط.
• --servicecat=all يعني كل الخدمات التي تمر على PAM، مثل sshd وlogin وsudo، وتستطيع أن تحصرها في sshd فقط إذا أردت.
• الأمر hbactest مهم جداً، فهو يجيب عن سؤال «هل يستطيع bob أن يدخل عبر sshd إلى هذا السيرفر؟» قبل أن تجربه فعلاً، وهو ما تحتاجه عند المراجعة الدورية للصلاحيات.
• تعطيل allow_all في نظام يعمل يغلق الدخول على كل من لا تشمله قاعدة جديدة، فاكتب القواعد أولاً، وجربها بـ hbactest، ثم عطل القاعدة الافتراضية، وإلا اتصل بك نصف الحرم في نفس الساعة.

قواعد sudo المركزية

بدلاً من ملف sudoers على كل سيرفر، تكتب القاعدة مرة واحدة، كما في ورشة sudo. هذه قاعدة تسمح لمجموعة webadmin بإعادة تشغيل خدمة الويب فقط على سيرفرات الويب، وهي نفس حاجة مساعد المختبر في الكلية الذي يعيد تشغيل خدمة واحدة على سيرفرات مختبره:

ipa sudocmd-add "/usr/bin/systemctl start httpd"
ipa sudocmd-add "/usr/bin/systemctl restart httpd"
ipa sudorule-add webadmin_sudo --runasusercat=all --runasgroupcat=all
ipa sudorule-add-user webadmin_sudo --group webadmin
ipa sudorule-add-host webadmin_sudo --hostgroup webservers
ipa sudorule-add-allow-command webadmin_sudo --sudocmdgroups webadmin_cmds

والسطر الأخير يفترض أنك أنشأت مجموعة أوامر webadmin_cmds تضم الأمرين، كما تفعل الورشة. والفرق الكبير عن sudoers المحلي أن تعطيل حساب المغادر أو حذفه من المجموعة يسحب منه sudo على كل السيرفرات في وقت واحد، وهذا ما يطلبه مقال دورة حياة حساب الموظف JML، ولو كان لدى الكلية FreeIPA قبل ثلاث سنوات لما بقيت حسابات الباحثة على خمسة سيرفرات. وتذكر أن قواعد sudo المركزية تحدد من يصبح root، ولا تسجل ماذا يفعل بعد ذلك، وتسجيل الجلسات موضوع مقال مستقل في هذا المسار.

تطبيقات الويب الداخلية بنفس القواعد

قلنا إن FreeIPA ليس مزود هوية لتطبيقات الويب بالمعنى الذي شرحناه مع OIDC، ولكن الكلية لديها تطبيقات داخلية قديمة على Apache، مثل صفحة إدارة المختبرات، وتريد أن يدخل إليها المسؤولون فقط. وتبين الوحدة 5 في الورشة طريقة تجعل خادم الويب يستخدم Kerberos وHBAC مباشرة على ثلاث طبقات:

• المصادقة: تنشأ خدمة باسم HTTP/client.ipademo.local ويحصل خادم الويب على مفتاحها في ملف keytab بالأمر ipa-getkeytab -p HTTP/client.ipademo.local -k app.keytab، ثم تجعل الوحدة mod_auth_gssapi في Apache كل متصفح يحمل تذكرة Kerberos يدخل دون كلمة مرور، ويصل اسمه إلى التطبيق في المتغير REMOTE_USER.
• بيانات المستخدم: الوحدة mod_lookup_identity تسأل SSSD عبر خدمته InfoPipe عن بريد المستخدم ومجموعاته وتضعها في متغيرات الطلب، فلا يحتاج التطبيق إلى أن يسأل LDAP بنفسه.
• الصلاحية: تنشأ خدمة HBAC باسم app، وقاعدة sysadmin_app تسمح لمجموعة sysadmin بها، وملف PAM باسم app يستخدم pam_sss.so، ثم يطلب Apache بالسطر Require pam-account app أن تسمح قاعدة HBAC قبل أن يدخل أحد.

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

مفاتيح SSH في مكان واحد

كثير من الباحثين يفضلون مفاتيح SSH على كلمات المرور، وفي الطريقة القديمة كان كل مفتاح ينسخ إلى كل سيرفر. وفي FreeIPA يرفع المستخدم مفتاحه العام إلى مدخله في الدليل، كما في الوحدة 10 في الورشة:

ipa user-mod alice \
    --sshpubkey="$(cat /home/alice/.ssh/id_rsa.pub)"

وتذكر الورشة أن OpenSSH أعد أثناء تسجيل السيرفر ليأخذ مفاتيح المستخدمين من SSSD، فلا يوجد ملف authorized_keys على السيرفرات يحتاج إلى تنظيف، وعند تعطيل الحساب يتوقف المفتاح على كل السيرفرات معاً، وبشرط أن تسمح قاعدة HBAC بالدخول عبر sshd. وتذكر أيضاً أن مفاتيح السيرفرات نفسها تنشر في FreeIPA، فيعرف المستخدم أن السيرفر الذي يتصل به هو الحقيقي دون أن يقبل بصمة غير معروفة عند أول اتصال.

شهادات الخدمات الداخلية

بوابة الكلية الداخلية وواجهة المكتبة تحتاجان شهادات TLS، وأغلب الفرق تستخدم شهادات ذاتية التوقيع ثم تعلم الموظفين أن يتجاهلوا تحذير المتصفح، وهذه عادة سيئة. وجهة الشهادات المدمجة في FreeIPA تحل ذلك داخلياً، كما في الوحدة 6 في الورشة: تطلب الشهادة بالأمر ipa-getcert request ومعه مسار المفتاح الخاص الذي ينشئه البرنامج certmonger بنفسه، واسم خدمة Kerberos، والاسم الذي يظهر في الامتداد Subject Alternative Name، ثم يتابع certmonger الشهادة ويجددها وحده قبل انتهائها، وتظهر حالتها بالأمر getcert list كـ MONITORING مع auto-renew: yes. وهذا ينهي مشكلة الشهادة التي تنتهي في يوم الامتحانات دون أن يتذكرها أحد، بشرط أن توزع شهادة جهة FreeIPA على أجهزة الكلية حتى تثق المتصفحات بها.

تصميم المجموعات قبل أول أمر

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

• مجموعات المستخدمين User Groups: بحسب الدور وليس بحسب الشخص، مثل students وresearchers وlab-assistants-cs وsysadmin. والباحثة التي تعمل في مشروعين تكون عضواً في مجموعتين، ولا تكتب لها قاعدة خاصة.
• مجموعات السيرفرات Host Groups: بحسب الوظيفة والحساسية، مثل lab-cs وresearch-gpu وstudent-data وweb-services. والسيرفر الذي يحمل بيانات الطلاب يجب أن يكون في مجموعة مستقلة حتى لو كان يشبه غيره تقنياً، لأن قواعده أشد.
• القواعد: كل قاعدة HBAC أو sudo تربط مجموعة مستخدمين بمجموعة سيرفرات، ولا تذكر أسماء أشخاص أو سيرفرات مفردة إلا في حالة استثنائية مكتوبة السبب.

وفي FreeIPA أيضاً قواعد للعضوية التلقائية Automember، تضيف المستخدم أو السيرفر إلى مجموعة بحسب صفة فيه، مثل أن يضاف كل سيرفر يبدأ اسمه بـ lab-cs إلى مجموعة مختبر الحاسب عند تسجيله. وهذا يقلل الأخطاء، ولكن لا تبدأ به حتى يستقر تصميم المجموعات، لأن القاعدة التلقائية الخاطئة تضع عشرات السيرفرات في المكان الخطأ دفعة واحدة. والقاعدة التي نقترحها: إذا لم تستطع أن تشرح لماذا هذا الشخص في هذه المجموعة في جملة واحدة، فالمجموعة تحتاج إلى إعادة تصميم.

الانتقال من الحسابات المحلية دون أن يتوقف أحد

الكلية لا تبدأ من الصفر، فعلى السيرفرات حسابات محلية بأرقام مستخدمين UID، وملفات في مجلدات المستخدمين يملكها هذا الرقم. وFreeIPA يعطي المستخدمين أرقاماً من نطاق خاص به ينشئه عند التثبيت، وهذا يعني أن الباحثة التي كان رقمها 1005 على سيرفر الأبحاث سوف يصبح لها رقم مختلف في FreeIPA، وملفاتها القديمة لن تكون ملكها عندما تدخل بحسابها الجديد. لذلك يمر الانتقال بخطوات:

1. الجرد: قائمة بكل الحسابات المحلية على كل سيرفر، وأرقامها، ومن صاحبها، وهل ما زال يحتاجها. وهذه الخطوة وحدها تكشف عادة حسابات المغادرين، كما حدث مع الباحثة في قصتنا.
2. مختبر تجريبي: مختبر واحد يسجل في FreeIPA أولاً، ويستخدمه مساعدو المختبر والطلاب أسبوعين، وتجمع المشكلات قبل أن تتكرر على ثمانين سيرفراً.
3. نقل الملكية: لكل مستخدم ينتقل، تغير ملكية ملفاته القديمة إلى رقمه الجديد بالأمر chown، ثم يحذف الحساب المحلي، حتى لا يوجد حسابان بنفس الاسم يربكان SSSD.
4. حذف الملفات المحلية القديمة: ملفات sudoers ومفاتيح authorized_keys المحلية تحذف بعد أن تعمل القواعد المركزية، لأن بقاءها يعني أن الباب القديم ما زال مفتوحاً بجانب الجديد.
5. الحساب المحلي الوحيد الذي يبقى: حساب الطوارئ، بكلمة مرور مختومة وتنبيه عند الاستخدام.

يوم مغادرة الباحثة: ماذا يتغير بأمر واحد؟

لنعد إلى الباحثة التي انتقلت إلى جامعة أخرى، ولنفترض أن الكلية تعمل الآن بـ FreeIPA. يكفي أمر واحد هو ipa user-disable باسمها، وبعده لا تستطيع أن تحصل على تذكرة Kerberos جديدة، ولا يقبل أي سيرفر دخولها بكلمة المرور أو بمفتاح SSH المحفوظ في مدخلها، لأن SSSD يسأل FreeIPA عن حالة الحساب عند الدخول. وهذا يختلف كثيراً عن ساعات من البحث في خمسة سيرفرات. ولكن هناك ثلاث نقاط يجب أن يعرفها المسؤول حتى لا يظن أن الأمر انتهى:

• التذكرة الموجودة: إذا كانت الباحثة قد حصلت على TGT صباحاً فهي صالحة حتى تنتهي مدتها، يوماً كاملاً بالقيمة الافتراضية، وتستطيع أن تطلب بها تذاكر خدمات. لذلك فالمدة الأقصر للتذاكر ليست تفصيلاً، وإنما المدة التي يبقى فيها المغادر قادراً على الدخول بعد تعطيله.
• الجلسات المفتوحة: الجلسة التي فتحتها قبل التعطيل تبقى مفتوحة، فإذا كانت المغادرة غير ودية أنه جلساتها على السيرفرات بنفسك.
• الذاكرة المؤقتة في SSSD: SSSD يحتفظ ببيانات الدخول حتى يعمل السيرفر عندما ينقطع الاتصال بـ FreeIPA، وهذا مفيد للتوافرية، ولكنه يعني أن سيرفراً معزولاً عن الشبكة قد يقبل كلمة مرور قديمة من الذاكرة. وعلى السيرفر المتصل يكفي أن يسأل SSSD من جديد، ويمكنك أن تفرغ ذاكرته المؤقتة بالأمر sss_cache -E إذا أردت أن يطبق التغيير فوراً.

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

مشكلات شائعة وما تعنيه

أغلب مشكلات FreeIPA في الأسابيع الأولى تأتي من أربعة أماكن، وكلها خارج FreeIPA نفسه: الوقت، والأسماء، والقواعد، والذاكرة المؤقتة.

وعندما تواجه مشكلة لا يفسرها الجدول، فابدأ دائماً بسؤالين: هل الوقت متزامن، وهل يتحول اسم السيرفر إلى عنوانه في الاتجاهين؟ والسبب أن Kerberos مبني كله على هذين الأمرين، وأغلب الرسائل الغامضة تعود إلى أحدهما.

النسخ المتماثلة: لا تجعل FreeIPA نقطة فشل واحدة

بعد أشهر من التشغيل أصبح كل دخول في الكلية يمر على FreeIPA، وهذا يعني أن توقفه يمنع أي دخول جديد إلى أي سيرفر. وتقول الوحدة 7 في الورشة إن FreeIPA مصمم ليعمل في بيئة نسخ متعددة الرؤوس Multi-master، أي أن كل سيرفر يقبل التعديل، وكل تغيير في LDAP على أي سيرفر ينسخ إلى البقية. والنسخة تنشأ بتسجيل الآلة الجديدة ككلاينت أولاً، ثم بالأمر ipa-replica-install، وتضاف لها أدوار جهة الشهادات وDNS لاحقاً بالأمرين ipa-ca-install وipa-dns-install. وتنصح الورشة بأن تكون في كل مركز بيانات نسخة واحدة على الأقل من خدمتي CA وDNS.

ولاحظ أن النسخ المتماثلة تحمي من توقف سيرفر، ولا تحمي من خطأ إداري، فحذف مجموعة بالخطأ ينسخ إلى كل السيرفرات خلال ثوان. لذلك تحتاج إلى نسخة احتياطية Backup أيضاً، يأخذها FreeIPA بالأداة ipa-backup وتعاد بـ ipa-restore، وجرب الاستعادة على آلة معزولة قبل أن تحتاجها.

Active Directory ومزودو الهوية الخارجيون

الموظفون الإداريون في الكلية على أجهزة Windows ولهم حسابات في Active Directory، وبعضهم يحتاج إلى الدخول إلى سيرفرات Linux. وبدلاً من حساب ثان لكل منهم، يستطيع FreeIPA أن ينشئ علاقة ثقة Trust بين عالم Kerberos الخاص به ونطاق Active Directory، فيدخل الموظف إلى سيرفرات Linux بحسابه في AD، وتبقى قواعد HBAC وsudo في FreeIPA تطبق عليه، كما يشرح دليل إعداد الثقة في موقع المشروع. والعكس غير صحيح، فمستخدمو FreeIPA لا يدخلون إلى أجهزة Windows بهذه الثقة.

وهناك طريق ثالث أحدث: الدخول عبر مزود هوية خارجي يدعم OAuth 2.0. فبحسب الوحدة 12 في الورشة، يستطيع FreeIPA من الإصدار 4.10 أن يفوض المصادقة إلى مزود خارجي مثل Keycloak بطريقة Device Authorization Grant المعرفة في RFC 8628، فيكتب المستخدم kinit فيعرض له رابطاً يفتحه على جهاز آخر ويوافق، ثم يحصل على تذكرة Kerberos تحمل المؤشر idp. وتذكر الورشة قيوداً مهمة: كثير من مزودي الهوية لا يدعمون هذه الطريقة، والحسابات يجب أن تنشأ في الطرفين دون مزامنة تلقائية جيدة، ولا يمكن الدخول إلى واجهة الويب في FreeIPA بها مباشرة بعد.

تشغيل FreeIPA يوماً بعد يوم

التثبيت يأخذ ساعة، والتشغيل يأخذ سنوات، وما يحدد نجاح الكلية مع FreeIPA هو ما يفعله الفريق كل أسبوع، وليس ما فعله في يوم التثبيت. وهذه الأعمال الدورية التي نقترحها لفريق من ثلاثة أشخاص:

• فحص الصحة: تأتي مع FreeIPA في توزيعات RHEL وFedora أداة اسمها ipa-healthcheck تفحص الشهادات والنسخ والخدمات وتطبع ما يحتاج إلى انتباه، فشغلها دورياً وأرسل نتيجتها إلى نظام المراقبة، بدلاً من أن تكتشف المشكلة عندما يشتكي المستخدمون.
• شهادات FreeIPA نفسه: FreeIPA يستخدم شهادات داخلية كثيرة للدليل وخادم الويب وجهة الشهادات، ويجددها certmonger تلقائياً كما يجدد شهادات الخدمات. والمشكلة تظهر عندما يبقى سيرفر متوقفاً أشهراً ثم يعاد تشغيله بعد انتهاء شهاداته، لذلك لا تترك نسخة متماثلة متوقفة طويلاً، واحذفها من التوزيع إذا لم تعد تحتاجها.
• التحديث: التحديث يتم بمدير الحزم في التوزيعة، ثم يعدل FreeIPA بنيته الداخلية وحده عند إعادة تشغيل الخدمات. والطريقة الآمنة أن تحدث نسخة متماثلة واحدة أولاً، وتتأكد من أنها تعمل وتنسخ، ثم البقية، بدلاً من تحديثها كلها في ليلة واحدة.
• المراجعة الشهرية: قائمة بالمستخدمين النشطين الذين لم يدخلوا منذ تسعين يوماً، والمجموعات التي تغير أعضاؤها، وقواعد HBAC وsudo التي أضيفت أو عدلت، ثم سؤال كل صاحب مجموعة: هل هؤلاء ما زالوا يحتاجون؟ وهذه هي المراجعة الدورية التي يطلبها الضابط 2-2-3-5 بشكل عملي.
• اختبار الاستعادة: مرة كل ثلاثة أشهر، استعد آخر نسخة احتياطية على آلة معزولة لا تتصل بالشبكة الحقيقية، وتأكد من أنك تستطيع أن تحصل على تذكرة بحساب المدير منها.

وكل هذه الأعمال تمر عبر واجهة واحدة، فالأمر ipa وواجهة الويب يستخدمان نفس الواجهة البرمجية، وكل ما تفعله في الواجهة تستطيع أن تكتبه في سكربت يعمل كل ليلة. وهذا ما يجعل FreeIPA مناسباً لفريق صغير يدير سيرفرات كثيرة: الأعمال المتكررة تتحول إلى سكربتات، ويبقى وقت الفريق للقرارات.

الربط بالضوابط

إذا كانت جهتك ضمن نطاق الضوابط الأساسية للأمن السيبراني ECC-2:2024، فالضابط 2-2-3-3 يطلب منح الصلاحيات بحسب الحاجة وأقل صلاحية ممكنة وفصل المهام، والضابط 2-2-3-5 يطلب المراجعة الدورية للهويات والصلاحيات، كما في الوثيقة الرسمية. وقواعد HBAC وsudo المركزية مع hbactest تعطيك دليلاً مكتوباً على الأمرين، بدلاً من ملفات sudoers متفرقة يصعب جمعها عند التدقيق. والضابط 2-2-3-2 يطلب التحقق متعدد العوامل للدخول عن بعد وللحسابات المميزة، ومؤشرات المصادقة في FreeIPA مع --auth-ind هي الطريقة التي تفرض بها ذلك على سيرفرات بعينها، فيقبل سيرفر بيانات الطلاب تذاكر otp فقط.

ملاحظات أمنية

• حدث فوراً: الإصدار 4.13.4 أغلق ثغرتين، منهما CVE-2026-76578 التي كانت تسمح لكلاينت LDAP دون مصادقة أن ينشئ مدخل OTP ويحقن فيه اسم Kerberos Principal، وهي خطوة ممكنة نحو صلاحيات المدير، كما في ملاحظات الإصدار. والسيرفر الذي يحمل مفاتيح كل السيرفرات يجب أن يكون أول ما تحدثه.
• سيرفران على الأقل: نسخة متماثلة Replica بالأمر ipa-replica-install، لأن توقف السيرفر الوحيد يمنع الدخول الجديد إلى كل السيرفرات.
• حساب طوارئ محلي: اترك على كل سيرفر حساباً محلياً لا يعتمد على FreeIPA للحالات التي يتوقف فيها الكل، واحمه كما نشرح في مقال حسابات الطوارئ Break-glass.
• لا تعمل يومياً بحساب Directory Manager: استخدم admin أو حسابات مديرين بأسمائهم، حتى يبقى في السجلات اسم من فعل ماذا.
• ملفات keytab أسرار: الملف /etc/krb5.keytab على كل سيرفر هو هوية السيرفر نفسه، ومن يسرقه يستطيع أن ينتحل السيرفر، فلا تنسخه بين الأجهزة ولا تضعه في النسخ الاحتياطية العامة.
• سجلات التشخيص: تحذر الورشة من أن تفعيل سجل التشخيص للدخول عبر المزود الخارجي يكتب بيانات شخصية للمستخدمين، فأعده إلى وضعه بعد حل المشكلة.

FreeIPA مقارنة بالبدائل

ولمن يقارن بين FreeIPA وKanidm تحديداً: Kanidm أخف بكثير، وفيه OIDC ومفاتيح المرور جاهزة، ويعمل في Container دون systemd كما جربنا في مقاله، ولكنه لا يملك Kerberos ولا جهة شهادات ولا قواعد sudo مركزية بنفس العمق. لذلك فالكلية التي تدير ثمانين سيرفر Linux وتحتاج إلى قواعد مختلفة لكل مختبر سوف تجد في FreeIPA ما يناسبها، والشركة الناشئة بعشرة سيرفرات وتطبيقات ويب كثيرة سوف تجد Kanidm أبسط.

قائمة تحقق قبل التشغيل في الإنتاج

• آلتان افتراضيتان على الأقل بنظام Fedora أو RHEL أو AlmaLinux، في موقعين مختلفين، بأسماء كاملة ثابتة، وNTP يعمل.
• نطاق فرعي مخصص لـ FreeIPA لا يتعارض مع Active Directory أو DNS الخارجي.
• مجموعات سيرفرات ومجموعات مستخدمين تعكس هيكل المؤسسة، ثم قواعد HBAC مجربة بـ hbactest، ثم تعطيل allow_all.
• قواعد sudo مركزية بأوامر محددة، وحذف ملفات sudoers المحلية القديمة.
• مدة تذاكر أقصر لحسابات المديرين، وعامل ثان للحسابات المميزة والخدمات الحساسة عبر مؤشرات المصادقة.
• نسخ احتياطي بـ ipa-backup واستعادة مجربة، وحساب طوارئ محلي على كل سيرفر.
• متابعة إصدارات FreeIPA والتحديث الأمني السريع.

دليلKanidm وLLDAP: دليل مستخدمين خفيف بديل Active Directoryجربنا LLDAP وKanidm في Docker بمستخدمين عرب ومخرجات LDAP حقيقية، لترى متى يكفيك دليل خفيف مجاني بدلاً من Active Directory.دليلLDAP ودليل المستخدمين: كيف تعرف التطبيقات من هو المستخدم؟نبني دليل مستخدمين على OpenLDAP ونرى بمخرجات ldapsearch الحقيقية كيف تتحقق التطبيقات من كلمة المرور والمجموعات، وأين يخطئ أغلب من يبدأ.دليلدورة حياة حساب الموظف JML من أول يوم إلى آخر يومكيف تجعل الموارد البشرية مصدر كل حساب، فيجد الموظف ما يحتاجه في يومه الأول وتغلق كل أبوابه في يوم مغادرته.دليلتسجيل جلسات المسؤولين ومراجعتها: sudo وtlog وauditdأعدنا ليلة تغيير مجهول على سيرفر إنتاج، ثم أضفنا تسجيل جلسات sudo وسيرفر سجلات مركزياً وtlog حتى لا يمحو root أثره.دليلوصول مؤقت عند الحاجة Just-in-Time وحساب الطوارئ Break-glassجربنا صلاحيات تنتهي وحدها بقاعدة sudo وشهادة SSH قصيرة العمر، ثم حساب طوارئ مختوماً بثلاثة أشخاص يرسل تنبيهاً عند كل استخدام.

الخلاصة

• FreeIPA يجمع الدليل 389 Directory وKerberos وجهة الشهادات Dogtag وDNS اختيارياً، ويضيف قواعد دخول HBAC وsudo مركزية ومفاتيح SSH لكل سيرفرات Linux عبر SSSD.
• Kerberos يجعل كلمة المرور تذهب إلى KDC مرة واحدة، وكل سيرفر بعد ذلك يتحقق من تذكرة بمفتاحه في keytab، ومدة التذاكر ومؤشرات المصادقة سياسة مركزية.
• اختره عندما تكون لديك سيرفرات Linux كثيرة، واختر Active Directory لأجهزة Windows، وKanidm أو authentik لتطبيقات الويب، ويمكن أن تعمل هذه معاً بالثقة والقراءة عبر LDAP.
• يحتاج إلى اسم ثابت كامل FQDN، و2 جيجابايت ذاكرة لسيرفر تجربة، ونسخاً متماثلة في كل موقع ونسخاً احتياطية في الإنتاج.
• عطل القاعدة allow_all بعد أن تكتب قواعدك وتجربها بـ hbactest، واستخدمه في المراجعة الدورية.
• جربنا Image الرسمية 4.13.4 على Fedora 44 في Docker Desktop فرفض systemd 259 العمل على cgroups v1، فمكان FreeIPA آلة افتراضية أو نظام بـ cgroups v2.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من التوثيق الرسمي لـ FreeIPA 4.13.4، ومحاولة تشغيل quay.io/freeipa/freeipa-server:fedora-44-4.13.4 في Docker Desktop وتوثيق سبب فشلها.
• أكتوبر 2026: توسيع المقال بقصة كاملة وأقسام عن Kerberos ومدة التذاكر ومفاتيح SSH وشهادات الخدمات والنسخ المتماثلة والتكامل مع Active Directory ومزودي الهوية الخارجيين، وخمس صور جديدة.