Samba, dominios, impresoras y políticas con Windows XP

Esta vez toca escribir en español porque la mayoría de entradas que encontré en la red sobre Samba y máquinas Windows estaba en castellano lo cual parece indicar que es una herramienta muy usada en paises latinos.

Dentro del poco conocimiento que tengo de Samba y advirtiendo que algunas de las afirmaciones que vienen a continuación podrían ser incorrectas, describo cómo hemos resuelto los problemas de políticas usuario, perfiles e impresoras en dominios netbios que contienen equipos con Windows XP y Windows 2000.
Samba hace que un servidor Linux funcione como controlador de dominio Windows (netbios) de manera que puede enviar el perfil de los usuarios a las máquinas cliente cuando hacen login junto con políticas que definen permisos. Además en nuestro caso hay un servidor LDAP que contiene la base de datos de usuarios que pueden acceder al sistema. La configuración de Samba y de OpenLDAP puede encontrarse en internet en multiples sitios por lo que no voy a detallarla aquí. Voy a hablar de los problemas que hemos tenido y su solución que tiene que ver con el funcionamiento de las redes Windows.
Samba también funciona para compartir unidades de red mediante la red windows así que en muchos sitios se usa como lugar de almacenamiento compartido.
Samba está un poco obsoleto para administrar equipos posteriores a la familia NT, ya que a partir de Windows XP, las políticas de usuario ya no se definien con Poledit sino con las herramientas para "Group Policies" (gpedit.msc, etc). Samba no soporta Group Policies. Así, cuando una máquina con Windows XP tiene definidas políticas de grupo, éstas prevalecen sobre las que envía el servidor Samba y dicho servidor queda inútil en ese sentido.
Existe otro motivo fundamental por el que las políticas definias mediante Samba no tienen efecto en el equipo Windows y es que haya un fichero NTUser.DAT o algun otro NTUSERalgo. Este fichero es generado por Windows y contiene políticas y claves del registro de Windows.
Puede ser que la maquina Windows cliente genere este fichero y lo aloje en el directorio profile de Samba en el servidor. Para evitarlo hay que crear un fichero ntuser.man o poner permisos de sólo lectura en el directorio profile. Tambien puede ser que la maquina Windows no pueda conectar con
el servidor y genere el NTUser.DAT localmente dentro de la carpeta del usuario en C:\Documents and Settings. En tal caso hay que entrar como administrador local y eliminar toda la carpeta. Puede ser que haya que reinciar la máquina para que sea posible borrar.
De lo anterior deduzco que cuando una máquina Windows entra en un dominio, obtiene una copia local de ciertos datos del servidor, ya que permite a los usuarios hacer login incluso sin conexión con el servidor. Por este motivo, si la maquina que ejerce como controlador de dominio cambia, pero el nombre del dominio no ha cambiado, hay que sacar del dominio a los clientes, pasarlos a un
grupo de trabajo y volverlos a meter en el dominio para que funcionen correctamente. Digamos que es la manera de refrescarles los datos que mantienen del servidor. La misma operacion es necesaria para cambiar el nombre de un equipo.

El fichero donde se definen las políticas de usuario se genera con la herramienta Poledit en un pc Windows, y se guarda con el nombre NTconfig.POL en la carpeta netlogon del servidor Samba.
El problema de que el teclado aparezca en inglés se resuelve añadiendo la plantilla administrativa del teclado a Poledit. Esta es la plantilla para que el teclado aparezca en español (keyboard.adm):

CLASS USER

CATEGORY "Keyboard Layout"

POLICY "Poner el teclado en español"
KEYNAME "Keyboard Layout\Preload"
VALUENAME       "1"
VALUEON "0000040a"
VALUEOFF "0000040a"
ACTIONLISTON
VALUENAME       "2"     VALUE   "0000040a"
END ACTIONLISTON
ACTIONLISTOFF
VALUENAME       "2"     VALUE   "0000040a"
END ACTIONLISTOFF
END POLICY

END CATEGORY

Para que la impresora predeterminada aparezca a los usuarios cuando hacen login en la maquina cliente, hemos instalado un script .bat también en el directorio netlogon que contiene lo siguiente:

rundll32 printui.dll,PrintUIEntry /dn /n "\\nombreDelPCqueTieneLaImpresora\HP LaserJet 1200 Series PCL" /q
rundll32 printui.dll,PrintUIEntry /in /n "\\nombreDelPCqueTieneLaImpresora\HP LaserJet 1200 Series PCL"
rundll32 printui.dll,PrintUIEntry /y /n "\\nombreDelPCqueTieneLaImpresora\HP LaserJet 1200 Series PCL"

(Cambie HP LaserJet 1200... por el nombre de su impresora)

VPN + Virtual Machine

He we are writing in this brand new blog category called Plumbing. Welcome to the misterious world of the systems/servers/networking :-S
I started working as a sysadmin some years ago. It is something I don't love exactly but here in the Canaries you have to do everything yourself; you design, you develop, you patch, and you manage the servers and networks. Now I am a Plumbing Power Ranger again! It is nice sometimes though.

The idea of having a Virtual Private Network to which connect a Virtual Machine that is using your local machine resources but accesing the internet through the other peer of the VPN is very useful. This is another idea of my friend Alberto Morales, a.k.a Master Alberto . By doing so you can see how the network is behaving on the other side of the tunnel so that you get an idea on how the PCs in the office are working. If the system installed in those PCs is the same that you are running in your virtual machine, the conditions are pretty much the same.

This time we are using OpenVPN and VirtualBox which allow us testing Windows or Linux machines as both tools run on Windows and Linux. However we are using Linux right now. OpenVPN uses a static key in the server side for simplicity sake.

Server side, OpenVPN config:

• /etc/openvpn/server.conf
  proto tcp-server
  dev tap
  up ./server.up
  secret secret.key
• /etc/openvpn/server.up
  /sbin/ifconfig $1 0.0.0.0 promisc up
  /usr/sbin/brctl addif br0 $1

In order for that to work a bridge br0 has to be configured and up. An ethernet bridge is like a networking switch. When openvpn starts the network interface /dev/tapX (X will be a number) is configured. A tap interface is like the rj45 socket of the switch (ethernet bridge).

What we do to connect the server above using VirtualBox (the client):

• brctl addbr br1 # create a bridge called bridge 1
• openvpn --dev tap --remote serverIPorName 1194 --proto tcp-client --secret /etc/openvpn/secret.key
• # The previous line will create a /dev/tapX device, let's call it /dev/tap2
• ifconfig tap1 0.0.0.0 promisc up # create tap1 making sure it didn't exist already
• ifconfig tap2 0.0.0.0 promisc up # set tap2 promisc, considering that tap2 was created by openvpn
• ifconfig br1 0.0.0.0 promisc up # let the bridge be promisc
• brctl addif br1 tap1 # give the bridge a socket
• brctl addif br1 tap2 # give the bridge another socket
• chmod 0666 /dev/net/tun # set the permissions for the user to access the tap sockets
• Start virtualbox, select the virtual machine to run, go to settings and configure the network: Use "Host Interface" for the network adapter. Interface name will be tap1, the one that is in the bridge but not used by OpenVPN.

The reason we need 2 tap interfaces is that OpenVPN uses one so it gets busy and the virtual machine needs another. If we just wanted to establish a tunnel with OpenVPN and access the other peer of the virtual LAN, we don't need the bridge in the client side. Just launch OpenVPN with the command above and give an ip address to the tap device:

• ifconfig tap2 192.168.3.34 netmask 255.255.255.0

Now you should be able to ping the LAN ip of the server. You are in the virtual LAN. If rather than setting the ip manually you request dhcp, the dhcp server will change the default gateway in your local machine so you loose the internet connection and openvpn falls down. Always check the routing table (route -n)
In case you make the same mistake I did and set the ip of the tap device having a bridge with 2 tap devices, you get to weird situations. In that case the packages were sent through tap2 but they were trying to come back through tap1. It ends up in lost packages, tap1 drops packages because it didn't send them. That is: having the bridge with more than one tap device, never give an ip address to any of the tap devices.