Históricamente, os permisos sudo rexíanse polo contido dos ficheiros de /etc/sudoers.d и visado, e realizouse a autorización de chave mediante ~/.ssh/authorized_keys. Non obstante, a medida que crece a infraestrutura, existe o desexo de xestionar estes dereitos de forma centralizada. Hoxe pode haber varias opcións de solución:
- Sistema de xestión de configuración - Xefe, Títere, Ansible, Sal
- Active Directory + ssd
- Varias perversións en forma de guións e edición manual de ficheiros
Na miña opinión subxectiva, a mellor opción para a xestión centralizada segue sendo unha combinación Active Directory + ssd. As vantaxes deste enfoque son:
- Verdadeiramente un único directorio de usuarios centralizado.
- Distribución de dereitos sudo consiste en engadir un usuario a un grupo de seguranza específico.
- No caso de varios sistemas Linux, faise necesario introducir comprobacións adicionais para determinar o SO cando se usan sistemas de configuración.
A suite de hoxe estará dedicada especificamente á conexión Active Directory + ssd para a xestión de dereitos sudo e almacenamento ssh claves nun só repositorio.
Entón, a sala conxelouse nun tenso silencio, o director levantou a batuta e a orquestra preparouse.
Vaia.
Dado:
— Dominio de Active Directory testopf.local en Windows Server 2012 R2.
— Host Linux que executa Centos 7
— Autorización configurada mediante ssd
Ambas solucións fan cambios no esquema Active Directory, polo que comprobamos todo nun ambiente de proba e só despois facemos cambios na infraestrutura de traballo. Gustaríame sinalar que todos os cambios están dirixidos e, de feito, só engaden os atributos e clases necesarios.
Acción 1: control sudo roles a través Active Directory.
Para ampliar o circuíto Active Directory necesitas descargar a última versión — 1.8.27 desde hoxe. Descomprimir e copiar o ficheiro esquema.ActiveDirectory dende o directorio ./doc ata o controlador de dominio. Desde a liña de comandos con dereitos de administrador desde o directorio onde se copiou o ficheiro, execute:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Non esquezas substituír os teus valores)
Aberto adsiedit.msc e conéctese ao contexto predeterminado:
Crea unha división na raíz do dominio suores. (A burguesía afirma teimudamente que é nesta unidade onde o demo ssd busca un elemento sudoRole obxectos. Non obstante, despois de activar a depuración detallada e estudar os rexistros, revelouse que a busca se realizou en toda a árbore de directorios.)
Creamos o primeiro obxecto pertencente á clase na división sudoRole. O nome pódese escoller de forma absolutamente arbitraria, xa que serve unicamente para unha identificación conveniente.
Entre os posibles atributos dispoñibles da extensión do esquema, os principais son os seguintes:
- sudoCommand — determina que comandos se permiten executar no host.
- sudoHost — determina a que hosts se aplica este rol. Pódese especificar como ALL, e para un anfitrión individual polo nome. Tamén é posible usar unha máscara.
- sudoUsuario — indicar que usuarios teñen permiso para executar sudo.
Se especificas un grupo de seguranza, engade un signo "%" ao principio do nome. Se hai espazos no nome do grupo, non hai nada de que preocuparse. A xulgar polos rexistros, a tarefa de escapar dos espazos é asumida polo mecanismo ssd.
Fig 1. Obxectos sudoRole na subdivisión sudoers na raíz do directorio
Figura 2. Pertenza a grupos de seguridade especificados en obxectos sudoRole.
A seguinte configuración realízase no lado de Linux.
En arquivo /etc/nsswitch.conf engade a liña ao final do ficheiro:
sudoers: files sssEn arquivo /etc/sssd/sssd.conf na sección [sssd] engadir aos servizos sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Despois de todas as operacións, cómpre limpar a caché do daemon sssd. As actualizacións automáticas ocorren cada 6 horas, pero por que debemos esperar tanto cando queremos agora?
sss_cache -EMoitas veces ocorre que limpar a caché non axuda. Despois detemos o servizo, limpamos a base de datos e iniciamos o servizo.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Conectámonos como primeiro usuario e comprobamos o que está dispoñible para el en 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/catFacemos o mesmo co noso segundo usuario:
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
Este enfoque permítelle definir de forma centralizada roles sudo para diferentes grupos de usuarios.
Almacenamento e uso de claves ssh en Active Directory
Cunha lixeira expansión do esquema, é posible almacenar claves ssh nos atributos de usuario de Active Directory e usalas cando se autoriza en hosts Linux.
Debe configurarse a autorización mediante sssd.
Engade o atributo necesario mediante un script de PowerShell.
EngadirsshPublicKeyAttribute.ps1Función 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])
$oide
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$atributos = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Chave pública de usuario para o inicio de sesión SSH';
}
Novo-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nome -eq "usuario"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Despois de engadir o atributo, debes reiniciar os servizos de dominio de Active Directory.
Pasemos aos usuarios de Active Directory. Xeraremos un par de claves para a conexión ssh mediante calquera método que che conveña.
Lanzamos PuttyGen, prememos o botón "Xerar" e movemos frenéticamente o rato dentro da zona baleira.
Ao rematar o proceso, podemos gardar as claves públicas e privadas, cargar a chave pública ao atributo de usuario de Active Directory e gozar do proceso. Non obstante, a chave pública debe usarse desde o "Chave pública para pegar no ficheiro authorized_keys de OpenSSH:«.
Engade a chave ao atributo de usuario.
Opción 1 - GUI:
Opción 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Polo tanto, actualmente temos: un usuario co atributo sshPublicKey cuberto, un cliente Putty configurado para a autorización mediante claves. Queda un pequeno punto: como forzar o daemon sshd a extraer a chave pública que necesitamos dos atributos do usuario. Un pequeno guión atopado na Internet burguesa pode facer fronte a isto.
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'Establecemos os permisos en 0500 para root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Neste exemplo, úsase unha conta de administrador para vincularse ao directorio. En condicións de combate debe haber unha conta separada cun conxunto mínimo de dereitos.
Persoalmente, estaba moi confundido polo momento do contrasinal na súa forma pura no guión, a pesar dos dereitos establecidos.
Opción de solución:
- Gardo o contrasinal nun ficheiro separado:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Establecín os permisos dos ficheiros en 0500 para root
chmod 0500 /usr/local/etc/secretpass - Cambiando os parámetros de inicio de ldapsearch: parámetro -w SuperSecretPassword cámbioo por -y /usr/local/etc/secretpass
O acorde final da suite de hoxe é editar sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Como resultado, obtemos a seguinte secuencia coa autorización de chave configurada no cliente ssh:
- O usuario conéctase ao servidor indicando o seu inicio de sesión.
- O daemon sshd, mediante un script, extrae o valor da chave pública dun atributo de usuario en Active Directory e realiza a autorización mediante as chaves.
- O daemon sssd autentica aínda máis o usuario en función da pertenza ao grupo. Atención! Se isto non está configurado, calquera usuario de dominio terá acceso ao host.
- Cando tentas sudo, o daemon sssd busca roles no Active Directory. Se hai roles, compróbanse os atributos do usuario e a pertenza ao grupo (se sudoRoles está configurado para usar grupos de usuarios)
O total.
Así, as claves almacénanse en atributos de usuario de Active Directory, permisos sudo; do mesmo xeito, o acceso aos servidores Linux por contas de dominio realízase comprobando a pertenza ao grupo Active Directory.
A onda final da batuta do director e o salón conxélase nun reverente silencio.
Recursos empregados na escritura:
Fonte: www.habr.com