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.
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:
| Term | Description |
|---|---|
| NIS domainname | Un servidor maestro de NIS y todos sus clientes (incluyendo a sus servidores esclavos) poseen el mismo nombre dominio NIS. Al igual que ocurre con el nombre de dominio de Windows NT, el nombre de dominio de NIS no tiene nada que ver con el nombre de dominio de DNS. |
| portmap | Debe ejecutarse para que se activen las llamadas a procedimientos remotos (Remote Procedure Call o RPC) que son utilizadas por NIS. Si portmap no se está ejecutando no se podrá ejecutar ni clientes ni servidores de NIS. |
| ypbind | “Asocia” un cliente con un servidor NIS. Primeramente se lee el nombre de dominio NIS del sistema y utilizando RPC se conecta con el servidor. ypbind es la parte central de la comunicación cliente servidor del sistema NIS; si ypbind muere en una máquina cliente, dicha máquina no podrá acceder al servidor NIS. |
| ypserv | Debe ejecutarse sólamente en los servidores NIS; se trata del proceso servidor de NIS. Si ypserv(8) muere, el servidor no será capaz de responder a peticiones NIS (no obstante, si se definen servidores NIS esclavos la situación puede recuperarse). Existen algunas implementaciones de NIS (no es el caso de FreeBSD) que no intentan conectarse con otro servidor si el servidor con otro servidor si el servidor que se estaba que se estaba utilizando muere. A menudo lo único que se puede hacer en estos casos es reiniciar el servidor (el proceso o la propia máquina) o el proceso ypbind del cliente. |
| rpc.yppasswdd | Otro proceso que sólo debe ejecutarse en el servidor maestro de NIS; se trata de un dæmon que permite a los clientes de NIS modificar las contraseñas de los usuarios. Si no se ejecuta este dæmon los usuarios tendrán que entrar en el servidor maestro de NIS para cambiar sus contraseñas allí. |
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.
Servidor de NIS maestro. Este servidor, semejante a un controlador de dominio primario de Windows NT mantiene todos los archivos que utilizan los clientes. Los ficheros passwd, group y algunos otros se encuentran ubicados en el servidor maestro.
Nota: Resulta posible configurar una máquina para que actúe como servidor NIS maestro para más de un dominio NIS. No obstante esta configuración no se va a tratar en esta introducción, en la cual asumimos un entorno NIS de tamaño relativamente pequeño.
Servidores de NIS esclavos. Semejantes a los controladores de backup de Windows NT, los servidores NIS esclavos se utilizan para proporcionar redundancia en entornos de trabajo donde la disponibilidad del servicio resulta muy importante. Además se utilizan para distribuir la carga que normalmente soporta un servidor maestro: los clientes de NIS siempre se asocian con el servidor de NIS que posee mejor tiempo de respuesta, y esto y esto también incluye a los servidores de NIS esclavos.
Clientes NIS. Los clientes NIS, de forma semejante a las estaciones de trabajo de Windows NT, se validan contra un servidor NIS (en el caso de Windows NT se validan contra un controlador de dominio) para acceder al sistema.
Esta sección trata sobre cómo configurar y poner en funcionamiento un entorno de NIS sencillo.
Nota: Esta sección supone que se está utilizando utilizando FreeBSD 3.3 o posteriores. Las instrucciones dadas aquí probablemente funcionen también en cualquier versión de FreeBSD superior a la 3.0 pero no podemos garantizar que esto sea así.
Vamos a suponer que somos el administrador de un pequeño laboratorio de una universidad. En este laboratorio, compuesto por 15 máquinas FreeBSD, actualmente no existe ningún punto de administración centralizada; cada máquina posee sus sus propios /etc/passwd y /etc/master.passwd. Estos ficheros se encuentran sincronizados el uno con el otro mediante intervención manual; por tanto, cuando queramos añadir un usuario a nuestro laboratorio tendremos que ejecutar adduser en todas las máquinas. Claramente esta situación tiene que cambiar, de tal forma que hemos decidido crear un dominio NIS en el laboratorio usando dos máquinas como servidores NIS.
La configuración de nuestro laboratorio debería ser algo parecido a lo siguiente:
| Nombre de máquina | Dirección IP | Papel |
|---|---|---|
| ellington | 10.0.0.2 | servidor NIS maestro |
| coltrane | 10.0.0.3 | Servidor NIS esclavo |
| basie | 10.0.0.4 | Estación de trabajo del profesorado |
| bird | 10.0.0.5 | máquina cliente |
| cli[1-11] | 10.0.0.[6-17] | Resto de máquinas clientes |
Si se está configurando un esquema de NIS por primera vez es una buena idea detenerse a pensar cómo queremos implantar el sistema. Existen varias decisiones que se deben tomar independientemente del tamaño de nuestra red.
Este nombre puede no ser el “nombre de dominio” al que estamos acostumbrados. Resulta más preciso llamarlo “nombre de dominio NIS”. Cuando un cliente genera peticiones de NIS que llegan a todas las máquinas (broadcast) solicitando información se incluye el nombre de dominio NIS que tiene configurado. De esta forma, varios servidores de dominios distintos situados en la misma red pueden discriminar las peticiones recibidas. Se puede pensar en el nombre de dominio NIS como un identificador de grupos de máquinas que se encuentran relacionados administrativamente de alguna forma.
Algunas organizaciones eligen utilizar su nombre de dominio de Internet como nombre de dominio NIS. Esto no se recomienda ya que puede causar confusión cuando se intentan depurar problemas de red. El nombre de dominio NIS debería ser un nombre único dentro de nuestra red y resulta más útil aún si el nombre elegido puede describir de alguna forma al conjunto de máquinas que representa. Por ejemplo el departamento de arte de la empresa Acme puede utilizar como nombre de dominio “acme-art”. En nuestro ejemplo hemos utilizado el nombre test-domain.
No obstante algunos sistemas operativos (de forma notable SunOS) utilizan como nombres de dominio nombres de Internet. Si se poseen máquinas con esta restricción no queda más remedio que utilizar los nombres de dominio de Internet como nombres de dominio NIS.
Existen varias cosas que debemos tener en cuenta cuando se selecciona una máquina para actuar como servidor NIS. Una de las características desafortunadas del servicio de páginas amarillas es el alto nivel de dependencia que llegan a tener los clientes respecto del servidor de NIS. Si el cliente no puede contactar con el servidor NIS normalmente la máquina se queda en un estado totalmente inutilizable. La carencia de información de usuarios y grupos provoca que las máquinas se bloqueen. Con esto en mente debemos debemos asegurarnos de escoger un servidor de NIS que no se reinicie de forma habitual o uno que no se utilice para para desarrollar. Si se dispone de una red con poca carga puede resultar aceptable colocar el servidor de NIS en una máquina donde se ejecuten otros servicios pero en todo momento se debe tener presente que si por cualquier motivo el servidor de NIS quedara inutilizable afectaría a todas las máquinas de forma negativa.
Las copias canónicas de toda la información que mantiene el sistema de páginas amarillas se almacenan en una única máquina denominada servidor maestro de NIS. Las bases de datos utilizadas para almacenar la información se denominan mapeos NIS. En FreeBSD estas asociaciones o mapeos se almacenan en el directorio /var/yp/[nombrededominio] donde [nombrededominio] es el nombre del dominio de NIS que el servidor gestiona. Un único servidor NIS puede gestionar varios dominios al mismo tiempo de forma que resulta posible tener varios directorios como el anterior, uno por cada dominio soportado. Cada dominio posee su conjunto de mapeos independiente y propio.
Los servidores maestro y esclavos manejan todas las peticiones de a través del dæmon ypserv. ypserv se responsabiliza de recibir peticiones de los clientes NIS. Estas peticiones se traducen a una ruta dentro del servidor. Esta ruta localiza un fichero de base de datos determinado del servidor de NIS, y finalmente ypserv se encarga de transmitir la información de dicha base de datos de vuelta al cliente que la solicitó.
La configuración de un servidor de NIS maestro puede resultar relativamente sencilla dependiendo de las necesidades que se tengan. FreeBSD viene preconfigurado por defecto con un servicio NIS. Todo lo que necesitamos es añadir la siguiente línea en /etc/rc.conf y FreeBSD se encarga del resto.
nisdomainname="test-domain"Esta línea establece el nombre de dominio NIS como test-domain, cuando se realiza la configuración de la red (por ejemplo, después de un reinicio).
nis_server_enable="YES"Esta variable indica a FreeBSD que ejecute los procesos necesarios para actuar como un servidor de NIS la próxima vez que se configure el subsistema de red.
nis_yppasswdd_enable="YES"Esto permite activar el dæmon rpc.yppasswdd el cual, como se ha mencionado anteriormente, permite a los usuarios realizar cambios de contraseña desde las máquinas clientes de NIS.
Nota: Dependiendo de la configuración de NIS podemos necesitar añadir algunas entradas más. Consulte la sección sobre servidores NIS que también actúan como clientes, más adelante en el texto, para saber más sobre esto.
Una vez hecho esto todo lo que tenemos que hacer es ejecutar /etc/netstart como superusuario. Esta orden realiza los pasos de configuración necesarios utilizando los valores de las variables definidas en /etc/rc.conf.
Las asociaciones o mapeos de NIS no son más que ficheros de base de datos. Estos ficheros se generan a partir de los ficheros de configuración contenidos en el directorio etc/ excepto para el caso del fichero etc/master.passwd. Esto es así por una buena razón ya que no suele ser buena idea propagar las contraseñas de root y de otras cuentas de administración a todos los servidores NIS del dominio. servidores NIS del dominio. Así, antes de inicializar los mapeos se debe ejecutar:
# cp /etc/master.passwd /var/yp/master.passwd # cd /var/yp # vi master.passwd
Se deben borrar todas las entradas que hagan referencia a cuentas del sistema (bin, tty, kmem, games, etc), junto con cualquier cuenta que no deseemos que se transmita a los clientes NIS (por ejemplo la cuenta de root y cualquier otra cuenta con UID 0 (el del superusuario)).
Nota: Asegúrese de que /var/yp/master.passwd no se puede leer ni por grupos ni por el resto de usuarios (modo 600). Utilice chmod en caso de necesidad.
Una vez hecho esto es hora de inicializar las asociaciones de NIS. FreeBSD incluye un
“script” denominado ypinit para realizar esta tarea
(consulte su página del manual para obtener más información). Recuerde que este
“script” se encuentra disponible en la mayoría de los sistemas UNIX, pero no en todos. En sistemas Digital UNIX/Compaq Tru64
UNIX se denomina ypsetup. Debido a que se pretende generar
asociaciones para un servidor NIS maestro vamos a ejecutar ypinit con la opción -m. A modo de
ejemplo, suponiendo que todos los pasos comentados anteriormente se han realizado con
éxito, ejecute:
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.
ypinit debería haber creado el fichero /var/yp/Makefile a partir de /var/yp/Makefile.dist. Una vez creado este archivo presupone que se está usando un entorno NIS con un único servidor utilizando sólamente máquinas FreeBSD. Debido a que test-domain posee también un servidor NIS esclavo se debe editar el fichero var/yp/Makefile:
ellington# vi
/var/yp/Makefile
Se debe comentar la línea que dice:
NOPUSH = "True"
(si es que no se encuentra ya comentada).
La configuración de un servidor NIS esclavo resulta ser incluso más sencilla que la
del maestro. Basta con entrar en el servidor esclavo y editar /etc/rc.conf de foma semejante a como se realizó en el apartado
anterior. La única diferencia consiste en que ahora debemos utilizar la opción -s cuando ejecutemos ejecutemos ypinit. A
continuación del parámetro -s se debe especificar el nombre
del servidor maestro de modo que la orden tendría que ser algo parecido a esto:
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.
En estos momentos debemos tener un nuevo directorio llamado /var/yp/test-domain. Las copias de los mapeos del servidor maestro se almacenan en dicho directorio. Es nuestra responsabilidad como administradores asegurar que dichas copias permanecen actualizadas en todo momento. La siguiente entrada en el archivo /etc/crontab del servidor esclavo se encarga de realizar esta tarea:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
Estas dos líneas obligan al servidor esclavo a sincronizar los mapeos con el servidor maestro. Estas entradas no son obligatorias ya que el servidor maestro siempre intenta comunicar cualquier cambio que se produzca en sus asociaciones a todos los servidores esclavos ya que la información de, esclavos, ya que la información de, por ejemplo, contraseñas es de vital importancia para el funcionamiento de los sistemas que dependen del servidor. No obstante es una buena idea obligar a que se realicen estos cambios mediante las entradas anteriores. Esto resulta ser incluso más importante en redes de sobrecargadas donde las actualizaciones de asociaciones pueden algunas veces no llegar a realizarse de forma completa.
A continuación se ejecuta /etc/netstart en el servidor esclavo de igual de igual forma que se hizo con el servidor maestro; esto relanza de nuevo el servidor de NIS.
Un cliente de NIS establece lo que se conoce con el nombre de asociación (bind en inglés) con un servidor NIS NIS determinado utilizando el dæmon ypbind. ypbind comprueba el dominio por defecto del sistema (especificado mediante domainname) y comienza a enviar peticiones RPC a todos los elementos de la red local (broadcast). Estas peticiones especifican el nombre del dominio con el que se quiere establecer la asociación. Si esta petición alcanza una petición alcanza un servidor NIS configurado para servir dicho dominio el servidor responde a la petición e ypbind almacenará la dirección de dicho servidor. Si existen varios servidores disponibles (un maestro y varios esclavos, por ejemplo), ypbind utilizará la dirección del primero en responder. A partir de este punto el cliente dirigirá el resto de sus peticiones NIS directamente a la dirección IP almacenada. Ocasionalmente ypbind envía un “ping” sobre el servidor para comprobar que en efecto se encuentra funcionando. Si no se recibe contestación al ping dentro de un espacio de tiempo determinado ypbind marca el dominio como “sin asociar” y comienza de nuevo a inundar la red con la esperanza de localizar algún otro servidor NIS.
La configuración de un cliente FreeBSD de NIS resulta ser una operación extremadamente sencilla.
Editar el fichero /etc/rc.conf y añadir las siguientes líneas para establecer el nombre de dominio NIS y para que se ejecute ypbind al arranque de la red:
nisdomainname="test-domain" nis_client_enable="YES"
Para importar todas las entradas de contraseñas del servidor de NIS hay que eliminar todas las cuentas de usuario de /etc/master.passwd y utilizar vipw para añadir la siguiente línea al final de dicho fichero:
+:::::::::
Nota: Esta línea permite que cualquiera abra una cuenta en local, siempre que dicha cuenta se encuentre definida en las asociaciones de cuentas y contraseñas del servidor NIS. Existen varias formas de configurar los clientes NIS modificando esta línea. Consulte la sección sobre netgroups que se encuentra más adelante en este mismo texto. Si quiere saber más puede consultar el libro de O'Reilly Managing NFS and NIS.
Nota: Se debe mantener al menos una cuenta local (por ejemplo, una cuenta que no se importe a través de NIS) en el fichero /etc/master.passwd y además dicha cuenta debería ser miembro del grupo wheel. Si algo va mal con el procedimiento descrito esta cuenta se puede utilizar para entrar en la máquina cliente de forma remota para posteriormente convertirse en superusuario e intentar solucionar el problema.
Para importar todas las entradas de grupo posibles del servidor NIS se debe añadir la siguiente línea al fichero /etc/group:
+:*::
Después de completar estos pasos deberímos ser capaces de ejecutar ypcat passwd y ver la asociación de contraseñas que se encuentra en el servidor de 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.
Nota: Esta ruta de fichero varía dependiendo del camino especificado con la opción
-p. Dicho fichero contiene entradas compuestas de, por un lado, un rango de red y por otro una máscara de red, separados por espacios en blanco. Las líneas que comienzan por “#” se consideran comentarios. A continuación se muestra un ejemplo de un fichero “securenet”:
# 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.
Nota: Aunque ambos mecanismos de control de acceso proporcionan un grado de seguridad mayor que no utilizar nada resultan vulnerables a ataques de “falsificación de IPs”. El cortafuegos de la red donde se implanta el servicio de NIS debería encargarse de bloquear el tráfico específico de dicho servicio.
Los servidores que utilizan /var/yp/securenets pueden no prestar servicio a clientes NIS legítimos cuando se trabaja con implementaciones arcaicas de TCP/IP. Algunas de estas implementaciones ponen a cero todos los bits de máquina cuando se realizan broadcast y/o pueden fallar al especificar la máscara de red en el mismo caso, por citar algunos ejemplos. Mientras que algunos de estos problemas se pueden solucionar variando la configuración del cliente en otros casos podemos vernos obligados a prescindir del cliente en cuestión o a prescindir del fichero var/yp/securenets.
Se desaconseja la utilización de var/yp/securenets en un sistema con una implementación arcaica de TCP/IP y puede suponer una pérdida de funcionalidad para grandes zonas de la red.
La utilización del paquete tcpwrapper incrementa la latencia del servidor NIS. El retardo adicional introducido puede ser lo suficientemente grande como para causar la expiración de ciertos temporizadores de los programas clientes, especialmente en redes muy cargadas o con servidores de NIS lentos. Si se experimentan estos síntomas en varias máquinas clientes, puede ser conveniente convertir dichas máquinas en servidores NIS esclavos y obligarlas a asociarse con ellas mismas.
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 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#
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.
| Nombre del Usuario/usuarios | Descripción |
|---|---|
| alpha, beta | Empleados normales del departamento de IT |
| charlie, delta | Los nuevos aprendices del departamento de IT |
| echo, foxtrott, golf, ... | Empleados normales |
| able, baker, ... | Los actuales internos |
| Nombre de la Máquina(s) | Descripción |
|---|---|
| guerra, muerte, hambre, peste | Los servidores más importantes. Sólo los empleados de IT pueden entrar en estas máquinas |
| orgullo, avaricia, envidia, ira, lujuria, pereza | Servidores de menor importancia. Todos los miembros del departamento de IT pueden entrar en ellos. |
| uno, dos, tres, cuatro, ... | Estaciones de trabajo ordinarias. Sólo los empleados actuales pueden utilizar estas máquinas. |
| trashcan | Una máquina muy vieja sin ningún dato dato crítico. Incluso los internos pueden utilizar esta máquina. |
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. La orden 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:
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.
El nombre de la cuenta que pertenece al netgroup que estamos definiendo.
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.
Nota: No se deben utilizar nombres de los netgroups superiores a ocho caracteres, especialmente si las máquinas de nuestro dominio utilizan sistemas operativos variados. Los nombres son sensibles a las mayúsculas/minúsculas: se recomienda utilizar nombres en mayúsculas para distinguirlos de los usuarios o máquinas.
Algunos clientes de NIS (distintos de los clientes FreeBSD) no pueden gestionar netgroups con un gran número de entradas. Por ejemplo algunas versiones antiguas de SunOS comienzan a presentar problemas si un netgroup contiene más de quince entradas. Se puede solventar este problema creando varios sub-netgroups de como mucho quince usuarios y finalmente creando el verdadero netgroup compuesto por los sub-netgroups:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3Se puede repetir este proceso si se tienen que definir más de 225 usuarios dentro de un único netgroup.
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 de la primera orden debería parecerse a los contenidos del fichero /var/yp/netgroup. La segunda orden no mostrará ninguna salida salvo que se hayan especificado netgroups específicos para máquinas. La tercera orden 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, la orden cd ~ no va a funcionar, ls -l muestra el identificador numérico en lugar del nombre de usuario y 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.
AvisoAsegúrese de que la línea +:::::::::/sbin/nologin se sitúa después de +@IT_EMP:::::::::. Si esto no se cumple todas las cuentas de usuario importadas del servidor NIS poseerán /sbin/nologin como shell de acceso.
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.
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.
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.
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.
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 de la siguiente orden como root:
# cap_mkdb /etc/login.conf
Nota: El formato de las contraseñas que ya se encuentran definidas en /etc/master.passwd no se actualizará hasta que el usuario cambie su contraseña, después de que se haya reconstruido la base de datos de tipos de acceso.
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.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista
<[email protected]>.
Envíe sus preguntas sobre la documentación a <[email protected]>.