تاريخيًا، كانت أذونات Sudo محكومة بمحتويات الملفات من /etc/sudoers.d и visudo، وتم تنفيذ الترخيص الرئيسي باستخدام ~ / .ssh / author_keys. ومع ذلك، مع نمو البنية التحتية، هناك رغبة في إدارة هذه الحقوق مركزيًا. اليوم قد يكون هناك العديد من خيارات الحل:
- نظام إدارة التكوين - تشف, دمية, Ansible, ملح
- نشط الدليل + ssd
- انحرافات مختلفة في شكل البرامج النصية والتحرير اليدوي للملفات
في رأيي الشخصي، فإن الخيار الأفضل للإدارة المركزية لا يزال هو الجمع نشط الدليل + ssd. مزايا هذا النهج هي:
- حقا دليل مستخدم مركزي واحد.
- توزيع الحقوق سودو يتعلق الأمر بإضافة مستخدم إلى مجموعة أمان معينة.
- في حالة أنظمة Linux المختلفة، يصبح من الضروري تقديم فحوصات إضافية لتحديد نظام التشغيل عند استخدام أنظمة التكوين.
سيتم تخصيص جناح اليوم خصيصًا للاتصال نشط الدليل + ssd لإدارة الحقوق سودو والتخزين سه المفاتيح في مستودع واحد.
فتجمدت القاعة في صمت متوتر، ورفع قائد الفرقة الموسيقية هراوته، واستعدت الأوركسترا.
دعونا نذهب.
الممنوحة:
- مجال الدليل النشط testopf.local على ويندوز سيرفر 2012 R2.
— مضيف Linux يعمل بنظام Centos 7
— إذن تكوين باستخدام ssd
يقوم كلا الحلين بإجراء تغييرات على المخطط نشط الدليل، لذلك نتحقق من كل شيء في بيئة اختبار وبعد ذلك فقط نجري تغييرات على البنية التحتية للعمل. أود أن أشير إلى أن جميع التغييرات مستهدفة، وفي الواقع، أضف فقط السمات والفئات الضرورية.
الإجراء 1: السيطرة سودو الأدوار من خلال نشط الدليل.
لتوسيع الدائرة نشط الدليل تحتاج إلى تنزيل أحدث إصدار – 1.8.27 اعتبارًا من اليوم. قم بفك ضغط الملف ونسخه schema.ActiveDirectory من الدليل ./doc إلى وحدة تحكم المجال. من سطر الأوامر الذي يتمتع بحقوق المسؤول من الدليل الذي تم نسخ الملف فيه، قم بتشغيل:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(لا تنس استبدال قيمك)
فتح adsiedit.msc والاتصال بالسياق الافتراضي:
إنشاء قسم في جذر المجال sudoers. (تدعي البرجوازية بعناد أنه في هذه الوحدة يوجد الشيطان ssd يبحث عن عنصر sudoRole أشياء. ومع ذلك، بعد تشغيل التصحيح التفصيلي ودراسة السجلات، تم الكشف عن إجراء البحث عبر شجرة الدليل بأكملها.)
نقوم بإنشاء الكائن الأول الذي ينتمي إلى الفصل في القسم sudoRole. يمكن اختيار الاسم بشكل تعسفي تمامًا، لأنه يعمل فقط على تحديد الهوية بسهولة.
من بين السمات المتاحة المحتملة من ملحق المخطط، السمات الرئيسية هي التالية:
- sudoCommand — تحديد الأوامر المسموح بتنفيذها على المضيف.
- sudoHost — يحدد المضيفين الذين ينطبق عليهم هذا الدور. يمكن تحديدها ك الجميعولمضيف فردي بالاسم. من الممكن أيضًا استخدام القناع.
- sudoUser - الإشارة إلى المستخدمين المسموح لهم بالتنفيذ سودو.
إذا قمت بتحديد مجموعة أمان، أضف علامة "%" في بداية الاسم. إذا كانت هناك مسافات في اسم المجموعة، فلا داعي للقلق. إذا حكمنا من خلال السجلات، فإن مهمة الهروب من المساحات تتولى الآلية ssd.
الشكل 1. كائنات sudoRole في قسم sudoers الفرعي في جذر الدليل
الشكل 2. العضوية في مجموعات الأمان المحددة في كائنات sudoRole.
يتم الإعداد التالي على جانب Linux.
في ملف /etc/nsswitch.conf أضف السطر إلى نهاية الملف:
sudoers: files sssفي ملف /etc/sssd/sssd.conf في قسم [سسسد] إضافة إلى الخدمات سودو
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
بعد كل العمليات، تحتاج إلى مسح ذاكرة التخزين المؤقت للبرنامج الخفي sssd. تحدث التحديثات التلقائية كل 6 ساعات، ولكن لماذا يجب أن ننتظر طويلاً عندما نريدها الآن؟
sss_cache -Eغالبًا ما يحدث أن مسح ذاكرة التخزين المؤقت لا يساعد. ثم نقوم بإيقاف الخدمة وتنظيف قاعدة البيانات وبدء الخدمة.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
نتواصل كمستخدم أول ونتحقق مما هو متاح له ضمن sudo:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catنحن نفعل الشيء نفسه مع مستخدمنا الثاني:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
يتيح لك هذا الأسلوب تحديد أدوار Sudo مركزيًا لمجموعات مستخدمين مختلفة.
تخزين واستخدام مفاتيح ssh في Active Directory
مع توسيع طفيف للمخطط، من الممكن تخزين مفاتيح ssh في سمات مستخدم Active Directory واستخدامها عند التفويض على مضيفي Linux.
يجب تكوين التفويض عبر sssd.
أضف السمة المطلوبة باستخدام برنامج PowerShell النصي.
AddsshPublicKeyAttribute.ps1الوظيفة الجديدة-معرف السمة {
$البادئة = "1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$أجزاء=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier")
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = معرف السمة الجديد
سمات $ = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'المفتاح العام للمستخدم لتسجيل الدخول إلى SSH';
}
جديد-ADObject -الاسم sshPublicKey -نوع مخطط السمات -المسار $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$ مخطط المستخدم | Set-ADObject -إضافة @{mayContain = 'sshPublicKey'}
بعد إضافة السمة، يجب عليك إعادة تشغيل خدمات مجال Active Directory.
دعنا ننتقل إلى مستخدمي Active Directory. سنقوم بإنشاء زوج مفاتيح لاتصال ssh باستخدام أي طريقة مناسبة لك.
نطلق PuttyGen، ونضغط على زر "إنشاء" ونحرك الماوس بشكل محموم داخل المنطقة الفارغة.
عند الانتهاء من العملية، يمكننا حفظ المفاتيح العامة والخاصة، وتحميل المفتاح العام إلى سمة مستخدم Active Directory والاستمتاع بالعملية. ومع ذلك، يجب استخدام المفتاح العام من "المفتاح العام للصقه في ملف OpenSSH Author_keys:".
أضف المفتاح إلى سمة المستخدم.
الخيار 1 - واجهة المستخدم الرسومية:
الخيار 2 - بوويرشيل:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
لذلك، لدينا حاليًا: مستخدم تم ملء سمة sshPublicKey به، وعميل Putty تم تكوينه للحصول على التفويض باستخدام المفاتيح. تبقى نقطة واحدة صغيرة: كيفية إجبار البرنامج الخفي sshd على استخراج المفتاح العام الذي نحتاجه من سمات المستخدم. يمكن لبرنامج نصي صغير موجود على الإنترنت البرجوازي التعامل مع هذا بنجاح.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'قمنا بتعيين الأذونات عليه على 0500 للجذر.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
في هذا المثال، يتم استخدام حساب المسؤول للربط بالدليل. في ظروف القتال يجب أن يكون هناك حساب منفصل مع الحد الأدنى من الحقوق.
أنا شخصياً كنت في حيرة شديدة من لحظة ظهور كلمة المرور بشكلها النقي في النص، على الرغم من ضبط الحقوق.
خيار الحل:
- أقوم بحفظ كلمة المرور في ملف منفصل:
echo -n Supersecretpassword > /usr/local/etc/secretpass - لقد قمت بتعيين أذونات الملف على 0500 للجذر
chmod 0500 /usr/local/etc/secretpass - تغيير معلمات تشغيل ldapsearch: المعلمة -w كلمة المرور الفائقة أغيره إلى -y /usr/local/etc/secretpass
الوتر الأخير في مجموعة اليوم هو تحرير sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
ونتيجة لذلك، نحصل على التسلسل التالي مع ترخيص المفتاح الذي تم تكوينه في عميل ssh:
- يتصل المستخدم بالخادم من خلال الإشارة إلى تسجيل الدخول الخاص به.
- يستخرج البرنامج الخفي sshd، من خلال برنامج نصي، قيمة المفتاح العام من سمة المستخدم في Active Directory ويقوم بإجراء التفويض باستخدام المفاتيح.
- يقوم البرنامج الخفي sssd أيضًا بمصادقة المستخدم بناءً على عضوية المجموعة. انتباه! إذا لم يتم تكوين هذا، فسيتمكن أي مستخدم مجال من الوصول إلى المضيف.
- عندما تحاول Sudo، يبحث البرنامج الخفي sssd في Active Directory عن الأدوار. في حالة وجود الأدوار، يتم التحقق من سمات المستخدم وعضوية المجموعة (إذا تم تكوين SudoRoles لاستخدام مجموعات المستخدمين)
ملخص.
وبالتالي، يتم تخزين المفاتيح في سمات مستخدم Active Directory، وأذونات Sudo - وبالمثل، يتم الوصول إلى مضيفي Linux من خلال حسابات المجال عن طريق التحقق من العضوية في مجموعة Active Directory.
الموجة الأخيرة لعصا قائد الفرقة الموسيقية - وتتجمد القاعة في صمت موقر.
المصادر المستخدمة في الكتابة:
المصدر: www.habr.com