საერთაშორისო კონკურსების SSH და სუდოს გამარჯვებულები კვლავ სცენაზე არიან. ხელმძღვანელობს გამორჩეული Active Directory დირიჟორი

ისტორიულად, სუდოს ნებართვები იმართებოდა ფაილების შინაარსით /etc/sudoers.დ и ვიზუდო, და გასაღების ავტორიზაცია განხორციელდა გამოყენებით ~/.ssh/authorized_keys. თუმცა ინფრასტრუქტურის ზრდასთან ერთად ჩნდება ამ უფლებების ცენტრალიზებული მართვის სურვილი. დღეს შეიძლება არსებობდეს გადაწყვეტის რამდენიმე ვარიანტი:

• კონფიგურაციის მართვის სისტემა - შეფ, თოჯინები, შეუძლებელია, მარილი
• Active Directory + სსსდ
• სხვადასხვა პერვერსიები სკრიპტებისა და ფაილის ხელით რედაქტირების სახით

ჩემი სუბიექტური აზრით, ცენტრალიზებული მართვის საუკეთესო ვარიანტი მაინც კომბინაციაა Active Directory + სსსდ. ამ მიდგომის უპირატესობებია:

• ნამდვილად ერთი ცენტრალიზებული მომხმარებლის დირექტორია.
• უფლებების განაწილება sudo დამოკიდებულია მომხმარებლის დამატებით უსაფრთხოების კონკრეტულ ჯგუფში.
• Linux-ის სხვადასხვა სისტემის შემთხვევაში, კონფიგურაციის სისტემების გამოყენებისას OS-ის დასადგენად საჭირო ხდება დამატებითი შემოწმებების დანერგვა.

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

მაისი
— Active Directory დომენი testopf.ადგილობრივი Windows Server 2012 R2-ზე.
- Linux ჰოსტი, რომელიც მუშაობს Centos 7-ზე
— კონფიგურირებული ავტორიზაციის გამოყენებით სსსდ
ორივე გამოსავალი ცვლის სქემას Active Directoryასე რომ, ჩვენ ვამოწმებთ ყველაფერს სატესტო გარემოში და მხოლოდ ამის შემდეგ ვაკეთებთ ცვლილებებს სამუშაო ინფრასტრუქტურაში. მინდა აღვნიშნო, რომ ყველა ცვლილება მიზანმიმართულია და, ფაქტობრივად, მხოლოდ საჭირო ატრიბუტებსა და კლასებს ემატება.

მოქმედება 1: კონტროლი sudo როლების მეშვეობით Active Directory.

წრედის გასაფართოვებლად Active Directory თქვენ უნდა ჩამოტვირთოთ უახლესი ვერსია sudo — 1.8.27 დღეის მდგომარეობით. ამოალაგეთ და დააკოპირეთ ფაილი სქემა.ActiveDirectory ./doc დირექტორიადან დომენის კონტროლერამდე. ბრძანების ხაზიდან ადმინისტრატორის უფლებებით იმ დირექტორიადან, სადაც ფაილი დაკოპირდა, გაუშვით:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(არ დაგავიწყდეთ თქვენი ღირებულებების ჩანაცვლება)
გახსნა adsiedit.msc და დაუკავშირდით ნაგულისხმევ კონტექსტს:
შექმენით განყოფილება დომენის ძირში ოფლიანობა. (ბურჟუაზია ჯიუტად ამტკიცებს, რომ დემონი სწორედ ამ ერთეულშია სსსდ ეძებს ნივთს სუდოროლი ობიექტები. თუმცა, დეტალური გამართვის ჩართვისა და ჟურნალების შესწავლის შემდეგ, გაირკვა, რომ ძიება განხორციელდა მთელი კატალოგის ხეზე.)
ჩვენ ვქმნით პირველ ობიექტს, რომელიც ეკუთვნის კლასს განყოფილებაში სუდოროლი. სახელი შეიძლება შეირჩეს აბსოლუტურად თვითნებურად, რადგან ის ემსახურება მხოლოდ მოსახერხებელი იდენტიფიკაციისთვის.
სქემის გაფართოებიდან შესაძლო ხელმისაწვდომ ატრიბუტებს შორის, მთავარია შემდეგი:

• sudoCommand — განსაზღვრავს, თუ რომელი ბრძანებებია დაშვებული ჰოსტზე შესასრულებლად.
• sudoHost — განსაზღვრავს რომელ მასპინძლებს ეხება ეს როლი. შეიძლება დაზუსტდეს როგორც ALL, და ინდივიდუალური მასპინძლისთვის სახელით. შესაძლებელია ნიღბის გამოყენებაც.
• sudoUser - მიუთითეთ, რომელი მომხმარებლების შესრულების უფლება აქვთ sudo.
  თუ თქვენ მიუთითებთ უსაფრთხოების ჯგუფს, დაამატეთ "%" ნიშანი სახელის დასაწყისში. თუ ჯგუფის სახელში არის სივრცეები, სანერვიულო არაფერია. მორების მიხედვით თუ ვიმსჯელებთ, სივრცეებიდან გაქცევის ამოცანას მექანიზმი იღებს სსსდ.

ნახ 1. sudoRole ობიექტები sudoers ქვედანაყოფში დირექტორიაში ძირში

სურათი 2. წევრობა უსაფრთხოების ჯგუფებში, რომლებიც მითითებულია sudoRole ობიექტებში.

შემდეგი დაყენება კეთდება Linux-ის მხარეს.
ფაილში /და ა.შ/nsswitch.conf დაამატეთ ხაზი ფაილის ბოლოს:

sudoers: files sss

ფაილში /და ა.შ.sssd/sssd.conf განყოფილებაში [sssd] სერვისების დამატება sudo

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

ჩვენ ვუკავშირდებით როგორც პირველი მომხმარებელი და ვამოწმებთ რა არის მისთვის ხელმისაწვდომი სუდოს ქვეშ:

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

ეს მიდგომა საშუალებას გაძლევთ ცენტრალურად განსაზღვროთ სუდო როლები მომხმარებლის სხვადასხვა ჯგუფებისთვის.

ssh კლავიშების შენახვა და გამოყენება Active Directory-ში

სქემის მცირე გაფართოებით, შესაძლებელია ssh კლავიშების შენახვა Active Directory მომხმარებლის ატრიბუტებში და მათი გამოყენება Linux ჰოსტებზე ავტორიზაციისას.

ავტორიზაცია sssd-ის საშუალებით უნდა იყოს კონფიგურირებული.
დაამატეთ საჭირო ატრიბუტი PowerShell სკრიპტის გამოყენებით.
AddsshPublicKeyAttribute.ps1ფუნქცია New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UIint64]::Parse($guid.SubString(0,4),„AllowHexSpecifier“)
$Parts+=[UIint64]::Parse($guid.SubString(4,4),„AllowHexSpecifier“)
$Parts+=[UIint64]::Parse($guid.SubString(9,4),„AllowHexSpecifier“)
$Parts+=[UIint64]::Parse($guid.SubString(14,4),„AllowHexSpecifier“)
$Parts+=[UIint64]::Parse($guid.SubString(19,4),„AllowHexSpecifier“)
$Parts+=[UIint64]::Parse($guid.SubString(24,6),„AllowHexSpecifier“)
$Parts+=[UIint64]::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 = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
ატრიბუტიId = $oid;
oMSyntax = 22;
atributSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'მომხმარებლის საჯარო გასაღები SSH შესვლისთვის';
}

New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -ფილტრი 'name -eq "user"'
$userSchema | Set-ADObject -დამატება @{mayContain = 'sshPublicKey'}

ატრიბუტის დამატების შემდეგ, თქვენ უნდა გადატვირთოთ Active Directory Domain Services.
მოდით გადავიდეთ Active Directory მომხმარებლებზე. ჩვენ გამოვქმნით გასაღების წყვილს ssh კავშირისთვის თქვენთვის მოსახერხებელი ნებისმიერი მეთოდის გამოყენებით.
ჩვენ გავუშვით PuttyGen-ს, ვაჭერთ ღილაკს "გენერაცია" და ცარიელ ადგილას მაუსის გულგრილად გადაადგილება.
პროცესის დასრულების შემდეგ ჩვენ შეგვიძლია შევინახოთ საჯარო და პირადი გასაღებები, ავტვირთოთ საჯარო გასაღები Active Directory მომხმარებლის ატრიბუტზე და ისიამოვნოთ პროცესით. თუმცა, საჯარო გასაღები უნდა იყოს გამოყენებული "საჯარო გასაღები OpenSSH authorized_keys ფაილში ჩასართავად:".

დაამატეთ გასაღები მომხმარებლის ატრიბუტში.
ვარიანტი 1 - GUI:

ვარიანტი 2 - PowerShell:
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-ზე root-ისთვის.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

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

• მე ვინახავ პაროლს ცალკე ფაილში:

  echo -n Supersecretpassword > /usr/local/etc/secretpass

• მე დავაყენე ფაილის ნებართვები 0500-ზე root-ისთვის

  chmod 0500 /usr/local/etc/secretpass

• ldapsearch გაშვების პარამეტრების შეცვლა: პარამეტრი -w superSecretPassword ვცვლი მასზე -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 კლიენტში კონფიგურირებული გასაღების ავტორიზაციით:

1. მომხმარებელი უერთდება სერვერს მისი შესვლის მითითებით.
2. sshd დემონი სკრიპტის საშუალებით ამოიღებს საჯარო გასაღების მნიშვნელობას მომხმარებლის ატრიბუტიდან Active Directory-ში და ასრულებს ავტორიზაციას კლავიშების გამოყენებით.
3. sssd დემონი დამატებით ამოწმებს მომხმარებლის ავთენტიფიკაციას ჯგუფის წევრობის საფუძველზე. ყურადღება! თუ ეს არ არის კონფიგურირებული, მაშინ დომენის ნებისმიერ მომხმარებელს ექნება წვდომა ჰოსტზე.
4. როდესაც თქვენ ცდილობთ sudo-ს, sssd დემონი ეძებს როლებს Active Directory-ში. თუ როლები არსებობს, მომხმარებლის ატრიბუტები და ჯგუფის წევრობა მოწმდება (თუ sudoRoles კონფიგურირებულია მომხმარებელთა ჯგუფების გამოსაყენებლად)

რეზიუმე.

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

წერილობით გამოყენებული რესურსები:

Sudo Active Directory-ის მეშვეობით
Ssh კლავიშები Active Directory-ის მეშვეობით
Powershell სკრიპტი, ამატებს ატრიბუტს Active Directory Schema-ში
სუდოს სტაბილური გამოშვება

წყარო: www.habr.com