Históricamente, los derechos de sudo se regían por el contenido de los archivos de /etc/sudoers.d и Visudo, y la autorización por claves se realizó mediante ~ / .ssh / Authorizedkeys. Sin embargo, con el crecimiento de la infraestructura, existe el deseo de gestionar estos derechos de forma centralizada. En la actualidad, existen varias soluciones posibles:
- Sistema de Gestión de la Configuración - Chef, Marioneta, Ansible, Sal
- Directorio Activo + ssd
- Diversas perversiones en forma de scripts y edición manual de archivos.
En mi opinión subjetiva, la mejor opción para la gestión centralizada sigue siendo un montón Directorio Activo + ssd. Las ventajas de este enfoque son:
- Realmente el directorio centralizado uniforme de usuarios.
- Distribución de derechos sudo se reduce a agregar un usuario a un grupo de seguridad específico.
- En el caso de varios sistemas Linux, se hace necesario introducir comprobaciones adicionales para determinar el sistema operativo cuando se utilizan sistemas de configuración.
La suite de hoy estará dedicada al paquete Directorio Activo + ssd para la gestión de derechos sudo y almacenamiento ssh llaves en un solo repositorio.
Así, la sala se congeló en un tenso silencio, el director levantó la batuta, la orquesta se preparó.
Vamos.
mayo:
- Dominio de directorio activo testopf.local en Windows Server 2012 R2.
- Host Linux con Centos 7
- Autorización personalizada usando ssd
Ambas soluciones hacen cambios de esquema. Directorio Activo, por lo que verificamos todo en un entorno de prueba y solo luego hacemos cambios en la infraestructura de trabajo. Quiero señalar que todos los cambios son puntuales y, de hecho, agregan solo los atributos y clases necesarios.
Acción 1: gestión sudo roles a través de Directorio Activo.
Para extender el esquema Directorio Activo necesitas descargar la última versión — 1.8.27 hoy. Descomprimir, copiar el archivo esquema.ActiveDirectory desde el directorio ./doc a un controlador de dominio. Desde la línea de comando con derechos de administrador del directorio donde se copió el archivo, ejecute:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(No olvides sustituir tus valores)
Abrir adsiedit.msc y conéctese al contexto predeterminado:
Crear una subdivisión en la raíz del dominio sudoers. (Los burgueses afirman obstinadamente que es en esta unidad donde el demonio ssd busca un artículo sudoRole objetos. Sin embargo, después de activar la depuración detallada y examinar los registros, se descubrió que la búsqueda se realiza en todo el árbol de directorios).
Crea el primer objeto en la división que pertenece a la clase. sudoRole. El nombre se puede elegir de manera absolutamente arbitraria, ya que sirve únicamente para una identificación conveniente.
Entre los posibles atributos disponibles de una extensión de esquema, los principales son:
- comando sudo - determina qué comandos se pueden ejecutar en el host.
- sudoHost - determina para qué hosts se aplica este rol. Se puede dar como TODASy para un host separado por nombre. También es posible utilizar una máscara.
- sudoUsuario - especificar qué usuarios pueden ejecutar sudo.
Si se especifica un grupo de seguridad, agregue un signo "%" al comienzo del nombre. Si hay espacios en el nombre del grupo, no hay nada de qué preocuparse. A juzgar por los registros, la tarea de escapar de los espacios la asume el mecanismo. ssd.
Figura 1 Objetos sudoRole en la subdivisión sudoers en la raíz del directorio
Fig. 2. Membresía en grupos de seguridad especificados en objetos sudoRole.
La siguiente configuración se realiza en el lado de Linux.
En archivo /etc/nsswitch.conf agregue la siguiente línea al final del archivo:
sudoers: files sssEn archivo /etc/sssd/sssd.conf en la sección [sssd] agregar a los servicios sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Después de todas las operaciones, debe borrar el caché del demonio sssd. Las actualizaciones automáticas se realizan cada 6 horas, pero ¿por qué deberíamos esperar tanto cuando queremos hacerlo ahora?
sss_cache -EA menudo sucede que borrar el caché no ayuda. Luego detenemos el servicio, limpiamos la base de datos, iniciamos el servicio.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Nos conectamos como el primer usuario y verificamos lo que está disponible para él desde 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/catHacemos lo mismo con nuestro 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 le permite definir de forma centralizada las funciones de sudo para diferentes grupos de usuarios.
Almacenamiento y uso de claves ssh en Active Directory
Con una ligera expansión del esquema, es posible almacenar claves ssh en atributos de usuario de Active Directory y usarlas al autorizar hosts Linux.
Se debe configurar la autorización vía sssd.
Agregamos el atributo requerido usando el script de PowerShell.
AddsshPublicKeyAttribute.ps1Función New-AttributeID {
$Prefijo="1.2.840.113556.1.8000.2554"
$GUID=[Sistema.Guid]::NewGuid().ToString()
$partes=@()
$Partes+=[UInt64]::Analizar($guid.SubString(0,4),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($guid.SubString(4,4),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($guid.SubString(9,4),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($guid.SubString(14,4),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($guid.SubString(19,4),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($guid.SubString(24,6),"AllowHexSpecifier")
$Partes+=[UInt64]::Analizar($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 = ID de atributo nuevo
$atributos = @{
lDAPDisplayName = 'sshPublicKey';
atributoId = $id;
oMSintaxis = 22;
atributoSyntax="2.5.5.5";
esValorÚnico = $verdadero;
adminDescription = 'Clave pública de usuario para inicio de sesión SSH';
}
Nuevo-ADObject -Nombre sshPublicKey -Tipo atributoEsquema -Ruta $esquemaruta -Otros atributos $atributos
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$usuarioEsquema | Establecer-ADObject -Agregar @{mayContain = 'sshPublicKey'}
Después de agregar el atributo, debe reiniciar los Servicios de dominio de Active Directory.
Pasemos a los usuarios de Active Directory. De cualquier manera conveniente para usted, generamos un par de claves para la conexión ssh.
Lanzamos PuttyGen, presionamos el botón "Generar" y arrastramos frenéticamente el mouse dentro del área vacía.
Al finalizar el proceso, podemos guardar las claves pública y privada, subir la clave pública al atributo de usuario de Active Directory y disfrutar del proceso. Sin embargo, la clave pública debe ser utilizada desde el "Clave pública para pegar en el archivo de claves autorizadas de OpenSSH:«.
Agregue la clave al atributo de usuario.
Opción 1 - GUI:
Opción 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Así, de momento tenemos: un usuario con el atributo sshPublicKey rellenado, un cliente Puty configurado para autorización por claves. Queda un pequeño punto, cómo obligar al demonio sshd a extraer la clave pública que necesitamos de los atributos del usuario. Un pequeño guión que se encuentra en los espacios abiertos de la Internet burguesa hace frente con éxito a esto.
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'Le asignamos los derechos 0500 para root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
En este ejemplo, la cuenta de administrador se utiliza para enlazar con el directorio. En condiciones de combate, debe haber una cuenta separada con un conjunto mínimo de derechos.
Personalmente, me dio mucha vergüenza el momento de la contraseña en su forma pura en el guión, a pesar de los derechos establecidos.
Opción de solución:
- Guardo la contraseña en un archivo separado:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Configuré los derechos del archivo 0500 para root
chmod 0500 /usr/local/etc/secretpass - Cambiar las opciones de inicio de ldapsearch: parámetro -w contraseña supersecreta cambiar a -y /usr/local/etc/secretpass
El acorde final en la suite de hoy es 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 obtenemos la siguiente secuencia con autorización configurada por claves en el cliente ssh:
- El usuario se conecta al servidor especificando su inicio de sesión.
- El demonio sshd extrae el valor de la clave pública del atributo de usuario en Active Directory a través de un script y realiza la autorización por claves.
- El daemon sssd realiza una autenticación de usuario adicional basada en la pertenencia al grupo. ¡Atención! Si no está configurado, cualquier usuario del dominio tendrá acceso al host.
- Cuando intenta sudo, el demonio sssd busca roles en Active Directory. Si hay roles, se verifican los atributos y la pertenencia al grupo del usuario (si sudoRoles está configurado para usar grupos de usuarios)
Resumen.
Por lo tanto, las claves se almacenan en los atributos de usuario de Active Directory, permisos de sudo; de manera similar, el acceso a los hosts de Linux utilizando cuentas de dominio se lleva a cabo mediante la verificación de la membresía en un grupo de Active Directory.
El movimiento final de la batuta del director, y la sala se congela en un silencio reverente.
Recursos utilizados en la escritura:
Fuente: habr.com