23.9. NIS/YP

23.9.1. ¿Qué es esto?

NIS, siglas de Network Information Services (Servicios de Información de Red), fué un servicio desarrollado por Sun Microsystems para centralizar la administración de sistemas UNIX® (originalmente SunOS™). Actualmente se considera como un estándar de la industria; los principales sistemas tipo UNIX (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, etc) implementan NIS.

NIS también se conocía como el servicio de páginas amarillas pero debido a problemas legales debidos a la propiedad de marcas comerciales, Sun tuvo que cambiar el nombre. El antíguo término (“Yellow Pages” o yp) todavía se ve y se utiliza con frecuencia.

Se trata de un sistema cliente servidor basado en llamadas RPC que permite a un grupo de máquinas que se encuentran definidas dentro de un dominio administrativo NIS compartir un conjunto de ficheros de configuración. Esto permite al administrador de sistemas por un lado configurar clientes NIS de forma minimalista y por otro lado centralizar la gestión de los ficheros de configuración en una única ubicación (una sola máquina).

Se trata de algo similar al sistema de dominio de Windows NT® aunque la implementación interna no se puede comparar, la funcionalidad y el servicio obtenido son similares.

23.9.2. Términos/Procesos que Usted Debe Conocer

Existen varios conceptos y varios procesos de usuario que el usuario no versado en estos temas suele encontrarse la primera vez que se intenta implantar un servicio de NIS en FreeBSD, tanto si se intenta configurar un servidor como si se intenta configurar un cliente:

23.9.3. ¿Cómo Funciona?

Existen tres tipos de máquinas dentro del entorno NIS: los servidores maestros, los servidores esclavos y los clientes de NIS. Los servidores actúan como repositorios centrales para almacenamiento de información de configuración. Los servidores maestros mantienen una copia maestra de dicha información, mientras que los servidores esclavos mantienen copias de la información maestra por motivos de redundancia. Los servidores se encargan de transmitir la información necesaria a los clientes a petición de estos últimos.

De esta forma se pueden compatir mucha información contenida en varios archivos. Los ficheros master.passwd, group y hosts normalmente se comparten a través de NIS. Siempre que un proceso en un cliente necesita información que, en caso de no utilizar NIS, se podría recuperar de ficheros locales, en este caso se envía una solicitud al servidor NIS con el que nos encontramos asociados.

23.9.4. Utilización de NIS/YP

Esta sección trata sobre cómo configurar y poner en funcionamiento un entorno de NIS sencillo.

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server   :  ellington
next host to add:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..salida de la generacion de mapeos..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

ellington# vi
              /var/yp/Makefile

NOPUSH = "True"

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

23.9.5. Seguridad en NIS

En general cualquier usuario remoto puede realizar peticiones de RPC a ypserv(8) y recuperar los contenidos de las asociaciones de NIS siempre y cuando el usuario remoto conozca el nombre de dominio de NIS. Para evitar este tipo de transacciones no autorizadas, ypserv(8) soporta una característica denominada “securenets” la cual se puede utilizar para limitar el acceso a un determinado conjunto de máquinas. En el arranque ypserv(8) intenta cargar la información de “securenets” a partir de un fichero denominado /var/yp/securenets.

# admitir conexiones desde localhost -- obligatorio
127.0.0.1     255.255.255.255
# admitir conexiones desde cualquier host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# admitir conexiones desde cualquier host
# between 10.0.0.0 to 10.0.15.255
# esto incluye las maquinas en el 'testlab'
10.0.0.0      255.255.240.0

Si ypserv(8) recibe una petición de una dirección que coincide con alguna de las reglas especificadas en el fichero se procesa la petición. Si no existe ninguna coincidencia la petición se rechaza y se graba un mensaje de aviso. Si el archivo /var/yp/securnets no existe ypserv acepta conexiones de cualquier máquina.

El programa ypserv también posee soporte para el paquete de Wietse Venema denominado tcpwrapper. Este paquete permite utilizar los ficheros de configuración de tcpwrapper para realizar control de acceso en lugar de utilizar var/yp/securenets.

23.9.6. Prohibir el Acceso a Determinados Usuarios

En nuestro laboratorio de ejemplo existe una máquina denominada basie que actúa sólo como una estación de trabajo para el profesorado. No queremos sacar a esta máquina del dominio NIS pero nos damos cuenta de que el fichero passwd que se encuentra en el servidor de NIS posee cuentas tanto para profesores como para alumnos. ¿Qué podemos hacer?.

Existe una forma de prohibir el acceso a determinados usuarios sobre una determinada máquina incluso aunque se encuentren dados de alta en la base de datos de NIS. Para realizar esto todo lo que debemos hacer es añadir -nombredeusuario al final del fichero /etc/master.passwd en la máquina cliente donde nombredeusuario es el nombre de usuario del usuario al que queremos prohibirle el acceso. Esto se debe realizar a poder ser mediante el comando vipw ya que vipw realiza comprobaciones de seguridad sobre los cambios realizados y además se encarga de reconstruir la base de datos de contraseñas cuando se termina la edición. Por ejemplo, si quisiéramos prohibir el acceso al usuario bill a la máquina basie haríamos:

basie# vipw
[añadimos -bill al final y salimos]
vipw: rebuilding the database...
vipw: done

basie# cat /etc/master.passwd

root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill

basie#

23.9.7. Utilización de Netgroups

El método descrito en la sección anterior funciona razonablemente bien si las reglas especiales se definen para un conjunto pequeño de usuarios y/o máquinas. En dominios admnistrativos grandes puede que se nos olvide prohibir el acceso a algún usuario en determinadas máquinas perdiendo de esta forma el principal beneficio de utilizar el servicio de páginas amarillas:administración centralizada.

La solución creada por los desarrolladores de NIS se denomina netgroups. Su propósito se asemeja al concepto de grupos utilizado por los sistemas UNIX. La diferencia principal es la carencia de un identificador numérico y la habilidad para definir un “netgroup” que incluye tanto a cuentas de usuario como a otros “netgroups”.

Los netgroups se desarrollaron para gestionar redes grandes y y complejas con cientos de usuarios y máquinas. Por un lado esto es una Cosa Buena si nos encontramos en tal situación pero por otro lado esta complejidad añadida hace que sea casi imposible de explicar a través de ejemplos sencillos. El ejemplo que va a utilizar en lo que queda de sección ilustrará este hecho.

Vamos a suponer que la exitosa introducción del servicio de páginas amarillas en nuestro laboratorio ha llamado la atención de nuestros jefes. Nuestra siguiente tarea consiste en extender el dominio de NIS para que cubra otras máquinas del campus. Las tablas que se muestran a continuación contienen los nombres de los nuevos usuarios y máquinas junto con una breve descripción de ellas.

Si se trata de implementar estas restricciones a nivel de usuario particular tendríamos que añadir una línea -usuario a cada fichero passwd del sistema para cada usuario que tuviera prohibido el acceso a dicho sistema. Si nos olvidamos de una sola entrada podrímos tener serios problemas. Puede ser factible realizar esta configuración cuando se instala el servicio pero no obstante el riesgo que corremos al mantener este sistema de restricciones en el día día es muy alto. Después de todo Murphy era un optimista.

La gestión de esta situación mediante netgroups ofrece varias ventajas. Cada usuario no tiene que tratarse de una forma individualizada; basta con añadir un usuario a uno o más netgroups y posteriormente permitir o prohibir el acceso para todos los usuarios del netgroup. Si se añade una nueva máquina al servicio de NIS simplemente tendremos que definir restricciones de acceso para los netgroups definidos en la red. Si se añade un nuevo usuario bastará con añadir dicho usuario a un netgroup existente. Estos cambios son independientes unos de otros: se acabó la necesidad de aplicar la frase “por cada combinación de usuario y máquina haga esto y esto”. Si hemos planificado nuestro servicio de NIS cuidadosamente, sólo tendremos que modificar un fichero de configuración en un determinado servidor para permitir o denegar estos accesos.

El primer paso consiste en la inicialización de la asociación o mapeo del netgroup. El comando de FreeBSD ypinit(8) no crea este mapeo por defecto pero una vez creado será tenido en cuenta por la implementación de NIS. Para crear una asociación vacía simplemente escriba:

ellington# vi /var/yp/netgroup

y comienze a añadir contenido. En nuestro ejemplo necesitamos al menos cuatro netgroups: empleados de IT, aprendices de IT, empleados normales e internos.

IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)

IT_EMP, IT_APP etc. son los nombres de los netgroups. Cada conjunto delimitado por paréntesis define una o más cuentas como pertenecientes al netgroup. Existen tres campos definidos dentro de dichos de dichos grupos:

1. El nombre de las máquinas donde los siguientes items son aplicables. Si no se especifica un nombre de máquina la entrada se aplica a todas las máquinas existentes. Si se especifica una máquina determinada entraremos en un mundo lleno de horrores y confusiones así que mejor no hacerlo.

2. El nombre de la cuenta que pertenece al netgroup que estamos definiendo.

3. El dominio NIS donde reside la cuenta. Se pueden importar cuentas de otros dominios NIS (en caso de que usted pertenezca al extraño grupo de personas que gestionan más de un dominio NIS.

Cada uno de estos campos puede contener comodines. Consulte netgroup(5) para obtener más detalles.

La activación y distribución de nuestro nuevo mapeo NIS resulta sencillo:

ellington# cd /var/yp
ellington# make

Esto genera las tres asociaciones NIS netgroup, netgroup.byhost y netgroup.byuser. Utilice ypcat(1) para comprobar si el nuevo mapeo NIS se encuentra disponible:

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

La salida del primer comando debería parecerse a los contenidos del fichero /var/yp/netgroup. El segundo comando no mostrará ninguna salida salvo que se hayan especificado netgroups específicos para máquinas. El tercer comando se puede utilizar para obtener la lista de los netgroups a los que petenece un determinado usuario.

La configuración del cliente es bastante simple. Para configurar el servidor guerra se debe ejecutar vipw(8) y sustituír la línea

+:::::::::

por

+@IT_EMP:::::::::

Ahora sólo se importan los datos para los usuarios que se encuentren definidos en el netgroup IT_EMP; dichos datos se importan en la base de datos de contraseñas de guerra y sólo se permite el acceso a estos usuarios.

Por desgraciaesta información también se aplica a la función ~ del shell y a todas las rutinas que traducen nombres de usuarios con los correspondientes identificadores númericos de usuario (uid). En otras palabras, el comando cd ~ no va a funcionar, el comando ls -l muestra el identificador numérico en lugar del nombre de usuario y el comando find . -user joe -print produce un error de “ No such user” (“Usuario desconocido”). Para solucionar esto debemos importar todas las entradas de usuario en la máquina cliente NIS pero sin permitirles el acceso.

Esto se puede realizar añadiendo otra línea al fichero /etc/master.passwd. Esta línea debería contener lo siguiente:

+:::::::::/sbin/nologin, lo que significa que se “importen todas las entradas pero que se reemplace el shell por /sbin/nologin”. Se puede sustituir cualquier campo de la entrada de contraseñas especificando un valor concreto para dicho campo en el fichero local local /etc/master.passwd.

Después de este cambio si se introduce un nuevo empleado en el departamento de IT basta con cambiar una asociación de NIS. Se podría aplicar una aproximación similar para los servidores menos importantes sustituyendo la cadena +::::::::: en las versiones locales del fichero /etc/master.passwd por algo parecido a esto:

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

Las líneas correspondientes para las estaciones de trabajo normales podrían ser:

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

Y parece que todos nuestros problemas de gestión han desaparecido; hasta que unas semanas más tarde se produce un cambio en la política de gestión: el depatamento de IT comienza a alquilar interinos. Los interinos de IT pueden utilizar las estaciones de trabajo normales y los servidores menos importantes y los aprendices de IT pueden acceder a los servidores principales. No nos queda más remedio que añadir un nuevo netgroup denominado IT_INTERN y añadir los nuevos interinos de IT a este nuevo grupo y comenzar a cambiar la la configuración de cada máquina, una por una... Como dice el antiguo proverbio: “Errores en la planificación centralizada conllevan grandes quebraderos de de cabeza globales”.

La habilidad que posee NIS para crear netgroups a partir de otros netgroups se puede utilizar para evitar la situación anterior. Una posibilidad consiste en la creación de netgroups basados en roles. Por ejemplo, se podría crear un netgroup denominado BIGSRV para definir las restricciones de acceso para los servidores importantes, otro grupo denominado USERBOX para las estaciones de trabajo... Cada uno de estos netgroups podría contener los netgroups que pueden acceder a dichas máquinas. Las nuevas entradas para nuestro mapeo NIS de netgroups sería algo así:

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

Este método de definir restricciones de acceso funciona razonablemente bien si podemos definir grupos de máquinas que posean restricciones semejantes. Por desgracia lo normal es que este caso resulta ser una excepción más que una regla. En la mayor parte de las ocasiones necesitaremos definir restricciones de acceso en función de máquinas individuales.

Las definiciones de netgroups específicos para determinadas máquinas constituyen el segundo método que se puede utilizar para gestionar el cambio de política del ejemplo que estamos explicando. En nuestro caso el fichero /etc/master.passwd de cada máquina contiene dos líneas que comienzan por “+”. La primera de ellas añade un netgroup con las cuentas que pueden acceder a esa máquina, mientras que la segunda añade el resto de cuentas con shell el resto de cuentas con shell /sbin/nologin. Es una buena idea utilizar la versión “todo en mayúsculas” del nombre de máquina como el nombre del netgroup. En otras palabras, las líneas deberían ser como la siguiente:

+@BOXNAME:::::::::
+:::::::::/sbin/nologin

Una vez que hemos completado esta tarea para todas las máquinas nunca más resultará necesario modificar las versiones locales de /etc/master.passwd. Los futuros cambios se pueden gestionar simplemente modificando el mapeo o asociación de NIS. A continuación se muestra un mapeo de netgroups para el escenario que se está explicando junto con algunas buenas ideas:

# Definimos antes que nada los grupos de usuarios
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Ahora definimos unos pocos grupos basados en roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# Y un grupo para tareas especiales
# Permitimos a echo y golf acceso a nuestra maquina-anti-virus
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# netgroups basados en maquinas
# Nuestros servidores principales
GUERRA   BIGSRV
HAMBRE   BIGSRV
# El usuario india necesita acceso a este servidor
PESTE  BIGSRV  (,india,test-domain)
#
# Este es realmente importante y necesita mas restricciones de 
# acceso
MUERTE     IT_EMP
#
# La maquina-anti-virus que mencionabamos mas arriba
ONE       SECURITY
#
# Restringimos una maquina a un solo usuario
TWO       (,hotel,test-domain)
# [...otros grupos]

Si estamos utilizando algun tipo de base de datos para gestionar cuentas de usuario debemos ser capaces de crear la primera parte del mapeo utilizando las herramientas proporcionadas por dicho sistema de base de datos. De este modo los nuevos usuarios tendrán automáticamente derechos de acceso sobre las máquinas.

Una última, por precaución: puede no ser siempre aconsejable utilizar netgroups basados en máquinas. Si se están desplegando, por ejemplo, un par de docenas o incluso cientos de máquinas idénticas en laboratorios de estudiantes, es mejor utilizar netgroups basados en roles en lugar de netgroups basados en máquinas individuales para mantener el tamaño de la asociación NIS dentro de unos límites razonables.

23.9.8. Cosas Importantes para Recordar

Todavía quedan un par de cosas que tendremos que hacer de forma distinta a lo comentado hasta ahora en caso de encontrarnos dentro de un entorno de NIS.

• Cada vez que deseemos añadir un usuario a nuestro laboratorio debemos añadirlo al servidor NIS maestro únicamente y es tarea fundamental del administrador acordarse de reconstruir los mapeos NIS. Si nos olvidamos de esto el nuevo usuario será incapaz de acceder a ninguna máquina excepto al servidor NIS. Por ejemplo, si necesitáramos añadir el nuevo usuario jsmith al laboratorio tendríamos que ejecutar lo siguiente:

  # pw useradd jsmith
  # cd /var/yp
  # make test-domain
  

  Se puede ejecutar también adduser jsmith en lugar de pw useradd jsmith.

• No introduzca las cuentas de administración dentro de los mapeos de NIS. No es buena idea propagar cuentas y contraseñas de administración a máquinas donde residen usuarios que normalmente no deberían poder acceder a dichas cuentas.

• Mantenga el servidor maestro y esclavo de NIS seguros y minimize el tiempo de interrupción del servicio. Si alguien fuera capaz de comprometer la integridad de estas máquinas o de apagarlas los usuarios del dominio no podrían acceder a sus cuentas en ningún sistema.

  Esto es la debilidad principal de cualquier sistema de administración centralizada. Si no se protegen los servidores NIS tendremos frente a nosotros a una horda de usuarios bastante enfadados.

23.9.9. Compatibilidad con NIS v1

El servicio ypserv de FreeBSD puede servir también a clientes NIS v1. La implementación de NIS de FreeBSD sólo utiliza el protocolo NIS v2 aunque otras implementaciones incluyen soporte para el protocolo v1 por razones de compatibilidad con sistemas antiguos. Los dæmones ypbind suministrados con estos sistemas tratan de establecer una asociación con un servidor NIS versión 1 aunque puede que nunca la lleguen a utilizar (y pueden continuar realizando búsquedas mediante broadcast incluso cuando reciben una respuesta de un servidor versión 2). Tenga muy presente que mientras se soportan las llamadas normales de clientes v1, la versión de ypserv actualmente suministrada no gestiona peticiones de transferencia de mapeos a través de la versión 1; en consecuencia no se puede utilizar como maestro o esclavo junto con servidores de NIS antiguos que sólo soporten el protocolo v1. Por suerte quedan muy pocos servidores de este estilo en funcionamiento hoy en día.

23.9.10. Servidores NIS que Actúan También Como Clientes NIS

Se debe tener cuidado cuando se ejecuta ypserv en un entorno multi-servidor donde las máquinas servidoras actúan también como máquinas clientes de NIS. Normalmente es una buena idea obligar a los servidores a que se asocien con ellos mismos mejor que permitirles emitir peticiones de asociación en broadcast, lo que posiblemente terminará con los servidores asociados entre sí. Se pueden producir extraños fallos si un servidor del que dependen otros deja de funcionar. Puede darse que los contadores de todos los clientes expiren e intenten asociarse a otro servidor, pero el retardo puede ser considerable y los fallos todavía podrín persistir debido a que los servidores se asocian contínuamente los unos a los otros.

Se puede obligar a una máquina a asociarse con un servidor en particular ejecutando ypbind con la opción -S. Si no se quiere ejecutar esto manualmente cada vez que se reinice el servidor NIS se puede puede añadir la siguiente línea al fichero /etc/rc.conf:

nis_client_enable="YES"    # ejecuta tambien el soft cliente 
nis_client_flags="-S NIS domain,server"

Consulte ypbind(8) para obtener más información.

23.9.11. Formatos de Contraseñas

Uno de los problemas más comunes que se encuentra la gente a la hora de implantar un servicio de NIS es la compatibilidad del formato de las contraseñas. Si nuestro servidor de NIS utiliza contraseñas cifradas mediante DES sólo podrá aceptar clientes que utilicen DES. Por ejemplo, si poseemos clientes de NIS Solaris en nuestra red casi seguro que necesitaremos utilizar contraseñas cifradas mediante DES.

Para comprobar qué formato utilizan los servidores y los clientes, se puede mirar en /etc/login.conf. Si la máquina se configura para utilizar cifrado de contraseñas mediante DES, entonces la clase por defecto debe poseer una entrada como la siguiente:

default:\
    :passwd_format=des:\
    :copyright=/etc/COPYRIGHT:\
    [Se han omitido otras entradas]

Otros posibles valores para característica de passwd_format pueden ser blf y md5 (para utilizar los algoritmos Blowfish y MD5 respectivamente).

Se debe reconstruir la base de datos de acceso siempre que se modifique el fichero /etc/login.conf mediante la ejecución del siguiente comando como root:

# cap_mkdb /etc/login.conf

A continuación para asegurarse de que las contraseñas se cifran con el formato seleccionado también debemos comprobar que la variable crypt_default dentro del fichero /etc/auth.conf da preferencia al formato de contraseña elegido. Por ejemplo cuando se utilizan contraseñas cifradas con DES la entrada debe ser:

crypt_default  =   des blf md5

Si se realizan los pasos anteriores en cada una de las máquinas clientes y servidoras de nuestro entorno NIS podemos asegurar que todas utilizan el mismo formato de contraseña dentro de nuestra red. Si se presentan problemas de validación con determinados usuarios en una determinada máquina cliente se puede empezar a investigar sobre el asunto. Recuerde: si se quiere desplegar un servicio de páginas amarillas sobre un entorno de red heterogéneo probablemente se deba utilizar DES en todos los sistemas puesto que DES es el mínimo común denominador.