Para una estación de trabajo o servidor SLES 15 típico que requiere usuarios e inicios de sesión respaldados por AD, utilice User Logon Managementel módulo de YaST y seleccione Microsoft Active Directory tanto para la identidad como para la autenticación; esta es la ruta basada en SSSD de SUSE. Por ejemplo, este tutorial utiliza un host ficticio llamado linux01y un dominio ad.example.com. Se aplica cuando el cliente puede acceder a los servicios DNS y de hora de AD y usted tiene una credencial de inscripción de equipo autorizada.
Este procedimiento sigue la Guía de seguridad y endurecimiento de SLES 15 SP7 de SUSE. Los Service Packs anteriores pueden tener pantallas de YaST o detalles de paquete diferentes, por lo que debe usar la guía que coincida con el SP instalado. Si necesita específicamente compatibilidad con NTLM o relaciones de confianza entre bosques, SUSE recomienda el módulo independiente de pertenencia a dominios de Windows, basado en Winbind, como la mejor opción.
El descubrimiento de Active Directory se basa en los registros DNS, y la autenticación Kerberos depende de una hora precisa. Configure el cliente SLES para que utilice un servidor DNS que pueda resolver el dominio de Active Directory y sus controladores de dominio; en una configuración común, esto significa usar el servidor DNS de Active Directory en lugar de un resolvedor público. Sincronice el cliente con la fuente de hora aprobada para su dominio.
En YaST, abra Network Settings, seleccione Hostname/DNSy establezca Name Server 1la dirección del servidor DNS de AD. La dirección en la ilustración es solo un marcador de posición. Luego, confirme el nombre de host local y el estado de la hora:
hostname
timedatectl statusCompare el nombre del equipo con el nombre registrado en Active Directory. Si difieren, el cuadro de diálogo de unión de SUSE proporciona un AD hostnamecampo para ello. No desactive el firewall como atajo de detección; solicite al equipo de red que permita el tráfico necesario entre el cliente y el controlador de dominio según las reglas de su organización. SUSE también advierte que los nombres que terminan en .localpueden entrar en conflicto con el DNS multicast, así que revise su configuración de DNS si ese es el sufijo de su dominio.
En YaST, abra User Logon Management. No elija Windows Domain Membershippara este procedimiento: SUSE documenta ese módulo como basado en Winbind, mientras que User Logon Management es la opción basada en SSSD y generalmente se prefiere para la autenticación de AD.
Abra Change Settings, seleccione Add Domainy escriba el nombre DNS del dominio, como ad.example.com. Configure tanto el servicio de identidad como el servicio de autenticación en Microsoft Active Directoryy asegúrese de Enable the domainque esté seleccionado.
Mantenga las demás opciones predeterminadas a menos que su entorno requiera un nombre de host de AD específico o una lista fija de controladores de dominio. Si la detección automática de DNS no es apropiada, ingrese los nombres de host de los controladores de dominio proporcionados por su equipo de AD. Seleccione OKesta opción para que YaST pueda instalar el software faltante y verificar si se puede acceder a un controlador.
Cuando YaST indique que ha detectado un servidor AD, pero el equipo aún no esté registrado, introduzca la cuenta y la contraseña de registro autorizadas. El cuadro de diálogo documentado de SUSE utiliza una cuenta de administrador de AD; siga el proceso aprobado por su equipo de directorio para el registro de equipos y nunca incluya la contraseña en un script o artículo. Si el cuadro de diálogo no puede detectar un servidor, vuelva a realizar las comprobaciones de DNS y nombre de host antes de intentarlo de nuevo.
Tras la inscripción, habilítelo Allow Domain User Logon. Decida si habilitarlo Create Home Directoriessegún la política de datos de usuario del servidor. Esto crea directorios personales locales para los usuarios de AD al iniciar sesión por primera vez; resulta útil para equipos que deben conservar los datos personales locales, pero no crea ni gestiona la cuenta de usuario en AD.
Si AD ya proporciona el atributo de cada usuario UnixHomeDirectory, confirme que esté completo y disponible según lo requiera el diseño de su directorio. Cuando el cliente necesite una ruta de reserva, use Service Options> Name switch> Extended Optionspara configurar fallback_homedir, por ejemplo /home/%u. La documentación de SUSE indica que se utiliza una ruta de reserva cuando no se proporciona una ruta de AD; override_homediren su lugar, hace que el valor del cliente tenga prioridad. Elija una solo después de verificar la política de su directorio personal.
Guarde la configuración y revise el resumen de configuración resultante. Si el sistema también utiliza Samba, seleccione la opción para sobrescribir la configuración de Samba solo cuando se requiera dicha integración; esto es independiente de la activación del inicio de sesión de usuario basado en SSSD.
Verifique que SSSD esté activo y, a continuación, consulte una cuenta de dominio real utilizando el formato de nombre aprobado para su dominio. En este ejemplo, reemplace EXAMPLEy alicecon el nombre de dominio corto y una cuenta de prueba existente:
systemctl status sssd
getent passwd 'EXAMPLE\alice'Una entrada de passwd confirma que NSS puede resolver la cuenta; sin embargo, esto no prueba por sí solo que el usuario pueda autenticarse o acceder a las aplicaciones. Pruebe un inicio de sesión interactivo con las credenciales del dominio, utilizando el formulario documentado DOMAIN_NAME\USER_NAMEen la consola o el administrador de pantalla. Después de iniciar sesión, ejecute el comando klistpara verificar si la sesión tiene un ticket Kerberos.
Si SSSD está en ejecución pero la búsqueda de usuario falla, revise el nombre de dominio completo, el servidor DNS, el nombre de host y las opciones de identidad y autenticación en YaST. Si la búsqueda funciona pero el inicio de sesión falla, verifique que la cuenta esté habilitada, que su contraseña sea válida y que el cliente pueda acceder al controlador de dominio. Finalice el proceso solo después de que un usuario de prueba autorizado pueda iniciar sesión, se confirme el comportamiento esperado del directorio personal y los servicios necesarios del servidor sigan funcionando.
Configure RMT en SLES 15, replique los repositorios autorizados y verifique el registro HTTPS y el acceso a los paquetes desde un cliente de prueba.
Conecte SLES 15 a Active Directory mediante la gestión de inicio de sesión basada en SSSD de YaST y, a continuación, verifique la búsqueda en el directorio, el inicio de sesión en el dominio y los tickets de Kerberos.
Configure la ruta de Live Patching correcta para SLES 16.0 o 15 SP7, aplique las correcciones del kernel que cumplan los requisitos y confirme qué está activo sin confundirlo con una actualización del kernel que requiera reiniciar el sistema.
SLES 15 SP5 puede migrar en línea a SP6, pero cada nodo debe reiniciarse. Utilice una actualización progresiva probada o una transición azul-verde para mantener las cargas de trabajo accesibles.
Cree, refine y verifique un perfil de AppArmor con privilegios mínimos en SLES 15 SP7, con una nota clara sobre la configuración predeterminada de SELinux en SLES 16.
Utilice el perfil STIG compatible con SUSE para analizar SLES 15, probar la remediación, revisar los hallazgos restantes y conservar la evidencia de la evaluación.
Para rastrear una conexión fallida a Cockpit, utilice DNS, el puerto 9090, el socket systemd, firewalld, TLS y la configuración de inicio de sesión, siguiendo las directrices actuales de SUSE.
Cree una conexión Ethernet redundante en SLES 15 con YaST y Wicked, configure la agregación de enlaces activo-pasivo y verifique ambos puertos y la conmutación por error.
Convierta un sistema SLES 15 existente en un perfil AutoYaST revisado, valídelo y utilícelo para implementar un servidor de prueba con menos pasos manuales.
Instale las herramientas SLES 15 KVM y libvirt, habilite el servicio de host correcto y configure las máquinas virtuales seleccionadas para que se inicien después de un reinicio.
