Linux დიდი ხანია მხარს უჭერს LDAP ავტორიზაციის მხარდაჭერას Active Directory-ში. მაგრამ Active Directory-ის ძალიან დიდ forest-ებში, სტანდარტულ კონფიგურაციებს შეუძლიათ ავტორიზაცია უკიდურესად შეანელონ.

ეს არასტანდარტული მეთოდიკა დატესტილია Debian 10 და 11, Ubuntu 20-22, და Red Hat 7 – 9-ზე. თუმცა დიდი ალბათობით იმუშავებს სხვა მონათესავე დისტრიბუტივებზე.

საჭირო პაკეტების დაყენება

საბაზისო პაკეტები realmd-ისთვის (გამოიყენება Active Directory-თან დაკავშირებული ქსელის ავთენტიფიკაციის სერვისების კონფიგურაციისა და მართვისთვის) და System Security Services Daemon-ისთვის (SSSD — პროგრამული კომპონენტი, რომელიც ჩვეულებრივ გამოიყენება Linux სისტემებში ცენტრალიზებული ავტორიზაციის უზრუნველსაყოფად) როგორც წესი სტანდარტულად არ ყენდება დისტრიბუტივის დესკტოპ ვერსიებში. ამიტომ ჩვენ გამოვიყენებთ apt-get ბრძანებას, რომელიც აინსტალირებს პაკეტებს და მათ დამოკიდებულებებს Debian ტიპის დისტრიბუტივებზე  (მათ შორის სერვერის ან უბუნტუს ღრუბლოვან ვერსიებზე).

Active Directory-თან დასაკავშირებლად ჩვენ დამატებით გვჭირდება sssd-ad, AD დანამატი SSSD-სთვის და adcli, რომელიც არის ინსტრუმენტი AD ჩანაწერების შესაცვლელად. libnss-sss და libpam-sss უზრუნველყოფს ბმას SSSD-სა და PAM/NSS არქიტექტურას შორის, რომელსაც ემყარება ავთენტიფიკაციის ყველა მექანიზმი Linux-ზე.

Oddjob-mkhomedir შეიცავს მეთოდებს (hooks), რომლებიც შესვლისთანავე ავტომატურად ქმნიან home დირექტორიებს . გარდა ამისა, cifs-utils და samba-common-bin შეიცავს SMB პროტოკოლის იმპლემენტაციას, ხოლო msktutil და krb5-user გამოიყენება კომპიუტერისა და მომხმარებლის ობიექტების Kerberos ticket-ების მისაღებად და გასაახლებლად.

მაშ ასე, Debian დისტრიბუტივებზე გავუშვათ ბრძანება:

apt install realmd sssd oddjob oddjob-mkhomedir adcli sssd-ad cifs-utils msktutil libnss-sss libpam-sss sssd-tools samba-common-bin krb5-user

Red Hat ოჯახის დისტრიბუტივებისთვის კი გამოგვადგება ბრძანება:

dnf install realmd sssd oddjob oddjob-mkhomedir adcli sssd-ad cifs-utils msktutil krb5-workstation krb5-libs samba-common-tools

Red Hat-ზე დაფუძნებულ დისტრიბუტებზე პროგრამული უზრუნველყოფის მართვისთვის ამჟამად გამოიყენება dnf . თუ დისტროს არ აქვს dnf (Red Hat 7), შეცვალეთ ის მისი წინამორბედით, yum-ით.

realm list ბრძანება გამოიყენება Active Directory დომენის ან სხვა identity პროვაიდერების სიის მისაღებად, რომლ(ებ)ზეც დაჯოინებულია მოცემული Linux სისტემა. ეს ბრძანება გვაწვდის ინფორმაციას ამჟამად კონფიგურირებული დომენის ან დომენების შესახებ და აჩვენებს ისეთ დეტალებს, როგორიცაა დომენის სახელი, დომენის ტიპი (მაგ., Active Directory) და კავშირის სტატუსი. ბრძანება მოითხოვს kerberos და ldap SRV ჩანაწერებს DNS-ში. თუ realm list არ აბრუნებს შესაბამისი დომენის მონაცემებს, დარწმუნდით, რომ თქვენი DNS აბრუნებს ჩანაწერებს, როგორც ეს აღწერილია Microsoft-ის ამ სტატიაში.

 

დაჯოინება

AD-ში დაჯოინებისთვის ვიყენებთ ბრძანება realm-ს

realm join -U ad_user domain.tld --computer-ou="ou=computers,ou=department"

–computer-ou ოფცია არ საჭიროებს დაკონკრეტებას, თუ ამ კომპიუტერის ობიექტი უკვე არსებობს AD-ში.

ეს ბრძანება მოითხოვს მოხმარებლის იუზერს და პაროლს. შემდგომში ის დააკონფიგურირებს SSSD daemon-ს. ამ ეტაპზე, ჩართეთ მომხმარებლის home დირექტორიის ავტომატური შექმნა authselect (Red Hat) ან pam-auth-update (Debian) ინსტრიმენტის გამოყენებით.

ახლა თქვენ უნდა შეძლოთ თქვენ მომხარებელზე ინფორმაციის მიღება  სრულად კვალიფიციური მომხმარებლის სახელის (FQUN) გამოყენებით. @ სიმბოლოს წინ გამოიყენეთ escape სიმბოლო \ (როგორც ეს სურათზეა ნაჩვენები), რადგან ზოგიერთი shell  @ სიმბოლოს თავისებურად განმარტავს

შექმენის კონფიგურაციის ფაილის სარეზერვო ასლი (ბრძანების პირველი სტრიქონი) და შემდეგ დაარედაქტირეთ ორიგინალი ფაილი. თუ არ გაქვთ  sssd.conf ფაილი, სისტემა არ გადატვირთოთ, რადგან თქვენი სისტემა შეიძლება არ ჩაიტვირთოს ან სისტემაში ვერ შეხვიდეთ. ასეთ დროს მოგიწევთ აღდგენის რეჟიმის გამოყენება.

cp /etc/sssd/sssd.conf /etc/sssd/sssd.orig
nano /etc/sssd/sssd.conf
ამის შემდეგ შეგიძლიათ დაარედაქტიროთ კონფიგურაციის ფაილი დაახლოებით ასე
[sssd]
config_file_version = 2
services = nss, pam
domains = domain.tld
default_domain_suffix = domain.tld


[domain/domain.tld]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = დ
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
ldap_sasl_authid = HOSTNAME$
fallback_homedir = /home/%d/%u
ad_domain = domain.tld
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
ad_gpo_access_control = disabled
enumerate = False
ignore_group_members = True

[nss]
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

რა თქმა უნდა DOMAIN.TLD უნდა შეცვალოთ თქვენი დომენის დასახელებით შემდეგ სტრიქონში (და ყველა სხვა სტრიქონში სადაც მისი ხსენებაა)

კონფიგურაციის ფაილის განხილვა

default_domain_suffix = domain.tld

ეს ჩანაწერი განსაზღვრავს „ნაგულისხმევ“ დომენს, რომელსაც შესვლისას თქვენი იუზერები გამოიყენებენ . ჩვეულებრივ, მომხმარებლები უნდა შევიდნენ თავიანთი FQUN-ის გამოყენებით (მაგ., myaduser@mydomain.test). მაგრამ როცა default_domain_suffix არსებობს მომხმარებელს მხოლოდ myaduser-ის შეყვანა მოუწევს.

თუ თქვენ გაქვთ მულტიდომენური forest, სხვა დომენების მომხმარებლებს კვლავ შეუძლიათ გამოიყენონ FQUN (მაგალითად: hraduser@hr.mydomain.test)

თუ თქვენს დომენს აქვს Unix extensions, LDAP ატრიბუტები არეგულირებენ ნაგულისხმევი shell-ს და home directory პარამეტრებს. კონფიგურაციის ფაილის ეს ნაწილი

default_shell = /bin/bash
fallback_homedir = /home/%d/%u

ადგენს ნაგულისხმევს, თუ მომხმარებელს არ აქვს ეს ატრიბუტები, ან თქვენს დომენს არ აქვს Unix extensions.

%d/%u-ს ჩანაწერის წყალობით მომხმარებლის ანგარიშები სხვადასხვა დომენში მსგავსი sAMAccountNames არ გამოიწვევენ კონფლიქტს (jdoe@finance.mydomain.test და jdoe@hr.mydomain.test). %d შეიცვლება მომხმარებლის დომენით შესვლისას. %u არის მომხმარებლის სახელი, სავარაუდოდ sAMAccountName ატრიბუტი. ზემოთ მოყვანილი მაგალითის გამოყენებით, ერთი მომხმარებელი შევა /home/finance.mydomain.test/jdoe, ხოლო მეორე გამოიყენებს /home/hr.mydomain.test/jdoe.
ამ ნაწილში ჩვენ ვთიშავთ GPO access control-ს:
ad_gpo_access_control = disabled

მიუხედავად იმისა, რომ ყველა აპლიკაციამ (მაგ., RDP) არ იცის GPO-ს შესახებ, ლოკალური შესვლა ჩვეულებრივ ინტერპრეტირდება როგორც „Allow log on locally“, ხოლო SSH (დისტანციური) შესვლა იყენებს „Allow log on through Remote Desktop Services“ GPO-ს.

თუმცა, GPO-ს სრული გამორთვის შედეგად, ვერავინ შეძლებს დალოგინებას. იმისათვის, რომ ნებისმიერს, ვისაც აქვს აქტიური AD credentials, შესვლის უფლებას მიეცეს კონფიგურაციის ფაილში დაამატეთ:

realm permit –all

თუმცა ეს მეთოდი ნაკლებად უსაფრთხოა, უმჯობესი იქნება რომ კონკრეტულად განსაზღვროთ დაშვებული ჯგუფები:

realm deny –all
realm permit user@domain.tld
realm permit -g group@domain.tld

კონფიგურაციის ქვემოთ მოცემული სტრიქონები გათვლილია დიდი ზომის AD-ზე. სტანდარტულად, SSSD ჩამოიწერს (retrieve and cache) ყველა მომხმარებლის და ჯგუფის  ინფორმაციას, რაც დიდ დომენებში კატასტროფის ტოლფასია. ქეშირებას სისტემა დიდ დროს და memory-ს მოახმარს. შემდგომში დომენის ინფორმაციის მოძიება (მაგ., id და getent calls) ძალიან ნელდება. მოცემულ კონფიგურაციაში, ჩვენ ვაიგნორებთ nested ჯგუფებს. თუ თქვენ გარემოში ეს პირიქით მნიშვნელოვანია  შეიძლება დაგჭირდეთ მისი ჩართვა(ignore_group_members = true).

enumerate = False
ignore_group_members = True

მომხმარებლებს მათი ინფორმაცია ადგილობრივად ქეშირებული ექნებათ. კონფიგურაციის ფაილის  NSS განყოფილება ზრდის RAM-ის ნაგულისხმევ ქეშს 200 მბ-მდე, რაცა ასწრაფებს getent მოთხოვნებს. დარწმუნდით, რომ თქვენ შემთხვევაში ქეშის ზომაა მომხმარებელთა რაოდენობის მიხედვით სწორადაა შერჩეული და არ გამოიწვევს სისტემის გაჭედვას.

nss
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

SSSD გაშვება

მას შემდეგ რაც მორჩებით კონფიგურაციის ფაილთან მუშაობას დაარესტარტეთ სერვისი

systemctl restart sssd

სერვისის სტატუსის შესამოწმებლად გამოიყენეთ

systemctl status sssd

ხოლო log-ის სანახავად კი:

journalctl -u sssd