Историски гледано, дозволите за sudo беа регулирани од содржината на датотеките од /etc/sudoers.d и визудо, а овластувањето за клучот беше извршено со користење ~/.ssh/authorized_keys. Меѓутоа, како што расте инфраструктурата, постои желба централно да се управува со овие права. Денес може да има неколку опции за решение:
- Систем за управување со конфигурација - готвач, куклен, Ansible, Сол
- Active Directory + ssd
- Различни перверзии во форма на скрипти и рачно уредување на датотеки
Според мое субјективно мислење, најдобрата опција за централизирано управување е сепак комбинацијата Active Directory + ssd. Предностите на овој пристап се:
- Навистина единствен централизиран кориснички директориум.
- Распределба на правата sudo се сведува на додавање корисник во одредена безбедносна група.
- Во случај на различни системи Линукс, станува неопходно да се воведат дополнителни проверки за да се одреди оперативниот систем кога се користат системи за конфигурација.
Денешниот пакет ќе биде посветен конкретно на поврзувањето Active Directory + ssd за управување со правата sudo и складирање SSH клучеви во едно складиште.
Така, салата замрзна во напната тишина, диригентот ја крена палката, а оркестарот се подготви.
Оди
Со оглед:
— Домен на Active Directory тестопф.локален на Windows Server 2012 R2.
- Линукс домаќин кој работи на Centos 7
— Конфигурирано овластување користејќи ssd
Двете решенија прават промени во шемата Active Directory, затоа проверуваме сè во тест средина и дури потоа правиме промени во работната инфраструктура. Би сакал да забележам дека сите промени се насочени и, всушност, ги додаваат само потребните атрибути и класи.
Акција 1: контрола sudo улоги преку Active Directory.
За проширување на колото Active Directory треба да го преземете најновото издание — 1.8.27 од денес. Отпакувајте ја и копирајте ја датотеката шема.ActiveDirectory од директориумот ./doc до контролерот на доменот. Од командната линија со администраторски права од директориумот каде што е копирана датотеката, извршете:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Не заборавајте да ги замените вашите вредности)
Отворено adsiedit.msc и поврзете се со стандардниот контекст:
Направете поделба во коренот на доменот потење. (Буржоазијата тврдоглаво тврди дека демонот е во оваа единица ssd бара ставка sudoRole предмети. Меѓутоа, по вклучувањето на деталното дебагирање и проучувањето на дневниците, беше откриено дека пребарувањето е извршено низ целото стебло на директориуми.)
Го креираме првиот објект што припаѓа на класата во поделбата sudoRole. Името може да се избере апсолутно произволно, бидејќи служи исклучиво за удобна идентификација.
Меѓу можните достапни атрибути од наставката на шемата, главните се следниве:
- sudoCommand — одредува кои команди се дозволени да се извршуваат на домаќинот.
- sudoHost — одредува на кои домаќини се однесува оваа улога. Може да се наведе како СИТЕ, и за индивидуален домаќин по име. Исто така е можно да се користи маска.
- sudoКорисник — наведете кои корисници смеат да ги извршуваат sudo.
Ако наведете безбедносна група, додадете знак „%“ на почетокот на името. Ако има празни места во името на групата, нема што да се грижите. Судејќи според трупците, задачата за бегство од простори ја презема механизмот ssd.
Сл. 1. објектите sudoRole во подподелбата sudoers во коренот на директориумот
Слика 2. Членство во безбедносни групи наведени во објектите sudoRole.
Следното поставување е направено на страната на Linux.
Во датотека /тнк/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 улогите за различни кориснички групи.
Складирање и користење ssh клучеви во Active Directory
Со мало проширување на шемата, можно е да се складираат ssh клучеви во корисничките атрибути на Active Directory и да се користат при авторизирање на хостови на Linux.
Овластувањето преку sssd мора да се конфигурира.
Додадете го потребниот атрибут користејќи PowerShell скрипта.
AddsshPublicKeyAttribute.ps1Функција Нов-АтрибутИД {
$Префикс = "1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Парсе ($guid.SubString(0,4),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($guid.SubString(4,4),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($guid.SubString(9,4),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($guid.SubString(14,4),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($guid.SubString(19,4),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($guid.SubString(24,6),„AllowHexSpecifier“)
$Parts+=[UInt64]::Парсе ($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])
$оид
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = Нов-Атрибут ID
$атрибути = @{
lDAPDisplayName = 'sshPublicKey';
атрибутId = $oid;
oMSинтакса = 22;
atributSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Кориснички јавен клуч за најавување SSH';
}
Нов-ADObject -Име sshPublicKey -Тип атрибутSchema -Пат $schemapath -ДругиАтрибути $атрибути
$userSchema = get-adobject -SearchBase $schemapath -Филтер „име -eq „корисник““
$userSchema | Set-ADObject -Додај @{mayContain = 'sshPublicKey'}
Откако ќе го додадете атрибутот, мора да ги рестартирате услугите на доменот на Active Directory.
Ајде да преминеме на корисниците на 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 superSecret Password Го менувам во -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