1.3.1. ¿Qué tipo de información se puede almacenar en un directorio?

El modelo de información de LDAP está basado en entradas. Una entrada es una colección de atributos que tienen un único y global Nombre Distinguido[1] (DN). El DN se utiliza para referirse a una entrada sin ambigüedades. Cada atributo de una entrada posee un tipo y uno o más valores. Los tipos son normalmente palabras nemotécnicas, como "cn" para common name, o "mail" para una dirección de correo. La sintaxis de los atributos depende del tipo de atributo. Por ejemplo, un atributo cn puede contener el valor "Sergio González". Un atributo email puede contener un valor "sergio@ejemplo.com". El atributo jpegPhoto ha de contener una fotografía en formato JPEG.

1.3.2. ¿Cómo se almacena la información?

En LDAP, las entradas están organizadas en una estructura jerárquica en árbol. Tradicionalmente, esta estructura reflejaba los límites geográficos y organizacionales. Las entradas que representan países aparecen en la parte superior del árbol. Debajo de ellos, están las entradas que representan los estados y las organizaciones nacionales. Debajo de estás, pueden estar las entradas que representan las unidades organizacionales, empleados, impresoras, documentos o todo aquello que pueda imaginarse. La Figura 1-1 muestra un ejemplo de un árbol de directorio LDAP haciendo uso del nombramiento tradicional.

El árbol también se puede organizar basándose en los nombres de dominio de Internet. Este tipo de nombramiento se está volviendo muy popular, ya que permite localizar un servicio de directorio haciendo uso de los DNS. La Figura 1-2 muestra un ejemplo de un directorio LDAP que hace uso de los nombres basados en dominios.

Además, LDAP permite controlar que atributos son requeridos y permitidos en una entrada gracias al uso del atributo denominado objectClass. El valor del atributo objectClass determina que reglas de diseño (schema rules) ha de seguir la entrada.

1.3.3. ¿Cómo es referenciada la información?

Una entrada es referenciada por su nombre distinguido, que es construido por el nombre de la propia entrada (llamado Nombre Relativo Distinguido[4] o RDN) y la concatenación de los nombres de las entradas que le anteceden. Por ejemplo, la entrada para Nuno Gonçalves en el ejemplo del nombramiento de Internet anterior tiene el siguiente RDN: uid=nuno y su DN sería: uid=nuno,ou=estig,dc=ipb,dc=pt. El formato completo para los DN está descrito en el RFC2253, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names."

1.3.4. ¿Cómo se accede a la información?

LDAP define operaciones para interrogar y actualizar el directorio. Provee operaciones para añadir y borrar entradas del directorio, modificar una entrada existente y cambiar el nombre de una entrada. La mayor parte del tiempo, sin embargo, LDAP se utiliza para buscar información almacenada en el directorio. Las operaciones de búsqueda de LDAP permiten buscar entradas que concuerdan con algún criterio especificado por un filtro de búsqueda. La información puede ser solicitada desde cada entrada que concuerda con dicho criterio.

Por ejemplo, imagínese que quiere buscar en el subárbol del directorio que está por debajo de dc=ipb,dc=pt a personas con el nombre Nuno Gonçalves, obteniendo la dirección de correo electrónico de cada entrada que concuerde. LDAP permite hacer esto fácilmente. O tal vez prefiera buscar las organizaciones que posean la cadena IPB en su nombre, posean número de fax y estén debajo de la entrada st=Bragança,c=PT. LDAP le permite hacer esto también. La siguiente sección describe con mayor detalle que se puede hacer con LDAP y como puede serle útil.

1.3.5. ¿Cómo se protege la información de los accesos no autorizados?

Algunos servicios de directorio no proveen protección, permitiendo a cualquier persona acceder a la información. LDAP provee un mecanismo de autentificación para los clientes, o la confirmación de identidad en un servidor de directorio, facilitando el camino para un control de acceso que proteja la información que el servidor posee. LDAP también soporta los servicios de privacidad e integridad.

1.7.1. LDAPv3:

slapd implementa la versión 3 de Lightweight Directory Access Protocol. slapd soporta LDAP sobre IPv4, IPv6 y Unix IPC.

1.7.2. Simple Authentication and Security Layer (SASL):

slapd tiene soporte de autentificación fuerte gracias al uso de SASL. La implementación SASL de slapd hace uso del software Cyrus SASL, el cual soporta un gran número de mecanismos de autentificación, como: DIGEST-MD5, EXTERNAL, y GSSAPI.

1.7.3. Transport Layer Security:

slapd provee protecciones de privacidad e integridad gracias al uso de TLS (o SSL). La implementación TLS de slapd hace uso del software OpenSSL.

1.7.4. Control Topológico

slapd se puede configurar para restringir el acceso a la capa de socket basándose en la información topológica de la red. Esta característica hace uso de los TCP wrappers.

1.7.5. Control de Acceso:

slapd provee facilidades de control de acceso muy potentes, permitiéndole controlar el acceso a la información de su(s) base(s) de datos. Puede controlar el acceso a las entradas basándose en la información de autorización de LDAP, en la dirección IP, en los nombres de dominio y otros criterios. slapd soporta tanto el control de acceso a la información dinámico como estático.

1.7.6. Internacionalización:

slapd soporta Unicode y etiquetas de lenguaje.

1.7.7. Elección del backend de la base de datos:

slapd viene con una serie de backends para diferentes bases de datos. Estos incluyen DBD, un backend de una base de datos transaccional de alto rendimiento; LDBM, un backend ligero basado en DBM; SHELL, una interface para scripts de shell; y PASSWD, un backend simple para el archivo passwd (5). El backend BDB hace uso de Sleepycat Berkeley DB. LDBM utiliza cualquiera de las siguientes: Berkeley DB o GDBM.

1.7.8. Muchas instancias de bases de datos:

slapd se puede configurar para servir a múltiples bases de datos al mismo tiempo. Esto significa que un único servidor slapd puede responder a peticiones de diferentes porciones lógicas del árbol de LDAP, haciendo uso del mismo o distintos backends de bases de datos.

1.7.9. IP genérica de módulos:

Si necesita más personalización, slapd le permite escribir sus propios módulos fácilmente. slapd consiste en dos partes diferentes: un frontend que maneja las comunicaciones protocolares con los clientes LDAP; y módulos que manejan tareas específicas como las operaciones con las bases de datos. Debido a que estas dos piezas se comunican a través de una API C bien definida, puede escribir sus propios módulos, que extenderán slapd de múltiples maneras. También existen numerosos módulos programables de bases de datos. Estos permiten a slapd acceder a fuentes de datos externas haciendo uso de lenguajes de programación populares (Perl, shell, SQL y TCL).

1.7.10. Hilos:

slapd hace uso de hilos para obtener alto rendimiento. Un proceso único multihilo maneja todas las peticiones entrantes haciendo uso de una piscina de hilos. Esto reduce la carga del sistema a la vez que provee alto rendimiento.

1.7.11. Replicación:

slapd se puede configurar para que mantenga copias de la información del directorio. Este esquema de replicación, un único maestro/múltiples esclavos, es vital en ambientes con un volumen alto de peticiones, donde un único servidor slapd no podría proveer la disponibilidad ni la confiabilidad necesarias. slapd incluye también un soporte experimental para la replicación de múltiples maestros. slapd soporta dos métodos de replicación: Sync LDAP y slurpd (8).

1.7.12. Proxy caché:

slapd puede ser configurado como un servicio proxy de caché LDAP.

1.7.13. Configuración:

slapd es altamente configurable a través de un único archivo de configuración, que permite modificar todo aquello que se necesite cambiar. Las opciones por defecto son razonables, lo que facilita mucho el trabajo.

1.9.1. Página principal

El Proyecto OpenLDAP dispone de una página principal, http://www.openldap.org/, desde donde puede obtener mucha información sobre el proyecto. De hecho, para elaborar esta sección ha utilizado la información allí disponible.

1.9.2. Cómo obtener OpenLDAP

El código de OpenLDAP es de libre distribución (vea los The OpenLDAP Public License y Apéndice AS para más información) y su código fuente está disponible desde distintas fuentes, como se verá a continuación.

OpenLDAP dispone de distintas ramas de desarrollo, entre las que se encuentran:

• La versión estable (a la hora de escribir este documento era la versión 2.1.30), cuya característica es que el software que la compone ha sido ampliamente comprobado y se considera muy confiable.

• La última liberación para uso general (a la hora de escribir este documento eran las versiones 2.2.5 y 2.1.30), la cual no ha sido todo lo ampliamente testeada como para considerarla estable.

• La liberación de pruebas, ocasionalmente, los desarrolladores de OpenLDAP harán versiones beta o gamma u otro tipo de liberaciones. La característica de estas, es que sólo tienen el propósito de ser probadas, no son para el uso general.

• Otras liberaciones, cuya existencia puede tener múltiples motivos. Normalmente se suelen emplear para actualizar versiones antiguas de OpenLDAP (como por ejemplo las versiones 1.x y 2.0.x).

La forma de acceso al código fuente se detalla a continuación:

• Acceso al CVS: para más información visite esta página.

• Uso de los mirrors: Si desea bajarse el código fuente ya empaquetado, consulte los mirrors disponibles para hacerlo

• Obtención directa de la página del proyecto: Además de los métodos anteriores de obtención del código fuente, el Proyecto OpenLDAP pone a su disposición el código fuente en las siguientes ubicaciones:

  • Acceso por FTP y HTTP

  • Acceso por FTP

De todas formas, la mayoría de las distribuciones de GNU/Linux disponen de paquetes binarios de OpenLDAP, si los necesitase. Obtenga la información de su distribución para comprobar que posee paquetes de este software.

1.9.3. Documentación

La página principal del Proyecto OpenLDAP dispone de una sección dedicada a la documentación, desde donde se pueden obtener documentos tan interesantes como OpenLDAPProject01, entre otros. Para más detalles, visite: http://www.openldap.org/doc/index.html

1.9.4. Información de soporte

La página dedicada al soporte de OpenLDAP, informa sobre los distintos métodos existentes para obtener ayuda en un determinado momento. Los métodos más importantes para obtener ayuda son los siguientes:

1.9.5. Reporte de bugs

OpenLDAP dispone de un Sistema de seguimiento de tareas, desde donde se pueden reportar errores y bugs relacionados con OpenLDAP (tanto en lo relativo al software como a la documentación), hacer peticiones de nuevas características y realizar contribuciones al software.

1.9.6. Cómo contactar

Para obtener más información sobre OpenLDAP, puede contactar con el Proyecto en la siguiente dirección:

The OpenLDAP Project
c/o The OpenLDAP Foundation
270 Redwood Shores Pwy, PMB#107
Redwood City, California 94065
USA

<Project@OpenLDAP.org>

2.2.1. Instalación de slapd y ldap-utils

El primer paso para instalar OpenLDAP, es instalar los paquetes slapd y ldap-utils. Veamos el procedimiento:

Se ha de tener en cuenta que en algunas ocasiones no aparecen todas las capturas de pantalla que se muestran en el Ejemplo 2-1, eso se puede deber a que ya se haya instalado anteriormente slapd en el sistema o debido al nivel de preguntas elegido en la configuración de debconf. Si por cualquier motivo no apareciesen, puede forzar la configuración de slapd con el comando: # /usr/sbin/dpkg-reconfigure --priority=low slapd

# apt-get install slapd ldap-utils
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Se instalarán los siguientes paquetes NUEVOS:
  ldap-utils slapd
0 actualizados, 2 se instalarán, 0 para eliminar y 1 no actualizados.
Se necesita descargar 0B/1042kB de archivos.
Se utilizarán 2884kB de espacio de disco adicional después de desempaquetar.
Preconfiguring packages ...

Figura 2-7. Configuración de slapd, ¿conservar los datos al desinstalarlo?

Tenga cuidado con la elección de esta pantalla, puede perder los datos almacenados en la base de datos de OpenLDAP si "accidentalmente" se desinstala slapd.

Seleccionamos que No queremos que se borre la base de datos de OpenLDAP al desinstalarse el servidor slapd.

Figura 2-8. Configuración de slapd, ¿mover los datos antiguos?

Esta pantalla de configuración puede no aparecer cuando instale OpenLDAP en su sistema, no se preocupe por ello. El motivo para que no aparezca es que no existen datos en el directorio /var/lib/ldap, esto se puede deber a que esta sea su primera instalación de OpenLDAP o se hayan borrado los datos de dicho directorio, entre otros.

Dependiendo de sus necesidades debería contestar o Sí o No en esta pantalla. En este ejemplo se contestará que Sí, de esta forma los datos existentes en /var/lib/ldap se empaquetarán y se moverán moverán a un directorio similar a /var/backups/var_lib_ldap-*FECHA*/ donde *FECHA* se sustituirá por la fecha que posea el ordenador en ese momento.

find: /var/lib/ldap: No existe el fichero o el directorio

Seleccionando el paquete ldap-utils previamente no seleccionado.
(Leyendo la base de datos ...
252690 ficheros y directorios instalados actualmente.)
Desempaquetando ldap-utils (de .../ldap-utils_2.1.30-1_i386.deb) ...
Seleccionando el paquete slapd previamente no seleccionado.
Desempaquetando slapd (de .../slapd_2.1.30-1_i386.deb) ...
Configurando ldap-utils (2.1.30-1) ...
Configurando slapd (2.1.30-1) ...
Creating initial slapd configuration... done
Creating initial LDAP directory... done
Starting OpenLDAP: slapd.

localepurge: checking system for new locale ...
localepurge: processing locale files ...
localepurge: processing man pages ...

2.2.2. Observaciones a la instalación

Una vez más, dependiendo de como se encuentre su sistema y los paquetes que tenga instalados en el mismo, se instalarán y sugerirán más o menos dependencias a la hora de instalar OpenLDAP.

La siguiente captura muestra la información relativa a los paquetes que se acaban de instalar (dependencias, sugerencias de instalación, etc).

$ /usr/bin/apt-cache show slapd ldap-utils
Package: slapd
Priority: optional
Section: net
Installed-Size: 2516
Maintainer: Torsten Landschoff <torsten@debian.org>
Architecture: i386
Source: openldap2
Version: 2.1.30-1
Provides: ldap-server
Depends: libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcrypt7,
libgnutls10 (>= 1.0.0-0), libgpg-error0 (>= 0.7),
libiodbc2 (>= 3.51.2-2), libldap2 (>= 2.1.17-1),
libltdl3 (>= 1.5.2-2), libsasl2 (>= 2.1.18), libslp1,
libtasn1-2 (>= 0.2.7), libwrap0, zlib1g (>= 1:1.2.1),
debconf (>= 0.5), coreutils (>= 4.5.1-1) | fileutils (>= 4.0i-1),
psmisc, libldap2 (= 2.1.30-1), perl (>> 5.8.0) | libmime-base64-perl
Recommends: db4.2-util, libsasl2-modules
Suggests: ldap-utils
Conflicts: umich-ldapd, ldap-server, libbind-dev, bind-dev,
libltdl3 (= 1.5.4-1)
Filename: pool/main/o/openldap2/slapd_2.1.30-1_i386.deb
Size: 940506
MD5sum: 3cc284bf5c0bc8da52a5aabc61c56ca7
Description: OpenLDAP server (slapd)
 This is the OpenLDAP (Lightweight Directory Access Protocol) standalone
 server (slapd). The server can be used to provide a standalone directory
 service and also includes the slurpd replication server.

Package: ldap-utils
Priority: optional
Section: net
Installed-Size: 328
Maintainer: Torsten Landschoff <torsten@debian.org>
Architecture: i386
Source: openldap2
Version: 2.1.30-1
Replaces: openldap-utils, slapd (<< 2.1.25), openldapd
Provides: ldap-client, openldap-utils
Depends: libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcrypt7,
libgnutls10 (>= 1.0.0-0), libgpg-error0 (>= 0.7),
libiodbc2 (>= 3.51.2-2), libldap2 (>= 2.1.17-1),
libltdl3 (>= 1.5.2-2), libsasl2 (>= 2.1.18), libslp1,
libtasn1-2 (>= 0.2.7), zlib1g (>= 1:1.2.1), libldap2 (= 2.1.30-1)
Recommends: libsasl2-modules
Conflicts: umich-ldap-utils, openldap-utils, ldap-client
Filename: pool/main/o/openldap2/ldap-utils_2.1.30-1_i386.deb
Size: 113996
MD5sum: 2842fec02d967bbf70943def051d9f58
Description: OpenLDAP utilities
 Utilities from the OpenLDAP (Lightweight Directory Access Protocol)
 package. These utilities can access a local or remote LDAP server
 and contain all the client programs required to access LDAP servers.

2.3.1. Ejecución del demonio

En este punto, ya se debería tener un servidor OpenLDAP instalado y ejecutándose, aunque no esté ajustado todavía a los objetivos que persigue este apartado. Para comprobar que efectivamente el demonio slapd se está ejecutando, realizaremos un par de consultas al sistema. La primera consiste en ver si el demonio slapd se encuentra en la lista de procesos que actualmente se estén ejecutando en el sistema:

# /bin/ps auxf | /bin/grep slapd
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root      4453  0.0  0.5 12144 3004 ?        S    12:52   0:00 /usr/sbin/slapd
root      4455  0.0  0.5 12144 3004 ?        S    12:52   0:00  \_ /usr/sbin/slapd
root      4456  0.0  0.5 12144 3004 ?        S    12:52   0:00      \_ /usr/sbin/slapd

En la captura de pantalla anterior se ha eliminado la línea que hacía referencia la instrucción tecleada (/bin/ps auxf | /bin/grep slapd) y se ha añadido la línea de información sobre cada parte de la captura, para mejorar la legibilidad.

La segunda comprobación ha realizar, para ver si el demonio se está realmente ejecutando, es verificar que está escuchando en la red[7]:

# /bin/netstat -puta
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 *:ldap                  *:*                     LISTEN     4453/slapd

2.3.2. Conectando con el servidor

Una vez comprobado que el demonio slapd se está ejecutando en el sistema, se verificará que la conexión con el mismo está permitida. Para ello, se realizará una búsqueda sencilla en el directorio. Si todo va bien, se debería mostrar algo similar a:

$ /usr/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope base
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=gsr,dc=pt

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

---

2.3.2.1. Posibles problemas de conexión

2.3.2.1.1. TCP Wrappers

Se han de tener en cuenta las opciones de configuración pasadas, antes de la compilación de OpenLDAP, para generar los paquetes que se están utilizando. Si nos fijamos en las opciones de configuración que posee OpenLDAP por defecto en Debian GNU/Linux (consulte el Apéndice O) veremos que utiliza la opción --enable-wrappers, lo que habilita el soporte de los TCP Wrappers en OpenLDAP.

Si se posee una configuración restrictiva de los TCP Wrappers, puede que sea esta la causa de los problemas de conexión. A continuación se simulará un fallo de conexión debido a un bloqueo de los TCP Wrappers, mostrándola manera de detectarlo y corregirlo.

Se supone la siguiente configuración de los TCP Wrappers (en los Apéndice AM y Apéndice AN se encuentran los archivos finales para los TCP Wrappers):

Ejemplo 2-6. Archivo /etc/hosts.allow

# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5), hosts_options(5)
#                   and /usr/doc/netbase/portmapper.txt.gz
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper. See portmap(8)
# and /usr/doc/portmap/portmapper.txt.gz for further information.
#

Ejemplo 2-7. Archivo /etc/hosts.deny

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5), hosts_options(5)
#                  and /usr/doc/netbase/portmapper.txt.gz
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper. See portmap(8)
# and /usr/doc/portmap/portmapper.txt.gz for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address. You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID

# Desautorizar a todos los hosts con nombre sospechoso
ALL: PARANOID

# Desautorizar a todos los hosts
ALL:ALL

Ahora se realizará la misma búsqueda que en Ejemplo 2-5:

Ejemplo 2-8. Realización de una búsqueda simple con ldapsearch (conexión fallida)

$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
ldap_bind: Can't contact LDAP server (81)

Como se puede apreciar, no se ha podido conectar con el servidor LDAP. El siguiente ejemplo realizará la misma búsqueda, sólo que en este caso se activará el modo de depuración del comando ldapsearch "-d -1" (se hará uso del nivel de depurado -1, que es el mayor nivel existente).

Ejemplo 2-9. Realización de una búsqueda simple con ldapsearch (modo depuración)

    $ ldapsearch -d -1 -x -b '' -s base '(objectclass=*)' namingContexts
    ldap_create
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP gsr.pt:389 
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.2.1:389 
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_int_sasl_open: host=gsr.pt
ldap_open_defconn: successful 
ldap_send_server_request
ber_flush: 14 bytes to sd 3
  0000:  30 0c 02 01 01 60 07 02  01 03 04 00 80 00         0....`........
ldap_write: want=14, written=14
  0000:  30 0c 02 01 01 60 07 02  01 03 04 00 80 00         0....`........
ldap_result msgid 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1
wait4msg continue, msgid 1, all 1
** Connections:
* host: gsr.pt  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Tue Mar  9 16:18:26 2004

** Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** Response Queue:
   Empty
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
ldap_int_select
read1msg: msgid 1, all 1
ber_get_next
ldap_read: want=8, got=0

ber_get_next failed. 
ldap_perror 
ldap_bind: Can't contact LDAP server (81) 

Aquí se puede ver que el host con el que establece la conexión es el correcto.

Una vez encontrado el host, se conecta satisfactoriamente al mismo.

En este momento comienzan los errores de conexión.

Como se puede observar en el Ejemplo 2-9, que no se obtiene la información suficiente para deducir cual ha sido el problema que ocasiona el error en la conexión. Por este motivo se ejecutará el demonio slapd en modo depuración y, aunque no sea necesario, se ejecutará con el nivel de depurado "-1".

Antes proceder con este ejemplo, se mostrarán los posibles valores que puede tomar el modo de depuración de slapd y su significado[8]:

Tabla 2-1. Niveles de depurado de slapd

Nivel	Descripción
-1	Habilita todo el depurado
0	Sin depurado
1	Rastrea las llamadas a funciones
2	Depura el manejo de paquetes
4	Rastreo de depuración intensivo
8	Administración de la conexión
16	Muestra los paquetes enviados y recibidos
32	Procesado de búsqueda por filtro
64	Procesado del archivo de configuración
128	Procesado de la lista de control de acceso
256	stats log connections/operations/results
512	stats log entries sent
1024	Muestra las comunicaciones con los backends de la shell
2048	Muestra las entradas analizadas (parsing)

Ejemplo 2-10. Ejecución del servidor slapd en modo de depuración

    # /usr/sbin/slapd -d -1 -h ldap://gsr.pt:389/
    @(#) $OpenLDAP: slapd 2.1.30 (May 24 2004 23:50:57) $
        @pulsar:/home/torsten/packages/openldap/release-2.1.30-1/openldap2-2.1.30/debian/build/servers/slapd
daemon_init: ldap://gsr.pt:389/
daemon_init: listen on ldap://gsr.pt:389/
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://gsr.pt:389/)
daemon: initialized ldap://gsr.pt:389/
daemon_init: 1 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
reading config file /etc/ldap/slapd.conf
line 11 (include         /etc/ldap/schema/core.schema)
reading config file /etc/ldap/schema/core.schema/

(...)

slapd startup: initiated.
slapd starting
daemon: added 6r
daemon: select: listen=6 active_threads=0 tvp=NULL

En este momento ya tenemos el demonio slapd en modo depuración, por lo que si realizamos de nuevo la búsqueda del Ejemplo 2-8, se verá la información que muestra el servidor cuando esta se realiza:

Ejemplo 2-11. Ejecución del servidor slapd en modo de depuración (mensaje de rechazo de una conexión)

    daemon: activity on 1 descriptors
daemon: new connection on 9
fd=9 DENIED from unknown (192.168.2.1) 
daemon: closing 9
daemon: activity on:
daemon: select: listen=6 active_threads=0 tvp=NULL

Esta línea muestra el motivo del rechazo de la conexión, no se permite la conexión desde la IP 192.168.2.1, que es desde la que se está tratando de realizar la consulta precisamente.

Si se añade la siguiente línea al archivo /etc/hosts.allow "slapd: 192.168.2.1" y se ejecuta de nuevo la búsqueda del Ejemplo 2-8, sucede lo siguiente:

• El servidor muestra la siguiente información:

  Ejemplo 2-12. Ejecución del servidor slapd en modo de depuración (mensaje de aceptación de una conexión)

      daemon: activity on 1 descriptors
  daemon: new connection on 9
  conn=2 fd=9 ACCEPT from IP=192.168.2.1:32852 (IP=192.168.2.1:389) 
  daemon: added 9r
  daemon: activity on:
  daemon: select: listen=6 active_threads=0 tvp=NULL
  daemon: activity on 1 descriptors
  daemon: activity on: 9r
  daemon: read activity on 9
  connection_get(9)
  connection_get(9): got connid=2
  connection_read(9): checking for input on id=2
  ber_get_next
  
  (...)
  
  conn=2 op=1 SRCH base="" scope=0 filter="(objectClass=*)"
  conn=2 op=1 SRCH attr=namingContexts
  => test_filter
      PRESENT
  => access_allowed: search access to "" "objectClass" requested
  => acl_get: [1] check attr objectClass
  => dn: [2]
  => acl_get: [2] matched
  => acl_get: [2] check attr objectClass
  <= acl_get: [2] acl  attr: objectClass
  => acl_mask: access to entry "", attr "objectClass" requested
  => acl_mask: to all values by "", (=n)
  <= check a_dn_pat: *
  <= acl_mask: [1] applying read(=rscx) (stop)
  <= acl_mask: [1] mask: read(=rscx)
  => access_allowed: search access granted by read(=rscx)
  <= test_filter 6
  => send_search_entry: dn=""
  => access_allowed: read access to "" "entry" requested
  => acl_get: [1] check attr entry
  => dn: [2]
  => acl_get: [2] matched
  => acl_get: [2] check attr entry
  <= acl_get: [2] acl  attr: entry
  => acl_mask: access to entry "", attr "entry" requested
  => acl_mask: to all values by "", (=n)
  <= check a_dn_pat: *
  <= acl_mask: [1] applying read(=rscx) (stop)
  <= acl_mask: [1] mask: read(=rscx)
  => access_allowed: read access granted by read(=rscx)
  => access_allowed: read access to "" "namingContexts" requested
  => acl_get: [1] check attr namingContexts
  => dn: [2]
  => acl_get: [2] matched
  => acl_get: [2] check attr namingContexts
  <= acl_get: [2] acl  attr: namingContexts
  access_allowed: no res from state (namingContexts)
  => acl_mask: access to entry "", attr "namingContexts" requested
  => acl_mask: to all values by "", (=n)
  <= check a_dn_pat: *
  <= acl_mask: [1] applying read(=rscx) (stop)
  <= acl_mask: [1] mask: read(=rscx)
  => access_allowed: read access granted by read(=rscx)
  
  (...)
  
  ber_get_next on fd 9 failed errno=0 (Success)
  connection_read(9): input error=-2 id=2, closing.
  connection_closing: readying conn=2 sd=9 for close
  connection_close: deferring conn=2 sd=9
  do_unbind
  conn=2 op=2 UNBIND
  connection_resched: attempting closing conn=2 sd=9
  connection_close: conn=2 sd=9
  daemon: removing 9
  conn=2 fd=9 closed
  daemon: select: listen=6 active_threads=0 tvp=NULL
  daemon: activity on 1 descriptors
  daemon: select: listen=6 active_threads=0 tvp=NULL

  

  Finalmente se ha aceptado la conexión.

• Del lado del cliente se obtiene la misma información que en el Ejemplo 2-5.

---

2.3.2.1.2. Address family not supported by protocol

Un error derivado de la instalación por defecto, es el que se muestra en título de esta sección. Si no se especifica en que interfaces ha de escuchar el demonio slapd, dará el mentado error.

A continuación se verá la diferencia de ejecutar el servidor especificando o no la interfaz sobre la que tiene que escuchar. Para ello, una vez más se ejecutará en modo depuración.

Ejemplo 2-13. Ejecución del demonio slapd sin especificar la interfaz donde escuchar

    # /usr/sbin/slapd -d -1
    @(#) $OpenLDAP: slapd 2.1.30 (May 24 2004 23:50:57) $
        @pulsar:/home/torsten/packages/openldap/release-2.1.30-1/\
                              openldap2-2.1.30/debian/build/servers/slapd
daemon_init: <null>
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
slap_open_listener: socket() failed for AF_INET6 errno=97 (Address family not supported by protocol) 
daemon: initialized ldap:///
daemon_init: 2 listeners opened
ldap_pvt_gethostbyname_a: host=todoscsi, r=0
slapd init: initiated server.
slap_sasl_init: initialized!
reading config file /etc/ldap/slapd.conf
line 11 (include         /etc/ldap/schema/core.schema)
reading config file /etc/ldap/schema/core.schema

(...)

slapd startup: initiated.
slapd starting
daemon: added 6r
daemon: select: listen=6 active_threads=0 tvp=NULL

Aquí se muestra el error.

Ejemplo 2-14. Ejecución del demonio slapd especificando la interfaz donde escuchar

    # /usr/sbin/slapd -d -1 -h ldap://gsr.pt:389/
    @(#) $OpenLDAP: slapd 2.1.30 (May 24 2004 23:50:57) $
        @pulsar:/home/torsten/packages/openldap/release-2.1.30-1/\
                              openldap2-2.1.30/debian/build/servers/slapd
daemon_init: ldap://gsr.pt:389/
daemon_init: listen on ldap://gsr.pt:389/
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://gsr.pt:389/)
daemon: initialized ldap://gsr.pt:389/
daemon_init: 1 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
reading config file /etc/ldap/slapd.conf
line 11 (include         /etc/ldap/schema/core.schema)
reading config file /etc/ldap/schema/core.schema

(...)

slapd startup: initiated.
slapd starting
daemon: added 6r
daemon: select: listen=6 active_threads=0 tvp=NULL

En el Ejemplo 2-14 se puede ver que ya no muestra ningún tipo de error al inicializar el servidor.

En el Capítulo 3 se verá como configurar slapd para que arranque automáticamente con la especificación de la interfaces.

3.1.1. Cambio del usuario y grupo de ejecución de slapd

Por defecto, el demonio slapd se ejecuta como usuario root (vea el Ejemplo 2-3 para más detalles), comportamiento que no es recomendable por las implicaciones de seguridad que acarrea. En esta sección se describirán los pasos necesarios para ejecutar el demonio slapd con un usuario y un grupo específicos.

# addgroup --system slapd
Añadiendo el grupo slapd (133)...
Hecho.
# adduser --home /var/lib/ldap --shell /bin/false --no-create-home --ingroup slapd --system
adduser: Aviso: El directorio home que Usted especificó ya existe.
Añadiendo usuario del sistema slapd...
Añadiendo nuevo usuario slapd (126) con grupo slapd.
No se crea el directorio home.

---

3.1.1.2. Cambio de propietario/grupo en los archivos de slapd

Antes de continuar con este paso, ha de parar el demonio slapd para evitar comportamientos no esperados: Ejemplo 3-2. Modo de parar el demonio slapd # /etc/init.d/slapd stop Stopping OpenLDAP: slapd.

Antes de ejecutar el demonio slapd con el nuevo usuario y grupo creados, es necesario cambiar el propietario y el grupo de algunos archivos y directorios relacionados con slapd, para que este funcione con normalidad. Los cambios han de realizarse en los siguientes directorios, así como en los archivos que albergan:

• /etc/ldap

• /var/lib/slapd

• /var/lib/ldap

• /var/run/slapd

Para ello se ha de ejecutar:

Ejemplo 3-3. Cambio del propietario/grupo en archivos relacionados con slapd

# /bin/chown -R slapd.slapd /etc/ldap /var/lib/slapd /var/lib/ldap /var/run/slapd slapd

En estos momentos slapd ya casi está preparado para ejecutarse con el nuevo usuario.

SLAPD_USER="slapd"
SLAPD_GROUP="slapd"

# /etc/init.d/slapd start
Starting OpenLDAP: slapd.
# /bin/ps auxf
USER       PID %CPU %MEM   VSZ  RSS TTY   STAT START TIME COMMAND
slapd    12728  0.0  0.6 12216 3556 ?     S    15:02 0:00 /usr/sbin/slapd -g slapd -u slapd 
slapd    12729  0.0  0.6 12216 3556 ?     S    15:02 0:00  \_ /usr/sbin/slapd -g slapd -u slapd 
slapd    12730  0.0  0.6 12216 3556 ?     S    15:02 0:00      \_ /usr/sbin/slapd -g slapd -u slapd 

3.1.2. Especificación de las interfaces donde escuchar

La configuración por defecto del demonio slapd hace que escuche en todas las interfaces de red presentes en el sistema. Esta característica no es deseable, por este motivo se verá la forma de modificarla.

La especificación de las interfaces de red, así como el protocolo utilizado en cada una de ellas (ldap, ldaps, ldai), se realiza en el archivo /etc/default/slapd. Dentro de este, la variable SLAPD_SERVICES poseerá las interfaces donde se desea que escuche slapd. El Ejemplo 3-6 muestra como hacerlo.

SLAPD_SERVICES="ldap://gsr.pt:389/ ldaps://gsr.pt:636/"

El protocolo "ldap" especifica las interfaces y los puertos donde escuchará slapd con la característica de que las conexiones que se establezcan a la misma no harán uso de encriptación. El protocolo "ldaps" especifica las interfaces y los puertos donde escuchará slapd con la característica de que las conexiones que se establezcan a la misma harán uso de encriptación. Adicionalmente se puede establecer un nuevo protocolo de comunicaciones, "ldapi", destinado a las peticiones realizadas desde sockets Unix.

Una vez se han asignado las interfaces necesarias, se ha de reiniciar el demonio slapd:

# /bin/netstat -puta
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address     Foreign Address    State   PID/Program name
tcp        0      0 *:ldap            *:*                LISTEN 12728/slapd
# /etc/init.d/slapd restart
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.
# /bin/netstat -puta
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address    Foreign Address   State   PID/Program name
tcp        0      0 gsr.pt:ldap      *:*               LISTEN 12817/slapd
tcp        0      0 gsr.pt:ldaps      *:*               LISTEN 12817/slapd
# /bin/ps auxfw

USER  PID   %CPU %MEM  VSZ  RSS TTY STAT START TIME COMMAND
slapd 12817 0.0  0.6 12216 3552 ?   S    15:19 0:00 /usr/sbin/slapd -h ldap://gsr.pt:389/ 
                                                    |                  ldaps://gsr.pt:636/
                                                    |               -g slapd -u slapd
slapd 12818 0.0  0.6 12216 3552 ?   S    15:19 0:00  \_ /usr/sbin/slapd -h ldap://gsr.pt:389/ 
                                                       |                   ldaps://gsr.pt:636/
                                                       |                -g slapd -u slapd
slapd 12819 0.0  0.6 12216 3552 ?   S    15:19 0:00     \_ /usr/sbin/slapd -h ldap://gsr.pt:389/ 
                                                                              ldaps://gsr.pt:636/
                                                                           -g slapd -u slapd

La salida del comando /bin/ps se ha retocado para mejorar la legibilidad.

4.2.1. Certificado autofirmado

La primera forma para la creación del certificado del servidor emplea OpenSSL y genera un certificado autofirmado para el servidor. Para ello, desde la línea de comandos se ha de teclear (la letra en negrita son las opciones que ha de introducir el usuario):

OpenLDAP sólo trabaja con llaves no encriptadas, por lo que se ha de emplear el parámetro "-nodes" de OpenSSL para evitar la encriptación de la llave privada.

$ openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 365
Generating a 1024 bit RSA private key
..........................++++++
...............................++++++
writing new private key to 'server.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PT
State or Province Name (full name) [Some-State]:Braganca
Locality Name (eg, city) []:Braganca
Organization Name (eg, company) [Internet Widgits Pty Ltd]:gsr.pt
Organizational Unit Name (eg, section) []:gsr.pt
Common Name (eg, YOUR name) []:gsr.pt
Email Address []:sergio@gsr.pt

Esto creará un archivo server.pem en el directorio donde haya ejecutado el comando del Ejemplo 4-1. Puede ver una muestra en el Apéndice A.

Ahora sólo falta indicar a OpenLDAP que utilice el certificado anteriormente creado. Para ello se han de añadir las siguientes líneas al archivo de configuración de slapd, /etc/ldap/slapd.conf:

TLSCACertificateFile server.pem 
TLSCertificateFile server.pem 
TLSCertificateKeyFile server.pem

4.2.2. Certificado emitido por una CA

Si ya posee una entidad certificadora (CA) de confianza, sáltese esta sección dedicada al proceso de obtención de un certificado firmado por una entidad certificadora y la creación de un certificado y una llave privada para el servidor.

Sin embargo, si no posee de una entidad certificadora de confianza, OpenSSL realiza el mismo proceso rápida y fácilmente. Para ello siga los siguientes pasos:

1. Creación de un directorio para crear y firmar los certificados, por ejemplo: /var/tmp/mica

   Ejemplo 4-3. Creación de un directorio para crear y firmar los certificados

   $ /bin/mkdir -v /var/tmp/mica
   /bin/mkdir: se ha creado el directorio `/var/tmp/mica'

2. Sitúese en el directorio /var/tmp/mica y ejecute el script CA.sh de OpenSSL.

   Ejemplo 4-4. Creación de una entidad certificadora

   $ cd /var/tmp/mica
   $ /usr/lib/ssl/misc/CA.sh -newca
   CA certificate filename (or enter to create)
   [Enter]
   Making CA certificate ...
   Generating a 1024 bit RSA private key
   ....................+++
   ...................................+++
   writing new private key to './demoCA/private/./cakey.pem'
   Enter PEM pass phrase: [Clave ca] 
   Verifying - Enter PEM pass phrase: [Clave ca]
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:PT
   State or Province Name (full name) [Some-State]:Braganca
   Locality Name (eg, city) []:Braganca
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:gsr.pt
   Organizational Unit Name (eg, section) []:gsr.pt
   Common Name (eg, YOUR name) []:gsr.pt
   Email Address []:sergio@gsr.pt
   

   

   La clave utilizada ha de tener un mínimo de 4 caracteres.

   Esto creará la siguiente estructura de directorios bajo /var/tmp/mica:

   $ /usr/bin/tree
   .
   `-- demoCA
       |-- cacert.pem
       |-- certs
       |-- crl
       |-- index.txt
       |-- newcerts
       |-- private
       |   `-- cakey.pem
       `-- serial
   
   5 directories, 4 files

   Pero los archivos realmente interesantes con demoCA/cacert.pem y demoCA/private/cakey.pem (El certificado de la entidad certificadora y la llave privada, respectivamente).

3. Creamos la petición para la firma del certificado perteneciente al servidor (CSR):

   Ejemplo 4-5. Creación de la petición para la firma del certificado del servidor

   $ /usr/bin/openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem
   Generating a 1024 bit RSA private key
   ...++++++
   ...........++++++
   writing new private key to 'newreq.pem'
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:PT
   State or Province Name (full name) [Some-State]:Braganca
   Locality Name (eg, city) []:Braganca
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:gsr.pt
   Organizational Unit Name (eg, section) []:gsr.pt
   Common Name (eg, YOUR name) []:gsr.pt
   Email Address []:sergio@gsr.pt
   
   
   Please enter the following 'extra' attributes
   to be sent with your certificate request
   A challenge password []:[Clave] 
   An optional company name []:.
   

   

   La clave utilizada ha de tener un mínimo de 4 caracteres.

   El resultado es el archivo newreq.pem.

4. Firma del CSR:

   Ejemplo 4-6. Firma del CSR

   $ /usr/lib/ssl/misc/CA.sh -sign
   Using configuration from /usr/lib/ssl/openssl.cnf
   Enter pass phrase for ./demoCA/private/cakey.pem:[Clave ca]
   Check that the request matches the signature
   Signature ok
   Certificate Details:
           Serial Number: 1 (0x1)
           Validity
               Not Before: Mar  9 23:25:59 2004 GMT
               Not After : Mar  9 23:25:59 2005 GMT
           Subject:
               countryName               = PT
               stateOrProvinceName       = Braganca
               localityName              = Braganca
               organizationName          = gsr.pt
               organizationalUnitName    = gsr.pt
               commonName                = gsr.pt
               emailAddress              = sergio@gsr.pt
           X509v3 extensions:
               X509v3 Basic Constraints:
                   CA:FALSE
               Netscape Comment:
                   OpenSSL Generated Certificate
               X509v3 Subject Key Identifier:
                   6D:5B:86:85:67:82:40:81:1A:00:17:13:6A:55:87:C6:0F:AE:0B:2F
               X509v3 Authority Key Identifier:
                   keyid:FD:76:7B:FA:EB:98:03:6D:8C:D6:AF:2F:65:DD:0A:62:BB:79:66:58
                   DirName:/C=PT/ST=Braganca/L=Braganca/O=gsr.pt/OU=gsr.pt/CN=gsr.pt/\
                                                            emailAddress=sergio@gsr.pt
                   serial:00
   
   Certificate is to be certified until Mar  9 23:25:59 2005 GMT (365 days)
   Sign the certificate? [y/n]:y
   
   1 out of 1 certificate requests certified, commit? [y/n]y
   Write out database with 1 new entries
   Data Base Updated
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number: 1 (0x1)
           Signature Algorithm: md5WithRSAEncryption
           Issuer: C=PT, ST=Braganca, L=Braganca, O=gsr.pt, OU=gsr.pt, \
                                              CN=gsr.pt/emailAddress=sergio@gsr.pt
           Validity
               Not Before: Mar  9 23:25:59 2004 GMT
               Not After : Mar  9 23:25:59 2005 GMT
           Subject: C=PT, ST=Braganca, L=Braganca, O=gsr.pt, OU=gsr.pt, \
                                               CN=gsr.pt/emailAddress=sergio@gsr.pt
           Subject Public Key Info:
               Public Key Algorithm: rsaEncryption
               RSA Public Key: (1024 bit)
                   Modulus (1024 bit):
                       00:b7:19:89:78:17:a5:89:74:65:fe:57:23:3b:53:
                       e0:49:81:bb:12:71:6b:28:90:09:73:1f:7f:88:d5:
                       0a:1e:f1:c7:13:7a:e0:48:f7:ff:1a:92:bf:35:31:
                       6d:df:ad:95:09:1d:12:0e:59:8f:b8:b5:ef:43:92:
                       e6:e0:f2:cd:db:85:bc:70:d6:d5:f7:a3:12:f5:52:
                       20:2a:55:40:10:1f:f7:bd:5c:ef:d7:db:33:f9:4e:
                       f5:c7:6f:a5:07:15:c0:74:b2:98:ff:13:d7:6f:19:
                       16:c5:f9:d9:47:b5:91:22:5b:f1:fe:05:ee:5b:af:
                       00:18:93:47:e2:ff:04:7e:1b
                   Exponent: 65537 (0x10001)
           X509v3 extensions:
               X509v3 Basic Constraints:
                   CA:FALSE
               Netscape Comment:
                   OpenSSL Generated Certificate
               X509v3 Subject Key Identifier:
                   6D:5B:86:85:67:82:40:81:1A:00:17:13:6A:55:87:C6:0F:AE:0B:2F
               X509v3 Authority Key Identifier:
                   keyid:FD:76:7B:FA:EB:98:03:6D:8C:D6:AF:2F:65:DD:0A:62:BB:79:66:58
                   DirName:/C=PT/ST=Braganca/L=Braganca/O=gsr.pt/OU=gsr.pt/\
                                                CN=gsr.pt/emailAddress=sergio@gsr.pt
                   serial:00
   
       Signature Algorithm: md5WithRSAEncryption
           05:49:b1:11:79:97:b9:0e:23:c1:1f:65:c1:8d:51:0d:b4:06:
           b8:39:a1:74:6f:e1:ce:5b:45:56:b7:6c:09:f1:7c:ec:24:62:
           03:8e:8a:f6:6c:4a:88:20:d9:33:95:fe:22:2a:92:b5:cb:3f:
           6e:97:74:45:4a:68:26:80:62:d3:4b:17:cf:41:96:e8:47:41:
           77:26:67:33:8e:72:f3:87:10:a1:c1:21:89:1c:55:26:ab:d4:
           c6:26:a0:9a:f7:ef:e6:4e:62:27:47:9f:16:0f:a2:0d:45:ae:
           d1:82:0a:2e:c0:ae:d3:05:e7:f2:3a:a2:9f:84:af:d9:4f:21:
           c2:f8:a3:13:db:2b:62:53:4b:7f:03:89:ef:ec:af:7d:6c:04:
           05:f8:9b:c8:67:4c:10:1d:09:15:3a:6b:d2:06:83:88:69:e6:
           eb:f3:fe:03:8a:eb:a6:48:8b:f8:f0:7e:ab:05:31:24:15:86:
           d0:69:84:f3:ec:da:97:58:74:36:3f:47:ba:1a:8b:9a:61:f5:
           9d:16:dc:6e:1c:20:f5:65:f7:21:8d:39:4c:29:5d:4e:ef:b0:
           df:07:d3:e3:95:24:94:67:78:d5:57:bf:26:14:60:44:45:c2:
           74:6a:00:d6:f7:d3:a4:52:fb:69:1c:a7:38:73:7b:35:4d:fe:
           02:43:82:65
   -----BEGIN CERTIFICATE-----
   MIIEEzCCAvugAwIBAgIBATANBgkqhkiG9w0BAQQFADCBhDELMAkGA1UEBhMCUFQx
   ETAPBgNVBAgTCEJyYWdhbmNhMREwDwYDVQQHEwhCcmFnYW5jYTEPMA0GA1UEChMG
   Z3NyLnB0MQ8wDQYDVQQLEwZnc3IucHQxDzANBgNVBAMTBmdzci5wdDEcMBoGCSqG
   SIb3DQEJARYNc2VyZ2lvQGdzci5wdDAeFw0wNDAzMDkyMzI1NTlaFw0wNTAzMDky
   MzI1NTlaMIGEMQswCQYDVQQGEwJQVDERMA8GA1UECBMIQnJhZ2FuY2ExETAPBgNV
   BAcTCEJyYWdhbmNhMQ8wDQYDVQQKEwZnc3IucHQxDzANBgNVBAsTBmdzci5wdDEP
   MA0GA1UEAxMGZ3NyLnB0MRwwGgYJKoZIhvcNAQkBFg1zZXJnaW9AZ3NyLnB0MIGf
   MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3GYl4F6WJdGX+VyM7U+BJgbsScWso
   kAlzH3+I1Qoe8ccTeuBI9/8akr81MW3frZUJHRIOWY+4te9Dkubg8s3bhbxw1tX3
   oxL1UiAqVUAQH/e9XO/X2zP5TvXHb6UHFcB0spj/E9dvGRbF+dlHtZEiW/H+Be5b
   rwAYk0fi/wR+GwIDAQABo4IBEDCCAQwwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E
   HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFG1bhoVn
   gkCBGgAXE2pVh8YPrgsvMIGxBgNVHSMEgakwgaaAFP12e/rrmANtjNavL2XdCmK7
   eWZYoYGKpIGHMIGEMQswCQYDVQQGEwJQVDERMA8GA1UECBMIQnJhZ2FuY2ExETAP
   BgNVBAcTCEJyYWdhbmNhMQ8wDQYDVQQKEwZnc3IucHQxDzANBgNVBAsTBmdzci5w
   dDEPMA0GA1UEAxMGZ3NyLnB0MRwwGgYJKoZIhvcNAQkBFg1zZXJnaW9AZ3NyLnB0
   ggEAMA0GCSqGSIb3DQEBBAUAA4IBAQAFSbEReZe5DiPBH2XBjVENtAa4OaF0b+HO
   W0VWt2wJ8XzsJGIDjor2bEqIINkzlf4iKpK1yz9ul3RFSmgmgGLTSxfPQZboR0F3
   JmczjnLzhxChwSGJHFUmq9TGJqCa9+/mTmInR58WD6INRa7RggouwK7TBefyOqKf
   hK/ZTyHC+KMT2ytiU0t/A4nv7K99bAQF+JvIZ0wQHQkVOmvSBoOIaebr8/4Diuum
   SIv48H6rBTEkFYbQaYTz7NqXWHQ2P0e6GouaYfWdFtxuHCD1ZfchjTlMKV1O77Df
   B9PjlSSUZ3jVV78mFGBERcJ0agDW99OkUvtpHKc4c3s1Tf4CQ4Jl
   -----END CERTIFICATE-----
   Signed certificate is in newcert.pem
   

   Esto crea el archivo newcert.pem (el certificado del servidor firmado por la entidad certificadora) con la clave privada, newreq.pem.

   Para verificar que el certificado está correctamente firmado se puede utilizar el siguiente comando: Ejemplo 4-7. Verificación de la firma creada en un certificado por una CA $ /usr/bin/openssl verify -CAfile demoCA/cacert.pem newcert.pem newcert.pem: OK

5. Ahora se puede renombrar y mover los certificados al sitio deseado. En este caso se moverá al directorio /etc/ldap/ssl, quedando la estructura final como sigue:

   Ejemplo 4-8. Estructura de directorios final para los certificados

   # /usr/bin/tree /etc/ldap/ssl
   /etc/ldap/ssl
   |-- cacert.pem
   |-- certs
   |   `-- servidorcert.pem 
   |-- crl
   |-- index.txt
   |-- newcerts
   |   `-- 01.pem
   |-- private
   |   |-- cakey.pem
   |   `-- servidorkey.pem 
   `-- serial
   
   4 directories, 7 files

   

   Este archivo se corresponde con el archivo newcert.pem generado tras el Ejemplo 4-6

   

   Este archivo se corresponde con el archivo newreq.pem generado tras el Ejemplo 4-6

   Sería recomendable hacer la llave privada del servidor sólo legible por el usuario con el que se ejecuta slapd, para ello teclee: # /bin/chmod -v 400 /etc/ldap/ssl/private/servidorkey.pem el modo de `/etc/ldap/ssl/private/servidorkey.pem' cambia a 0400 (r--------) Los demás certificados tendría que poderse leer por todo el mundo.

6. Hacer que el certificado de la entidad certificadora esté disponible para los clientes de LDAP.

   Si los clientes están en la misma máquina, se ha de copiar el archivo cacert.pem a un lugar accesible por los clientes. Si los clientes están en otros equipos, se ha de copiar el archivo cacert.pem a esas máquinas y hacerlo accesible.

Como se ha podido apreciar, este proceso requieres algunos pasos más que la creación un certificado autofirmado, pero los beneficios obtenidos sobrepasan cualquier gasto de tiempo empleado en crear la entidad certificadora.

4.2.3. El certificado de los clientes

Los certificados para los clientes se crean de forma similar a los certificados para el servidor. Si se siguen los pasos detallados en Sección 4.2.2, los únicos cambios son los siguientes:

Ahora que ya están creados los certificados, sólo queda configurar OpenLDAP.

4.3.1. Servidor

Se ha de añadir las siguientes líneas al archivo de configuración de slapd, slapd.conf.

# Certificado firmado de una entidad certificadora y
# el certificado del servidor

TLSCipherSuite HIGH:MEDIUM:+SSLv2 
TLSCACertificateFile /etc/ldap/ssl/cacert.pem 
TLSCertificateFile /etc/ldap/ssl/certs/servidorcert.pem 
TLSCertificateKeyFile /etc/ldap/ssl/private/servidorkey.pem

# Si desea que el cliente necesite autentificación,
# descomente la siguiente línea
TLSVerifyClient demand
# ... si no, descomente esta otra
# TLSVerifyClient never

4.3.2. Cliente

El archivo de configuración /etc/ldap/ldap.conf configura las opciones por defecto para los clientes LDAP.

Si se necesitan valores específicos para los usuarios, se puede crear el archivo ldaprc o .ldaprc en el home del usuario o en el directorio actual, lo que sobreescribirá la configuración global de LDAP.

Si se requiere la autentificación de los clientes, se necesita añadir el certificado y la llave privada del cliente al archivo ldaprc o .ldaprc.

---

4.3.2.2. Ejemplo de un archivo ldap.conf

A continuación se muestra un ejemplo de configuración de un archivo ldap.conf:

En el Apéndice Q se encuentra un ejemplo de configuración más extenso de este archivo.

Ejemplo 4-10. Ejemplo de configuración de un archivo ldap.conf

# 
# Configuración global de LDAP
# 
 
# Lea ldap.conf(5) para más detalles
# Este archivo se ha de poder leer por todo el mundo, pero no escribir. 
HOST miservidor.pt 
PORT 636 
 
TLS_CACERT /etc/ldap/ssl/certs/cacert.pem 
TLS_REQCERT demand

Esta configuración hará que los clientes se conecten a ldaps://miservidor.pt:636 sin necesidad de especificar el host ni el puerto en los comandos del cliente.

# 
# Configuraciones de usuario específicas para LDAP
# 
 
# Sobreescribe la directiva global (si se ha establecido) 
TLS_REQCERT demand 
 
# Autentificación del cliente
TLS_CERT /home/ldap-user/ssl/certs/client.cert.pem 
TLS_KEY /home/ldap-user/ssl/certs/keys/client.key.pem

4.3.3. Schema

En el archivo slapd.conf, los esquemas (schema) aparecen cerca de la parte superior del archivo. A continuación se muestra un ejemplo de algunos de los esquemas que se pueden establecer.

En el directorio /etc/ldap/schema se encuentran varias definiciones de esquemas para LDAP.

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/misc.schema
include         /etc/ldap/schema/openldap.schema
include         /etc/ldap/schema/inetorgperson.schema

4.3.4. Resumen de configuración

Existen varios grados de configuración SSL que se pueden establecer. La Tabla 4-2 resume las directivas y los valores que estas han de tomar para realizar desde una configuración básica ("Básica") a una muy estricta ("La mejor") en el servidor en cuanto a conexiones SSL se refiere.

LEYENDA:

-: no se usa

x: se usa y se ha de asignar un nombre de archivo o un directorio

Note: El valor por defecto de TLSVerifyClient es "never" y el valor por defecto de TLS_REQCERT es "demand"

5.2.1. Instalación de pam_ldap

pam_ldap permite hacer uso de un servidor LDAP para la autentificación de usuarios (comprobación de claves) a aquellas aplicaciones que utilicen PAM.

En Debian GNU/Linux el paquete libpam-ldap provee esta funcionalidad, por lo que será instalado en la máquina, como muestra el Ejemplo 5-2

Antes de proceder con su instalación, eche un vistazo a la descripción del paquete:

$ /usr/bin/apt-cache show libpam-ldap
Package: libpam-ldap
Priority: extra
Section: admin
Installed-Size: 284
Maintainer: Stephen Frost <sfrost@debian.org>
Architecture: i386
Version: 164-2 
Depends: libc6 (>= 2.3.2-1), libldap2 (>= 2.1.17-1), libpam0g (>= 0.76), debconf (>= 0.5)
Suggests: libnss-ldap
Filename: pool/main/libp/libpam-ldap/libpam-ldap_164-2_i386.deb
Size: 49744
MD5sum: 386b9b94a707b491d4414f2c28eea660
Description: Pluggable Authentication Module allowing LDAP interfaces
 This module let's you use you LDAP server to authenticate users with
 programs that utilize PAM. If used along with libnss-ldap, you can
 replace your entire flat file (/etc/*) structure or NIS with LDAP.

# /usr/bin/apt-get install libpam-ldap
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Paquetes sugeridos:
  libnss-ldap
Se instalarán los siguientes paquetes NUEVOS:
  libpam-ldap
0 actualizados, 1 se instalarán, 0 para eliminar y 1 no actualizados.
Se necesita descargar 0B/49,7kB de archivos.
Se utilizarán 291kB de espacio de disco adicional después de desempaquetar.
Preconfiguring packages ...
Seleccionando el paquete libpam-ldap previamente no seleccionado.
(Leyendo la base de datos ...
252791 ficheros y directorios instalados actualmente.)
Desempaquetando libpam-ldap (de .../libpam-ldap_164-2_i386.deb) ...
Configurando libpam-ldap (164-2) ...

localepurge: checking system for new locale ...
localepurge: processing locale files ...
localepurge: processing man pages ...

Antes de continuar se van a configurar algunos aspectos del paquete libpam-ldap. Para ello es necesario ejecutar el siguiente comando:

# /usr/sbin/dpkg-reconfigure --priority=low libpam-ldap

La configuración del módulo pam_ldap.so se almacena en el archivo /etc/pam_ldap.conf, cuyo contenido se encuentra en el Apéndice T.

El archivo /etc/pam_ldap.conf se ha de poder leer por todos los usuarios del sistema, para asegurarse de que es legible por todo el mundo, puede ejecutar: /bin/chmod 644 /etc/pam_ldap.conf.

En estos momentos el sistema ya está listo para la configuración de los distintos servicios que utilizan PAM, de forma que estos utilicen LDAP para la comprobación de la clave. Cada servicio que hace uso de PAM para la autentificación, posee su propio archivo bajo el directorio /etc/pam.d/. Para que dicho servicio utilice LDAP en la comprobación de claves, se ha de modificar su archivo de configuración. Esto se verá en la Sección 5.3.2.

5.2.2. Instalación de nss-ldap

nss-ldap permite a un servidor LDAP actuar como un servidor de nombres. Esto significa que provee la información de las cuentas de usuario, los IDs de los grupos, la información de la máquina, los alias, los grupos de red y básicamente cualquier cosa que normalmente se obtiene desde los archivos almacenados bajo /etc o desde un servidor NIS.

En Debian GNU/Linux el paquete libnss-ldap provee esta funcionalidad, por lo que será instalado en la máquina, como muestra el Ejemplo 5-5

Antes de proceder a su instalación, eche un vistazo a la descripción del paquete:

$ /usr/bin/apt-cache show libnss-ldap
Package: libnss-ldap
Priority: extra
Section: net
Installed-Size: 208
Maintainer: Stephen Frost <sfrost@debian.org>
Architecture: i386
Version: 211-4 
Depends: libc6 (>= 2.3.2-1), libdb4.1, libldap2 (>= 2.1.17-1), debconf
Recommends: nscd, libpam-ldap
Filename: pool/main/libn/libnss-ldap/libnss-ldap_211-4_i386.deb
Size: 68052
MD5sum: c7fbc3504f8429655742e6a8cc7ec54c
Description: NSS module for using LDAP as a naming service
 This package provides a Name Service Switch that allows your LDAP server
 act as a name service. This means providing user account information,
 group id's, host information, aliases, netgroups, and basically anything
 else that you would normally get from /etc flat files or NIS.
 .
 If used with glibc 2.1's nscd (Name Service Cache Daemon) it will help
 reduce your network traffic and speed up lookups for entries.

# /usr/bin/apt-get install libnss-ldap
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Paquetes recomendados
  nscd
Se instalarán los siguientes paquetes NUEVOS:
  libnss-ldap
0 actualizados, 1 se instalarán, 0 para eliminar y 1 no actualizados.
Se necesita descargar 0B/68,1kB de archivos.
Se utilizarán 213kB de espacio de disco adicional después de desempaquetar.
Preconfiguring packages ...

Seleccionando el paquete libnss-ldap previamente no seleccionado.
(Leyendo la base de datos ...
252836 ficheros y directorios instalados actualmente.)
Desempaquetando libnss-ldap (de .../libnss-ldap_211-4_i386.deb) ...
Configurando libnss-ldap (211-4) ...

localepurge: checking system for new locale ...
localepurge: processing locale files ...
localepurge: processing man pages ...

La configuración de nss-ldap se almacena en el archivo /etc/libnss-ldap.conf, cuyo contenido se encuentra en el Apéndice U.

El archivo /etc/libnss-ldap.conf se ha de poder leer por todos los usuarios del sistema, para asegurarse de que es legible por todo el mundo, puede ejecutar: /bin/chmod 644 /etc/libnss-ldap.conf.

5.3.1. /etc/nsswitch.conf

nsswitch.conf es el fichero de configuración de las Bases de Datos del Sistema y del sistema de Conmutación de los Servicios de Nombres (Name Service Switch).

En otras palabras, es un archivo que indica el orden y el procedimiento a seguir para la búsqueda de la información requerida, por ejemplo, para hacer búsquedas de hosts o usuarios.

La forma de configurar este archivo es muy simple: primero se especifica la base de datos sujeta a la búsqueda (primera columna) seguida del procedimiento que se va a emplear para realizar una búsqueda sobre la misma (columnas siguientes).

De esta forma, basta con configurar el procedimiento de búsqueda para que haga uso de LDAP en algún momento. El Ejemplo 5-7 muestra como hacerlo:

passwd:          files ldap 
group:           files ldap 
shadow:          files ldap 
hosts:           files ldap dns 

En el Apéndice S se encuentra disponible un ejemplo completo de configuración de nsswitch.conf.

Fíjese que no se ha eliminado el uso de los ficheros locales, "files", ya que algunos usuarios y grupos de usuarios (como por ejemplo root) permanecerán de forma local. Si su sistema no utiliza la entrada "files", y el servidor LDAP se cae, nadie, ni siquiera root, podrá entrar al sistema.

nss-ldap espera que las cuentas sean objetos con los siguientes atributos: uid, uidNumber, gidNumber, homeDirectory y loginShell. Estos atributos están permitidos por la clase objeto (objectClass) posixAccount.

Una vez realizada la configuración, se puede comprobar que todo funciona bien con el comando getent seguido de la base de datos de búsqueda deseada (por ejemplo: /usr/bin/getent hosts). Como resultado se mostrará la base de datos consultada por pantalla.

5.3.2. Configuración de PAM

PAM permite configurar el método de autentificación que van a utilizar las aplicaciones que hagan uso de él. Gracias a esto, se pueden añadir fácilmente distintas opciones de autentificación, como el uso de una base de datos LDAP.

En las siguientes secciones se mostrarán los archivos que se han de modificar para lograr la autentificación a través de LDAP.

Hace relativamente poco tiempo que la versión en desarrollo de Debian (Sid) ha cambiado la forma de configuración de PAM. Actualmente posee secciones comunes a todos los archivos, estas secciones comunes son aquellos archivos localizados en el directorio /etc/pam.d/ que comiencen por "common-". Se ha de tener en cuenta la forma en la que se ha ido actualizando Debian Sid en la última temporada, para determinar si su sistema está utilizando o no dichos archivos comunes para la configuración de PAM. Un buen punto de partida, sería ojear los archivos almacenados bajo /etc/pam.d/ y comprobar las diferencias entre los archivos con extensión .dpkg-dist y los que no la tienen.

pam-ldap asume que las cuentas del sistema son objetos con los siguientes atributos: uid y userPassword. Los atributos están permitidos por la clase objeto (objectClass) posixAccount.

---

5.3.2.1. /etc/pam.d/common-account

Este archivo ha de tener únicamente estas entradas:

Ejemplo 5-8. Opciones de configuración para /etc/pam.d/common-account

account required          pam_unix.so
account sufficient        pam_ldap.so

En el Apéndice V tiene un ejemplo completo de este archivo de configuración.

---

5.3.2.2. /etc/pam.d/common-auth

Este archivo ha de tener únicamente estas entradas:

Ejemplo 5-9. Opciones de configuración para /etc/pam.d/common-auth

auth     sufficient     pam_unix.so
auth     sufficient     pam_ldap.so try_first_pass
auth     required       pam_env.so
auth     required       pam_securetty.so
auth     required       pam_unix_auth.so
auth     required       pam_warn.so
auth     required       pam_deny.so

En el Apéndice W tiene un ejemplo completo de este archivo de configuración.

---

5.3.2.3. /etc/pam.d/common-session

Este archivo ha de tener únicamente estas entradas:

Ejemplo 5-10. Opciones de configuración para /etc/pam.d/common-session

session required        pam_limits.so
session required        pam_unix.so
session optional        pam_ldap.so

Si desea que el sistema sea capaz de crear directorios home "al vuelo" (piense en el siguiente caso: acaba de añadir un usuario en la base de datos LDAP, pero no ha creado un directorio home para este usuario en el sistema), puede utilizar el módulo pam_mkhomedir para este propósito. Para ello añada la siguiente línea al principio del archivo common-session:

Ejemplo 5-11. Opción para crear directorios home al vuelo

session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022

El módulo pam_mkhomedir sólo crea directorios de un nivel. Es importante tener esto en cuenta para planificar la estructura del home de los usuarios.

En el Apéndice Y tiene un ejemplo completo de este archivo de configuración.

---

5.3.2.4. /etc/pam.d/common-passwd

Este archivo ha de tener únicamente estas entradas:

Ejemplo 5-12. Opciones de configuración para /etc/pam.d/common-password

password required       pam_cracklib.so  retry=3 minlen=8 difok=4
password sufficient     pam_unix.so use_authtok md5 shadow
password sufficient     pam_ldap.so use_authtok
password required       pam_warn.so
password required       pam_deny.so

Se supone que tiene instalado en su sistema la librería libpam-cracklib, si no es así, instálela o comente esta línea.

En el Apéndice X tiene un ejemplo completo de este archivo de configuración.

---

5.3.2.5. Comprobando que todo funciona

Ahora que ya está el sistema preparado para hacer uso de LDAP en la autentificación de los usuarios, sería recomendable hacer algunas pruebas con la nueva configuración para ver si todo funciona correctamente.

El comando pamtest puede ayudar a realizar estas pruebas. pamtest acepta dos parámetros: el primero es el nombre del servicio al cual se va a conectar para realizar la autentificación, el segundo es el nombre del usuario que se va a autentificar sobre dicho servicio. Veamos unos ejemplos:

El comando pamtest se encuentra en el paquete libpam-dotfile, por lo que si no está disponible en su sistema, ha de ejecutar: # /usr/bin/apt-get install libpam-dotfile

Ejemplo 5-13. Comprobando la configuración del sistema con pamtest

$ /usr/bin/pamtest passwd sergio
Trying to authenticate <sergio> for service <passwd>.
Password:[Clave del usuario]
Authentication successful.
$ /usr/bin/pamtest ssh sergio
Trying to authenticate <sergio> for service <ssh>.
Password:[Clave fallida del usuario]
Failed to authenticate: Authentication service cannot retrieve authentication info.
$ /usr/bin/pamtest ssh sergio
Trying to authenticate <sergio> for service <ssh>.
Password:[Clave del usuario]
Authentication successful.

Una vez se ha llegado a este punto, el sistema ya está preparado para autentificar a los usuarios a través de LDAP. En el apartado dedicado a Samba (Parte II en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) veremos, entre otras cosas, como añadir usuarios a la base de datos LDAP.

6.3.1. Compartiendo un disco

Si todo está bien configurado, se debería ver el servidor Samba, toltec, a través del entorno de red de la máquina Windows denominada maya. De hecho, la Figura 6-2 muestra el entorno de red de la maya, incluyendo a toltec y a cada una de las máquinas que residen en el grupo de trabajo METRAN. Dese cuenta del icono "Entire Network" al principio de la lista. Como se mencionó anteriormente, pueden existir más grupos de trabajo sobre una red SBM al mismo tiempo. Si un usuario hace click sobre ese icono, verá la lista de todos los grupos de trabajo que actualmente existen en la red.

Se puede ver con más detalle los recursos compartidos por toltec haciendo doble click sobre su icono. Esta acción provoca un contacto con toltec, solicitándole la lista de sus recursos compartidos -la impresora y el disco- que proporciona. En este caso, existe una impresora denominada lp, un directorio personal denominado jay y el disco compartido llamado spirit en el servidor, como se muestra en la Figura 6-3. Tenga en cuenta que Windows muestra los hostnames con letras mayúsculas/minúsculas (Toltec). La distinción entre mayúsculas y minúsculas es irrelevantes en los nombres de las máquinas (hostname), por lo que puede ver toltec, Toltec y TOLTEC como resultado de algunos comandos o en distintas pantallas, pero todos se refieren al mismo sistema. Gracias a Samba, Windows 98 ve al servidor Unix como a un servidor SBM válido, y puede acceder al directorio spirit como si fuese un directorio más del sistema.

Una característica interesante de Windows es la capacidad de mapear una letra de unidad (como E:, F: o Z:) hacia un directorio compartido usando la opción "Conectar a Unidad de Red" (Map Network Drive) desde el explorador de Windows [12]. Una vez hecho esto, las aplicaciones podrán acceder a la carpeta compartida utilizando la letra de la unidad de disco asignada. Se pueden almacenar datos en ella, instalar y ejecutar programas desde ella e incluso protegerla con una contraseña para evitar accesos no deseados. La Figura 6-4 muestra un ejemplo de mapeado de un directorio compartido hacia una letra de una unidad.

Eche un vistazo a la línea que aparece al lado de la ruta (Path) en la figura Figura 6-4. Una forma equivalente de representar un directorio en una máquina de la red es utilizando dos barras invertidas (\\), seguidas del nombre de la máquina de red, otra barra invertida (\), y el directorio de red de la máquina, como se muestra en el Ejemplo 6-1:

\\maquina-de-red\directorio

Esto se conoce como notación UNC (Universal Naming Convention) en el mundo Windows. Por ejemplo, la caja de diálogo de la Figura 6-4 representa el directorio de red del servidor toltec como en el Ejemplo 6-2:

\\toltec\spirit

Si esto le resulta familiar, probablemente esté pensando en uniform resource locator (URL), que es la notación que utilizan los navegadores web como Mozilla o Konqueror para acceder a las máquinas a través de Internet. Asegúrese de no confundir ambas notaciones, las URLs utilizan barras inclinadas hacia la derecha en vez de barras invertidas, y están precedidas por el nombre del protocolo de transferencia de datos (por ejemplo: ftp, http) y dos puntos (:). En realidad, URL y UNC son dos cosas completamente distintas, aunque algunas veces se pueda especificar un recurso SBM haciendo uso de la notación URL en vez de la notación UNC. Para especificar la siguiente dirección, \\toltec\spirit, en notación URL, se ha de escribir: smb://toltec/spirit.

Una vez que la unidad de red está configurada, Windows y sus programas la verán como una unidad de disco más. Si tiene alguna aplicación multiusuario, puede instalarla sobre una unidad de red[13]. La Figura 6-5 muestra la unidad de red resultante, como si fuese una unidad más en el cliente Windows 98. Advierta la tubería de enlace en el icono de la unidad "J:"; esto indica que es una unidad de red, en lugar de una unidad física.

Dependiendo del sistema operativo Widows que utilice (Windows Me, Windows 2000 o Windows XP), el entorno de red funcionará de una forma distinta. Es necesario pulsar sobre algunos iconos más, pero se puede ver el servidor toltec como se muestra en la Figura 6-6. Esta captura está realizada desde un sistema Windows 2000. Haciendo uso de la opción "Conectar a unidad de red" (Map Network Drive), obtendríamos el mismo resultado en otras versiones de Windows.

6.3.2. Compartiendo una impresora

Probablemente se haya fijado en la impresora lp que aparece en la lista de recursos de toltec en la Figura 6-3. Esto indica que el servidor Unix posee una impresora que puede ser compartida con los clientes SBM del grupo de trabajo. Los datos enviados a la impresora desde cualquier cliente será colocado en la cola de impresión del servidor Unix, para seguidamente ser impresos en el orden de llegada.

Configurar una impresora para que sea accesible a través de Samba a los clientes Windows es, si cabe más sencillo que configurar una unidad de disco. Haciendo doble click sobre la impresora e identificando el fabricante y modelo de la misma, puede instalar el controlador para esa impresora en el cliente Windows. Desde ese momento, Windows podrá formatear cualquier información enviada a la impresora de red y acceder a ella como si fuese una impresora local. En Windows 98, al hacer doble click sobre el icono de impresoras que aparece en el Panel de Control, abre la ventana de impresoras que se muestra en la Figura 6-7. Una vez más, note la tubería colocada bajo la impresora, lo que indica que se trata de una impresora en red.

6.3.3. Viendo las cosas desde Unix

Como se mencionó anteriormente, Samba no es más que un conjunto de demonios. Puede verlos haciendo uso del comando ps; puede ver cualquier mensaje que generen a través de archivos de depuración personalizados o a través del syslog (dependiendo de como se haya configurado Samba); y puede configurarlos desde un único archivo de configuración: smb.conf. A parte de esto, si quiere saber que están haciendo los demonios en un determinado momento, Samba posee un programa denominado smbstatus que muestra la información requerida. El Ejemplo 6-3 muestra su salida:

# /usr/bin/smbstatus
Processing section "[homes]"
Processing section "[printers]"
Processing section "[spirit]"

Samba version 2.2.6
Service     uid    gid    pid     machine
-----------------------------------------
spirit      jay    jay    7735    maya     (172.16.1.6) Sun Aug 12 12:17:14 2002
spirit      jay    jay    7779    aztec    (172.16.1.2) Sun Aug 12 12:49:11 2002
jay         jay    jay    7735    maya     (172.16.1.6) Sun Aug 12 12:56:19 2002

Locked files:
Pid    DenyMode   R/W        Oplock     Name
--------------------------------------------------
7735   DENY_WRITE RDONLY     NONE       /u/RegClean.exe   Sun Aug 12 13:01:22 2002

Share mode memory usage (bytes):
   1048368(99%) free + 136(0%) used + 72(0%) overhead = 1048576(100%) total

El informe de estado de Samba proporciona tres grupos de datos, cada uno de ellos dividido en secciones separadas. La primera sección identifica los sistemas que han conectado con el servidor Samba, identificando a cada cliente por su nombre de máquina (maza y aztec) y su dirección IP. La segunda sección informa del nombre y estado de los ficheros compartidos por el servidor que están actualmente en uso, incluyendo el estado de lectura/escritura o cualquier bloqueo que estos posean. Finalmente, Samba informa sobre la memoria en uso por los recursos que administra, incluyendo la cantidad de memoria que se está utilizando por los recursos compartidos más el gasto fijo de memoria. (Tenga en cuenta que esta no es la misma cantidad de memoria que el total de memoria utilizada por los procesos smbd y nmbd.)

6.4.1. Comprendiendo NetBIOS

Para comenzar, echemos la vista atrás. En 1984, IBM diseñó una API (Application Programming Interface) simple para conectar en red sus ordenadores, llamada Network Basic Input/Output System (NetBIOS). La API NetBIOS proporcionaba un diseño rudimentario para que una aplicación se conectase y compartiese datos con otros ordenadores.

Es útil pensar en la API NetBIOS como una extensión de red para las llamadas de la API BIOS estándar. La BIOS contiene código de bajo nivel para realizar operaciones en el sistema de archivos de un ordenador local. Originalmente, NetBIOS tenía que intercambiar instrucciones con los ordenadores a través de redes IBM PC o Token Ring. Esto exigió un protocolo de transporte de bajo nivel para transportar las peticiones de un ordenador al siguiente.

A finales de 1985, IBM liberó dicho protocolo, combinándolo con la API NetBIOS para convertirse en NetBIOS Extended User Interface (NetBEUI). NetBEUI fue diseñado para pequeñas redes de área local (LANs), permitiendo a cada ordenador usar un nombre (de hasta 15 caracteres) que no estuviese siendo utilizado en la red. Se entiende por una "LAN pequeña", una red de menos de 255 nodos -¡Esto se consideraba un número generoso en 1985!-.

El protocolo NetBEUI se volvió muy popular en las aplicaciones de red, incluyendo aquellas que corrían bajo Windows for Workgroups. Más tarde, aparecieron implementaciones de NetBIOS sobre los protocolos IPX de Novell, los cuales competían con NetBEUI. Sin embargo, los protocolos de red escogidos por la floreciente comunidad de Internet fueron TCP/IP y UDP/IP, así como las implementaciones de las APIs NetBIOS sobre dichos protocolos, que pronto se convirtieron en una necesidad.

Recuerde que TCP/IP hace uso de números para representar las direcciones de los ordenadores (192.168.220.100, por ejemplo), mientras que NetBIOS usa sólo nombres. Este fue el mayor problema encontrado a la hora de juntar los dos protocolos. En 1987, el grupo IETF (Internet Engineering Task Force) publicó una serie de documentos de estandarización, titulados RFC 1001 y 1002, que perfilaban cómo NetBIOS podría trabajar sobre una red TCP/UDP. Este conjunto de documentos todavía lidera las implementaciones que existen hoy en día, incluyendo aquellas proporcionadas por Microsoft para sus sistemas operativos Windows, así como a la suite Samba.

Desde entonces, el estándar que estos documentos lideran se ha convertido en NetBIOS sobre TCP/IP, o NBT[14] para abreviar.

El estándar NBT (RFC 1001/1002) actualmente establece un trio de servicios sobre una red:

• Un Servicio de Nombres

• Dos Servicios de Comunicación:

  • Datagramas

  • Sesiones

El servicio de nombres resuelve el problema del paso de un nombre a una dirección anteriormente comentado; permite a cada ordenador proclamar un nombre específico en la red que puede se puede convertir en una dirección IP legible, como hacen hoy en día los DNS en Internet. Los servicios de datagramas y sesiones son protocolos secundarios de comunicación, usados para transmitir datos desde y hacia máquinas NetBIOS a través de la red.

Como se ha visto hasta este momento, SMB puede correr sobre múltiples protocolos. El siguiente diagrama muestra este hecho[15]:

6.4.2. Obteniendo un nombre

En el mundo NetBIOS, cuando cada ordenador se activa, quiere reclamar un nombre para sí; esto se denomina registro de nombre. Sin embargo, dos máquinas en el mismo grupo de trabajo no podrían solicitar el mismo nombre; ya que esto confundiría a una máquina que quisiese comunicarse con cualquiera de esas dos. Existen dos métodos diferentes para asegurarse de que esto no ocurrirá:

• Hacer uso de NBNS para controlar el registro de nombres NetBIOS por parte de las máquinas

• Permitir la defensa de su nombre a cada máquina de la red, en el caso de que otra máquina intente usarlo

La Figura 6-9 ilustra un registro de nombre (fallido), con y sin NBNS.

Como se mencionó anteriormente, debería existir alguna forma de resolver nombres NetBIOS a la dirección IP correspondiente; a esto se le conoce como resolución de nombres. Existen dos estrategias diferentes con NBT aquí también:

• Que cada ordenador comunique su dirección IP cuando "escuche" una petición broadcast para su nombre NetBIOS

• Usar el NBNS para ayudar a resolver los nombres NetBIOS a direcciones IP

La Figura 6-10 ilustra los dos tipos de resolución de nombres.

Como se podría esperar, tener un NBNS en su red puede ayudar enormemente. Para ver exactamente por qué, eche un vistazo al método broadcast.

Aquí, cuando un cliente arranca, envía un mensaje broadcast manifestando su deseo de registrar un nombre NetBIOS específico para el. Si nadie pone objeción al uso del nombre, el obtiene el nombre. Por otro lado, si otra máquina en la subred local está actualmente usando ese nombre, enviará un mensaje de respuesta al cliente solicitante indicando que ese nombre ya está siendo usado. Esto es conocido como defender el nombre del host. Este tipo de sistema es útil cuando un cliente se ha caído inesperadamente de la red -otro puede tomar su nombre-, pero se incurre en un importante aumento del tráfico de la red para algo tan simple como el registro de un nombre.

Con un NBNS, ocurre lo mismo, pero con la diferencia de que la comunicación está confinada a la máquina solicitante y al servidor de nombres NBNS. No se produce un broadcast cuando una máquina desea registrar su nombre; el mensaje de registro es simplemente enviado desde el cliente hacia el servidor NBNS, y el servidor NBNS responde si el nombre está o no libre. A esto se le denomina como comunicación punto-a-punto, y es beneficioso en redes con más de una subred. Esto se debe a que los routers suelen estar preconfigurados para bloquear los paquetes broadcast entrantes.

Los mismos principios se aplican a la resolución de nombres. Sin un servidor NBNS, la resolución de nombres NetBIOS se podría realizar mediante broadcast. Todos los paquetes se enviarían a cada ordenador de la red, con la esperanza de que el ordenador afectado por la petición responda directamente a la máquina solicitante. El uso de un servidor NBNS y la comunicación punto-a-punto para este propósito carga mucho menos la red que inundar la red con peticiones broadcast para cada petición de resolución de nombres que se produzca.

Se puede discutir que los paquetes broadcast no causan problemas significativos en las redes modernas y de gran ancho de banda compuestas por máquinas con CPUs muy rápidas, si sólo un grupo reducido de ordenadores están presentes en la red, o la demanda de ancho de banda es pequeña. Hay muchos casos en los que la anterior suposición es cierta; sin embargo, se aconseja no confiar en el broadcast tanto como se pueda. Esta es una regla a seguir en redes grandes y saturadas, y si se sigue este consejo a la hora de configurar redes pequeñas, estas podrán crecer sin problemas en el futuro.

6.4.3. Tipos de nodos

¿Cómo informo a los clientes sobre la estrategia a seguir para realizar el registro y la resolución de nombres? Cada máquina en una red NBT gana una de las siguientes designaciones, dependiendo de cómo se maneje el registro y la resolución de nombres: b-node, p-node, m-node y h-node. El comportamiento de cada tipo de nodo se resumen en la Tabla 6-1.

Los clientes Windows suelen encontrarse como h-nodes o nodos híbridos. Los tres primeros tipos de nodos aparecen el los RFCs 1001/1002, y los h-nodes fueron inventados más tarde por Microsoft, como un método más tolerable a fallos.

Puede encontrar el tipo de nodo de un ordenador Windows 95/98/Me ejecutando el comando winipcfg y pulsando sobre el botón de Más información. En Windows NT/2000/XP, puede hacer uso del comando ipconfig /all en el prompt de una ventana de comandos. En cualquier caso, busque la línea que diga Node Type.

6.4.4. ¿Qué hay en un nombre?

Los nombres utilizados en NetBIOS son ligeramente diferentes de los nombres empleados en los DNS, con los que estará familiarizado. En primer lugar, los nombres NetBIOS existen en un espacio de nombres único. En otras palabras, no existen niveles jerárquicos como en samba.org (dos niveles) o en ftp.samba.org (tres niveles). Los nombres NetBIOS están formados por una única cadena como toltec o maya, cada uno de ellos pertenecientes a un grupo de trabajo o un dominio. En segundo lugar, los nombres NetBIOS sólo pueden contener 15 caracteres y están compuestos únicamente por los caracteres alfanuméricos estándar (a-z, A-Z, 0-9) y los siguientes:

!  @  #  $  %  ^  &  (  )  -  '  {  }  .  ~

Aunque se puede hacer uso del punto (.) en un nombre NetBIOS, no es recomendable, debido a que esos nombres puede que no funcionen en futuras versiones de NBT.

No es una coincidencia que todos los nombres DNS válidos también sean válidos en NetBIOS. De hecho, el nombre DNS para un servidor Samba es frecuentemente usado como su nombre NetBIOS. Por ejemplo, si tiene un sistema con el siguiente nombre: toltec.ora.com, su nombre NetBIOS podría ser TOLTEC (seguido de 9 espacios en blanco).

TOLTEC<00>

D:\> nbtstat -a toltec
       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
TOLTEC          <00>  UNIQUE      Registered
TOLTEC          <03>  UNIQUE      Registered
TOLTEC          <20>  UNIQUE      Registered
...

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
METRAN         <00>   GROUP       Registered
METRAN         <1E>   GROUP       Registered
..__MSBROWSE__.<01>   GROUP       Registered

6.4.5. Scope ID

En los años oscuros del funcionamiento en red de SMB, antes de la introducción de los grupos NetBIOS, se debía utilizar una estrategia muy primitiva para aislar grupos de ordenadores del resto de la red. Cada paquete SMB contenía un campo denominado scope ID, la idea era que los sistemas de la red se pudiesen configurar de forma que sólo aceptasen los paquetes con el scope ID que coincidiese con su configuración. Esta característica fue apenas utilizada y desgraciadamente aun pervive en las implementaciones modernas. Algunas de las utilidades incluidas en la distribución de Samba permite establecer el scope ID. El establecimiento del scope ID en una red es sinónimo de problemas, sólo se ha mencionado para evitar confusiones cuando aparezca el término más adelante.

6.4.6. Datagramas y sesiones

En este punto, se hará un paréntesis para abordar la responsabilidad de NBT: proporcionar servicios de conexión entre dos máquinas NetBIOS. NBT ofrece dos servicios: el servicio de sesión y el servicio de datagramas. Comprender cómo funcionan estos servicios no es vital para usar Samba, pero le dará una idea sobre cómo trabaja NBT y cómo arreglar problemas cuando Samba no funcione.

El servicio de datagramas no proporciona una conexión estable entre ordenadores. Los paquetes de datos se envían o difunden (broadcast) de una máquina a otra, sin tener en cuenta el orden en que estos llegan al destino, o incluso si han llegado todos. El uso de datagramas requiere menos procesamiento que las sesiones, aunque la confiabilidad de la conexión puede sufrir. Los datagramas, por tanto, son empleados para enviar rápidamente bloques no vitales de datos a una o más máquinas. El servicio de datagramas se comunica usando las primitivas que se muestran en la Tabla 6-4.

El servicio de sesiones es más complejo. Las sesiones son un método de comunicación que, en teoría, ofrece la capacidad de detectar conexiones problemáticas o inoperativas entre dos aplicaciones NetBIOS. Esto lleva a pensar en una sesión NBT en términos de una llamada telefónica, analogía que obviamente influyó en el diseño del estándar CIFS.

Una vez que se establece la conexión, permanece abierta durante toda la conversación, cada lado conoce quien es el ordenador emisor y receptor, y cada uno se puede comunicar haciendo uso de las primitivas mostradas en la Tabla 6-5.

Las sesiones son el backbone de la compartición de recursos en una red NBT. Se utilizan normalmente para establecer conexiones estables desde los clientes a unidades de disco o impresoras compartidas en un servidor. El cliente "llama" al servidor y comienza a negociar la información, como los archivos que desea abrir, los datos que desea intercambiar, etc. Estas llamadas pueden durar mucho tiempo -horas, incluso días- y todo esto ocurre dentro del contexto de una única conexión. Si se produce un error, el software de sesión (TCP) retransmitirá los datos hasta que se reciban correctamente, a diferencia del método "envía-y-reza" del servicio de datagramas (UDP).

En realidad, mientras que las sesiones se supone que están para manejar comunicaciones problemáticas, algunas veces no lo hacen. Si la conexión es interrumpida, la información de sesión que está abierta entre dos ordenadores puede volverse inválida. Si esto ocurre, la única forma de restablecer la sesión entre los dos ordenadores es llamar de nuevo y comenzar desde cero.

Si desea más información sobre estos servicios, eche un vistazo al RFC 1001. Sin embargo, hay dos cosas importantes a recordar aquí:

• Las sesiones siempre ocurren entre dos máquinas NetBIOS. Si una sesión se interrumpe, se supone que el cliente ha almacenado suficiente información de estado para restablecerla. Sin embargo, en la práctica, normalmente esto no ocurre.

• Los datagramas pueden ser difundidos (broadcast) hacia múltiples ordenadores, pero no son confiables. En otras palabras, no hay manera de que el emisor sepa si los datagramas que ha enviado han llegado correctamente a sus destinos.

6.5.1. Grupos de trabajo Windows

Los grupos de trabajo de Windows son muy similares a los grupos SMB ya descritos. Pero necesita saber algunas cosas adicionales.

6.5.2. Navegando

La navegación es el proceso de buscar otros ordenadores o recursos compartidos en la red Windows. Tenga en cuenta que no tiene ningún parecido con un navegador web, a parte de la idea general de "descubrir que hay". Por otro lado, navegar por la red de Windows es parecido a hacerlo por la web, en el sentido de que todo lo que existe pude cambiar sin previo aviso.

Antes de la existencia del navegador, los usuarios debían conocer el nombre del ordenador al que se querían conectar, luego tenían que teclear manualmente una dirección UNC en el gestor de archivos o la aplicación implicada para poder acceder al recurso. La dirección UNC era algo parecido a lo que se muestra en el Ejemplo 6-7:

\\toltec\spirit\

La navegación es mucho más conveniente, ya que permite examinar los contenidos de la red haciendo uso de una interfaz "apunta-y-pulsa" del entorno de red de los clientes Windows.

Encontrará dos tipos de navegación en una red SMB:

• Navegar por una lista de ordenadores y sus recursos compartidos

• Navegar por los recursos compartidos de un determinado ordenador

A continuación se profundizará un poco en el primer tipo. En cada LAN (o subred) con un grupo de trabajo o dominio Windows, un ordenador tiene la responsabilidad de mantener la lista de ordenadores que están en un momento dado accesibles a través de la red. Este ordenador se denomina buscador (browser) maestro local, y la lista que mantiene se denomina lista de búsqueda. Los ordenadores de una red utilizan la lista de búsqueda para minimizar el tráfico de datos necesario para realizar una búsqueda. En vez de que cada ordenador pregunte por la lista de ordenadores actualmente disponibles, estos pueden preguntar al buscador maestro local para obtener una lista completa y actualizada.

Para navegar por los recursos de un determinado ordenador, el usuario debe conectar a dicho ordenador; esta información no se puede obtener de la lista de búsqueda. La navegación por la lista de recursos compartidos de un ordenador se realiza haciendo doble click sobre el icono del ordenador que se presenta en el entorno de red. Como se veía al principio del capítulo, el ordenador responderá con una lista de los recursos que están accesibles una vez que el usuario se haya autentificado.

Cada servidor en un grupo de trabajo Windows necesita anunciar su presencia al brower maestro local, una vez que ha registrado su nombre NetBIOS, y (teóricamente) anuncia que va a dejar el grupo de trabajo cuando es desconectado. Es responsabilidad del buscador maestro local almacenar los servidores que se han anunciado.

El entorno de red de Windows puede comportarse de manera extraña: hasta que se selecciona un ordenador, el entorno de red de Windows puede contener información no actualizada. Esto significa que el entorno de red de Windows puede mostrar ordenadores que se han caído o no informar de aquellos ordenadores que todavía no se han anunciado. Resumiendo, una vez seleccionado un servidor y realizada la conexión con el, puede estar seguro de que los recursos compartidos así como las impresoras existen realmente en la red.

A parte de los roles vistos con anterioridad, casi cualquier sistema Windows (incluyendo Windows para grupos de trabajo y Windows 95/98/Me o Windows NT/2000/XP) puede actuar como un buscador maestro local. Un buscador maestro local puede tener uno o más buscadores de respaldo en la subred local, que tomarán el relevo al buscador maestro local en el caso de que este falle o se vuelva inaccesible. Para asegurar operaciones fluidas, los buscadores de respaldo actualizarán frecuentemente su lista con la del buscador maestro local.

A continuación se muestra como calcular el número mínimo de buscadores de respaldo que se pueden asignar en un grupo de trabajo:

• Si la red está formada por hasta 32 máquinas Windows NT/2000/XP, o hasta 16 máquinas Windows 95/98/Me, el buscador maestro local asigna un buscador de respaldo a mayores del buscador maestro local

• Si el número de máquinas Windows NT/2000/XP está comprendido entre 33 y 64, o el número de máquinas Windows 95/98/Me está comprendido entre 17 y 32, el buscador maestro local asigna dos buscadores de respaldo

• Para cada grupo de 32 máquinas Windows NT/2000/XP o 16 ordenadores Windows 95/98/Me además de esto, el buscador maestro local asigna otro buscador de respaldo

No existe límite en cuanto al número máximo de buscadores de respaldo que pueden ser asignados por un buscador maestro local.

6.5.3. Elecciones para la navegación

La navegación es un aspecto crítico en cualquier grupo de trabajo Windows. Sin embargo, no todo funciona correctamente en todas las redes. Sirva el siguiente ejemplo para ilustrar este hecho: imagínese un ordenador con Windows ubicado en el despacho de un CEO de una pequeña compañía actúa como buscador maestro local -esto quiere decir, que será un buscador maestro local hasta que el CEO lo desconecte para recibir su masaje-. En este momento, la máquina Windows NT ubicada en la sección de piezas de recambio de un departamento está dispuesta a tomar el control del trabajo. Sin embargo, dicho ordenador está ejecutando un programa extremadamente grande y mal escrito que está consumiendo los recursos del procesador. La moraleja: los navegadores han de ser muy tolerantes con las idas y venidas de los servidores. Debido a que casi cualquier sistema Windows puede servir como buscador, ha de haber alguna forma de decidir en cualquier momento quien toma el trabajo. El proceso de decisión se denomina elección.

Casi cualquier sistema Windows tiene un algoritmo de elección, de forma que los sistemas se puedan poner de acuerdo en quien será el buscador maestro local y quien el buscador de respaldo local. Una elección puede ser forzada en cualquier momento. Por ejemplo, imagine que el CEO ha finalizado su masaje y reinicia el servidor. Como el servidor vuelve a estar disponible, anuncia su presencia, y tendrá lugar una elección para ver si el PC ubicado en la sección de piezas de recambio todavía continua siendo el buscador maestro local.

Cuando se ejecuta una elección, cada ordenador difunde información sobre sí mismo haciendo uso de datagramas. Esta información incluye:

• La versión del protocolo de elección utilizado

• El sistema operativo del ordenador

• La cantidad de tiempo que el ordenador ha estado conectado a la red

• El hostname del cliente

Estos valores determinan que sistema operativo tiene la veteranía y pueda cumplir con el rol de buscador maestro local[20]. La estructura desarrollada para lograr esto no es elegante y tiene problemas de seguridad implícitos. Mientras que un dominio de búsqueda puede ser integrado con un dominio de seguridad, el algoritmo de elección no tiene en cuenta que ordenadores van a ser buscadores. Esto es posible para cualquier ordenador que ejecute un servicio de búsqueda y se haya registrado como participante en la elección del buscador, una vez ha ganado es capaz de cambiar la lista de búsqueda. No obstante, la navegación es una característica llave en el funcionamiento de la red de Windows, y las características de compatibilidad hacia atrás garantizarán que seguirá en uso durante los años venideros.

6.5.4. Autentificación de Windows 95/98/Me

Existen tres tipos de claves cuando un sistema Windows 95/98/Me está interactuando en un grupo de trabajo Windows:

• Una clave de Windows

• Una clave de red Windows

• Una clave para cada uno de los recursos compartidos a los que se le ha asignado protección con contraseña

Las claves de Windows funcionan de tal forma que son la fuente de confusión para los administradores de sistemas Unix. No hay manera de prevenir el uso de los ordenadores por parte de usuarios sin autorización. (Si no se lo cree, pulse sobre el botón Cancelar del cuadro de diálogo de autentificación y compruebe lo que ocurre). En lugar de eso, la clave de Windows se utiliza para poder acceder a los archivos y recursos compartidos disponibles en la red de Windows que están protegidos con clave. Existe un archivo por cada usuario registrado en el sistema, este se puede encontrar en el directorio C:\Windows y su nombre será el de la cuenta del usuario, seguido por la extensión .pwl. Por ejemplo, si la cuenta de usuario es sara, el archivo será C:\Windows\sara.pwl. Este archivo está encriptado con la clave de Windows como llave de encriptación.

Como medida de seguridad, debería comprobar la existencia de archivos .pwl en los clientes Windows 95/98/Me, ya que pueden haber sido creados debido a los intentos de acceso fallidos por parte de los usuarios. Un archivo .pwl se puede romper con facilidad y puede contener claves válidas de cuentas Samba o recursos compartidos.

La primera vez que se accede a la red, Windows intenta utilizar la clave de Windows como clave de red. Si hay éxito, no se le preguntará al usuario por una clave de acceso a la red, de esta forma, los siguientes ingresos en el sistema Windows ingresarán automáticamente a su vez en la red de Windows, haciendo las cosas más sencillas al usuario.

Los recursos compartidos en un grupo de trabajo pueden tener asignados a su vez claves que limitan el acceso a los mismos. La primera vez que un usuario intenta acceder a este tipo de recursos, se le solicitará una clave, pudiendo seleccionar una opción en el cuadro de diálogo de autentificación para añadir la clave a su lista de claves. Esta opción está marcada por defecto; si se acepta, Windows almacenará la clave en el fichero .pwl del usuario, siendo manejadas automáticamente por Windows ulteriores autentificaciones para dicho recurso.

La estrategia de Samba para la autentificación en los grupos de trabajo es un poco diferente, y ha sido el resultado de mezclar el modelo de grupos de trabajo de Windows con el modelo Unix, donde se ejecuta Samba[21].

6.5.5. Dominios de Windows NT

El modelo de red punto-a-punto de los grupos de trabajo Windows funciona bastante bien siempre y cuando el número de ordenadores de la red sea pequeño y haya una comunidad de usuarios muy restringida. Sin embargo, en grandes redes la simplicidad de los grupos de trabajo llega a ser un factor limitador. Los grupos de trabajo ofrecen sólo el nivel más básico de seguridad, y debido a que cada recurso compartido puede tener su propia clave, es un inconveniente (por decir lo mínimo) para los usuarios tener que recordar la clave de cada recurso en una red de gran envergadura. Incluso si esto no fuese un problema, mucha gente encuentra frustrante tener que interrumpir su proceso de trabajo para teclear la clave del recurso compartido en el cuadro de diálogo cada vez que se accede a otro recurso de red.

Para soportar las necesidades de las grandes redes, tales como las que se encuentran en los departamentos computacionales, Microsoft introdujo los dominios con la versión 3.51 de Windows NT. Un dominio Windows NT es en esencia un grupo de trabajo de un ordenador SMB que tiene una característica añadida: el servidor que actúa como controlador de dominio (vea la Figura 6-12).

S-1-5-21-1638239387-7675610646-9254035128-545

6.6.1. Soporte PDC para clientes Windows 2000/XP

Anteriormente, Samba podía actuar como un PDC para autentificar sistemas Windows 95/98/Me y Windows NT 4. Esta funcionalidad ha sido extendida en la versión 2.2 para incluir a los sistemas Windows 2000 y Windows XP. De esta manera es posible disponer de un servidor Samba con soporte de autentificación en el dominio para los clientes Windows de la red, incluyendo las versiones más recientes. El resultado es una red más estable, de alto rendimiento y mucho más segura, con el beneficio de no tener que comprar Windows CALs a Microsoft.

6.6.2. Soporte Dfs de Microsoft

Microsoft Dfs permite que los recursos compartidos por un número determinado de servidores dispersos a lo largo de la red se junten y aparezcan, a los ojos de los usuarios, como si todos ellos existiesen en un sólo árbol de directorios de un servidor. Este método de organización hace la vida más fácil a los usuarios. En lugar de tener que buscar por la red, como si se tratase de un tesoro oculto, para encontrar un determinado recurso, los usuarios pueden ir directamente al servidor Dfs y coger lo que necesiten. Samba 2.2 ofrece soporte para servir Dfs, por lo que no se necesita un servidor Windows para este propósito.

6.6.3. Soporte de impresión en Windows NT/2000/XP

Windows NT/2000/XP poseen una interface de impresión basada en RPC diferente a la interfaz que poseen los sistemas Windows 95/98/Me. En la versión 2.2 de Samba, la interfaz de Windows NT/2000/XP está soportada. Junto con esto, el equipo de desarrollo de Samba ha añadido soporte para bajarse automáticamente el controlador de impresión desde un servidor Samba mientras se añade una nueva impresora desde un cliente Windows.

6.6.4. ACLs

Samba ahora soporta ACLs en aquellos sistemas Unix que las tienen incorporadas. Esta lista incluye Solaris 2.6, 7 y 8, Irix, AIX, GNU/Linux (con cualquiera de los parches de soporte de ACLs para los sistemas de archivos ext2/ext3, disponible en http://acl.bestbits.at o cuando se hace uso del sistema de archivos XFS y FreeBSD (versión 5.0 y posterior). Cuando se hace uso del soporte de ACLs, Samba traduce entre las ACLs de Unix y las de Windows NT/2000/XP, haciendo al equipo que ejecuta samba parecer y actuar más parecido a un servidor Windows NT/2000/XP desde el punto de vista de los clientes Windows.

6.6.5. Soporte de las herramientas de administración de clientes Windows

Windows vienen con una herramienta que puede ser utilizada desde un cliente para administrar los recursos compartidos en un servidor Windows remotamente. Samba 2.2 permite a esas herramientas manejar los recursos compartidos en un servidor Samba también.

6.6.6. Integración con Winbind

Windbind es una ayuda que permite a los usuarios cuya información de autentificación está almacenada en una base de datos de dominio Windows, poder autentificarse en un sistema Unix. El resultado es un entorno unificado de autentificación, en el cual una cuenta de usuario se puede conservar entre un sistema Unix o un controlador de dominio Windows NT/2000/XP. Esto facilita enormemente la administración de cuentas, debido a que los administradores ya no necesitarán mantener los dos sistemas sincronizados, permitiendo a los usuarios cuyas cuentas estén asociadas a un dominio Windows, autentificarse cuando accedan a un recurso compartido por Samba.

6.6.7. Extensiones CIFS en Unix

Las extensiones CIFS de Unix fue desarrollado por Hewlett-Packard e introducido en la versión 2.2.4 de Samba. Estas permiten a los servidores Samba soportar los atributos de los sistemas de archivos Unix, como los enlaces y los permisos, cuando se comparten archivos con otros sistemas Unix. Esta característica permite utilizar Samba como una alternativa a NFS para la compartición de archivos entre sistemas Unix. La ventaja de utilizar Samba es que autentifica a usuarios individualmente, mientras que NFS autentifica solamente clientes (basándose en su dirección IP, que es un modelo muy pobre en cuanto a la seguridad). Esto da un empujón en el área de seguridad a Samba, a parte de su gran capacidad de configuración. Consulte el capítulo 5 de la entrada bibliográfica TsEcksteinCollier-Brown01 para ver como operar con los sistemas Unix como clientes Samba.

6.6.8. Y más...

Como ya viene siendo habitual, el código posee muchas mejoras que no se ven a un nivel administrativo de forma inmediata u obvia. Actualmente Samba funciona mejor en los sistemas que utilizan PAM, y existe un nuevo soporte para perfiles. El soporte de Samba para los oplocks ha sido reforzado, ofreciendo mejor integración con los servidores NFS (actualmente sólo en Irix y GNU/Linux) y en el sistema de archivos local, con los bloqueos SMB mapeados a bloqueos POSIX (que es dependiente la implementación de los bloqueos POSIX de cada variante Unix). Y por supuesto, también han tenido lugar las correcciones normales de bugs.

6.10.1. Página principal

El Proyecto Samba dispone de una página principal, http://www.samba.org/, desde donde puede obtener mucha información sobre el proyecto. De hecho, para elaborar esta sección ha utilizado la información allí disponible.

6.10.2. Cómo obtener Samba

Las distribuciones del código fuente y de los binarios de Samba están disponibles en muchos mirrors a lo largo de Internet. La página principal de Samba es http://www.samba.org/. Desde allí, se puede seleccionar un mirror que esté geográficamente cerca de usted.

Las distintas formas de distribución de Samba desde la página oficial se pueden ver en http://www.samba.org/download.html.

La mayoría de las distribuciones de GNU/Linux y muchos distribuidores de Unix disponen de paquetes binarios de Samba. Suele ser más conveniente hacer uso de esos paquetes antes que el código fuente o los binarios del equipo de desarrollo de Samba, ya que los distribuidores se esfuerzan en suministrar paquetes que se adapten a las especificaciones de sus productos.

6.10.3. Documentación

Desde la página principal del proyecto Samba se puede acceder a distintos enlaces con documentación sobre el proyecto. Hay dos grandes formas de obtener la documentación:

• en formato electrónico, para lo cual hay que acceder a: http://www.samba.org/docs/

• comprando alguno de los libros disponibles sobre el tema. Para obtener un listado de algunos de ellos, visite: http://www.samba.org/books.html

6.10.4. Información de soporte

La página dedicada al soporte y al contacto de Samba, informa sobre los distintos métodos existentes para obtener ayuda en un determinado momento. Los métodos más importantes para obtener ayuda son los siguientes:

6.10.5. Reporte de bugs

Samba dispone de un Sistema de seguimiento de tareas, desde donde se pueden reportar errores y bugs relacionados con Samba (tanto en lo relativo al software como a la documentación) y hacer peticiones de nuevas características.

Si se quiere reportar un error grave de seguridad, lo más conveniente es utilizar el correo: security%40samba.org.

Si lo que se quiere es remitir un parche o una mejora para Samba, se ha de enviar un correo a samba-technical@samba.org o bien visitar: http://samba.org/samba-patches/.

Más detalles de las formas de reportar errores y parches en el siguiente enlace: http://www.samba.org/bugreports.html.

6.10.6. Cómo contactar

Para obtener más información sobre Samba, puede contactar con el Proyecto en la siguiente dirección:

Samba Team
26 Carstensz st
Griffith, ACT
2603 Australia

7.2.1. Instalación de un servidor

El paquete principal del servidor Samba es "samba", a continuación se muestra la información relativa al mismo:

$ /usr/bin/apt-cache show samba
Package: samba
Priority: optional
Section: net
Installed-Size: 5912
Maintainer: Eloy A. Paris <peloy@debian.org>
Architecture: i386
Version: 3.0.4-5
Replaces: samba-common (<= 2.0.5a-2)
Depends: samba-common  (= 3.0.4-5), netbase, logrotate,
libacl1 (>= 2.2.11-1), libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3),
libcupsys2-gnutls10 (>= 1.1.20final-1), libkrb53 (>= 1.3.2),
libldap2 (>= 2.1.17-1), libpam0g (>= 0.76), libpopt0 (>= 1.7),
debconf (>= 0.5) | debconf-2.0, libpam-runtime (>= 0.76-13.1),
libpam-modules
Suggests: samba-doc  
Filename: pool/main/s/samba/samba_3.0.4-5_i386.deb
Size: 2360466
MD5sum: 47bd4f3c91c0c4542c9a1cdb61416516
Description: a LanManager-like file and printer server for Unix
 The Samba software suite is a collection of programs that
 implements the SMB protocol for unix systems, allowing you to serve
 files and printers to Windows, NT, OS/2 and DOS clients. This protocol
 is sometimes also referred to as the LanManager or NetBIOS protocol.
 .
 This package contains all the components necessary to turn your
 Debian GNU/Linux box into a powerful file and printer server.
 .
 Currently, the Samba Debian packages consist of the following:
 .
  samba - LanManager-like file and printer server for Unix.
  samba-common - Samba common files used by both the server and the client.
  smbclient - LanManager-like simple client for Unix.
  swat - Samba Web Administration Tool
  samba-doc - Samba documentation.
  smbfs - Mount and umount commands for the smbfs (kernels 2.2.x and above).
  libpam-smbpass - pluggable authentication module for SMB password database
  libsmbclient - Shared library that allows applications to talk to SMB servers
  libsmbclient-dev - libsmbclient shared libraries
  winbind: Service to resolve user and group information from Windows NT servers
  python2.3-samba: Python bindings that allow access to various aspects of Samba
 .
 It is possible to install a subset of these packages depending on
 your particular needs. For example, to access other SMB servers you
 should only need the smbclient and samba-common packages.
Task: file-server, print-server

$ /usr/bin/apt-cache show samba-common
Package: samba-common
Priority: optional
Section: net
Installed-Size: 4392
Maintainer: Eloy A. Paris <peloy@debian.org>
Architecture: i386
Source: samba
Version: 3.0.4-5
Replaces: samba (<< 2.999+3.0.alpha21-4)
Depends: debconf, libpam-modules, libc6 (>= 2.3.2.ds1-4),
libcomerr2 (>= 1.33-3), libkrb53 (>= 1.3.2),
libldap2 (>= 2.1.17-1), libpopt0 (>= 1.7)
Filename: pool/main/s/samba/samba-common_3.0.4-5_i386.deb
Size: 1880226
MD5sum: 2dd135efcdeae9778b02aa0b22bd6a26
Description: Samba common files used by both the server and the client
 The Samba software suite is a collection of programs that
 implements the SMB protocol for unix systems, allowing you to serve
 files and printers to Windows, NT, OS/2 and DOS clients. This protocol
 is sometimes also referred to as the LanManager or NetBIOS protocol.
 .
 This package contains the common files that are used by both the server
 (provided in the samba package) and the client (provided in the smbclient
 package).

Una vez obtenida la información sobre los paquetes que se van a instalar, se procede con la instalación de Samba:

# /usr/bin/apt-get install samba
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Se instalarán los siguientes paquetes extras:
  samba-common
Se instalarán los siguientes paquetes NUEVOS:
  samba samba-common
0 actualizados, 2 se instalarán, 0 para eliminar y 5 no actualizados.
Se necesita descargar 0B/3988kB de archivos.
Se utilizarán 9839kB de espacio de disco adicional después de desempaquetar.
¿Desea continuar? [S/n] S
Preconfiguring packages ...

--------------------- Sourcerer Apt Watcher ---------------------
Configure: samba-common
-----------------------------------------------------------------
Seleccionando el paquete samba-common previamente no seleccionado.
(Leyendo la base de datos ...
263674 ficheros y directorios instalados actualmente.)
Desempaquetando samba-common (de .../samba-common_3.0.4-5_i386.deb) ...
Seleccionando el paquete samba previamente no seleccionado.
Desempaquetando samba (de .../samba_3.0.4-5_i386.deb) ...
Configurando samba-common (3.0.4-5) ...

Configurando samba (3.0.4-5) ...
Generating /etc/default/samba... 
--------- IMPORTANT INFORMATION FOR XINETD USERS ---------- 
The following line will be added to your /etc/inetd.conf file:

#<off># netbios-ssn     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/smbd

If you are indeed using xinetd, you will have to convert the
above into /etc/xinetd.conf format, and add it manually. See
/usr/share/doc/xinetd/README.Debian for more information.
-----------------------------------------------------------

Starting Samba daemons: nmbd smbd.

Una vez se ha terminado de instalar el paquete, lo reconfiguramos, para seleccionar algunas opciones más relativas a Samba. Tenga en cuenta que esta parte puede no ser necesaria en su sistema, si a la hora de instalar el paquete se le han realizado todas las preguntas que se muestran a continuación, no será necesario realizar esta parte.

# /usr/sbin/dpkg-reconfigure --priority=low samba

Stopping Samba daemons: nmbd smbd.

Tras estos pasos, el servidor Samba ya se encontraría instalado e inicialmente configurado. En el siguiente capítulo se verá como adecuar la configuración a sus necesidades.

7.2.2. Instalación de un cliente

Hay dos paquetes importantes para un cliente Samba: "smbclient" y "smbfs", a continuación se verá su descripción:

$ /usr/bin/apt-cache show smbclient smbfs
Package: smbclient
Priority: optional
Section: net
Installed-Size: 5916
Maintainer: Eloy A. Paris <peloy@debian.org>
Architecture: i386
Source: samba
Version: 3.0.4-5
Replaces: samba (<< 2.999+3.0.alpha21-4)
Provides: samba-client
Depends: samba-common   (= 3.0.4-5), libc6 (>= 2.3.2.ds1-4),
libcomerr2 (>= 1.33-3), libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1),
libncurses5 (>= 5.4-1), libpopt0 (>= 1.7), libreadline4 (>= 4.3-1)
Suggests: smbfs  
Filename: pool/main/s/samba/smbclient_3.0.4-5_i386.deb
Size: 2382652
MD5sum: 2167b566f174efbf82611329937450cd
Description: a LanManager-like simple client for Unix
 The Samba software suite is a collection of programs that
 implements the SMB protocol for unix systems, allowing you to serve
 files and printers to Windows, NT, OS/2 and DOS clients. This protocol
 is sometimes also referred to as the LanManager or NetBIOS protocol.
 .
 This package contains some client components of the Samba suite. In
 particular it includes the command line utilities smbclient, smbtar,
 and smbspool. If you want to mount shares exported from Microsoft
 Windows machines or a Samba server you must install the smbfs package.
Task: file-server, print-server

Package: smbfs
Priority: optional
Section: otherosfs
Installed-Size: 716
Maintainer: Eloy A. Paris <peloy@debian.org>
Architecture: i386
Source: samba
Version: 3.0.4-5
Replaces: smbfsx
Depends: netbase (>= 2.02), samba-common  (= 3.0.4-5),
libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3),
libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1)
Suggests: smbclient  
Conflicts: smbfsx, suidmanager (<< 0.50)
Filename: pool/main/s/samba/smbfs_3.0.4-5_i386.deb
Size: 309678
MD5sum: 5e4809bb7c633d18df260a0f5548bb71
Description: mount and umount commands for the smbfs (for kernels >= than 2.2.x)
 Smbfs is a filesystem which understands the SMB protocol.
 This is the protocol Windows for Workgroups, Windows NT or
 LAN Manager use to talk to each other. It was inspired by
 samba, the program by Andrew Tridgell that turns any unix
 site into a file server for DOS or Windows clients.
 .
 If you want to use command-line utilities like smbclient, smbtar
 and/or smbspool you just need to install the smbclient package.
 .
 Starting with the Debian Samba packages version 2.2.0-1, the old smbfs
 utilities for 2.0.x have been removed. There are no wrapper scripts
 that call a specific smbmount/smbumount depending on the kernel
 version.  If you are using a 2.0.x kernel please upgrade or use the
 latest Samba 2.0.7 Debian package.
Task: file-server, print-server

Ahora que ya se tiene la información de los paquetes que se van a instalar en el cliente, se procede con su instalación:

# /usr/bin/apt-get install smbclient smbfs
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... 50%
Creando árbol de dependencias... Hecho
Se instalarán los siguientes paquetes NUEVOS:
  smbclient smbfs
0 actualizados, 2 se instalarán, 0 para eliminar y 5 no actualizados.
Se necesita descargar 0B/2684kB de archivos.
Se utilizarán 6754kB de espacio de disco adicional después de desempaquetar.
--------------------- Sourcerer Apt Watcher ---------------------
Configure: smbclient
-----------------------------------------------------------------
Seleccionando el paquete smbclient previamente no seleccionado.
(Leyendo la base de datos ...
263489 ficheros y directorios instalados actualmente.)
Desempaquetando smbclient (de .../smbclient_3.0.4-5_i386.deb) ...
Seleccionando el paquete smbfs previamente no seleccionado.
Desempaquetando smbfs (de .../smbfs_3.0.4-5_i386.deb) ...
Configurando smbclient (3.0.4-5) ...
Configurando smbfs (3.0.4-5) ...

Una vez se ha completado el proceso de instalación, el sistema tendrá disponibles las siguientes herramientas (para saber que hace cada una, se pueden consultar las páginas del manual que traen adjuntas):

$ /usr/bin/dpkg -L smbclient  | /bin/grep bin

/usr/bin
/usr/bin/smbclient
/usr/bin/smbtar
/usr/bin/rpcclient
/usr/bin/smbspool
/usr/bin/smbtree
/usr/bin/smbcacls
/usr/bin/smbcquotas
$ /usr/bin/dpkg -L smbfs  | /bin/grep bin

/sbin
/usr/bin
/usr/bin/smbmount
/usr/bin/smbumount
/usr/bin/smbmnt
/sbin/mount.smbfs
/sbin/mount.smb

9.2.1. Sintaxis

El archivo smb.conf utiliza la misma sintaxis que los antiguos ficheros .ini de Windows 3.1: cada archivo consistía en varias secciones, las cuales comenzaban con el nombre de la sección entre corchetes ([]) en una nueva línea. Cada una contenía cero o más pares llave/valor separados por un signo de igualdad (=). El archivo de configuración de Samba es un archivo en texto plano, por lo que se puede editar con cualquier editor de textos.

Cada sección en el archivo smb.conf representa un recurso compartido en el servidor Samba. La sección "global" es especial, ya que contiene opciones que se aplican a todo el servidor Samba y no sólo a un recurso compartido en particular.

Un archivo de configuración realmente pequeño, podría ser:

[global]
workgroup = GRUPODETRABAJO
netbios name = MINOMBRE

[recurso-compartido1]
path = /tmp

[recurso-compartido2]
path = /otro_directorio_compartido
comment = Algunos archivos aleatorios

9.2.2. Comprobando el archivo smb.conf

Es importante validar el contenido del archivo smb.conf haciendo uso del programa testparm. Si testparm se ejecuta correctamente, listará los servicios cargados.

En el Ejemplo 9-2 se comprobará el archivo que viene por defecto (vea el apéndice Apéndice AB) con el paquete de Samba de la distribución Debian GNU/Linux, una vez instalado el paquete.

# /usr/bin/testparm 
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[ENTER]
# Global parameters
[global]
        workgroup = GSRDOMAIN
        server string = %h server (Samba %v)
        obey pam restrictions = Yes
        passdb backend = tdbsam, guest
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        panic action = /usr/share/samba/panic-action %d
        invalid users = root

[homes]
        comment = Home Directories
        create mask = 0700
        directory mask = 0700
        browseable = No

[printers]
        comment = All Printers
        path = /tmp
        create mask = 0700
        printable = Yes
        browseable = No

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

9.3.1. Introducción

En esta sección se configurará Samba como un Controlador Primario de Dominio que almacena su base de datos SAM en un servidor OpenLDAP.

Para la configuración se asumirá que:

• El nombre del dominio será: GSRDOMAIN

• El nombre del servidor Netbios será: TODOSCSI

• El directorio home de los usuarios estará en: /home/samba/users/NOMBREUSUARIO

• Los perfiles móviles se almacenarán en: /home/samba/profiles/NOMBREUSUARIO

9.3.2. [global] - sección global

En la sección global se configurarán los parámetros globales del servidor. Entre otras cosas, se definirán los programas que serán utilizados para que un usuario pueda cambiar su clave (passwd program) y el diálogo que se establecerá entre el servidor y el usuario durante este cambio.

La opción "add user script" permite al demonio smb añadir, como usuario root, una nueva máquina. Cuando una máquina contacta con el dominio, este script es llamado y la nueva máquina es añadida al dominio. Esto hace que la administración de las cuentas para las máquinas sea muy sencilla. Por razones de seguridad, no todas las máquinas pueden entrar en el dominio, sólo aquellas cuyo administrador tenga una cuenta con los privilegios suficientes.

En las secciones siguientes se mostrarán los parámetros más importantes de la configuración de Samba, en el Apéndice AC se muestra un archivo de configuración completo para Samba.

[global]
   workgroup = GSRDOMAIN 
   netbios name = TODOSCSI 
   server string = SAMBA-LDAP PDC server 

   security = user 
   encrypt passwords = true 
   passdb backend = ldapsam:ldap://gsr.pt 
   guest account = guest 
   invalid users = root 
   unix password sync = yes 
   passwd program = /usr/local/sbin/smbldap-passwd -o %u 
   passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n . 
   

   ldap admin dn = cn=admin,dc=gsr,dc=pt 
;   ldap server = gsr.pt 
;   ldap port = 389 
   ldap ssl = off 
   ldap delete dn = no 
   ldap filter = (&(uid=%u)(objectclass=sambaSamAccount)) 
   ldap suffix = ou=people,dc=gsr,dc=pt 
   ldap user suffix = ou=people 
   ldap group suffix = ou=groups 
   ldap machine suffix = ou=machines 

   load printers = yes 
   printing = cups 
   printcap name = cups 
   printer admin = @domainadmins 

   os level = 80 
   preferred master = yes 
   domain master = yes 
   local master = yes 
   domain logons = yes 
   logon path = \\%L\profiles\%u 
   logon drive = H: 
   logon home = \\%L\%u\.profile 
   logon script = 
;   domain admin group = @domainadmins 

   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 
   idmap uid = 10000-20000 
   idmap gid = 10000-20000 
   template shell = /bin/bash 
   add user script = /usr/local/sbin/smbldap-useradd -w %u 

9.3.3. [homes] - directorios personales

Esta sección permite la compartición del directorio home de los usuarios, de forma que, dependiendo que usuario se haya autentificado en el sistema, Samba compartirá su directorio personal únicamente a él.

Los parámetros más importantes de esta sección se muestran a continuación:

   browseable = yes 
   writeable = yes 
   create mask = 0700 
   directory mask = 0700 

9.3.4. [netlogon]

El recurso compartido NETLOGON juega un papel fundamental en el soporte de inicio de sesión en un dominio y Miembro de Dominio. Este recurso compartido se provee en todos los Controladores de Dominio de Microsoft. Se utiliza para proveer de scripts de inicio de sesión, para almacenar archivos de Políticas de Grupo (NTConfig.POL), así como la localización de otras herramientas comunes que se puedan necesitar para el proceso de inicio de sesión. Este es un recurso esencial en un Controlador de dominio.

Los parámetros más importantes de esta sección se muestran a continuación:

   path = /home/samba/netlogon 
   writeable = no 
   write list = @domainadmins 

9.3.5. [profiles] - perfiles móviles

Este recurso compartido se utiliza para almacenar los perfiles de escritorio de los usuarios. Cada usuario ha de tener un directorio en el raíz de este recurso compartido. Este recurso ha de tener permisos de escritura para los usuarios y debería tener la permisos de lectura globales. Samba-3 tiene un módulo VFS denominado "fake_permissions" (permisos "falsos") que se deberían instalar en este recurso. Este módulo permitiría a un administrador de Samba hacer el directorio de sólo lectura para todo el mundo. Por supuesto, esto sólo es útil una vez se ha creado correctamente el perfil.

Los parámetros más importantes de esta sección se muestran a continuación:

   path = /home/samba/profiles 
   writeable = yes 
   browseable = no 
   create mask = 0600 
   directory mask = 0700 

9.3.6. [printers] - impresoras

Este es un recurso compartido especial que crea automáticamente servicios de impresión. La forma en que trabaja es la siguiente: si se crea un recurso compartido con el nombre [printers] en el archivo de configuración, Samba leerá automáticamente el archivo de definición de sus impresoras y creará una impresora compartida para cada impresora que aparezca en el archivo. Por ejemplo, si posee tres impresoras definidas: una lp otra pcl y una última ps, Samba proveerá tres impresoras compartidas con esos nombres, cada una configurada con las opciones que aparezcan en el recurso compartido [printers].

Los parámetros más importantes de esta sección se muestran a continuación:

   browseable = no 
   path = /tmp 
   printable = yes 
   guest ok = no 
   writable = no 
   create mask = 0700