Diseño de Sistemas de Información. Un caso práctico.

Adolfo Albaladejo Blázquez1, Juan Antonio Gil Martínez-Abarca1, Juan José

Zubizarreta Ugalde1
1 Escuela Politécnica Superior, Universidad de Alicante
AP. 99, 03080, Alicante, España
{adolfo,gil,zubi}@eps.ua.es

Resumen. La fase de diseño de un sistema de información es un punto vital a la

hora de conseguir un funcionamiento óptimo del sistema informático. En este
artículo se estudia un caso práctico de implantación de un sistema de
información con una estructura compleja, como es la de los laboratorios
informáticos de la Escuela Politécnica Superior de la Universidad de Alicante.
Se parte del estudio general de la red, para a continuación, revisar la estructura
física actual. Posteriormente se realizará la propuesta de implantación del
Sistema de Información. En este caso se propondrá la implantación de servicios
de Base de Datos, LDAP, DNS y DHCP. Finalmente se comprobarán los
resultados obtenidos y el grado de satisfacción en cuanto a objetivos
alcanzados.

Introducción

La estructura física de un sistema de información, así como su diseño de red, son dos
factores relevantes en el diseño e implementación de un sistema informático [1]. En
este artículo, los primeros pasos a seguir se encaminan, precisamente, al estudio del
diseño y la estructura física de nuestro sistema, para obtener una visión real y
pormenorizada de la estructura de red de los laboratorios informáticos de la Escuela
Politécnica.

Situación y entorno
La Escuela Politécnica Superior –EPS-, perteneciente a la Universidad de Alicante,
consta de dos edificios conectados entre sí por la red troncal de la universidad,
gestionada ésta por el servicio de informática de la universidad que actúa, desde el
punto de vista de la escuela, como proveedor de servicio de red. Tanto la
característica distribuida de la red, como la interconexión por medio de una troncal
potencialmente insegura, deben ser consideradas en su diseño [2].
Figura 1. Situación y entorno de la EPS

Diseño general de la red

Independientemente de cual sea el edificio de la EPS del que se hable, existirán
laboratorios de ordenadores y servicios para la gestión de éstos. Además, existen
otros servicios a los que se puede acceder desde cualquier otro lugar de Internet (web,
correo,…) no relacionados, directamente, con los laboratorios informáticos. Con estas
características, se distinguen 3 tipos de redes: las destinadas a los laboratorios; las de
servicios para la gestión de laboratorios; la de servicios externos. Por otra parte,
existe una red más destinada a los técnicos informáticos encargados del servicio.
En la figura 2 se puede apreciar las distintas redes mencionadas, de las que dos son
consideradas como potencialmente peligrosas y a las que se ha tenido especialmente
en cuenta en el momento del diseño: la extranet (en este caso la red de la Universidad
de Alicante), y la red de laboratorios.
La interconexión de las distintas redes se realiza mediante un router externo con
filtrado de paquetes desde y hacia la Universidad, tras el cual situamos otro router
con filtro de paquetes y gestión de VLAN’s que realiza, entre otras funciones, tareas
de traslación de direcciones –NAT-
Para cada red, se define una VLAN con el objetivo de segmentar los dominios de
difusión. Así, la zona desmilitarizada -zona de servicios de acceso externo separada
de la red interna [3- se encuentra asociada a una VLAN independiente y, en ella, se
conectan todos los servidores accesibles desde el exterior.
Además, se dispone de dos routers internos más, conectados con el firewall, que
también realizan tareas de filtrado de tráfico IP y gestión de VLANS. El primero de
ellos gestiona dos VLAN’s, una de servidores internos, y otra de equipos de
administración. Mediante ACLS’s, se tiene permiso de acceso a la VLAN de los
servidores internos desde la VLAN de administración. De hecho, desde la VLAN de
administración se tiene acceso a todas las VLAN’s tanto internas, como a la de
servidores externos (todos los permisos serán gestionados mediante las ACL’s de los
routers).

Figura 2. Diseño de la red en la Politécnica I

Figura 3. Diseño de la red en la Politécnica IV

El segundo router interno administra el grupo de VLAN’s destinadas a los

laboratorios. En concreto, gestiona una VLAN independiente por cada uno de los
laboratorios existentes y, mediante ACL’s, denegará el acceso a cada VLAN desde
todas las demás, excepto desde la de administración.
 El diseño de la red para el edificio Politécnica IV, como se puede observar en la
figura 3, es similar al de la Politécnica I, con la particularidad de que en este edificio,
no hay red de servicios externos.
En este caso, sólo se dispone de un router que, además de filtrar el tráfico de
paquetes desde-hacia la Universidad, también gestiona mediante VLAN’s dos zonas
separadas: una zona desmilitarizada donde se instalan los servidores y otra zona de
laboratorios potencialmente insegura. Mediante ACL’s se restringe el acceso a la
zona de servidores desde los laboratorios, al tiempo que se permite el acceso desde la
zona desmilitarizada de la Politécnica I, con el fin de que ambas zonas de servidores
puedan intercambiarse información.

Estructura física
Es imprescindible conocer la estructura física de nuestro sistema informático antes de
diseñar el Sistema de Información. La distribución de los edificios supone un punto
importante a tener en cuenta que conlleva un estudio minucioso en cuanto a la
elección y diseño del sistema de información.

Figura 4. Estructura de la red de la Politécnica I

Dentro del edificio Politécnica I se dispone de una gran cantidad de clientes con
necesidad de acceso a los datos, agrupados en laboratorios, y separados por plantas.
Cada planta presenta una estructura en estrella jerárquica compuesta por
conmutadores de 10Mbps y 100Mbps y un router de conexión a la red interna al que
se conectan todos los conmutadores mediante conexiones 100BASETX. Los
conmutadores de 10Mbps se destinan a las redes de los laboratorios mientras que los
de 100Mbps y los puertos de los routers de planta se dedican a las redes de servicios
internos y externos que principalmente están destinados en la segunda planta del
edificio.
Figura 5. Estructura de la red de la Politécnica IV

Por otra parte, todos los router están interconectados de forma mallada todos con
todos mediante conexiones de fibra óptica multimodo 1000BASESX para el
intercambio de información entre ellos. Además se dispone de un router específico
para dar salida hacia el exterior -red de la Universidad-, conectado al router de la
planta primera también mediante una conexión de fibra óptica multimodo
1000BASESX.

Figura 8. Red de Administración

En la tercera planta del edificio Politécnica I existe una subred para tareas
administrativas, compuesta por servidores accesibles únicamente desde la propia
subred, y equipos de control y desarrollo de software conectada a un conmutador
mediante conexiones 100BASETX. Estos servidores se utilizan básicamente para
poder realizar todas las pruebas en el desarrollo de aplicaciones software. Desde esta
subred se podrá acceder a todas las subredes de servidores para su control y
mantenimiento.
 La estructura física de la red del edificio Politécnica IV es similar a la de la
Politécnica I. Se estructura mediante una estrella jerárquica cuya raíz es un router al
que se conectan los conmutadores de cada planta mediante conexiones 100BASETX.
La red de este edificio se compone de dos laboratorios y una zona de servidores
accesibles exclusivamente desde los laboratorios del edificio y desde la Politécnica I.

Estado de la tecnología
Existe gran variedad de software disponible en el mercado, tanto libre como de pago,
para las distintas aplicaciones que dan soporte al sistema de información
Para bases de datos podemos encontrar desde software libre como Mysql [5],
rápida, muy ligera y sencilla, utilizada sobre todo con servidores Web, donde se
realizan muchas consultas e inserciones sencillas; PostgreSQL [4], más potente y
pesada que Mysql, gana en prestaciones lo que pierde en velocidad de ejecución, por
lo que es más apta para procesos con transacciones y, por último, productos
comerciales como Oracle [6], DB2 [7], SQL Server [8] que incluyen mucha más
funcionalidad, características avanzadas e interfaces que las de software libre a
cambio del precio. etc.
La cantidad de software LDAP no es tan importante, pero suficiente como para
poder escoger entre: software libre como OpenLDAP [9], muy utilizado por tener
muy buenas prestaciones; Netscape Directory Server [10] que, además, incluye una
interfaz muy potente e intuitiva y una gestión muy sencilla y eficaz de replicación de
datos y, como un segundo servidor de directorio no libre, Active Directory [8] cuyo
principal inconveniente está en que, para el control de usuarios, realiza más funciones
que lo convierten en un producto no estándar, como sí son los dos anteriores.
En cuanto a software para DNS el más importante, utilizado y reconocido (además
de ser libre) es bind (Berkeley Internet Name Domain) [11]. Para software de
asignación dinámica de IPs, uno de los servidores DHCP más importante y utilizado
es ISC DHCP versión 3 [11], también software libre.
La decisión a tomar vendrá condicionada tanto por el aspecto económico (es una
gran ventaja del software libre), como por el rendimiento esperado y las
características técnicas de cada producto.

Propuesta de implantación

La implantación de un sistema de información estará condicionada por las

necesidades y objetivos que se pretenden conseguir con él [12]. En el caso de la EPS,
las necesidades básicas que debe cubrir el sistema de información son:
ƒ Gestión de los laboratorios relacionada con el mantenimiento y uso, como por
ejemplo el inventario de los equipos, los horarios de clase, reserva, control de
acceso, …
ƒ Servicios de red , como por ejemplo, salida a Internet controlada, servicios de
nombre de equipos, …
ƒ Aplicaciones de apoyo a la docencia práctica como por ejemplo gestión de
turnos de prácticas, matriculación y entrega de prácticas, …
 ƒ Aplicaciones de gestión del centro como por ejemplo la administración de
prácticas en empresa, de tablón de anuncios de la secretaría del centro, …
Por otra parte, los objetivos que debe abarcar el sistema de información, incluye,
entre otros, los siguientes:
ƒ Autenticación integrada de los clientes, independientemente del sistema
operativo utilizado, ubicación del equipo, o tipo de acceso (Web, máquina
local), siendo única y realizada de manera segura (la información debe viajar
encriptada). Esta autenticación nos permitirá tener control por cada usuario sin
importar el equipo ni el lugar desde el que se conecte en cada momento.
ƒ Alta disponibilidad del servicio, pudiendo obtener una respuesta continua a
pesar de la caída de cualquier servidor o router.
ƒ Equilibrados de carga, permitiendo una mejor respuesta de los servidores ante
una cantidad importante de peticiones.

Servidores LDAP
El software escogido para el servicio de LDAP es Netscape Directory Server de Sun
en su versión 4.1 bajo el sistema operativo Solaris -funciona sensiblemente mejor
bajo el sistema operativo de la propia Sun-. Este software dispone de una completa e
intuitiva consola de administración, al tiempo que obtiene buenos tiempos de
respuesta en las consultas, y además incluye un sistema de replicación en tiempo real
sencillo y efectivo.
Para poder realizar la autenticación de todos los clientes tenemos un servidor LDAP
principal, dentro del grupo de servidores externos, que se utilizará únicamente para
realizar las actualizaciones y replicar los datos a los consumidores -servidores LDAP
secundarios que contienen copias del servidor principal-. Dentro del edificio
Politécnica I realiza una réplica de sus datos a cuatro servidores LDAP idénticos, y a
un servidor que actúa como copia de seguridad preparado para suplantar al servidor
principal de LDAP, en caso de caída de éste. Esta réplica se realiza sin encriptación
de datos ya que se realiza dentro de zonas seguras -desde la red interna segura hasta
la zona desmilitarizada- con lo que introducir encriptación sólo serviría para
ralentizar las transacciones.
En el caso de la Politécnica IV, para que los clientes se autentiquen con el mismo
mecanismo que el los laboratorios de la Politécnica I. se optó por introducir dos
servidores LDAP secundarios para optimizar el proceso de autenticación accediendo
a servidores locales en vez de remotos y que se actualicen con una réplica de los
datos del servidor principal.
La réplica de los datos en este caso, tiene un problema de seguridad, ya que la
comunicación atraviesa zonas ‘no seguras’ como es la red troncal de la Universidad.
Por ello, se optó por instalar una comunicación segura mediante un túnel entre los dos
servidores e implementado con IPSEC. La configuración de IPSEC se realiza entre
servidores, y no entre redes, ya que de este modo aseguramos la conexión
completamente de un extremo a otro de la comunicación. Una vez configurado
IPSEC, podemos transmitir cualquier información entre ellos y se usará, así, para
todas las transmisiones de información entre los dos servidores.
Figura 9. Replicación LDAP en la Politécnica I

Figura 10. Replicación LDAP en la Politécnica IV

Autenticación de los clientes

Todos los clientes de la Politécnica se autentican, tanto en Linux como Windows -los
dos sistemas operativos instalados- contra un servidor LDAP. En el caso de Linux, se
configuran las PAM para validar usuarios en un servidor LDAP, y en el caso de
Windows, se utiliza una librería dinámica “Pgina” [13], que nos permite realizar la
misma función y es un software de libre distribución. Estas autenticaciones se
realizan de forma encriptada con SSL, ya que la comunicación se realiza en zonas
potencialmente inseguras como son las redes de los laboratorios.
En el caso de la Politécnica I, no lo hacen directamente sobre el servidor principal
-utilizado sólo para las actualizaciones-, sino sobre los cuatro servidores LDAP
secundarios. De esta manera se deja libre de esta carga de peticiones al servidor
principal, que se encargará únicamente de recibir las actualizaciones, que sólo se
podrán realizar desde la aplicación web desarrollada para ello, y replicar las mismas a
los secundarios; un dato importante a tener en cuenta que en el uso de un servidor
LDAP, el porcentaje de actualizaciones con respecto a las consultas es muy bajo.
Dada la gran cantidad de clientes se optó por tener varios servidores LDAP
disponibles y equilibrar la carga de peticiones entre los cuatro. Este equilibrado o
balanceo lo realiza el router de planta. Por ello los clientes están configurados para
realizar la petición de autenticación sobre el router, que redirige la petición a uno de
los servidores secundarios. Ante algún problema con alguno de los servidores, el
router lo elimina de la lista de balanceo hasta la resolución del problema.
Además se configuran los tres routers internos con el protocolo VRRP (protocolo
de comunicación entre routers, que ordena y decide cuál de ellos actuará como
gateway de los clientes), para aumentar la disponibilidad, consiguiendo que no se
interrumpan las comunicaciones a pesar de la caída de cualquiera de ellos.

Figura 11. Autenticación en la Politécnica I

En la Politécnica IV los clientes de los laboratorios realizan la autenticación sobre

su servidor LDAP local. Sólo se utiliza un servidor para responder las peticiones de
autenticación, ya que la cantidad de clientes -únicamente dos laboratorios- suponen
una carga de peticiones pequeña. La disponibilidad no es automática ya que, en el
caso de este edificio, se basa en la posibilidad de interactuar con el segundo servidor
secundario que se configuró, aunque la suplantación de identidad no es automática.
En ningún caso los clientes pueden modificar sus datos en el LDAP -estos servidores
réplicas sólo conceden acceso de lectura- desde el propio sistema operativo. Para
poder modificar datos del usuario se debe hacer en el servidor principal, desde el que
sólo se podrá acceder por Web mediante una aplicación web específica para esta
función, que no se realiza mediante un protocolo seguro puesto que no atraviesa redes
inseguras.
Figura 12. Autenticación en la Politécnica IV

Figura 13. Autenticación Web

Servidores de base de datos

El software utilizado como servidor de base de datos es Mysql en su versión 4.0.17
bajo el sistema operativo Linux. Es una base de datos de extrema sencillez, pero muy
apta, por su rapidez, para uso en el web, con muchas consultas e inserciones simples.
Además, incluye la posibilidad de replicación entre bases de datos en tiempo real.
La base de datos principal se encuentra dividida en dos. Una base de datos con
información accesible desde los clientes de laboratorios y otra con información
interna, sólo accesible desde los servidores Web. Ambas se encuentran en servidores
diferentes y cada uno de ellos en una red distinta, con filtros diferentes.
La base de datos externa se encuentra replicada en otro servidor sito, por motivos de
rendimiento, en la Politécnica IV y con filtros que garanticen que sólo los clientes de
los laboratorios de este edificio se conectan a este gestor de base de datos.
Además, como copia de seguridad, las dos bases de datos, interna y externa, se han
replicado en otro servidor que, en caso de caída, suplantaría al servidor de base de
datos caído mientras dure el problema. Estas copias se mantienen actualizadas en
tiempo real mediante la replicación de las bases de datos proporcionada por el propio
software de MySQL. Se realiza sin encriptación, pero como en el caso de la
replicación de los servidores LDAP, no es necesaria ya que atraviesa ‘zonas seguras’
y sólo ralentizaríamos las comunicaciones, salvo para la replicación de la base de
datos interna en el servidor de la Politécnica IV. Para este caso, se dispone de un
túnel implementado con IPsec tal y como se ha descrito en el apartado LDAP.

Figura 14. Replicación BD en la Politécnica I

Figura 15. Replicación BD en la Politécnica IV

Acceso a las bases de datos

Como se ha comentado anteriormente, el acceso de los clientes sólo es permitido a la
base de datos externa. Por ello, todos los clientes pueden acceder directamente a la
base de datos del servidor, aunque en la práctica, estos accesos no lo hacen los
usuarios sino aplicaciones internas de la EPS.
Figura 16. Acceso a BD en la Politécnica I

Todos los accesos desde los clientes de los laboratorios se encriptan con SSL por
los mismos motivos que la autenticación. Así mismo, el protocolo VRRP asegura la
disponibilidad del servicio.

Figura 17. Acceso a BD en la Politécnica IV

En la Politécnica IV acceden los clientes (las aplicaciones internas de la EPS

instaladas en los clientes) a su servidor con su réplica de la base de datos interna. Al
igual que el LDAP, en caso de caída, los clientes accederían al servidor de copia
mientras se soluciona el problema.
En cuanto al acceso a la base de datos interna, sólo se permite desde los servidores
web y se realiza sin encriptación para evitar retardos -atraviesa zonas seguras-.
Figura 18. Acceso a BD desde el Web

Servidores DNS
El software utilizado es bind en su versión 9 bajo el sistema operativo Linux, al ser el
más utilizado y reconocido, además del aspecto económico ya que se trata de
software libre.
En la EPS se dispone de un servidor que realiza la función de DNS primario. Con
objeto de aumentar la disponibilidad y el rendimiento del servicio, se dispone también
de cuatro servidores DNS secundarios.
En la Politécnica IV se dispone de dos servidores DNS secundarios. La utilización
de estos servidores DNS desde los equipos de este edificio optimiza los tiempos de
respuesta, al no tener que acceder a la Politécnica I. El método de replicación para los
secundarios es el utilizado por el propio protocolo DNS, la transferencia de zonas
[14].
Como para el resto de servicios, la replicación en la Politécnica I no necesita
encriptación ya que ésta se realiza dentro de una red segura. En el caso de la
replicación a la Politécnica IV, se volverá a utilizar la conexión IPSEC para asegurar
una replicación encriptada.

Figura 19. Replicación DNS en la Politécnica I

Figura 20. Replicación DNS en la Politécnica IV

Acceso al servicio de DNS

El acceso de los equipos al servicio DNS no se realizará en ningún caso sobre el
servidor principal, que únicamente se usará para la actualización y replicación de los
datos, sino sobre los servidores DNS secundarios. Esta política se gestiona mediante
filtros establecidos a nivel de red mediante los routers y a nivel de aplicación
mediante la correcta configuración del servicio para que sólo admita peticiones de los
clientes internos del edificio.

Figura 21. Acceso al servicio de DNS en la Politécnica I

En el caso de la Politécnica I, ni siquiera se realizarán peticiones directas a los

servidores secundarios, sino sobre el router de planta, que realizará la función de
director, balanceando las peticiones entre los cuatro secundarios. Esta estructura se
diseñó para la alta disponibilidad y no con el fin de equilibrar tráfico DNS ya que las
peticiones DNS no suponen un exceso de carga relevante. El router asegura que la
petición la reenvía siempre a un servidor disponible ya que se encarga de eliminar del
balanceo aquel servidor que no le responda. Esta estructura nos evitará el clásico
retardo en el servicio cuando el primer servidor DNS no se encuentra disponible.
Para la politécnica IV, no es posible tener la misma estructura, ya que no se
dispone de un router (u otro servidor) para que realice el balanceo -el router de acceso
a la red de la Universidad es ajeno a la gestión de la Politécnica-. Sus equipos
intentarán conectarse a los servidores DNS secundarios locales con lo que el tiempo
de respuesta será mejor que si tuviesen que acceder a la Politécnica I. Sin embargo,
en caso de tener problemas con el primer servidor DNS, se tendría que esperar un
retardo hasta descartar el servidor, y enviar la petición al segundo.

Figura 22. Acceso al servicio de DNS en la Politécnica IV

Servidores DHCP
Se dispone de un servicio de DHCP con el fin de poder facilitar el mantenimiento de
la configuración de la red de todos los equipos [15]. El software utilizado para ello es
Dhcp en su versión 3 que, como el software bind para el DNS, es el más utilizado y
reconocido, además de ser libre.
Se dispone de un servidor principal DHCP que contiene los datos de configuración
de red de todos los equipos, aunque no da servicio como tal, sino que se utiliza con el
fin de actualizar los datos y replicar la información a un grupo de servidores DHCP
secundarios, que son los que atenderán las peticiones DHCP.
En concreto se utilizan cuatro servidores DHCP secundarios para la Politécnica I,
y dos más para la Politécnica IV.
El protocolo DHCP no define ningún tipo de replicación de datos entre servidores,
por lo que la replicación del servidor principal se realizará mediante un guión propio
que copia el fichero de configuración donde reside toda la información necesaria al
resto de los servidores.
Figura 23. Replicación DHCP en la Politécnica I

Como en el resto de los servicios, la replicación en la Politécnica I no necesita

encriptación, mientras que la replicación a la Politécnica IV necesitará el uso de
IPSEC para asegurar una transmisión encriptada de la información.

Figura 24. Replicación DHCP en la Politécnica IV

Acceso al servicio DHCP

Para poder obtener los datos de la configuración de red, cada equipo enviará una
petición DHCP al broadcast. En la Politécnica I, esta petición será recibida por su
router por defecto -mediante VRRP cualquier router puede serlo ante problemas con
su router de planta- que debe estar configurado para tomar la petición DHCP y
enviarla a los servidores DHCP existentes (Relay DHCP).
Todos los routers están configurados para tomar las peticiones DHCP de cualquier
equipo en cualquier laboratorio, y enviar la petición a los cuatro servidores DHCP
secundarios. La respuesta de los servidores DHCP será devuelta por el router a la
subred del laboratorio origen.
En la Politécnica IV se realizan idénticos pasos. Las peticiones provenientes de los
equipos de los laboratorios llegarán hasta el router por defecto -el único router de la
Politécnica IV- que está configurado como los de la Politécnica I, es decir, mediante
Relay DHCP toma las peticiones y las envía a los dos servidores DHCP.
Posteriormente, recogerá las respuestas de los servidores, que serán devueltas al
laboratorio desde el que se enviaron.

Figura 25. Acceso al servicio DHCP en la Politécnica I

Figura 26. Acceso al servicio DHCP en la Politécnica IV

Conclusiones

La instalación del sistema de información: bases de datos, LDAP, DNS y DHCP

consigue alcanzar los objetivos buscados, ya que:
ƒ Se tiene un único servidor con todos los datos centralizados para todos los
servicios de información.
ƒ Se consigue, a través de las replicaciones, que las peticiones sean atendidas
por servidores locales, minimizando los tiempos de respuesta, así como
aumentar la disponibilidad del servicio ante la caída de algún servidor.
ƒ Mediante el equilibrado de carga de peticiones entre varios servidores se
consigue disminuir los tiempos de respuesta.
ƒ Todas las comunicaciones cliente-servidor o servidor-servidor (replicaciones)
que se realizan a través de redes potencialmente inseguras, se realizan de
manera encriptada mediante técnicas como IPSEC o SSL.
ƒ La configuración del protocolo VRRP en los router aumenta la disponibilidad
ante caídas de cualquiera de los routers internos (los routers de salida hacia la
red de la Universidad de los dos edificios no son gestionados directamente por
la EPS).
El software utilizado cumple con las expectativas, ya que tanto Mysql como
Netscape Directory Server, bind y dhcp obtienen rápidos tiempos de respuesta (es la
mayor prioridad en cuanto a las necesidades en los clientes) así como un sencillo y
efectivo sistema de replicación de datos (en el caso de bind, la replicación la
incorpora el propio protocolo DNS) excepto para el caso de dhcp. En el caso de
Mysql, bind y dhcp, se une a esto que además el software es gratuito.
Como trabajos futuros, y con el objetivo de controlar también el ámbito de acceso
por red que tenga cada usuario (sin red, subred local, acceso total, etc.), se estudiará
la implantación de un servidor RADIUS [16], que se integre totalmente dentro de
nuestro sistema, validando los usuarios contra nuestro servidor LDAP.
Además se estudiará la posibilidad de unificar todos los tipos de acceso desde una
misma máquina: acceso local al sistema operativo, acceso a la red (RADIUS), acceso
a las aplicaciones Web, evitando múltiples validaciones del mismo usuario.

References

1. Factbook. Tecnologías de la Información. CAP GEMINI, SAP. Aranzadi & Thomson

(2001).
2. Information System. A Management Perspective. Steven Alter. The
Benjamin/Cumming Publishing Company, Inc. 2ª edición (1996).
3. Building Secure Servers with Linux. Michael D. Bauer. O’Reilly (2003).
4. http://www.postgresql.org
5. http://www.mysql.org
6. http://www.oracle.com
7. http://www.ibm.com
8. http://www.microsoft.com
9. http://www.openldap.org
10. http://www.sun.com
11. http://www.isc.org
12. Análisis y Diseño de Sistemas de Información. James A. Senn. MacGraw-Hill. 2ª
edición (1992).
13. http://pgina.xpasystems.com
14. DNS & BIND Cookbook. Cricket Liu. O’Reilly (2003).
15. TCP/IP. Dr. Sidnie Feit. McGraw-Hill (1998).
16. Diseño de seguridad en redes. Marine Kaeo. Cisco Press (2003).