СШ жана судо боюнча эл аралык мелдештердин жеңүүчүлөрү кайрадан сахнага чыгышты. Ардактуу Active Directory дирижеру жетектеген

Тарыхый жактан, sudo уруксаттары файлдардын мазмуну менен башкарылчу /etc/sudoers.d и Visudo, жана негизги уруксат колдонуу менен ишке ашырылган ~/.ssh/authorized_keys. Бирок, инфраструктура өсүп жаткандыктан, бул укуктарды борбордон башкаруу каалоосу бар. Бүгүнкү күндө бир нече чечим варианттары болушу мүмкүн:

  • Конфигурацияны башкаруу системасы - баш, куурчак, Ansible, туз
  • Active Directory + ssd
  • Скрипттер жана кол менен файлдарды түзөтүү түрүндөгү ар кандай бузукулар

Менин субъективдүү пикиримде, борборлоштурулган башкаруунун эң жакшы варианты дагы эле айкалыштыруу болуп саналат Active Directory + ssd. Бул ыкманын артыкчылыктары болуп төмөнкүлөр саналат:

  • Чынында эле бирдиктүү борборлоштурулган колдонуучу каталогу.
  • Укуктарды бөлүштүрүү Sudo белгилүү бир коопсуздук тобуна колдонуучуну кошуу үчүн келип чыгат.
  • Ар кандай Linux системаларында конфигурация системаларын колдонууда ОСти аныктоо үчүн кошумча текшерүүлөрдү киргизүү зарыл болуп калат.

Бүгүнкү сюита атайын байланышка арналат Active Directory + ssd укуктарды башкаруу үчүн Sudo жана сактоо SSH бир репозиторийдеги ачкычтар.
Ошентип, зал чымырканган жымжырттыкка тоңуп, дирижер эстафетасын көтөрдү, оркестр даярданды.
Бар.

Берилген:
— Active Directory домени testopf.local Windows Server 2012 R2де.
— Centos 7 менен иштеген Linux хосту
— Конфигурацияланган авторизацияны колдонуу ssd
Эки чечим тең схемага өзгөртүүлөрдү киргизет Active Directory, ошондуктан биз бардыгын сыноо чөйрөсүндө текшерип, андан кийин гана жумушчу инфраструктурага өзгөртүүлөрдү киргизебиз. Бардык өзгөртүүлөр багытталганын жана чындыгында керектүү атрибуттарды жана класстарды гана кошо тургандыгын белгилегим келет.

1-аракет: көзөмөлдөө Sudo аркылуу ролдор Active Directory.

Айлананы кеңейтүү үчүн Active Directory акыркы релизди жүктөп алышыңыз керек Sudo — бүгүнкү күнгө карата 1.8.27. Пакеттен чыгарып, файлды көчүрүңүз schema.ActiveDirectory ./doc каталогунан домен контроллерине. Файл көчүрүлгөн каталогдон администратордун укуктары менен буйрук сабынан:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Баалыктарыңызды алмаштырууну унутпаңыз)
көрүү adsiedit.msc жана демейки контекстке туташыңыз:
Домендин түбүндө бөлүм түзүңүз жемпир. (Буржуазия дал ушул бирдикте жин бар деп өжөрлүк менен ырасташат ssd бир нерсени издейт sudoRole объектилер. Бирок, деталдуу мүчүлүштүктөрдү оңдоону күйгүзүп, журналдарды изилдегенден кийин, издөө бүт каталог дарагы боюнча жүргүзүлгөнү аныкталды.)
Бөлүмдө класска тиешелүү биринчи объектти түзөбүз sudoRole. Ыңгайлуу идентификация үчүн гана кызмат кылгандыктан, ысымды өзүм билемдик менен тандаса болот.
Схеманы кеңейтүүдөн мүмкүн болгон атрибуттардын ичинен негизгилери төмөнкүлөр:

  • sudoCommand — хостто кайсы командаларды аткарууга уруксат берилгенин аныктайт.
  • sudoHost — бул роль кайсы хостторго тиешелүү экенин аныктайт. катары көрсөтүүгө болот ALL, жана жеке хост үчүн аты менен. Ошондой эле масканы колдонууга болот.
  • sudoUser — кайсы колдонуучуларга аткарууга уруксат берилгенин көрсөтүү Sudo.
    Эгер сиз коопсуздук тобун көрсөтсөңүз, аттын башына “%” белгисин кошуңуз. Топтун аталышында боштуктар бар болсо, тынчсыздана турган эч нерсе жок. Журналдарга Караганда, мейкиндиктерден качуу милдети механизм тарабынан кабыл алынат ssd.

СШ жана судо боюнча эл аралык мелдештердин жеңүүчүлөрү кайрадан сахнага чыгышты. Ардактуу Active Directory дирижеру жетектеген
Fig 1. каталогдун тамырындагы sudoers бөлүмүндөгү sudoRole объекттери

СШ жана судо боюнча эл аралык мелдештердин жеңүүчүлөрү кайрадан сахнага чыгышты. Ардактуу Active Directory дирижеру жетектеген
Сүрөт 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Функция New-AttributeID {
$Prefix="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 = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "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 -Add @{mayContain = 'sshPublicKey'}

Атрибутту кошкондон кийин, Active Directory Domain Services кайра иштетүү керек.
Келгиле, Active Directory колдонуучуларына өтөбүз. Биз сизге ыңгайлуу ыкманы колдонуп, ssh туташуусу үчүн ачкыч жупту жаратабыз.
Биз PuttyGenди ишке киргизип, "Түзүү" баскычын басып, чычканды бош аймакта жылдырабыз.
Процесс аяктагандан кийин биз ачык жана купуя ачкычтарды сактап, ачык ачкычты Active Directory колдонуучу атрибутуна жүктөй алабыз жана процесстен ырахат алабыз. Бирок, ачык ачкыч "ден колдонулушу керек.OpenSSH authorized_keys файлына чаптоо үчүн ачык ачкыч:".
СШ жана судо боюнча эл аралык мелдештердин жеңүүчүлөрү кайрадан сахнага чыгышты. Ардактуу Active Directory дирижеру жетектеген
Колдонуучу атрибутуна ачкычты кошуңуз.
1-вариант - GUI:
СШ жана судо боюнча эл аралык мелдештердин жеңүүчүлөрү кайрадан сахнага чыгышты. Ардактуу Active Directory дирижеру жетектеген
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 деп койдук.

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 кардарында конфигурацияланган негизги авторизация менен төмөнкү ырааттуулукту алабыз:

  1. Колдонуучу логинди көрсөтүү менен серверге кошулат.
  2. sshd демону скрипт аркылуу Active Directoryдеги колдонуучу атрибутунан ачык ачкычтын маанисин чыгарып, ачкычтарды колдонуу менен авторизацияны ишке ашырат.
  3. Sssd демону топ мүчөлүгүнүн негизинде колдонуучуну андан ары аутентификациялайт. Көңүл бургула! Эгер бул конфигурацияланбаса, каалаган домен колдонуучу хостко кире алат.
  4. Сиз sudo аракетинде, sssd демону Active Directoryден ролдорду издейт. Эгер ролдор бар болсо, колдонуучунун атрибуттары жана топтун мүчөлүгү текшерилет (эгерде sudoRoles колдонуучу топторун колдонууга конфигурацияланган болсо)

Жыйынтык.

Ошентип, ачкычтар Active Directory колдонуучу атрибуттарында, sudo уруксаттарында сакталат - ушул сыяктуу эле, домен эсептери боюнча Linux хостторуна кирүү Active Directory тобуна мүчөлүктү текшерүү аркылуу ишке ашырылат.
Дирижердун эстафетасынын акыркы толкуну - жана залды урмат-сый менен жымжырттык каптап турат.

Жазууда колдонулган ресурстар:

Active Directory аркылуу Sudo
Active Directory аркылуу Ssh баскычтары
Powershell скрипти, Active Directory схемасына атрибут кошуу
sudo туруктуу чыгаруу

Source: www.habr.com

Комментарий кошуу