ProHoster > Блог > Administrado > La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor

La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor

Historie, sudo-permesoj estis regataj de la enhavo de dosieroj de /etc/sudoers.d и visado, kaj ŝlosila rajtigo estis efektivigita uzante ~/.ssh/authorized_keys. Tamen, ĉar infrastrukturo kreskas, ekzistas deziro administri ĉi tiujn rajtojn centre. Hodiaŭ povas esti pluraj solvo-opcioj:

  • Agorda Administra Sistemo - kapon, Marioneto, Respondema, salon
  • Aktiva Dosierujo + ssd
  • Diversaj perversaĵoj en formo de skriptoj kaj mana dosiero-redaktado

Laŭ mia subjektiva opinio, la plej bona elekto por centralizita administrado ankoraŭ estas kombinaĵo Aktiva Dosierujo + ssd. La avantaĝoj de ĉi tiu aliro estas:

  • Vere ununura centralizita uzantdosierujo.
  • Disdono de rajtoj sudo dependas de aldoni uzanton al specifa sekureca grupo.
  • En la kazo de diversaj Linuksaj sistemoj, necesas enkonduki pliajn kontrolojn por determini la OS kiam oni uzas agordajn sistemojn.

La hodiaŭa serio estos dediĉita specife al la konekto Aktiva Dosierujo + ssd por administrado de rajtoj sudo kaj stokado ssh ŝlosiloj en ununura deponejo.
Do, la salono frostiĝis en streĉa silento, la direktisto levis sian bastonon, kaj la orkestro pretiĝis.
Iru.

Donita:
— Aktiva Dosierujo-domajno testopf.local sur Windows Server 2012 R2.
- Linuksa gastiganto kurante Centos 7
— Agordita rajtigo uzante ssd
Ambaŭ solvoj faras ŝanĝojn al la skemo Aktiva Dosierujo, do ni kontrolas ĉion en testa medio kaj nur tiam faras ŝanĝojn al la laboranta infrastrukturo. Mi ŝatus rimarki, ke ĉiuj ŝanĝoj estas celitaj kaj, fakte, aldonas nur la necesajn atributojn kaj klasojn.

Ago 1: kontrolo sudo roloj tra Aktiva Dosierujo.

Por vastigi la cirkviton Aktiva Dosierujo vi devas elŝuti la lastan eldonon sudo — 1.8.27 ekde hodiaŭ. Malpaku kaj kopiu la dosieron skemo.ActiveDirectory de la dosierujo ./doc al la domajna regilo. El la komandlinio kun administraj rajtoj de la dosierujo kie la dosiero estis kopiita, rulu:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ne forgesu anstataŭigi viajn valorojn)
Malfermu adsiedit.msc kaj konekti al la defaŭlta kunteksto:
Kreu dividon ĉe la radiko de la domajno ŝvitas. (La burĝaro obstine asertas, ke estas en ĉi tiu unuo, ke la demono ssd serĉas objekton sudoRole objektoj. Tamen, post ŝaltado de detala senararigado kaj studado de la protokoloj, estis rivelita ke la serĉo estis farita tra la tuta dosierujo.)
Ni kreas la unuan objekton apartenantan al la klaso en la divido sudoRole. La nomo povas esti elektita absolute arbitre, ĉar ĝi servas nur por oportuna identigo.
Inter la eblaj disponeblaj atributoj de la skema etendaĵo, la ĉefaj estas la jenaj:

  • sudoCommand — determinas kiuj komandoj rajtas esti ekzekutitaj sur la gastiganto.
  • sudoHost — determinas al kiuj gastigantoj koncernas ĉi tiu rolo. Povas esti specifita kiel ĈIUJ, kaj por individua gastiganto sub nomo. Ankaŭ eblas uzi maskon.
  • sudoUser — indiku, kiujn uzantoj rajtas ekzekuti sudo.
    Se vi specifas sekurecan grupon, aldonu signon "%" komence de la nomo. Se estas spacoj en la grupnomo, estas nenio por zorgi. Juĝante laŭ la ŝtipoj, la tasko eskapi spacojn transprenas la mekanismo ssd.

La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor
Fig 1. sudoRole-objektoj en la subdivido sudoers en la radiko de la dosierujo

La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor
Figuro 2. Membreco en sekurecaj grupoj specifitaj en sudoRole-objektoj.

La sekva agordo estas farita sur la Linukso-flanko.
En dosiero /etc/nsswitch.conf aldonu la linion al la fino de la dosiero:

sudoers: files sss

En dosiero /etc/sssd/sssd.conf en sekcio [sssd] aldoni al servoj sudo

cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo

Post ĉiuj operacioj, vi devas forigi la sssd-demonkaŝmemoron. Aŭtomataj ĝisdatigoj okazas ĉiujn 6 horojn, sed kial ni atendu tiom longe kiam ni volas ĝin nun?

sss_cache -E

Ofte okazas, ke malplenigo de la kaŝmemoro ne helpas. Tiam ni ĉesas la servon, purigas la datumbazon kaj komencas la servon.

service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start

Ni konektas kiel la unua uzanto kaj kontrolas kio estas disponebla por li sub 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

Ni faras la samon kun nia dua uzanto:

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

Ĉi tiu aliro permesas al vi centre difini sudo-rolojn por malsamaj uzantgrupoj.

Stoki kaj uzi ssh-ŝlosilojn en Active Directory

Kun iometa ekspansio de la skemo, eblas stoki ssh-ŝlosilojn en uzant-atributoj de Active Directory kaj uzi ilin dum rajtigo en Linuksaj gastigantoj.

Rajtigo per sssd devas esti agordita.
Aldonu la bezonatan atributon per PowerShell-skripto.
AddsshPublicKeyAttribute.ps1Funkcio New-AtributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Partoj=@()
$Partoj+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier”)
$Partoj+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier”)
$Partoj+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier”)
$Partoj+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier”)
$Partoj+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier”)
$Partoj+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier”)
$Partoj+=[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 = Nova-AtributoID
$atributoj = @{
lDAPDisplayName = 'sshPublicKey';
atributoId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $vera;
adminDescription = 'Uzanto Publika ŝlosilo por SSH-ensaluto';
}

Nova-ADObject -Name sshPublicKey -Type attributeSchema -Path $skemapath -OtherAttributes $atributoj
$userSchema = get-adobject -SearchBase $skemapath -Filtrilo 'nomo -eq "uzanto"'
$userSkema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}

Post aldoni la atributon, vi devas rekomenci Aktivajn Domajnajn Servojn.
Ni iru al uzantoj de Active Directory. Ni generos ŝlosilparon por ssh-konekto uzante ajnan metodon konvenan por vi.
Ni lanĉas PuttyGen, premas la butonon "Generu" kaj freneze movas la muson ene de la malplena areo.
Fininte la procezon, ni povas konservi la publikajn kaj privatajn ŝlosilojn, alŝuti la publikan ŝlosilon al la uzant-atributo de Active Directory kaj ĝui la procezon. Tamen, la publika ŝlosilo devas esti uzata de la "Publika ŝlosilo por glui en OpenSSH authorized_keys dosieron:".
La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor
Aldonu la ŝlosilon al la uzanta atributo.
Opcio 1 - GUI:
La gajnantoj de la internaciaj konkursoj SSH kaj sudo denove estas sur la scenejo. Gvidite de Distinguished Active Directory Conductor
Opcio 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Do, ni nuntempe havas: uzanton kun la atributo sshPublicKey plenigita, agordita Putty-kliento por rajtigo uzante ŝlosilojn. Restas unu malgranda punkto: kiel devigi la sshd-demonon ĉerpi la publikan ŝlosilon, kiun ni bezonas el la atributoj de la uzanto. Malgranda skripto trovita en la burĝa Interreto povas sukcese elteni ĉi tion.

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'

Ni starigis la permesojn sur ĝi al 0500 por radiko.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

En ĉi tiu ekzemplo, administranta konto estas uzata por ligi al la dosierujo. En batalkondiĉoj devas esti aparta konto kun minimuma aro de rajtoj.
Mi persone estis tre konfuzita de la momento de la pasvorto en ĝia pura formo en la skripto, malgraŭ la rajtoj fiksitaj.
Solva opcio:

  • Mi konservas la pasvorton en aparta dosiero: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • Mi starigis dosierpermesojn al 0500 por radiko 
    chmod 0500 /usr/local/etc/secretpass

  • Ŝanĝi la lanĉajn parametrojn de ldapsearch: parametro -w superSecretPassword Mi ŝanĝas ĝin al -y /usr/local/etc/secretpass

La fina akordo en la hodiaŭa serio estas redaktado de sshd_config

cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root

Kiel rezulto, ni ricevas la sekvan sekvencon kun ŝlosila rajtigo agordita en la ssh-kliento:

  1. La uzanto konektas al la servilo indikante sian ensaluton.
  2. La sshd-demono, per skripto, ĉerpas la publikan ŝlosilvaloron de uzant-atributo en Active Directory kaj plenumas rajtigon uzante la ŝlosilojn.
  3. La sssd-demono plu aŭtentikigas la uzanton laŭ grupa membreco. Atentu! Se ĉi tio ne estas agordita, tiam ajna domajna uzanto havos aliron al la gastiganto.
  4. Kiam vi provas sudo, la sssd-demono serĉas rolojn en la Aktiva Dosierujo. Se roloj ĉeestas, la atributoj de la uzanto kaj grupa membreco estas kontrolitaj (se sudoRoles estas agordita por uzi uzantgrupojn)

La funda linio.

Tiel, la ŝlosiloj estas konservitaj en uzant-atributoj de Active Directory, sudo-permesoj - simile, aliro al Linukso-gastigantoj per domajnaj kontoj estas efektivigita per kontrolado de membreco en la grupo Active Directory.
La fina ondo de la stango de la direktisto — kaj la halo frostas en respektema silento.

Rimedoj uzataj skribe:

Sudo per Active Directory
Ssh-ŝlosiloj per Active Directory
Powershell-skripto, aldonante atributon al Active Directory Schema
sudo stabila liberigo

fonto: www.habr.com

Aldoni komenton