Тарихи түрде sudo рұқсаттары файлдардың мазмұнымен басқарылатын /etc/sudoers.d и visudo, және негізгі авторизация көмегімен жүзеге асырылды ~/.ssh/authorized_keys. Дегенмен, инфрақұрылым өскен сайын бұл құқықтарды орталықтан басқаруға деген ұмтылыс бар. Бүгінгі күні шешімнің бірнеше нұсқасы болуы мүмкін:
- Конфигурацияны басқару жүйесі - бас, Қуыршақ, Қажет, тұз
- Active Directory + SSSD
- Сценарийлер және қолмен файлдарды өңдеу түріндегі әртүрлі бұрмалаулар
Менің субъективті пікірім бойынша, орталықтандырылған басқарудың ең жақсы нұсқасы әлі де комбинация болып табылады Active Directory + SSSD. Бұл тәсілдің артықшылықтары:
- Шынымен бір орталықтандырылған пайдаланушы каталогы.
- Құқықтарды бөлу sudo пайдаланушыны белгілі бір қауіпсіздік тобына қосуға байланысты.
- Әртүрлі Linux жүйелері жағдайында конфигурация жүйелерін пайдалану кезінде ОЖ анықтау үшін қосымша тексерулерді енгізу қажет болады.
Бүгінгі люкс қосылымға арнайы арналады Active Directory + SSSD құқықтарын басқаруға арналған sudo және сақтау SSH бір репозиторийдегі кілттер.
Сонымен, зал тыныштықта қатып қалды, дирижер таяқшасын көтерді, оркестр дайындалды.
Кеттік.
Берілгендер:
— Active Directory домені testopf.local Windows Server 2012 R2 жүйесінде.
— Centos 7 жұмыс істейтін Linux хосты
— Конфигурацияланған авторизация көмегімен SSSD
Екі шешім де схемаға өзгерістер енгізеді Active Directory, сондықтан біз барлығын сынақ ортасында тексереміз, содан кейін ғана жұмыс инфрақұрылымына өзгерістер енгіземіз. Барлық өзгерістер мақсатты және шын мәнінде тек қажетті атрибуттар мен сыныптарды қосатынын атап өткім келеді.
1-әрекет: бақылау sudo арқылы рөлдер ойнайды Active Directory.
Схеманы кеңейту үшін Active Directory соңғы шығарылымды жүктеп алу керек — бүгінгі жағдай бойынша 1.8.27. Файлды қаптамадан шығарып, көшіріңіз schema.ActiveDirectory ./doc каталогынан домен контроллеріне. Файл көшірілген каталогтан әкімші құқықтары бар пәрмен жолынан іске қосыңыз:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Мәндеріңізді ауыстыруды ұмытпаңыз)
Біз ашамыз adsiedit.msc және әдепкі контекстке қосылыңыз:
Доменнің түбірінде бөлім жасаңыз sudoers. (Буржуазия жынның дәл осы бөлімшеде екенін қыңырлықпен мәлімдейді SSSD элементті іздейді sudoRole нысандар. Дегенмен, егжей-тегжейлі жөндеуді қосқаннан және журналдарды зерттегеннен кейін іздеу бүкіл каталогтар ағашында орындалғаны анықталды.)
Бөлімде классқа жататын бірінші объектіні жасаймыз sudoRole. Атауды мүлдем ерікті түрде таңдауға болады, өйткені ол тек ыңғайлы сәйкестендіру үшін қызмет етеді.
Схема кеңейтіміндегі мүмкін қол жетімді атрибуттардың ішінде негізгілері мыналар:
- sudoCommand — хостта қандай командаларды орындауға рұқсат етілгенін анықтайды.
- sudoHost — бұл рөлдің қай хосттарға қолданылатынын анықтайды. ретінде көрсетуге болады БАРЛЫҚ, және аты бойынша жеке хост үшін. Сондай-ақ, масканы қолдануға болады.
- sudoUser — қандай пайдаланушыларға орындауға рұқсат етілгенін көрсетіңіз sudo.
Қауіпсіздік тобын көрсетсеңіз, аттың басына «%» белгісін қосыңыз. Топ атауында бос орындар болса, алаңдайтын ештеңе жоқ. Бөренелерге қарағанда, бос орындардан құтылу міндеті механизмге жүктеледі SSSD.
1-сурет. каталогтың түбіріндегі sudoers бөліміндегі sudoRole нысандары
Сурет 2. sudoRole нысандарында көрсетілген қауіпсіздік топтарындағы мүшелік.
Келесі орнату Linux жағында орындалады.
Файлда /etc/nsswitch.conf файлдың соңына жолды қосыңыз:
sudoers: files sssФайлда /etc/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
Біз бірінші пайдаланушы ретінде қосыламыз және оған 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 рөлдерін орталықтандырылған түрде анықтауға мүмкіндік береді.
Active Directory ішінде ssh кілттерін сақтау және пайдалану
Схеманы аздап кеңейту арқылы ssh кілттерін Active Directory пайдаланушы атрибуттарында сақтауға және оларды Linux хосттарында авторизациялау кезінде пайдалануға болады.
Sssd арқылы авторизация конфигурациялануы керек.
PowerShell сценарийін пайдаланып қажетті төлсипатты қосыңыз.
AddsshPublicKeyAttribute.ps1Жаңа атрибут идентификаторы {
$Префикс="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$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;
oMSсинтаксисі = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'SSH жүйесіне кіру үшін пайдаланушының жалпы кілті';
}
Жаңа-ADObject -Атауы sshPublicKey -Тип атрибутыSchema -Жол $schemapath -OtherAttributes $атрибуттар
$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'Біз оған рұқсаттарды root үшін 0500 етіп орнаттық.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Бұл мысалда әкімші тіркелгісі каталогқа байланыстыру үшін пайдаланылады. Ұрыс жағдайында ең аз құқықтар жиынтығы бар жеке шот болуы керек.
Құқықтар берілгеніне қарамастан, сценарийде құпия сөздің таза күйінде болған сәті мені қатты шатастырды.
Шешім опциясы:
- Мен құпия сөзді бөлек файлда сақтаймын:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Мен файл рұқсаттарын түбірлік үшін 0500 етіп орнаттым
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 клиентінде конфигурацияланған кілт авторизациясы бар келесі реттілік аламыз:
- Пайдаланушы өзінің логинін көрсету арқылы серверге қосылады.
- sshd демоны сценарий арқылы Active Directory ішіндегі пайдаланушы атрибутынан ашық кілт мәнін шығарады және кілттерді пайдаланып авторизацияны орындайды.
- Sssd демоны топ мүшелігіне негізделген пайдаланушыны қосымша аутентификациялайды. Назар аударыңыз! Бұл конфигурацияланбаса, кез келген домен пайдаланушысы хостқа қатынаса алады.
- Sudo әрекетін орындаған кезде, sssd демоны рөлдерді Active Directory ішінен іздейді. Рөлдер бар болса, пайдаланушы атрибуттары мен топ мүшелігі тексеріледі (егер sudoRoles пайдаланушы топтарын пайдалану үшін конфигурацияланған болса)
Нәтиже.
Осылайша, кілттер Active Directory пайдаланушы атрибуттарында, sudo рұқсаттарында сақталады - сол сияқты домен тіркелгілері арқылы Linux хосттарына қол жеткізу Active Directory тобына мүшелікті тексеру арқылы жүзеге асырылады.
Дирижер таяқшасының соңғы толқыны - және зал құрметпен тыныштықта қатып қалады.
Жазбаша пайдаланылған ресурстар:
Ақпарат көзі: www.habr.com