Group Policy-ს დანერგვის წინაპირობები

წინა სტატიაში ჩვენ ვისაუბრეთ როგორ უნდა გავაწევრიანოთ Linux-ის კომპიუტერი Windows Active Directory-ში. ასეთი გაწევრიანების მიზეზია როგორც ერთიანი ავთენთიფიკაციის მექანიზმის გამოყენება, ასევე ჯგუფური პოლიტიკების გავრცელება. სწორედ რომ ჯგუფური პოლიტიკების გამოყენებაზე ვისაუბრებთ დღევანდელ სტატიაში. რა თქმა უნდა ჩვენ უნდა გვესმოდეს რომ სრულყოფილი ჯგუფური პოლიტიკების გამოყენება Linux სისტემებზე არ გამოვა. საუბარია მხოლოდ ისეთი ჯგუფური პოლიტიკების გამოყენებაზე, რომელიც კავშირშია ავთენთიფიკაციის პროცესთან.

პირველ რიგში /etc/sssd/sssd.conf შევცვალოთ ad_gpo_access_control ხაზი:

ad_gpo_access_control = permissive

გაითვალისწინეთ, რომ კონფიგურაციის ყოველი ცვლილების შემდეგ, თქვენ უნდა გადატვირთოთ SSSD და შეამოწმოთ ლოგები შეცდომებზე. ეს შეიძლება განხორციელდეს შემდეგი ბრძანებებით:

systemctl restart sssd
systemctl status sssd
journalctl -u sssd

ამ პარამეტრს (permissive) აქვს იგივე შედეგი, რაც წინა სტატიაში ნახსენებ ad_gpo_access_control=disabled, მაგრამ ეხლა ლოგებში შეცდომები გაიგზავნება ყოველ ჯერზე, როცა GPO პარამეტრი დაბლოკავს login-ს. ეს საშუალებას მოგცემთ განახორციელოთ აუდიტი და შეამოწმოთ თქვენი გარემო ახალი პოლიტიკის გამოყენებამდე.

თქვენი სისტემის ლოგების მდებარეობა დამოკიდებულია თქვენს Linux დისტროზე. მაგალითად, Ubuntu სისტემისთვის სტანდარტულად გამოიყენება /var/log/auth.log. ლოგებში ეძებეთ ისეთი საკვანძო სიტყვები, როგორიცაა pam_sss და sssd_be.

ლინუქსი ავთენტიფიკაციისთვის იყენებს PAM-ს (Pluggable Authentication Module). თითოეულ სერვისს შეუძლია გამოიყენოს საკუთარი PAM კონფიგურაცია (მაგ., SSH იყენებს /etc/pam.d/sshd და XRDP იყენებს /etc/pam.d/xrdp-sesman). თქვენ შეგიძლიათ ნახოთ PAM-ის კონფიგურაციების სია /etc/pam.d-ის შიგთავსის ჩამოთვლით.

Group Policy-ს User Rights Assignment  მიმოხილვა შეგიძლიათ იხილოთ Microsoft-ის დოკუმენტაციაში.

Group Policy-ს ლინუქსოიდური სპეციფიკა

Windows-ისგან განსხვავებით, სადაც Group Policy პარამეტრები ინახება რეესტრში,  Linux დინამიურად მოიძიებს და გამოიყენებს GPO-ს Active Directory-დან.

ეს ნიშნავს, რომ SSSD არ ცვლის Linux  კონფიგურაციის ფაილებს. ამის ნაცვლად, ის იყენებს PAM-ს ავტორიზაციის პროცესის ჩასარევად და მის შესაცვლელად.

როდესაც მომხმარებელი ცდილობს შევიდეს Linux სისტემაში, SSSD ჯერ ამოწმებს, არის თუ არა GPO, რომელიც ეხება ამ მომხმარებელს და სისტემას. თუ არსებობს, SSSD გამოითხოვს GPO პარამეტრებს და შესაბამისად აკონფიგურირებს PAM მოდულს.

მაგალითად, GPO-თი შეგვიძლია დავადგინოთ, რომ სისტემაში შესვლა მხოლოდ გარკვეულ ჯგუფში შემავალ მომხმარებლებს შეუძლიათ . SSSD აკონფიგურირებს PAM მოდულს, რათა დაბლოკოს შესვლის მცდელობები არა ამ ჯგუფის მომხმარებლეთათვის.

SSSD ქეშინგი

SSSD-ს აქვს ქეში, რომელსაც იყენებს მომხმარებლების, ჯგუფებისა და სხვა ობიექტების შესახებ მონაცემების შესანახად. ქეშის წყალობით SSSD-ს უფრო იშვიათად სჭირდება დაკავშირება AD პროვაიდერთან.
SSSD ქეშის გასაწმენდად და შესაბამისად უახლოესი მონაცემების შესამოწმებლად შეგიძლიათ გამოიყენოთ sss_cache ბრძანება. Მაგალითად:

sss_cache -u jsmith # Flushes a specific user cache
sss_cache -g group # Flushes a specific group cache
sss_cache -U # Flushes all user caches
sss_cache -G # Flushes all group caches
sss_cache -E # Flushes everything

პოლიტიკების ბმა სხვა სოფტთან

სხვა სოფტი, როგორიცაა XRDP ან RStudio სერვერი,  ნაგულისხმევად არ არის დაკავშირებული GPO-სთან; შესაბამისად, მათი PAM მოდულების მეშვეობით ყველა შესვლა უარყოფილი იქნება (ad_gpo_map_default_right კონტროლის მიხედვით). ვინაიდან XRDP და RStudioც ინტერაქტიული დესკტოპის სერვისებია, ლოგიკური იქნება მათი გადაბმა RDP სერვისზე.  /etc/sssd/sssd.conf მიუთითეთ:

ad_gpo_map_remote_interactive = +xrdp-sesman, +rstudio

+ ნიშანი აღნიშნავს რომ ეს სერვისები უნდა დაემატოს შესაბამის ბმას. მინუს ნიშანი, პირიქით, მოხსნის სერვისს შესაბამისი ბმიდან, თუნდაც ის ბმა ნაგულისხმევად ყოფილიყო განსაზღვრული.

ეს მეთოდი შეიძლება გამოვიყენოთ სერვისების ხელახალი გადაბმისთვის, მაგალითად, თუ თქვენი ორგანიზაციაში არსებობს SSH  ავტომატიზირებული SSH-FTP სერვისებისთვის და, შესაბამისად, გსურთ გამოიყენოთ GPO, რომელიც განსაზღვრავს ამ კომპიუტერზე წვდომას უფლებებს.

ad_gpo_map_remote_interactive = -sshd
ad_gpo_map_network = +sshd
ad_gpo_map_permit და ad_gpo_map_deny პარამეტრები ჩამოთვლიან სერვისებს, რომლებიც ყოველთვის იქნება დაშვებული ან უარყოფილი GPO-ს მიუხედავად. მაგალითად, Windows-სა და Windows Server-ს ამჟამად არ გვაქვს ჯგუფური პოლიტიკის პარამეტრი, რომელიც ეხება Microsoft-ის მიერ მოწოდებულ OpenSSH-ს Windows-ზე. მაგრამ  ლინუქსში შეგვიძლია მივუთითოთ:

ad_gpo_map_permit = +sshd

ნაგულისხმევი პარამეტრები დამოკიდებულია ლინუქსის დისტროზე და დაინსტალირებულ პაკეტებზე (მაგ., desktop manager gdm ან lightdm შეიძლება იყენებდეს სხვა PAM სერვისს). თუ რაიმე  არ მუშაობს, შეამოწმეთ service და authentication log-ები  და დარწმუნდით  იყენებს თუ არა თქვენი დისტრო/პაკეტი PAM-ს ავტორიზაციისთვის. საჭიროებისამებრ შეცვალეთ ბმები

ad_gpo_default_right კონტროლი სტანდარტულად დაყენებულია უარყოფაზე. თუ რაიმე ახალი, აქამდე უცნობი PAM სერვისი ითხოვს წვდომას, დააყენეთ კონტროლი interactive, remote_interactive, network, batch, ან service მნიშვნელობაზე, რათა აკონტროლოთ შესაბამისი GPO გამოყენება; ალტერნატიულად, ავტომატური ნებართვის დაშვება შეგიძლიათ კონტროლით permit. მაგრამ ასეთი კონტროლი თავის თავში გულისხმობს უსაფრთხოების პრობლემას: ყველას აქვს წვდომის უფლება (გარდა იმათი, ვისაც კონკრეტულად ავუკრძალეთ წვდომა).

კონფიგურაციის ბოლოს შეამოწმეთ ლოგები, რათა დარწმუნდეთ, რომ არ აძლევთ უფლებას ან პირიქით არ ბლოკავთ ვინმეს ვისი დაშვებაც ან დაბლოკვაც არ გინდოდათ.

როდესაც კმაყოფილი იქნებით თქვენი კონფიგურაციით, შეცვალეთ ad_gpo_access_control თქვენს SSSD კონფიგურაციაში enforcing-ზე. არ დაგავიწყდეთ სერვისის დარესტარტება (systemctl restart sssd).

თუ ქსელში არის სერვისი (მაგ. ვებ სერვისი), რომელიც არ იყენებს PAM-ს ან SSSD-ს და იყენებს საკუთარ Active Directory-ს ან LDAP ავთენტიფიკაციას რა თქმა უნდა მის გაკონტროლებას ზემოთ ხსენებული მეთოდებით ვერ შეძლებთ. გარდა ამისა, სერვისებს შეიძლება ჰქონდეთ საკუთარი უსაფრთხოების მექანიზმები, რომლებმაც შეიძლება დაუშვან ან უარყონ logon GPO-მდე ან მის მერე. გადაამოწმეთ ასეთი აპლიკაციები თუ სერვისები საფუძვლიანად, რათა დარწმუნდეთ, რომ არსებული კონფიგურაციები შეესაბამებიან თქვენ მოლოდინებს.