Geekly articles weekly

En el escenario nuevamente ganadores de las competiciones internacionales SSH y sudo. Bajo la guía de Active Directory de Honored Conductor

Históricamente, los derechos de sudo estaban regulados por el contenido de los archivos de /etc/sudoers.d y visudo , y la autorización de la clave se realizaba usando ~ / .ssh / Authorized_keys . Sin embargo, con el crecimiento de la infraestructura, existe el deseo de administrar estos derechos de manera centralizada. Hasta la fecha, puede haber varias soluciones:

  • Sistema de gestión de la configuración: chef , marioneta , ansible , sal
  • Active Directory + sssd
  • Distintas distorsiones en forma de scripts y edición manual de archivos.

En mi opinión subjetiva, la mejor opción para la administración centralizada sigue siendo un montón de Active Directory + sssd . Las ventajas de este enfoque son:

  • Realmente un único directorio de usuarios centralizado.
  • La distribución de derechos de sudo se trata de agregar un usuario a un grupo de seguridad específico.
  • En el caso de varios sistemas Linux, es necesario introducir controles adicionales para determinar el sistema operativo cuando se utilizan sistemas de configuración.

La suite de hoy estará dedicada al paquete Active Directory + sssd para administrar los derechos de sudo y almacenar las claves ssh en un único repositorio.
Entonces, la audiencia se congeló en tenso silencio, el director levantó su varita, la orquesta se preparó.
Vamos

Dado:

  • Dominio de Active Directory testopf.local en Windows Server 2012 R2.
  • Host Linux que ejecuta Centos 7
  • Autorización configurada usando sssd

Ambas soluciones realizan cambios en el esquema de Active Directory , por lo que verificamos todo en un entorno de prueba y solo luego hacemos cambios en la infraestructura de trabajo. Quiero señalar: todos los cambios están basados ​​en puntos y, de hecho, agregan solo los atributos y clases necesarios.

Paso 1: administre los roles sudo a través de Active Directory .


Para ampliar el esquema de Active Directory, debe descargar la última versión de sudo : 1.8.27 hoy. Desempaquete, copie el archivo schema.ActiveDirectory del directorio ./doc al controlador de dominio. Desde la línea de comandos con derechos de administrador desde el directorio donde copió el archivo, ejecute:

ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(No olvides sustituir tus valores)

Abra adsiedit.msc y conéctese al contexto predeterminado:

En la raíz del dominio, cree una unidad sudoers . (Los burgueses argumentan obstinadamente que es en esta subdivisión donde el demonio sssd busca objetos sudoRole . Sin embargo, después de activar la depuración detallada y examinar los registros, se reveló que la búsqueda se realiza en todo el árbol del catálogo).

Cree el primer objeto en la unidad 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 la extensión del esquema, los principales son:

  • sudoCommand : determina qué comandos se pueden ejecutar en el host.
  • sudoHost : determina a qué hosts se aplica esta función. Se puede establecer como TODO o para un host individual por nombre. También es posible usar una máscara.
  • sudoUser : indica qué usuarios pueden ejecutar sudo .
    Si se especifica un grupo de seguridad, agregue el signo "%" al comienzo del nombre. Si hay espacios en el nombre del grupo, no hay nada de qué preocuparse. A juzgar por los registros, el mecanismo sssd asume la tarea de escapar de los espacios.


Figura 1. objetos sudoRole en la unidad sudoers en la raíz del directorio


Figura 2. Membresía en los grupos de seguridad especificados en objetos sudoRole.

La siguiente configuración se realiza en el lado de Linux.

En el archivo /etc/nsswitch.conf , agregue la línea al final del archivo:

 sudoers: files sss

En el archivo /etc/sssd/sssd.conf en la sección [sssd] , agregue sudo a los servicios

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

Después de todas las operaciones, debe borrar el caché de daemon sssd. Las actualizaciones automáticas se realizan cada 6 horas, pero ¿por qué tenemos que esperar tanto cuando queremos ahora?

 sss_cache -E

A menudo sucede que limpiar el caché no ayuda. Luego detenemos el servicio, limpiamos la base, comenzamos el servicio.

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

Nos conectamos bajo el primer usuario y verificamos que sea accesible desde debajo de 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

Hacemos 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 centralmente roles sudo para diferentes grupos de usuarios.

Almacenar y usar claves ssh en Active Directory


Con una pequeña extensión del esquema, es posible almacenar claves ssh en atributos de usuario de Active Directory y usarlas para la autorización en hosts Linux.

Se debe configurar la autorización a través de sssd.

Agregue el atributo deseado utilizando el script de PowerShell.

AddsshPublicKeyAttribute.ps1
Función New-AttributeID {
$ Prefix = "1.2.840.113556.1.8000.2554"
$ GUID = [System.Guid] :: NewGuid (). ToString ()
$ Partes = @ ()
$ 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 = [Cadena] :: Formato ("{0}. {1}. {2}. {3}. {4}. {5}. {6}. {7}", $ prefijo, $ Partes [ 0],
$ Partes [1], $ partes [2], $ partes [3], $ partes [4], $ partes [5], $ partes [6])
$ oid
}
$ schemaPath = (Get-ADRootDSE) .schemaNamingContext
$ oid = New-AttributeID
$ atributos = @ {
lDAPDisplayName = 'sshPublicKey';
attributeId = $ oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $ true;
adminDescription = 'Clave pública de usuario para inicio de sesión SSH';
}

New-ADObject -Name sshPublicKey -Type attributeSchema -Path $ schemapath -OtherAttributes $ atributos
$ userSchema = get-adobject -SearchBase $ schemapath -Filter 'nombre -eq "usuario"'
$ userSchema | Set-ADObject -Add @ {mayContain = 'sshPublicKey'}

Después de agregar el atributo, reinicie los Servicios de dominio de Active Directory.
Pasamos a los usuarios de Active Directory. De cualquier manera conveniente para usted, generamos un par de claves para la conexión ssh.

Inicie PuttyGen, haga clic en el botón "Generar" y haga clic frenéticamente en el mouse dentro de un área vacía.

Al finalizar el proceso, podemos guardar las claves públicas y privadas, completar la clave pública en el atributo de usuario de Active Directory y disfrutar del proceso. Sin embargo, la clave pública debe usarse desde la ventana " Clave pública para pegar en el archivo OpenSSH Authorized Keys: ".



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=='}

Entonces, tenemos en este momento: un usuario con el atributo sshPublicKey completado, un cliente Putty configurado para la autorización de clave. Queda un pequeño punto, cómo hacer que el demonio sshd extraiga la clave pública que necesitamos de los atributos del usuario. Una pequeña secuencia de comandos 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 Administrator@testopf.local -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp'

Establecemos permisos 0500 para root en él.

 chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP

En este ejemplo, la cuenta de administrador se usa para el enlace al directorio. En condiciones de combate debe haber una cuenta separada con un conjunto mínimo de derechos.

Personalmente, estaba muy confundido por el momento de la contraseña en su forma pura en el script, 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 permisos en el archivo 0500 para root

     chmod 0500 /usr/local/etc/secretpass
  • Cambio los parámetros de inicio de ldapsearch: el parámetro -w superSecretPassword se cambia a -y / usr / local / etc / secretpass

El acorde final en la suite de hoy está editando 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 la autenticación de clave configurada en el cliente ssh:

  1. El usuario se conecta al servidor, indicando su nombre de usuario.
  2. El demonio sshd, a través de un script, extrae el valor de la clave pública del atributo de usuario en Active Directory y autoriza las claves.
  3. El daemon sssd autentica aún más al usuario en función de la pertenencia al grupo. Atencion Si esto no está configurado, cualquier usuario de dominio tendrá acceso al host.
  4. Cuando sudo lo intenta, el demonio sssd busca roles en el directorio de Active Directory. Si hay roles, se verifican los atributos y la membresía de usuario del grupo (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 por cuentas de dominio se realiza al verificar la membresía en el grupo de Active Directory.

La última ola de la varita del conductor, y la sala se congela en un silencio asombrado.

Recursos utilizados en la escritura:

Source: https://habr.com/ru/post/449702/

More articles:


All Articles