Es mi primera pregunta en el foro, así que no se enojen si pierdo información importante sobre mi problema.
Utilizo Debian 8 y me uní a un dominio de Active Directory (servidor Windows 2012) con SSSD segúneste tutorial.
Todo funciona bien, puedo iniciar sesión con una cuenta AD. Además, creé un grupo de directorio activo para reunir a los usuarios a quienes se les permitirá conectarse a este servidor.
Permito este grupo con el comando:
realm permit -g [email protected]
Hasta ahora, todo está bien y cuando me conecto por primera vez en mi servidor Linux con una cuenta de Active Directory, se /home/domain/usercrea.
Sin embargo, cuando quiero revocar el permiso para conectarse al servidor para un usuario (entonces elimino la cuenta del grupo). Su carpeta /home/domain/useraún permanece en el servidor y, además, la cuenta raíz (o la cuenta con permisos sudo) puede conectarse con el usuario que ya no tiene permisos (con un mensaje de advertencia Access Denied (ignored)).
Finalmente, la única forma de no permitirlo su <deleted user>es eliminar la cuenta de AD (pero no puedo eliminar la cuenta de AD cada vez que revoco los permisos).
En mi opinión, es un problema de seguridad terrible. ¿Es posible eliminar definitivamente el usuario (y su carpeta) en el servidor Linux cuando revoco los permisos de la cuenta AD?
¿Puede compartirme información sobre la autenticación entre AD y SSSD?
Consulte los archivos de configuración a continuación:
Contenido de /etc/nsswitch.conf:
passwd: compat sss
group: compat sss
shadow: compat sss
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files sss
ethers: db files
rpc: db files
netgroup: nis sss
sudoers: files sss
Contenido de /etc/sssd/sssd.conf:
[sssd]
domains = mydomain.com
config_file_version = 2
services = nss, pam
[domain/mydomain.com]
ad_domain = mydomain.com
krb5_realm = MYREALM.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = simple
simple_allow_groups = MyGroupAllowed
Antes de trabajar con SSSD, intenté usar Winbind, pero tuve el mismo problema.
Gracias por tu respuesta.
Respuesta1
En mi opinión, es un problema de seguridad terrible.
Entonces, ¿crees que el hecho de que sudolos usuarios puedan conectarse a una cuenta en un servidor Linux es un problema de seguridad? Todo lo que el sudousuario hace con esa cuenta se registra en consecuencia, incluido el usuario que realizó inicialmente sudo.
Lo que podría hacer es tener un demonio que sondee LDAP y sincronice las cuentas. Ni siquiera tiene que estar en cada caja de Linux, siempre que pueda conectarse a las cajas.
EDITAR: Otra forma de seguir adelante es asegurarse de que se eliminen las cachés de Kerberos; usar kdestroyen /etc/bash.bash_logout. De esta manera, el único "daño" que un usuario puede hacer es local, y podría hacerlo de todos modos, porque root puede hacer cualquier cosa local.
Nota: Esto también es bastante similar a Windows, ya que el administrador local puede convertirse fácilmente en un sistema local, y el sistema local puede hacer todo lo que está incluido en la caja, incluso suplantar a los usuarios actualmente conectados... y usarlo kdestroyal cerrar sesión emula el comportamiento de Windows.
Por eso tu pregunta fue una sorpresa para mí. Peor aún, en realidad, a menos que configure reglas de auditoría específicas en Windows, no verá el sistema local haciéndose pasar por usuarios, ni quién "controla actualmente esta sesión del sistema local haciendo cosas como jdoe".