Hoy voy a explicaros como podéis unir un cliente de Ubuntu a un dominio de Active Directory.
En este tutorial voy a unir un cliente de Ubuntu Server 20.04.3 con un Active Directory montado en Windows Server 2022 aunque seguramente si utilizáis versiones anteriores de estos sistemas operativos también os sean válidos los pasos que voy a explicar a continuación.
Verificaciones previas
Lo primero que necesitamos es asegurar que nuestro cliente Ubuntu es capaz de resolver el nombre del servidor de Active Directory. En mi caso es así ya que en la configuración de red de Ubuntu le he indicado que utilice un servidor DNS interno el cual es capaz de resolver la dirección del servidor de dominio pero si vuestro caso no es este entonces tendréis que modificar el fichero hosts para añadir un nuevo registro que os permita resolver el nombre del servidor.
Para agregar este nuevo registro simplemente tenéis que editar el fichero hosts.
sergio@server1:~$ sudo nano /etc/hosts
Agregar el siguiente registro que básicamente consistirá en relacionar la ip del servidor de dominio con su nombre.
127.0.0.1 localhost 127.0.1.1 server1 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 192.168.126.200 serverdc.tutorialesit.com
Guardar los cambios y probar a realizar un ping contra el nombre del servidor de dominio, aquí deberíamos recibir respuesta.
sergio@server1:~$ ping serverdc.tutorialesit.com PING serverdc.tutorialesit.com (192.168.126.200) 56(84) bytes of data. 64 bytes from serverdc.tutorialesit.com (192.168.126.200): icmp_seq=1 ttl=128 time=0.866 ms 64 bytes from serverdc.tutorialesit.com (192.168.126.200): icmp_seq=2 ttl=128 time=1.40 ms 64 bytes from serverdc.tutorialesit.com (192.168.126.200): icmp_seq=3 ttl=128 time=1.46 ms 64 bytes from serverdc.tutorialesit.com (192.168.126.200): icmp_seq=4 ttl=128 time=1.34 ms 64 bytes from serverdc.tutorialesit.com (192.168.126.200): icmp_seq=5 ttl=128 time=1.36 ms ^C --- serverdc.tutorialesit.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/avg/max/mdev = 0.866/1.283/1.456/0.212 ms
Instalación de los paquetes necesarios
Para que nuestro cliente Ubuntu sea capaz de logarse contra un dominio de Active Directory necesitamos instalar una serie de paquetes aunque como siempre recomiendo que lo primero que se haga es actualizar los repositorios que tengamos configurados en Ubuntu para obtener las últimas versiones de los mismos.
sergio@server1:~$ sudo apt update && sudo apt upgrade
Ahora ya estamos en disposición de instalar los paquetes que necesitamos 🙂
sergio@server1:~$ sudo apt-get -y install realmd sssd sssd-tools samba-common krb5-user packagekit samba-common-bin samba-libs adcli ntp
En el transcurso de la instalación se nos preguntará por el nombre del dominio al que nos queremos unir así que lo especificamos y pulsamos en OK para continuar.
A continuación nos preguntará por el nombre del servidor donde tenemos desplegado Active Directory, lo especificamos y continuamos con el proceso de instalación.
Cuando nos pregunte por el servidor administrativo, en la siguiente pantalla, nuevamente pondremos el nombre de nuestro servidor de dominio.
Unir el cliente Ubuntu a nuestro dominio
Una vez hemos instalado y configurado los paquetes necesarios el siguiente paso será unir nuestro cliente de Ubuntu a nuestro dominio para ello utilizaremos el siguiente comando (recordar cambiar el nombre del servidor del ejemplo por el vuestro).
sergio@server1:~sudo realm join serverdc.tutorialesit.com -U 'Administrador' -v * Resolving: _ldap._tcp.serverdc.tutorialesit.com * Resolving: serverdc.tutorialesit.com * Performing LDAP DSE lookup on: 192.168.126.200 * Successfully discovered: tutorialesit.com Password for Administrador: * Unconditionally checking packages * Resolving required packages * LANG=C /usr/sbin/adcli join --verbose --domain tutorialesit.com --domain-realm TUTORIALESIT.COM --domain-controller 192.168.126.200 --login-type user --login-user Administrador --stdin-password * Using domain name: tutorialesit.com * Calculated computer account name from fqdn: SERVER1 * Using domain realm: tutorialesit.com * Sending NetLogon ping to domain controller: 192.168.126.200 * Received NetLogon info from: ServerDC.tutorialesit.com * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-drSRPe/krb5.d/adcli-krb5-conf-2C6Nhf * Authenticated as user: [email protected] * Using GSS-SPNEGO for SASL bind * Looked up short domain name: TUTORIALESIT * Looked up domain SID: S-1-5-21-859403051-2604212796-179039482 * Using fully qualified name: server1 * Using domain name: tutorialesit.com * Using computer account name: SERVER1 * Using domain realm: tutorialesit.com * Calculated computer account name from fqdn: SERVER1 * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Computer account for SERVER1$ does not exist * Found well known computer container at: CN=Computers,DC=tutorialesit,DC=com * Calculated computer account: CN=SERVER1,CN=Computers,DC=tutorialesit,DC=com * Encryption type [3] not permitted. * Encryption type [1] not permitted. * Created computer account: CN=SERVER1,CN=Computers,DC=tutorialesit,DC=com * Sending NetLogon ping to domain controller: 192.168.126.200 * Received NetLogon info from: ServerDC.tutorialesit.com * Set computer password * Retrieved kvno '2' for computer account in directory: CN=SERVER1,CN=Computers,DC=tutorialesit,DC=com * Checking RestrictedKrbHost/SERVER1 * Added RestrictedKrbHost/SERVER1 * Checking host/SERVER1 * Added host/SERVER1 * Discovered which keytab salt to use * Added the entries to the keytab: [email protected]: FILE:/etc/krb5.keytab * Added the entries to the keytab: host/[email protected]: FILE:/etc/krb5.keytab * Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab * /usr/sbin/update-rc.d sssd enable * /usr/sbin/service sssd restart * Successfully enrolled machine in realm
Y listo, si nos dirigimos a nuestro servidor de dominio podremos comprobar como efectivamente nuestro cliente de Ubuntu ya se encuentra dentro del dominio.
Configuración inicio sesión usuarios
Una vez nuestro cliente Ubuntu se encuentra dentro del dominio el siguiente paso será realizar toda la configuración relacionada con usuarios (creación de directorios home, permisos de acceso y privilegios).
Configuración directorio home nuevos usuarios
Para que los directorios home de los nuevos usuarios de dominio se creen automáticamente la primera vez que inicien sesión en Ubuntu tendremos que ejecutar los siguientes comandos.
sergio@server1:~$ sudo bash -c "cat > /usr/share/pam-configs/mkhomedir" <<EOF
Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
required pam_mkhomedir.so umask=0022 skel=/etc/skel
EOF
Y continuación este otro:
sergio@server1:~$ sudo pam-auth-update
Marcamos la opción activate mkhomedir y pulsamos OK.
Por último para que el cambio de configuración que hemos hecho surta efecto reiniciamos el servicio sssd.
sergio@server1:~$ sudo systemctl restart sssd
Comprobación del correcto funcionamiento de la integración
Para comprobar que la integración funciona correctamente utilizaremos el comando seguido id seguido del nombre de un usuario del dominio y si todo funciona correctamente nos debería dar información de ese usuario de Active Directory.
sergio@server1:~$ id [email protected] uid=812201104([email protected]) gid=812200513(usuarios del [email protected]) groups=812200513(usuarios del [email protected])
Configuración control de acceso y asignación de privilegios
Permitir el acceso
Si queremos permitir el acceso de un usuario a nuestro cliente de Ubuntu simplemente tendremos que ejecutar el siguiente comando:
sergio@server1:~$ sudo realm permit [email protected]
Si en cambio queremos asignar el permiso de acceso a nivel de grupos ejecutaremos lo siguiente.
Nota: A partir del parámetro g deberéis especificar el nombre de vuestro grupo.
sergio@server1:~$ sudo realm permit -g 'UsuariosLinux'
Denegar el acceso
Si deseamos denegar el acceso a un usuario o grupo siento comunicaros 🙁 que el comando realm no permite denegar el acceso a un usuario o grupo en concreto sino que tendremos que denegar el acceso a todos los usuarios con el comando que os voy a exponer a continuación y posteriormente volver a permitir los accesos que correspondan.
sergio@server1:~$ sudo realm deny --all
Conceder permiso sudo a usuarios o grupos de dominio
Por defecto los usuarios de dominio no tendrán la posibilidad de escalar privilegios pero no os preocupéis que como todo en la vida esto tiene solución.
Vamos a crear el siguiente fichero.
sergio@server1:~$ sudo vim /etc/sudoers.d/usuarios_administradores
Añadimos los usuarios o grupos de usuarios que queramos que tengan permisos de sudo y para finalizar guardamos los cambios pulsando la tecla escape y escribimos :wq
#Ejemplo de un usuario [email protected] ALL=(ALL) ALL #Ejemplo de un grupo. Importante antes de poner el nombre del grupo poner un % %[email protected] ALL=(ALL) ALL
Y eso es todo. Como siempre espero que os haya sido de utilidad el tutorial.
Entradas relacionadas
- Comandos básicos – Aprende a redirigir la entrada y salida de comandos en Linux
- Como establecer una IP estática en Ubuntu
- Identificar los procesos que consumen más CPU y Memoria en Linux
- Forzar el arranque en modo consola como root en Ubuntu para solución de problemas
- Eliminar archivos en Linux con una antigüedad superior a X días
- Configurar Firewall de Ubuntu mediante UFW
Me dedico a la Administración de Sistemas y he creado este blog para compartir mis conocimientos con toda la comunidad y así aportar mi granito de arena y ayudar a todo el que lo necesite.
Todo me funciono, gracias por la sencillez de tus datos y su eficacia
Gracias a ti Manuel.
Saludos.
No pudo conectar supuestamente por falta de permisos «insufficient permissions to join the domain», sin embargo estoy usando al usuario Administrador. El error se aprecia gracias al modificador -v y es el siguiente:
Couldn´t authenticate to Active Directory: SASL (-1) generic failure: GSSAPI Error: Unspeficied GSS failure
Hola Rafael,
¿Has comprobado que desde la red donde se encuentre ese equipo tenga visibilidad con el servidor de dominio?, parece más un problema de conectividad que de permisos.
Saludos.
Muy buen tutorial.
He estado varios días indagando sobre esto para un proyecto del ciclo que estoy estudiando y este es muy sencillo y directo al grano ^^
Muchas gracias!
Gracias por tu comentario Eva 😉
excelente blog 🙂 me ayudo mucho 🙂
😉