Hasta ahora se ha cubierto la tecnología básica SMB, que sería todo lo que necesitaría saber si su red estuviese compuesta únicamente de clientes MS-DOS. Se asumirá que posee clientes Windows, especialmente las versiones más recientes, por lo que en las siguientes secciones se describirán las mejoras que Microsoft ha introducido en en las redes SMB -denominadas: Windows para grupos de trabajo y Dominios Windows.
Los grupos de trabajo de Windows son muy similares a los grupos SMB ya descritos. Pero necesita saber algunas cosas adicionales.
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, “Notación UNC”:
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.
![[Warning]](./imagenes/warning.png) | Aviso |
|---|---|
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.
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.
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.
![[Tip]](./imagenes/tip.png) | Sugerencia |
|---|---|
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].
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, “Un simple dominio Windows”).
Un controlador de dominio en un dominio Windows NT funciona de manera muy similar a un servidor NIS en una red Unix, manteniendo una base de datos del dominio que contiene la información de los usuarios y grupos, así como sus servicios asociados. Las responsabilidades de un controlador de dominio están principalmente centradas en la seguridad, incluyendo la autentificación o la tarea de permitir o denegar el acceso a los recursos del dominio a un determinado usuario. Esto se realiza normalmente gracias al uso de un nombre de usuario y una clave. El servicio que mantiene la base de datos en los controladores de dominio se denomina Security Account Manager (SAM).
El modelo de seguridad de Windows NT gira en torno a los identificadores de seguridad (SIDs) y las listas de control de acceso (ACLs). Los identificadores de seguridad son utilizados para representar objetos en un dominio, que incluyen (pero no limitan) a los usuarios, los grupos, los ordenadores y los procesos. Los SIDs se escriben normalmente en un formulario ASCII como campos separados por guiones, tal y como se muestra en el Ejemplo 6.8, “Muestra de un SID (Security IDentifier)”:
Un SID comienza con el carácter “S”, seguido de un guión. El número inmediatamente posterior al primer guión se denomina identificador relativo (RID) y es un número único dentro del dominio que identifica a un usuario, un grupo, un ordenador o cualquier otro objeto. El número RID es análogo al user ID (UID) o al group ID (GID) en un sistema Unix o dentro de un dominio NIS.
Las ACLs proveen la misma funcionalidad que los permisos de los archivos “rwx” comunes en los sistemas Unix. Sin embargo, las ACLs son más versátiles. Los permisos de los archivos Unix sólo pueden establecer permisos para el propietario y el grupo al que el fichero pertenece, y “otros”, significa que cualquier otro usuario. Las ACLs de Windows NT/2000/XP permiten establecer permisos individuales para cualquier número arbitrario de usuarios y/o grupos. Las ACLs están constituidas por una o más entradas de control de acceso (ACE - Access Control Entries), cada una de las cuales contienen un SID y derechos de acceso asociados a este.
El soporte de ACLs ha sido incluido como una característica estándar en algunas variantes de Unix y están disponibles como añadidos para otras. Samba soporta el mapeo de las ACLs entre Windows y Unix[23].
Ya se ha hablado sobre buscadores maestros y de respaldo. Los controladores de dominio se parecen a estos en que un dominio tiene un controlador primario (PDC) y puede tener uno o más controladores secundarios de dominio (BDCs). Si un PDC falla o no está accesible, sus tareas son automáticamente traspasadas a uno de los BDCs. Los BDCs sincronizan frecuentemente sus datos SAM con el PDC, por lo que si surge la necesidad cualquiera de ellos puede desempeñar inmediatamente los servicios del controlador primario, sin ningún tipo de impacto para los clientes. Sin embargo, tenga en cuenta que los BDCs tienen copias de solo lectura de la base de datos SAM; estos sólo pueden actualizar sus datos mediante la sincronización con un PDC. Un servidor en un dominio Windows puede hacer uso de la SAM de cualquier PDC o BDC para autentificar a un usuario que intente acceder a sus recursos e ingresar en el dominio.
Todas las versiones recientes de Windows pueden ingresar en un dominio como clientes para tener acceso a los recursos de los servidores de dominio. Los sistemas que son considerados miembros del dominio son una clase más exclusiva, compuesta de un PDC y uno o varios BDCs, así como los servidores miembros del dominio, que no son más que sistemas que se han unido como miembros al domino, y son conocidos por los controladores de dominio debido a la cuenta existente para ellos en la base de datos SAM.
Cuando un usuario teclea su usuario y clave para ingresar en un dominio Windows, se invoca un desafío de seguridad y un protocolo de respuesta entre el ordenador cliente y el controlador de dominio para verificar que el usuario y la clave son válidos. Seguidamente el controlador de dominio envía el SID de nuevo al cliente, quien lo utilizará para crear un SAT (Security Access Token) que es válido únicamente para este sistema, que será utilizado para autentificaciones ulteriores. Esta señal de acceso contiene la información sobre el usuario codificada en su interior, la cual incluye el nombre de usuario, el grupo y los permisos que el usuario posee en el dominio. En este momento, el usuario está autentificado en el dominio.
Posteriormente, cuando el cliente intenta acceder a un recurso compartido dentro del dominio, el sistema cliente entra en un desafío de seguridad y un intercambio de respuestas con el servidor del recurso. Seguidamente el servidor entra en otro desafío de seguridad y conversación de respuesta con el controlador de dominio, para comprobar que el cliente es válido. (Lo que ocurre realmente es que el servidor utiliza la información que ha obtenido del cliente para hacerse pasar por este y autentificarse el mismo ante el controlador de dominio. Si el controlador de dominio valida sus credenciales, envía un SID al servidor, que utilizará para crear su propio SAT para el cliente, de esta forma habilita el acceso a sus recursos locales en beneficio del cliente.) En este punto, el cliente se encuentra autentificado para los recursos del servidor y se le permite acceder a ellos. El servidor utiliza el SID almacenado en el SAT para determinar que permisos de modificación y uso posee el cliente para el recurso en cuestión, esto lo consigue comparándolo con las entradas de las ACLs del recurso.
Aunque este método de autentificación pueda parecer demasiado complicado, permite a los clientes la autentificación sin enviar las claves en texto plano a través de la red, y es mucho más difícil de romper que la endeble seguridad que proporcionan los grupos de trabajo descritos anteriormente.
El servicio de nombres de Internet de Windows (WINS) es una implementación de Microsoft del servidor de nombres NetBIOS (NBNS). Como tal, WINS hereda muchas de las características de NetBIOS. En primer lugar, WINS sólo puede tener nombres nombres simples o llanos para las máquinas, tales como inca, mixtec o navaho, y grupos de trabajo como PERU, MEXICO o USA. Otra característica es que WINS es dinámico: cuando un un cliente se conecta inicialmente a la red, este solicita un nombre, una dirección y un grupo de trabajo al servidor WINS local. Este servidor WINS almacenará la información mientras el cliente refresque periódicamente su registro WINS, lo que indicará que todavía está conectado a la red. Advierta que los servidores WINS no son específicos de un grupo de trabajo o un dominio; pueden contener información sobre múltiples dominios y/o grupos de trabajo, y pueden estar presentes en más de una subred.
Se pueden configurar múltiples servidores WINS para que se sincronicen unos con otros. Esto permite que las entradas de los ordenadores que aparecen y desaparecen de la red se propagarse de un servidor WINS a otro. Aunque que en teoría esto parece eficiente, podría volverse rápidamente problemático si hay varios servidores WINS en la red. Debido a que los servicios WINS pueden atravesar múltiples subredes (puede especificar la dirección del servidor WINS en cada uno de los clientes u obtenerla vía DHCP), normalmente es más eficiente tener a cada cliente Windows, no importa cuántos dominios Windows haya, apuntando a un mismo servidor WINS. De esa forma, sólo habrá un servidor WINS dominante con la información correcta, en lugar de tener varios servidores WINS esforzándose por mantenerse sincronizados con los cambios más recientes.
El servidor WINS activo en un determinado momento es conocido como el servidor WINS primario. También puede instalar un servidor WINS secundario, el cual entrará en acción en el caso de que el primario falle o se vuelva inaccesible. Tanto el servidor primario como cualquier otro servidor WINS sincronizarán sus bases de datos de direcciones periódicamente.
En la familia de sistemas operativos Windows, sólo la edición de servidor Windows NT/2000 puede actuar como servidor WINS. Samba 2.2 puede funcionar como servidor WINS primario, pero no puede actualizar su base de datos con otros servidores WINS. Por este motivo, no puede actuar como servidor secundario WINS o como un servidor primario WINS de un servidor secundario WINS Windows.
WINS maneja el servicio de nombres por defecto, aunque Microsoft añadió el DNS con Windows NT Server 4. Este es compatible con los DNSs que son estándar en virtualmente todos los sistemas Unix, y un servidor Unix (como el host Samba) puede ser utilizado para actuar de DNS.
Un aspecto adicional de los dominios Windows NT, que todavía no está soportado en Samba 2.2, es la posibilidad de configurar una relación de confianza entre dominios, permitiendo a los clientes de un dominio acceder a los recursos de otro sin necesidad de cualquier tipo de autentificación. El protocolo que está detrás de esto se denomina pass-through authentication, mediante el cual las credenciales de un usuario son pasadas de un cliente, en el primer dominio, a un servidor en el segundo dominio, quien consultará al controlador de dominio del primer dominio (de confianza) para comprobar que el usuario es válido antes de permitir el acceso a los recursos.
Ha de notar que en muchos aspectos, el comportamiento de un Windows para grupos de trabajo y un Windows NT concuerdan. Por ejemplo, el buscador maestro y de respaldo en un dominio son siempre el PDC y BDC, respectivamente. A continuación se actualizará el diagrama de dominios Windows para incluir tanto al buscador maestro local como el de respaldo. El resultado se muestra en la Figura 6.13, “Un dominio Windows con un buscador maestro local y uno de respaldo”.
El parecido entre los grupos de trabajo y los dominios NT no es accidental, ya que el concepto de dominio Windows no se desarrolló hasta la versión 3.5 de Windows NT, y los dominios Windows se vieron forzados a mantener la compatibilidad hacia atrás con los grupos de trabajo presentes en Windows para grupos de trabajo.
Samba puede actuar como un controlador primario de dominio para clientes Windows 95/98/Me y Windows NT/2000/XP, con la única limitación de que sólo puede actuar de PDC, no de BDC.
Samba también puede funcionar como un servidor miembro de dominio, esto significa que tendrá una cuenta de equipo en la base de datos del PDC y por tanto será reconocido como parte del dominio. Un servidor miembro del dominio no puede autentificar a los usuarios que ingresan en el dominio, pero puede manejar funciones de seguridad (como los permisos de los archivos) para los usuarios del dominio que acceden a sus recursos.
Dando comienzo con Windows 2000, Microsoft introdujo el Active Directory (Directorio Activo), el siguiente camino más allá de los dominios de Windows NT. No se va a entrar en mucho detalle con Active Directory, ya que es un tema extremadamente amplio. Samba 2.2 no soporta ninguna característica de Active Directory, y el soporte de la versión 3.0 de Samba se limita a actuar como un cliente. Desde ahora, sea consciente de que con Active Directory, el modelo de autentificación está centrado al rededor de LDAP, y el servicio de nombres lo suministra un DNS en lugar de un servidor WINS. Los dominios en Active Directory se pueden organizar en una estructura jerárquica en árbol, en la cual, cada controlador de dominio es fijo, no hay distinción entre controlador primario y secundario, como en los dominios Windows NT.
Los sistemas Windows 2000/XP pueden configurar un simple grupo de trabajo o un dominio de clientes Windows NT (que funcionaría con Samba). La edición Server de Windows 2000 puede configurarse para que ejecute Active Directory y dominios Windows NT para mantener la compatibilidad hacia atrás (modo mixto). En este caso, Samba 2.2 trabaja con los servidores Windows 2000 de la misma forma que lo hacía con los servidores Windows NT 4.0. Cuando se configura para que opere en modo nativo, los servidores Windows 2000 sólo soportan Active Directory. Incluso así, Samba 2.2 puede operar como un servidor en un dominio albergado por un servidor Windows 2000 en modo nativo, haciendo uso del modo emulación PDC de un servidor Windows 2000. Sin embargo, no es posible para Samba 2.2 o 3.0 operar como un controlador de dominio en un un dominio Active Directory de Windows 2000.
Sí, pero la mayoría de la gente que ha hecho esto ha tenido muchos quebraderos de cabeza. Abarcar múltiples subredes no era parte del diseño inicial de Windows NT 3.5 o de Windows para grupos de trabajo. Como resultado, un dominio Windows que abarca dos o más subredes es, en realidad, un "encolado" de dos o más grupos de trabajo que comparten un nombre idéntico. La buena noticia es que todavía se puede hacer uso de un controlador primario de dominio para el control de autentificación a lo largo de cada subred. La mala noticia es que las cosas no son tan sencillas en la navegación.
Como se mencionó anteriormente, cada subred ha de tener su propio buscador maestro local. Cuando un dominio Windows abarca múltiples subredes, un administrador del sistema tendrá que asignar una de las máquinas como buscador maestro de dominio. El buscador maestro de dominio mantendrá una lista de búsqueda para todo el dominio Windows. Esta lista de búsqueda es creada por la sincronización periódica de la lista de búsqueda de cada buscador maestro local con la lista de búsqueda del buscador maestro de dominio. Después de la sincronización, el buscador maestro local y el buscador maestro de dominio deberían contener entradas idénticas. Observe la Figura 6.14, “Grupo de trabajo que abarca más de una subred” para ver un ejemplo.
¿Suena bien? pues no se acerca al "cielo" por las siguientes razones:
Si existe, un PDC siempre juega el papel de buscador maestro de dominio. Debido al diseño de Microsoft, los dos siempre comparten el tipo de recurso NetBIOS <1B> y (desafortunadamente) no se pueden separar.
En los equipos Windows 95/98/Me no pueden llegar a ser ni siquiera contactar con un buscador maestro de dominio. Esto significa que necesariamente se ha de tener, al menos, un sistema Windows NT/2000/XP (o un servidor Samba) en cada subred del grupo de trabajo multi-red
Cada buscador maestro local de cada subred continua manteniendo la lista de búsqueda para su subred, para la cual se vuelve dominante. De esta forma, si un ordenador desease ver la lista de los servidores de su propia subred, el buscador maestro local de esa subred sería interrogado. Si un ordenador quisiese ver una lista de servidores fuera de su subred, sólo podrá llegar hasta donde le lleve el buscador maestro local. Esto funciona debido a los intervalos fijados, la lista de búsqueda dominante del buscador maestro local de una subred se sincroniza con el buscador maestro de dominio, quien está sincronizado con el buscador maestro local de las otras subredes pertenecientes al dominio. Esto se denomina propagación de la lista de búsqueda.
Samba puede actuar como buscador maestro de dominio en un dominio Windows NT, o puede actuar como un buscador maestro local para una subred, sincronizando su lista de búsqueda con el buscador maestro de dominio.
[20] El capítulo 7 de la entrada bibliográfica TsEcksteinCollier-Brown01 describe en más detalle el proceso de elección.
[21] Para más detalles, vea el capítulo 9 de la entrada bibliográfica TsEcksteinCollier-Brown01
[23] Para más información, consulte el capítulo 8 de la entrada bibliográfica TsEcksteinCollier-Brown01