SSH և sudo միջազգային մրցույթների հաղթողները կրկին բեմում են։ Ակտիվ գրացուցակի նշանավոր դիրիժորի ղեկավարությամբ

Պատմականորեն, sudo-ի թույլտվությունները ղեկավարվում էին ֆայլերի բովանդակությամբ /etc/sudoers.d и վիզուալ, և հիմնական թույլտվությունն իրականացվել է օգտագործելով ~/.ssh/authorized_keys. Այնուամենայնիվ, քանի որ ենթակառուցվածքները մեծանում են, ցանկություն է առաջանում կառավարել այդ իրավունքները կենտրոնացված կարգով: Այսօր կարող են լինել լուծման մի քանի տարբերակ.

  • Կազմաձևման կառավարման համակարգ - Chef, Տիկնիկ, Հղիություն, Աղ
  • Active Directory + սսսդ
  • Տարբեր այլասերումներ՝ սցենարների և ֆայլերի ձեռքով խմբագրման տեսքով

Իմ սուբյեկտիվ կարծիքով կենտրոնացված կառավարման լավագույն տարբերակը դեռ համադրությունն է Active Directory + սսսդ. Այս մոտեցման առավելություններն են.

  • Իսկապես մեկ կենտրոնացված օգտվողի գրացուցակ:
  • Իրավունքների բաշխում sudo հանգում է նրան, որ օգտատեր ավելացվի անվտանգության հատուկ խմբին:
  • Տարբեր Linux համակարգերի դեպքում անհրաժեշտ է դառնում լրացուցիչ ստուգումներ մտցնել՝ ՕՀ-ն որոշելու համար կոնֆիգուրացիայի համակարգեր օգտագործելիս:

Այսօրվա սյուիտը նվիրված կլինի հատուկ կապին Active Directory + սսսդ իրավունքների կառավարման համար sudo և պահեստավորում ssh բանալիները մեկ պահոցում:
Այսպիսով, դահլիճը սառեցրեց լարված լռության մեջ, դիրիժորը բարձրացրեց մահակը, և նվագախումբը պատրաստվեց։
Գնա։

Տրված է.
— Active Directory տիրույթ testopf.local Windows Server 2012 R2-ում:
— Linux հոսթ, որն աշխատում է Centos 7-ով
— Կազմաձևված թույլտվություն օգտագործելով սսսդ
Երկու լուծումներն էլ փոփոխություններ են կատարում սխեմայի մեջ 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 և միացեք լռելյայն համատեքստին.
Ստեղծեք բաժանում տիրույթի արմատում սուսերոներ. (Բուրժուազիան համառորեն պնդում է, որ հենց այս միավորում է դևը սսսդ որոնում է իր sudoRole առարկաներ. Այնուամենայնիվ, մանրամասն վրիպազերծումը միացնելուց և տեղեկամատյաններն ուսումնասիրելուց հետո պարզվեց, որ որոնումն իրականացվել է ամբողջ գրացուցակում:)
Մենք ստեղծում ենք բաժանման դասին պատկանող առաջին օբյեկտը sudoRole. Անունը կարելի է ընտրել բացարձակապես կամայականորեն, քանի որ այն ծառայում է բացառապես հարմար նույնականացման համար։
Սխեմայի ընդլայնման հնարավոր հասանելի ատրիբուտներից հիմնականները հետևյալն են.

  • sudoCommand — որոշում է, թե որ հրամաններն են թույլատրվում կատարել հոսթի վրա:
  • sudoHost — որոշում է, թե որ հյուրընկալողներին է վերաբերում այս դերը: Կարող է նշվել որպես ALL, և անհատ հյուրընկալողի համար՝ անունով: Հնարավոր է նաև դիմակ օգտագործել։
  • sudoUser — նշեք, թե որ օգտատերերին է թույլատրվում կատարել sudo.
    Եթե ​​նշեք անվտանգության խումբ, անվան սկզբում ավելացրեք «%» նշանը: Եթե ​​խմբի անվան մեջ բացատներ կան, անհանգստանալու ոչինչ չկա: Դատելով գերաններից՝ տարածություններից փախչելու գործն իր վրա է վերցնում մեխանիզմը սսսդ.

SSH և sudo միջազգային մրցույթների հաղթողները կրկին բեմում են։ Ակտիվ գրացուցակի նշանավոր դիրիժորի ղեկավարությամբ
Նկ 1. sudoRole օբյեկտները sudoers ստորաբաժանման մեջ գրացուցակի արմատում

SSH և sudo միջազգային մրցույթների հաղթողները կրկին բեմում են։ Ակտիվ գրացուցակի նշանավոր դիրիժորի ղեկավարությամբ
Նկար 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 daemon քեշը: Ավտոմատ թարմացումները տեղի են ունենում յուրաքանչյուր 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

Այս մոտեցումը թույլ է տալիս կենտրոնականորեն սահմանել սուդոյի դերերը տարբեր օգտվողների խմբերի համար:

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+=[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';
հատկանիշ Id = $oid;
oMSyntax = 22;
χαρακτηριστικόSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Օգտագործողի հանրային բանալի SSH մուտք գործելու համար';
}

Նոր-ADObject -Name sshPublicKey -Տիպային հատկանիշSchema -Ուղին $schemapath -Այլ ատրիբուտներ $հատկանիշներ
$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 ֆայլում տեղադրելու համար.»:
SSH և sudo միջազգային մրցույթների հաղթողները կրկին բեմում են։ Ակտիվ գրացուցակի նշանավոր դիրիժորի ղեկավարությամբ
Ավելացրեք բանալին օգտվողի հատկանիշին:
Տարբերակ 1 - GUI:
SSH և sudo միջազգային մրցույթների հաղթողները կրկին բեմում են։ Ակտիվ գրացուցակի նշանավոր դիրիժորի ղեկավարությամբ
Տարբերակ 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-ի համար root-ի համար
    chmod 0500 /usr/local/etc/secretpass

  • ldapsearch գործարկման պարամետրերի փոփոխություն՝ պարամետր -w superSecret Գաղտնաբառ Ես փոխում եմ այն -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 daemon-ը սկրիպտի միջոցով հանում է հանրային բանալու արժեքը Active Directory-ում օգտագործողի հատկանիշից և կատարում է թույլտվություն՝ օգտագործելով ստեղները:
  3. sssd daemon-ը հետագայում նույնականացնում է օգտատիրոջը՝ հիմնվելով խմբի անդամակցության վրա: Ուշադրություն. Եթե ​​սա կազմաձևված չէ, ապա տիրույթի ցանկացած օգտվող մուտք կունենա դեպի հոսթ:
  4. Երբ փորձում եք սուդո անել, sssd դեյմոնը դերեր է փնտրում Active Directory-ում: Եթե ​​առկա են դերեր, ստուգվում են օգտվողի հատկանիշները և խմբի անդամությունը (եթե sudoRoles-ը կազմաձևված է օգտվողների խմբեր օգտագործելու համար)

Ընդհանուր:

Այսպիսով, բանալիները պահվում են Active Directory-ի օգտատերերի ատրիբուտներում, sudo-ի թույլտվություններում. նմանապես, տիրույթի հաշիվներով Linux հոսթներին մուտքն իրականացվում է Active Directory խմբում անդամակցությունը ստուգելու միջոցով:
Դիրիժորական մահակի վերջին ալիքը, և դահլիճը սառչում է ակնածալից լռության մեջ:

Գրավոր օգտագործվող ռեսուրսները.

Sudo Active Directory-ի միջոցով
Ssh ստեղները Active Directory-ի միջոցով
Powershell սկրիպտ՝ ավելացնելով ատրիբուտ Active Directory Schema-ին
sudo կայուն թողարկում

Source: www.habr.com

Добавить комментарий