Supuesto de Entorno de Trabajo en SXE. Preparación de escenarios
Introducción
Plantearemos la instalación de un ERP, concretamente Odoo, en el entorno de una empresa
(PYME) en dos supuestos escenarios: ERP instalado en un Windows Server 2012 con equipos
clientes Ubuntu y Windows que a su vez se conectan a Internet a través del Servidor y la misma
situación pero un escenario donde el Servidor es Debian. En ambos a su vez instalaremos un AD
(Directorio Activo para gestión de usuarios de la empresa)
Plantemiento de los escenarios
1. El servidor es un equipo bajo Debian
Escenario 1
2. El servidor es un Windows 2012 Server
Escenario 2
1
A. Comenzamos configurando un Servidor Debian en una MV
En lo sucesivo DebServer, al cual añadiremos dos tarjetas, una en modo NAT y DHCP, y otra en
modo Red Interna.
Datos:
nombre: debserver
usuario: admindebian
pass: abc123.
En el fichero /etc/network/interfaces añadiremos las siguientes líneas para configurar la tarjeta en
Red Interna eth1. La tarjeta en modo NAT eth0 no hay que tocarla.
A continuación reiniciamos el servicio con:
#service networking restart
B. Configuramos un servidor DHCP cuya función será facilitar la configuración de red de los
equipos clientes sirviéndoles un rango de IP’s
#apt-get install isc-dhcp-server
Editamos el fichero /etc/dhcp/dhcpd.conf1 y lo modificamos según la imagen siguiente:
#nano /etc/dhcp/dhcpd.conf
1Algunos gráficos están tomados de Curso sobre Instalaciones Desatendidas del profesor Daniel Medina.
2
Reiniciamos el servidor DHCP:
#service isc-dhcp-server restart
Explicación. Este servidor servirá IP’s a los clientes desde el 10.0.0.50 hasta 10.0.0.100, para unos
50 clientes. Si en nuestro empresa hubiese más necesidad, pues nada, se aumentaría el rango. El
valor 10.0.0.1 es la IP de la tarjeta eth1 que permitirá la salida a Internet a los equipos clientes.
Para finalizar necesitamos enrutar la salida de eth1 a eth0 de Debserver para dar salida a Internet.
Para ello modificamos el fichero /etc/rc.local añadiento las siguientes líneas.
echo 1 > /proc/sys/net/ipv4/ip_forward
otra línea
/sbin/iptables – P FORWARD ACCEPT
/sbin/iptables –table nat -A POSTROUTING -o eth0 -j MASQUERADE
Solo nos que reiniciar Debserver o bien ejecutar el fichero con el comando:
#sh /etc/rc.local
Solo nos queda probar que todo funciona y para ello vamos a montar dos MV una con Windows
7/10 y otra con Ubuntu en modo Red Interna. Las podemos llamar Win1 y Ubu1. Una vez iniciadas
debemos comprobar dos cosas:
1. Que toman una IP del servidor DHCP (ipconfig o ifconfig)
2. Que tienen salida a Internet
C. Datos de las máquinas cliente:
Ubuntu:
nombre: ubucliente
usuario: adminubu
pass: abc123.
Red. RED INTERNA
3
Windows:
nombre: wincliente
usuario: adminwin
pass: abc123.
Red. RED INTERNA
En la siguiente imagen vemos la configuración de Red de Ubuntu donde se observan los datos que
le proporciona el servidor DHCP y la conexión a Internet del enrutamiento. Se conecta a Internet y
toma una IP del servidor DHCP:
Comprobamos que tiene acceso a la red externa.
D. Instalamos el servidor Windows 2012 Server
En lo sucesivo WinServer. Dos tarjetas una en modo NAT y otra en modo Red Interna.
4
Datos:
nombre: winservser
usuario: administrador
pass: abc123.
Red. RED INTERNA
Los datos de la tarjeta de Red Interna:
IP: 10.0.0.10
Netmask: 255.0.0.0
DNS: 8.8.8.8
Para identificar “quien es quien” en las dos tarjetas de Red, la NAT aparecere como RED, le
cambiamos el nombre y le ponemos INTERNET. La tarjeta de Red Interna aparece como RED NO
IDENTIFICADA, le cambiaremos el nombre a RED INTERNA.
E. Configuración del servidor de enrutamiento y del servidor DHCP en Windows Server
Datos:
a. Instalación basada en características o roles
b. Nombre del Servidor DHCP: winserver
c. Intervalo a distrubuir: 10.0.0.50 – 10.0.0.100 Intervalo a excluir: Ninguno
d. IP enrutador: 10.0.0.10 (configuramos el enrutador también en Windows Server)
Probamos si funciona con los equipos ubucliente y wincliente
5
Finalmente comprobamos que hay salida a Internet desde los equipos clientes.
F. Configuración de Windows Server como controlador de dominio AD (Escenario 2)
Un Directorio Activo podemos decir de forma sencilla que es un “un servicio establecido en uno o
varios servidores en donde se crean objetos tales como usuarios, equipos o grupos, con el
objetivo de administrar los inicios de sesión en los equipos conectados a la red, así como también
la administración de políticas en toda la red ”
Empecemos configurando el AD en Server 2012. Solo indicaremos las imágenes más importantes.
7
Y reiniciamos y lanzamos el elemento de administración del Directorio Activo que nos permite dar
altas, bajas o modificaciones de los diferentes objetos a administrar. Desde la opción herramientas
en la parte superior derecha de Windows Server podemos acceder a los diferentes elementos o
útiles de administración de los servidores de la familia Microsfot.
8
Nota.- En propiedades del ámbito DHCP del Server, hay que asignar algunos valores para que éstos se transmitan a
los clientes:
3. Puerta de Enlace: La IP del router 10.0.0.10
6. DNS servers: 10.0.0.10
15. Domain name: MIDOMINIO.LOCAL
Vamos a crear nuestro primer clon enlazado para añadir un equipo al dominio de Windows Server.
Arrancamos el nuevo clon y pasamos a agregarlo al domino. Para ello en el equipo cliente:
Equipo → (botón derecho) Propiedades → Cambiar configuración
9
Si falla ver configuración de DNS en tarjeta de red del cliente y añadir como DNS el Server 2012.
Para añadir un equipo Ubuntu a un AD bajo Windows Server creamos un clon enlazado de la
plantilla de Ubuntu.
Como en nuestro en el caso que nuestro dominio tiene el sufijo .local, se debe cambiar, el orden
de resolución de nombres en el archivo /etc/nsswitch.conf de manera que después de files, se
utilice el servicio dns.
El siguiente paso, será bajar la versión Open del PBIS (antiguo likewise) en el siguiente enlace2
PBIS es un programa que permite a una máquina UNIX/Linux unirse a un dominio Microsfot y
autenticarnos en esa máquina con nuestras credenciales de AD (Active Directory).
Tras descargar la versión para 64 bits le damos permiso de ejecución al script y lo ejecutamos:
$sudo chmod +x pbis-open-8.2.2.2993.linux.x86.deb.sh
$sudo ./pbis-open-8.2.2.2993.linux.x86.deb.sh
Si falla la instalación probamos previamente a desinstalar el servico avahi
$sudo apt-get remove avahi-daemon
2Imágenes tomadas de la web waytoit.wordpress.com
10
Contestamos afirmativamente a las dos preguntas que nos hace durante el proceso de instalación
y ya estaremos listos para agregar nuestro cliente al dominio y hace falta poner el nombre de
usuario con el que queremos agregar el dominio.
$sudo domainjoin-cli join –disable ssh MIEMPRESA.LOCAL administrador
Una vez entrada la password si todo ha ido bien, nos indica con un mensaje que se ha agregado
con éxito al dominio:
Podemos comprobar en el DC que efectivamente, se ha agregado la máquina con éxito:
El siguiente paso es configurar el cliente Ubuntu para que funcione correctamente el inicio de
sesión de los usuarios del dominio. En primer lugar ejecutaremos como root (o mediante sudo)
las siguientes configuraciones
Especialmente importante el detalle de añadir el símbolo ^ en lugar del espacio al definir el grupo
de usuarios que podrá iniciar sesión. Es conveniente utilizar “Usuarios^del^dominio” en vez del
término en inglés.
11
A continuación, editaremos el archivo /etc/pam.d/common-session y modificaremos la línea
correspondiente a session pam_lsass.so
Llegados a este punto, previo al último paso, realizaremos unas modificaciones que no se reflejan
en how-tos sobre el tema pero que nos evitan el que pueda producirse un error que consiste en
que el usuario no pueda acceder al dominio dando un mensaje de contraseña inválida y se deben a
un error de configuración del servicio lwsmd. Para ello debemos seguir los siguientes pasos:
$sudo nano /lib/systemd/system/lwsmd.service
A continuación añadimos la línea marcada en negrita:
[Unit]Description=BeyondTrust PBIS Service Manager
After=network.target
[Service]
Type=forking
EnvironmentFile=/opt/pbis/libexec/init-base.sh
ExecStart=/opt/pbis/sbin/lwsmd –start-as-daemon
ExecReload=/opt/pbis/bin/lwsm refresh
ExecStop=/opt/pbis/bin/lwsm shutdown
# We want systemd to give lwsmd some time to finish gracefully, but still want
# it to kill lwsmd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill lwsmd. We are sending useless SIGCONT here to give
# lwsmd time to finish.
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target nss-lookup.target
12
Creamos los enlaces al servicio y lo lanzamos:
$cd /etc/systemd/system
$sudo ln -s /lib/systemd/system/lwsmd.service
$sudo systemctl enable lwsmd.service
$sudo service lwsmd start
El último paso, es permitir que en la pantalla de inicio se permita iniciar sesión a cualquier usuario.
Para ello debemos editar la configuración de lightdm, que en esta versión ya no se encuentra
en /etc/ sino en:
/usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf
Añadiremos la siguiente línea:
greeter-show-manual-login=true
Ahora simplemente reiniciamos Ubuntu. Si nos apareciese un error en el arranque, deberemos
entrar en mode recovery y comprobar las dos últimas configuraciones explicadas. Si todo está
correcto, nos aparecerá la pantalla de inicio y podremos iniciar con un usuario del dominio:
Solo nos quedan algunos ajustes finales.
Si entramos en nuestro Ubuntu recién agregado al dominio con la cuenta del administrador del
dominio (administrator) y probamos de realizar una tarea con permisos elevados (sudo),
recibiremos el mensaje que el usuario no pertenece al grupo de sudoers.
Para conseguir este propósito, podemos hacer dos acciones diferentes:
• agregar un usuario directamente al grupo de sudo o
• crear un grupo de administradores de equipos linux y darle a este grupo capacidad de
ejecutar con privilegios elevados.
13
Si elegimos la primera opción, simplemente, deberemos validarnos en la máquina Linux con el
usuario local, en nuestro caso ubuadmin, (que sí pertenece al grupo sudo) y editar el archivo
/etc/group, añadiendo un usuario que pertenezca al dominio al grupo sudo. No hace falta indicar
que dicho usuario es del dominio, porque cuando configuramos el sistema en la primera parte ya
indicamos que asume el prefijo del dominio por defecto (AssumeDefaultDomain true).
Obviamente, podríamos haber añadido cualquier otro usuario del dominio como el administrator.
Si ahora ejecutamos el comando id veremos como este usuario, en este caso user1, además de ser
miembro del grupo Domain Users, es miembro del grupo sudo. Además podemos comprobar que
puede ejecutar comandos elevados.
La segunda opción, que es la que viene comentada en la guía de PowerBroker (pbis), consiste en
crear un grupo de administradores Linux en el Active Directory. Agregaremos a los
administradores del dominio a este grupo.
A continuación, en el cliente y con una cuenta que tenga derechos administrativos, ejecutamos
visudo y añadimos este grupo al final del archivo (documentamos la línea como buena práctica).
14
Comprobamos ahora entrando como administrator que se ha actualizado correctamente la
configuración.
La cuestión es la siguiente: “¿interesa que los usuarios del dominio que utilicen Ubuntu tengas
derechos administrativos sobre el equipo cliente?” Eso es algo que debería determinar el
administrador del sistema informático de la empresa según la lógica negocio de la empresa.
ACTIVIDAD. Instalación de Odoo en el servidor Windows y comprobación de acceso desde los
clientes.
G. Configuración de Debian-Server como controlador de dominio AD (Escenario 1)
En ambos casos el dominio será local con el nombre misapellidos.local. Siempre que sea posible
“desconectaremos” la tarjeta en NAT, especialmente cuando configuremos el servidor dns.
Instalamos el servicio ntp
# apt-get install ntp
15
A continuación procederemos a instalar Samba4. Aunque se puede descargar como paquete ya
construido mediante apt-get, la página de Samba recomienda bajar las fuentes y compilarlas.
En primer lugar, nos bajamos los archivos necesarios o prerequisitos:
# apt-get install build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls28-dev
libreadline-dev python-dev python-dnspython gdb pkg-config libpopt-dev libldap2-
dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl git bind9
El protocolo Kerberos nos pedirá tres datos que son:
Reino Kerberos: misapellidos.local
Servidor: debserverprofe (o nombre del servidor)
Servidor administrativo: debserverprofe (o nombre del servidor)
Una vez finalizada la instalación, bajaremos la versión más reciente del repositorio GIT:
# git clone git://git.samba.org/samba.git /usr/src/samba4/
Una vez finalizada la descarga procederemos a compilar:
# ./configure --enable-debug
# make
# make install
y añadiremos el path de las carpeta bin y sbin de samba:
# export PATH=”/usr/local/samba/sbin:/usr/local/samba/bin:$PATH”
Cuando reiniciemos el servidor o la sesión debemos ejecutar este comando para añadir al path.
Procedemos a la construcción del dominio utilizando el comando samba-tool domain provision y
procederemos a rellenar los datos de nuestro dominio, tal como muestra la imagen siguiente
16
En DNS forwarder, pondremos la dirección IP del DNS que queremos que resuelva las peticiones
externas (reenviador).
En cuanto la password que nos solicita, deberá tener complejidad, caso contrario nos pedirá una
nueva contraseña y hasta que no sea lo suficientemente compleja no dejará de solicitarla.
Si todo va bien, procedemos a desconectar la tarjeta NAT del servidor y comenzamos la
configuración.
Primero echamos un vistazo al fichero smb.conf donde completamos las líneas dns forwader y
allow dns updates
A continuación configuramos los ficheros relacionados con la tarjeta de red. A saber son tres:
• /etc/resolv.conf
17
• /etc/hosts
• /etc/network/interfaces
Reinciamos el servicio de Red.
#service networking restart
A continuación reiniciamos la máquina y cuando iniciamos sesión debemos iniciar siempre el
servicio de samba. Esto sera hara también siempre tras cada inicio de sesión.
# /usr/local/samba/sbin/samba start
Pasamos a configurar el servidor DNS.
18
Por defecto, Samba crea las siguientes dos zonas durante la implementación del nuevo dominio: -
Una zona para nuestro dominio, en nuestro caso misapellidos.local y la zona
_msdcs.debserverprofe.misapellidos.local que contiene los registros SRV para diversos servicios.
Samba no crea la zona de búsqueda inversa, de modo que la creamos de formal manual:
Solo nos falta incluir en /etc/bind/named.conf
Empezamos las comprobaciones:
19
Importante.- En Debian cada vez que activamos la NAT el fichero /etc/resolv.conf se modifica a su
estado original por ello es necesario tener la NAT solo activa cuando sea necesario. Podemos
hacerla estática, puedes verlo aquí o se podría resolver usando modo Bridge pero por
requerimientos de nuestra red del centro no es posible. Así que durante las prácticas nunca nos
olvidemos de repasarla cada vez que activemos la NAT.
Llegados a este punto, empezamos las pruebas de integración agregando los equipos al dominio. A
partir de aquí utilizaremos clones enlazados. Primero con Windows y posteriormente con Linux
(solo si tenemos tiempo). Añadiremos a Windows el servidor dns configurado en Linux.
20
Aunque Samba 4 dispone de herramientas gráficas web como SWAT, utilizaremos para administrar
el dominio unconjunto de herramientas gratuitas que ofrece Microsoft conocido como RSAT
(Remote Server Administration Tool). Dichas herramientas, disponibles tanto para Windows 7
como Windows 8, no permitirán gestionar nuestro controlador de dominio, de forma idéntica a si
estuviéramos delante de un Windows Server.
El primer paso será descargarnos de la página de Microsoft la versión RSAT adecuada a nuestro
equipo cliente. En nuestro caso, un Windows 7 Enterprise de 64 bits.
Una vez instalado el paquete de herramientas, procederemos a habilitar aquellas que necesitemos,
para ello deberemos ir a Panel de Control, Programas y características, Activar características de
Windows:
Aquí activaremos las herramientas de administración que sean necesarias, en nuestro caso
tendremos suficiente con la administración básica del AD y la administración de políticas de
grupo. Si posteriormente se necesitan herramientas adicionales, siempre se pueden activar.
Una vez hemos activado las diferentes herramientas, vamos a comenzar a administrar nuestro
dominio. En primer lugar, abrimos Usuarios y Equipos de Active Directory. En esta consola
podemos crear OU, grupos, usuarios y gestionar máquinas del dominio. Aquí a modo de ejemplo,
creamos dos usuarios que llamaremos ana y pepe.
21
Vamos a crear ahora la carpeta en el servidor donde ubicaremos las carpetas personales de los
usuarios del dominio y a continuación editaremos el archivo smb.conf (recordar que lo tenemos en
/usr/local/samba/etc para compartir dicho recurso. En el ejemplo vamos a llamar a dicha carpeta
Usuarios:
# mkdir /Usuarios
Una vez realizada esta acción, reiniciamos el servidor y volvemos a iniciar el servicio de samba
para que los cambios tengan efecto.
#/usr/local/samba/sbin/samba restart
ACTIVIDAD. Instalación de Odoo en el servidor Debian y comprobación de acceso desde los
clientes.
H. Ampliación I. Mejoras adicionales.
El siguiente paso es configurar los permisos de este nuevo recurso. Esto lo haremos desde el
cliente. Es muy importante recordar que debemos evitar que un usuario tenga acceso a la carpeta
personal de otro, para ello, es necesario bloquear las herencias de los permisos de la carpeta
Usuarios a las carpetas hijas creadas en su interior. Para acceder desde el cliente a la carpeta
compartida utilizaremos el explorador de archivos.
22
Botón derecho sobre la carpeta, seleccionamos Seguridad y elegimos Opciones Avanzadas.
Eliminamos todos los permisos que aparecen y procedemos ahora a crear los que necesitamos:
• Administrator (administrador del dominio) tiene control total para esa carpeta,
subcarpetas y archivos.
• Repetimos los mismos permisos para el grupo Domain Admins.
• Elegimos idéntica configuración para SYSTEM.
• A CREATOR OWNER (el usuario que crea un recurso) le damos control total pero solo de
subcarpetas y archivos.
• Al grupo Domain Users les daremos permiso de Atravesar carpeta/Ejecutar archivo,
mostrar carpeta/leer datos, Crear archivos/escribir datos y Cambiar permisos, pero
solamente en esta carpeta.
En las siguientes imágenes podemos observar algunas de las configuraciones que podemos
plantear en nuestro servidor.
23
Toca ahora configurar el perfil de los usuarios definidos anteriormente para que crear su carpeta
personal. Para ello, desde la consola de Usuarios y Equipos seleccionamos el usuario y en
Propiedades -> Perfil escribimos la ruta de su carpeta personal, utilizamos la variable de entorno
%username% que nos permitirá que usuarios nuevos creados a partir de copiar uno de los
anteriores, utilicen su nombre de usuario para crear la carpeta.
Si ahora iniciamos sesión en el cliente con uno de los usuarios, por ejemplo ana o pepe
comprobamos como nos aparece su carpeta personal.
24
A modo de ejemplo vamos a ver como mapear directamente a las carpetas personales en red de
los usuarios que se han creado en el servidor, la carpeta de Documentos que aparece en el perfil
de cada usuario. De esta manera, cuando un usuario guarde el archivo en Documentos, realmente
lo está guardando en red (informes, documentos, listados, etc) y por tanto, verá ese documento
independientemente del equipo desde el cual inicie sesión lo que implica dos beneficios, la
seguridad de no guardar en local y la comodidad de disponer en esos documentos desde cualquier
equipo cliente.
Para aplicar las GPO en nuestro caso, desde el equipo cliente y validados como administrador del
dominio, abrimos la herramienta Administración de directivas de grupo del conjunto
25
Creamos una nueva GPO y la vinculamos al dominio le ponemos un nombre, por ejemplo
mapear, una vez creada clicamos con el botón derecho y procedemos a editar
Desplegamos el árbol de directivas hasta la opción deseada, Configuración de usuario ->
Configuración de Windows -> Redirección de carpetas -> Documentos y con el botón derecho
seleccionamos Propiedades.
En Destino, marcamos la opción básica, la opción de crear una carpeta para cada usuario en la
ruta raíz y como ruta raíz, elegimos la ruta donde tenemos las carpetas en red de los usuarios.
26
En Configuración marcamos la opción de Mover el contenido de Documentos a la nueva ubicación.
Finalmente sobre la máquina cliente forzamos la actualización de las directivas y cerramos sesión.
C:\>gpupdate /force
Iniciamos sesión con un usuario del dominio y comprobamos como si vamos a la ruta de red,
aparece la carpeta Documentos creada en su carpeta personal. A veces es necesario, reiniciar la
sesión de usuario la primera vez para que los cambios tengan efecto.
27
Comprobamos creando un archivo en la carpeta Documentos de Bibliotecas, cómo este archivo
realmente se crea en la carpeta en red y por tanto estará disponible desde cualquier cliente del
dominio.
A partir de aquí se puede aplicar cualquier tipo de directiva, tanto de equipo como de usuario a los
miembros del dominio.
Para que los clientes Ubuntu se mapeen en las carpetas de Windows Server lo haremos de forma
gráfica.
28
En primer lugar vamos a Lugares -> Red
A partir de aquí debería solicitarnos usuario y contraseña tal como se muestra en las imágenes.
Este apartado lo ampliaremos en la prácticas de Gestión de Usuarios
I. Ampliación II. Mejoras adicionales.
Vamos a configurar el reenvio de puertos con NAT en VirtualBox. Si tenemos la red de nuestra
máquina virtual configurada en NAT y queremos acceder desde el exterior a dicha máquina,
deberemos de crear una regla sencilla en VirtualBox. Ya que si miramos la configuración IP de la
máquina virtual veremos que tiene una IP de la red 10, no accesible desde la máquina host.
Para ello primero hacemos clic botón derecho de nuestra máquina virtual y pulsamos en
settings...
En la ventana que nos abre vamos al apartado de red y pulsamos en Port forwarding
29
Vamos a habilitar el puerto 22 en la máquina virtual y el puerto de host de escucha sea el 2222.
Aquí señalar que es mejor utilizar como IP dela maquina real 127.0.0.1
Aquí hago la prueba con mi máquina. Como vemos, hago un ssh al puerto 2222 de mi máquina y
VirtualBox se encarga de redireccionarme la conexión al puerto 22 de la máquina virtual.
30
Estos redireccionamientos son útiles cuando creamos una máquina virtual en VirtualBox, por
defecto se le asigna una red de tipo NAT. La dirección IP de esta máquina será privada y asignada
por el propio VirtualBox que actúa como servidor DHCP.
El problema viene cuando tenemos que acceder a determinados servicios internos de esa máquina
desde nuestro ordenador (host real). Puede ser el caso por ejemplo de un servidor SSH, servidor
web Apache, Nginx, un Jboss, etc…
Muchas veces lo que se hace es simplemente cambiar el tipo de red de la máquina a Adaptador
Puente (Bridged Adapted) para que la máquina adquina coja una IP de nuestra red y acceder sin
problemas.
Sin embargo, también podemos dejar la red en tipo NAT y realizar una redirección de puertos tal
como mostramos anteriormente
Podríamos crear las reglas que consideráramos necesarias. Por ejemplo para Apache.
31
Corolario
Damos por finalizado con la configuración, más o menos estándar, de posibles escenarios que
contemplan varias posibles situaciones: servidores Linux o Windows junto con además clientes
Linux o Windows. Podríamos ampliar algunas características y configuraciones adicionales pero se
escapa del objetivo el módulo profesional en cuestión. La configuración de los escenarios
mediante la utilización de Servidores en NAT podría haberse realizado de forma similar con la
utilidad NAT Network pero en mi opinión perderíamos en cierta medida la perspectiva de un
escenario real.
32