Anotaciones sobre Samba
Las recetas, trucos y/ó anotaciones que a continuación aparecen son todas para un servidor Debian Lenny actuando en solitario frente a una red windows, principalmente Windows XP, pero con alguna versión 2000 purulando por ella.
Así pues, y como no estoy contemplando un número ilimitado de escenarios en red, es muy posible que lo aquí expuesto apenas tenga utilidad más allá de su problemática.
Conceptos varios
La documentación oficial de la versión 3 incluye una descripción del escenario muy clarificadora. Mientras que en las redes Windows existen dos tipos de seguridad, uno basado en los recursos (shares) y otro en los usuarios (users), Samba es mucho más flexible y proporciona hasta cinco tipos, uno basado en recursos y cuatro en los usuarios.
Dado que Samba es un puente entre Windows y GNU/Linux es necesario tener
en cuenta las diferencias conceptuales de ambos mundos en archivos, usuarios y
permisos de acceso de los últimos sobre los primeros. También conviene
recordar uno de los puntos que se remarcan en la documentación y es
que, al margen del tipo de seguridad que se defina en su configuración,
Samba es un servidor de archivos y de impresoras; por lo visto existe una
confusión al respecto cuando se define en la configuración security=server y
muchos entienden que es entonces cuando se comporta como un servidor. No, en
este caso Samba informa al cliente que está empleando seguridad basada en
usuarios pero pasando todas las peticiones de identificación y autorización a
otro servidor.
Aún más ...
En el mundo de los servidores SMB/CIFS éstos informan al cliente al inicio de
la sesión del tipo de seguridad que ofrecen, orientada a recursos (shares) ú
orientada a usuarios (users). Son los clientes los que con esta información
deciden qué y cómo identificarse y solicitar acceso a los recursos, y no
afecta directamente a la forma que tiene el servidor Samba de encarar la
seguridad.
El nivel de seguridad de recurso protege a éstos únicamente con una contraseña, no es necesario ninguna otra información más por parte del cliente, mientras que el nivel de seguridad de usuario precisa un nombre identificador y una contraseña para disponer de acceso al recurso. Es posible encontrar una explicación sobre esto, breve y concisa (aunque en inglés), en la red de Microsoft.
Puede sonar raro, pero por lo visto en el mundillo SMB/CIFS son los clientes
los que inician y controlan las operaciones. Los servidores se limitan a
informar de lo que está disponible y qué acciones están permitidas.
El término cliente, pues, se aplica a cualquier agente capaz de interactuar
con el servidor Samba; bien sea otro servidor Samba, un puesto de
trabajo (workstation), un servidor Windows, ó programas cliente simples como
smbclient.
No hay que olvidar que el protocolo SMB fue desarrollado inicialmente por IBM y que la variante que tratamos es fruto de la unión de dicho protocolo original con LAN Manager y otros inventos más de la casa.
Niveles de seguridad
Seguridad a nivel de usuario (user level security)
En este nivel el cliente, tras la negociación de protocolo, envía una petición de configuración de sesión que incluye un nombre de usuario y una contraseña. El servidor puede rechazar ó aceptar dicha combinación basándose únicamente en ella y/ó en la máquina de origen de la conexión, dado que no hay todavía un nombre de recurso que emplear para ello.
El cliente espera que a partir de entonces sea capaz de montar recursos usando conexiones árbol sin especificar una contraseña puesto que ya lo ha hecho al comienzo. Además, también es posible que el cliente envíe varias credenciales en la configuración de la sesión, en cuyo caso el servidor le devolverá un identificador bajo el que estárán todas ellas.
Nota: Los nombres de cuenta de usuario en las redes windows no distinguen entre mayúsculas y minúsculas.
El recurso debe tener la siguiente estrofa mínima en la configuración:
security = user
Seguridad a nivel de recurso (share level security)
En este tipo de seguridad el cliente presenta credenciales ante cada recurso,
enviando una contraseña junto a la petición de conexión en árbol, pero sin
añadir un nombre de usuario ya que espera que el recurso esté protegido
únicamente por la contraseña. Ante esto Samba tiene que apañárselas para
determinar el usuario que acompaña a la contraseña, ya que siempre emplea el
esquema de autorización UNIX donde priman ambos valores conjuntos.
¿ Cómo determina Samba el nombre del usuario en estos casos ? Pues de dos
formas:
Guardando el nombre de usuario que le proporciona el cliente cuando pide un inicio de sesión, ya que muchos de ellos cuando conectan efectúan dicha petición y le añaden el nombre del usuario aunque no la contraseña, y todo ello a pesar de que el servidor les informe previamente de que el nivel de seguridad es a nivel de recurso.
Si lo anterior no es posible
Sambaprocede entonces a verificar la contraseña recibida, contrastándola con la base de datos de usuarios hasta que encuentra una coincidencia entre ambas. De esto se deduce que es mejor no complicar las cosas y no permitir que dos usuarios compartan contraseña.Por otra parte, las bases de datos de usuarios que consulta
Sambadepende de si en el sistema existe un NSS en funcionamiento; si es así se consultará el archivo/etc/nsswitch.conf(donde puede que se incluyan cosas como NIS y/ó LDAP), y en caso contrario se empleará únicamente/etc/passwdy derivados directos.
El recurso debe tener la siguiente estrofa mínima en la configuración:
security = share
Usuarios
Optamos por emplear los usuarios del sistema debido a que ya existe una infraestructura de servicios y no queremos duplicar la base de datos de accesos y usuarios, ni permitir que desde las máquinas windows se puedan cambiar contraseñas ni crear usuarios.
En este caso conviene recordar, y mucho, que si se pretende lo contrario, que la máquina Debian se emplee como un servidor de dominio windows, las tareas y disposiciones previas cambian bastante de lo que aquí anoto.
En Debian, pues, es conveniente crear grupos de usuarios y asignarles contenido según las necesidades de acceso que tengan a los diferentes recursos.
Directorios
Para las rutas creamos un directorio raíz y le aplicamos los permisos adecuados según el ejemplo de la guía Samba.
# mkdir -p /srv/samba
# chown root.root /srv/samba
# chmod ug+rwxs,o-rwx /srv/samba
Tras lo cual los permisos de acceso al raíz quedan
drwsrws--- 2 root root 4096 oct 5 11:40 /srv/samba
Y continuamos con los directorios raíz de los correspondientes recursos:
# mkdir -p /srv/samba/{publico,semipublico,privado}
# chown -R nobody.nogroup /srv/samba/publico
# chown -R root.staff /srv/samba/semipublico
# chown -R root.staff /srv/samba/privado
# chmod ug+rwxs,o-w /srv/samba/{publico,semipublico,privado}
Es decir, queremos disponer de un directorio publico en el que podrá leer y
escribir cualquiera, un directorio semipúblico en el que únicamente los
usuarios del grupo staff podrán escribir y todos los demás leer, y otro
directorio totalmente privado para el mismo grupo staff.
Recursos
Para el recurso público la configuración es la siguiente:
[pub] comment = Archivo público path = /srv/samba/publico guest ok = yes writable = yesPara el recurso semipúblico sería:
[semipublico] comment = Archivos semipúblicos path = /srv/samba/semipublico guest ok = yes writable = no browseable = yes write list = @staffPara el recurso privado:
[privado] comment = Archivos privados path = /srv/samba/privado read only = No guest ok = No writable = yes browseable = yes valid users = @staff