UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA VALPARAÍSO – CHILE “ESTUDIO E IMPLEMENTACIÓN DE NUEVO SISTEMA DE AUTENTICACIÓN PARA EL DEPARTAMENTO DE ELECTRÓNICA” BRAULIO JAVIER VÁSQUEZ CHEPILLOS MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE: INGENIERO CIVIL TELEMÁTICO PROFESOR GUÍA: AGUSTÍN GONZÁLEZ V. PROFESOR CORREFERENTE: NICOLÁS JARA CARVALLO JUNIO 2011
116
Embed
ESTUDIO E IMPLEMENTACIÓN DE NUEVO SISTEMA DE · PDF fileLos servicios de autenticación y directorio basados en el protocolo LDAP, ... (Secure- File Transfer Protocol), ... de los
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA
VALPARAÍSO – CHILE
“ESTUDIO E IMPLEMENTACIÓN DE NUEVOSISTEMA DE AUTENTICACIÓN PARA EL
DEPARTAMENTO DE ELECTRÓNICA”
BRAULIO JAVIER VÁSQUEZ CHEPILLOS
MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE:
INGENIERO CIVIL TELEMÁTICO
PROFESOR GUÍA: AGUSTÍN GONZÁLEZ V.
PROFESOR CORREFERENTE: NICOLÁS JARA CARVALLO
JUNIO 2011
2
A mis padres, quienes por su entrega y amor
han hecho que parte de mi proyecto de vida se haya cumplido.
A mis amigos, que con su apoyo incondicional lograron
reducir gran parte de las adversidades surgidas en este periodo.
A los que hoy no están con nosotros, quienes gracias a su apoyo
terrenal y divino cada día protegen a este ser.
3
Estudio e implementación de nuevo sistema de autenticación
para Departamento de Electrónica
Memoria para optar al título de Ingeniero Civil Telemático
Braulio Javier Vásquez Chepillos
Profesor Guía: Agustín González
Junio 2011
Resumen
El objetivo principal de este trabajo es realizar un estudio y análisis sobre aplicaciones
que den servicio de directorio, autenticación, y acceso remoto para los usuarios del
Departamento de Electrónica de Universidad Técnica Federico Santa María.
Los servicios de autenticación y directorio basados en el protocolo LDAP, son utilizados
en una gran cantidad de instituciones que entregan espacios de alojamiento de información y
cuentas de identificación. Con ellos es posible acceder a los sistemas disponibles mediante la
utilización de una cuenta única, permitiendo una mejor integración entre aplicaciones Web,
acceso a estaciones de trabajo y uso de las aplicaciones disponibles en servidores dedicados.
Otro de los aspectos a mejorar en el Departamento es la forma de cómo los usuarios
acceden a los servicios de manera remota. Esta posibilidad entrega un sin fin de beneficios para
quienes hacen uso de las herramientas computacionales constantemente, ya que es posible
obtener direcciones IP de la red remota, montar los discos virtuales asignados y utilizar
programas que se encuentran habilitados con este motivo, como por ejemplo, servidores de
licencias.
Para resolver los requerimientos anteriores, se hicieron estudios y análisis de las
aplicaciones disponibles en el mercado para cada uno de los servicios mencionados, es decir,
servicios de autenticación y de acceso remoto. Para el primero se estudió la posibilidad de
utilizar Active Directory u OpenLDAP, donde su diferencia principal radica en que la primera es
privativa, en cambio la última es código abierto. Además para éste caso se entrega un plan de
migración e implementación para la Red de Electrónica, utilizando la tecnología que mejor se
acomode. En cambio para los sistemas de acceso remoto se entregarán recomendaciones de qué
tecnología utilizar a futuro, analizando OpenVPN y sistemas de ventanas X.
1.1 Problemática y Objetivos ............................................................................................................... 7
2.Estado del Arte ................................................................................................................................... 10
2.1 Situación en Chile ........................................................................................................................ 10
2.2 Situación en el mundo .................................................................................................................. 11
Anexo 1 Aspectos Avanzados del Protocolo LDAP ............................................................................... 83
Anexo 2 Instalación y Configuración de OpenLDAP 2.3 y Samba 3.4 sobre FreeBSD 7.2 ..................... 89
Anexo 3 Integración de SSH con OpenLDAP, mediante PAM ............................................................. 101
Anexo 4 Agregando máquinas al dominio LDAP/Samba ..................................................................... 104
Anexo 5 Instalación y Configuración del Servidor de Correo .............................................................. 107
Anexo 6 Códigos Fuentes de Sitios Web de Autenticación ................................................................... 112
Anexo 7 Códigos Fuentes para la Migración de Usuarios desde NIS+ a OpenLDAP ............................ 115
6
Capítulo 1
Introducción
Hoy en día, las redes de computadores se encuentran en una constante evolución debido
al alto impacto que éstas generan en una estructura organizacional determinada. Tanto en
empresas, como en instituciones educacionales, se ha vuelto una necesidad el mantenerse al día
con respecto a nuevas aplicaciones que imponen un uso eficaz de los recursos existentes en estos
lugares.
En muchas ocasiones, es posible encontrarse con errores y problemas de seguridad dentro
de una red, más aún si está sujeta a procesos de escritura y lectura durante intervalos de tiempo
prolongado. Esto puede llevarla a ser vulnerable a posibles ataques informáticos, obteniendo
como consecuencia la adquisición de datos privados, como también el envío de información
maliciosa. Lo anterior, ocurre principalmente por el hecho de no contar con las herramientas
necesarias para poder prever los ataques mencionados. Uno de los errores comunes que cometen
estas entidades, es la desactualización que existe tanto en software como en hardware,
manteniendo una estructura de red conforme a los requerimientos de los usuarios, ya que se les
entregan todos los servicios que éstos puedan prescindir, pero limitando a un uso óptimo de los
recursos.
Un aspecto importante en una red del tipo institucional es la cantidad de servicios que
ésta pueda prestar a los usuarios involucrados en su uso cotidiano. Para ello, se listarán algunos
de los cuales resultan ser comunes, pero de vital importancia para un funcionamiento eficiente de
los sistemas implementados.
Autenticación de Usuarios: Servicio de vital importancia al momento de querer
administrar y monitorear a los usuarios de una red. Este tiene que ser altamente fiable,
soportar con éxito ataques maliciosos y ser aceptable para los usuarios. La mayor parte
de los sistemas de redes mantienen una relación de identidades personales (usuarios)
asociadas normalmente con un perfil de seguridad, roles y permisos. El proceso de
autenticación permite a estos sistemas asumir con una garantía razonable que quien se
está conectando es quien dice ser, para que luego las acciones que se ejecuten en el
sistema puedan ser referidas a esa identidad y aplicar los mecanismos de autorización.
Acceso Remoto a Cuenta: Al momento en que un usuario está fuera del dominio de la
red, es posible acceder remotamente desde una máquina local. Comúnmente, en
ambientes Unix/Linux, se utilizan protocolos de accesos tales como Secure Shell (SSH),
FTP (File Transfer Protocol), SFTP (Secure- File Transfer Protocol), pero la idea es
mantener total transparencia al momento de acceder a los datos ubicados en servidores
externos.
Proveer Servicio Web: Si los usuarios poseen capacidad de almacenamiento, éstos
deben poder crear sitios web para los fines que se estime conveniente. Es por eso que es
7
necesaria la implementación de diversas tecnologías web, que permitan la creación de
sub-sistemas bajo el dominio en que se encuentran.
Existe una variedad de aplicaciones, que ayudan a satisfacer estos requerimientos, pero
que difieren en aspectos como el pertenecer al grupo de software open source, libre o privativo.
Entre ellos es posible mencionar algunos como:
Active Directory [1.1]: Implementación de Microsoft para ofrecer servicio de directorio en una
red distribuida de computadores. Utiliza una serie de protocolos tales como LDAP, DNS y
DHCP. Su estructura jerárquica permite mantener una serie de objetos relacionados con
componentes de red, como usuarios, grupos de usuarios, permisos y asignación de recursos y
políticas de acceso. Su funcionamiento es similar a otras estructuras de LDAP, ya que este
protocolo viene implementado como una base de datos, la cual almacena en forma centralizada
toda la información relativa a un dominio de autenticación. La ventaja que presenta esto es la
sincronización entre los distintos servidores de autenticación de todo el dominio.
OpenLDAP [1.2]: Es una implementación libre y de código abierto del protocolo LDAP
desarrollada por el proyecto OpenLDAP. Este protocolo se encuentra a nivel de aplicación y
permite el acceso a un servicio de directorio ordenado y distribuido para buscar información
diversa en un entorno de red. LDAP también es considerado una base de datos jerárquica a la que
pueden realizarse múltiples consultas.
Un directorio es un conjunto de objetos con atributos organizados en una manera lógica y
jerárquica. En cambio un árbol de directorio LDAP puede reflejar varios límites políticos,
geográficos u organizacionales, dependiendo del modelo elegido. Los despliegues de LDAP
tienden a usar nombres de Sistemas de Nombre de Dominio o DNS para estructurar los niveles
más altos de la jerarquía. Conforme se desciende en el directorio pueden aparecer entradas que
representan personas, unidades organizacionales, impresoras, documentos o cualquier cosa que
representa una entrada en el árbol.
1.1 Problemática y Objetivos
El departamento de Electrónica de la Universidad Técnica Santa María cuenta con un
sistema de administración de red el cual entrega una gran cantidad de servicios a sus profesores,
alumnos y funcionarios. Principalmente, la estructura está formada por un sistema de
autenticación bajo el software libre NIS+, el que permite mantener registro de todos los usuarios
participantes en la red mediante una arquitectura cliente/servidor. Esta tecnología se encuentra
instalada en “Lucas”, servidor que tiene como propósito permitir el correcto funcionamiento de
este servicio.
Tanto profesores como alumnos poseen servidores distintos, en los que están instaladas
aplicaciones que permiten un uso eficiente de la red. Por ejemplo, es posible la creación de base
de datos, el levantamiento de sitios web bajo el dominio del Departamento de Electrónica, acceso
remoto mediante el protocolo SSH, con exportación de ventanas X, entre otros. Además, hay una
amplia cantidad de asignaturas impartidas que exigen la utilización del servidor “Aragorn”, en
8
donde se pueden realizar procesos de compilación y depuración en diversos lenguajes de
programación, tales como C/C++, Java, Perl, y otros. También es posible la utilización de
programas de simulación como Matlab. Todo esto, ha llevado a que los usuarios realicen la
mayoría de sus actividades académicas en base a los sistemas informáticos que el departamento
ofrece.
Dado los requerimientos existentes, es necesaria una actualización referente a los
servicios que el Departamento de Electrónica entrega a sus usuarios. Para ello, se presentan
diversas tecnologías que serán estudiadas, ya que son utilizadas para ofrecer servicios de redes
en entidades con objetivos similares. A continuación se mencionarán los requerimientos
principales que un sistema de red de alto rendimiento, como el utilizado en el Departamento de
Electrónica, debe ser capaz de satisfacer.
Acceso a Servidores y sus servicios: Como se ha planteado, existen múltiples servidores los
cuales tienen tareas específicas a cumplir. Entre ellos se encuentra “Lucas”, con el sistema
operativo Solaris 8, encargado de la autenticación de los usuarios de la red; el servidor “Vega”,
destinado al sitio web del departamento contiene todo el almacenamiento referente a este
servicio y los sitios web de cada una de las asignaturas; “Aragorn”, utilizado por los alumnos, se
encuentra bajo el sistema operativo Debian 2.4 y se comunica a través de un puente (switch)
hacia Lucas para así obtener los registros de las cuentas de cada uno de los alumnos según año
de ingreso a la carrera, pero todo el procesamiento de información que el estudiante realiza se
manipula en “Aragorn”. Para el caso de los profesores, es el servidor “Deneb” el que almacena
todas las cuentas.
El proceso común con que un usuario ingresa a cada una de las máquinas (sujeto a los
permisos adquiridos), es a través de SSH donde se obtiene acceso a un terminal para así poder
realizar procesos de lectura/escritura dependiendo de la situación. En el caso de los alumnos,
éstos pueden almacenar material académico en sus cuentas, y así mantenerlos en la red.
Uno de los requerimientos planteados al realizar este estudio, es la obtención de una
única cuenta de usuario para el uso de la mayoría de los servidores, dependiendo de los permisos
otorgados. En la actualidad, al momento que un alumno pasa a ser parte de las carreras de
Ingeniería Civil Electrónica/Telemática, se procede a la creación de una cuenta, para lo cual él
debe dirigirse a la administración de la red para su activación. Ésta es del tipo Unix, la que a
través de Samba puede ser utilizada en las estaciones con Windows que se encuentran bajo el
dominio ELONT. La idea es que a la vez permita usarse para todos los servicios presentes en el
Departamento de Electrónica.
Dualidad de Sistemas Operativos: Los laboratorios de la Red de Computadores de Electrónica
(RCE), en su mayoría, se encuentran con el sistema operativo Microsoft Windows XP. La idea
de este tópico es poder incentivar a los alumnos el uso de Linux, dado que el mercado laboral así
lo requiere. Para ello es necesaria la estadía de ambos sistemas permitiendo su ingreso a través
de la cuenta única anteriormente mencionada.
Como en la actualidad no se encuentra habilitada esta funcionalidad, se ha restringido al
alumnado solo al uso de Windows, excepto en una máquina disponible con Debian. Es por eso
9
que es de vital importancia el cambio de NIS+ a alguna tecnología de acceso a directorios que sí
lo permita, dado que en estos momentos se están desaprovechando recursos existentes.
Integración de cuentas con sistemas Web: Al momento de desarrollar una aplicación Web que
será utilizada por los usuarios del Departamento de Electrónica, es necesario un sistema de
autenticación que unifique las cuentas ya existentes con dicha aplicación. En la actualidad el
SGP (Sistema de Gestión de Prácticas) y el Sistema de Solicitud de Memos, lo hacen mediante
consultas al servidor de correo. La idea es que las peticiones de autenticación no pasen por éste,
sino que vayan directamente al servidor de directorio o autenticación.
Sistema de Administración Webmin: Al momento de realizar los cambios a NIS +, será
necesaria la implementación de un sistema web de administración de cuentas. El propósito de
éste es que los encargados de la creación, modificación y eliminación de cuentas para alumnos y
profesores se enfrenten a un interfaz amigable de administración web.
En la actualidad se encuentra instalado el software Webmin [1.3], el cual es un sistema de
administración para Unix a través de la web. Usando cualquier explorador, es posible crear
cuentas de usuario, configuración de Apache, manejo de DNS y transferencia de archivos. La
aplicación anterior se transforma en una potente herramienta de trabajo, para quienes se encargan
de la tarea de creación y modificación de cuentas. Cabe mencionar que ésta tiene soporte para los
sistemas operativos RedHat, Debian, Solaris, entre otros.
Al analizar la situación actual de la Red del Departamento de Electrónica, es posible
visualizar las falencias que la red posee en general. El tema de la no actualización de los
sistemas, la falta de servicios para algunos tipos de usuarios, llevando eventualmente a una falla
en el cumplimiento de los objetivos básicos de esta red. Por esto el trabajo a realizar consiste, en
solucionar aquellos impedimentos y a hacer un estudio acabado de qué tecnologías pueden
satisfacer la demanda mencionada.
10
Capítulo 2
Estado del Arte
2.1 Situación en Chile
Se ha estudiado la situación con respecto a las redes institucionales de tres universidades
del país. Estas poseen departamentos especializados en el tema, los cuales pretenden mantener
de forma eficiente el funcionamiento de la estructura de red. A continuación se detallará como
operan cada una de éstas.
Pontificia Universidad Católica de Chile (Facultad de Ingeniería) [2.1]: La entidad a cargo
de administrar los recursos computacionales es la Subdirección de Servicios Informáticos (SSI).
Esta agrupación es responsable de la operatividad y conectividad de los recursos usados por la
facultad para atender sus quehaceres de docencia, investigación y administración. Dentro de la
infraestructura que ésta posee, es posible destacar los servidores centrales, y sus laboratorios
docentes, donde se facilita el licenciamiento de software para todos sus usuarios.
Existen variados servicios que esta agrupación entrega a sus usuarios. Entre ellos es
posible encontrar la utilización de cuentas de correo electrónico, con cuotas de disco variable
dependiendo si es un alumno, profesor o funcionario quien la solicita. Además los usuarios
pueden conectarse remotamente a las cuentas que poseen dentro del dominio institucional. Para
ello, se fomenta la instalación y manejo del software WinSCP [2.2], el cual se comunica con los
servidores centrales mediante el protocolo SFTP, SCP y SSH. Con esto es posible acceder a
todos los archivos almacenados en las máquinas servidoras del SSI.
Universidad de Valparaíso [2.3]: El Departamento de Computación de esta universidad, tiene
como objetivo el manejo de todos los servicios relacionados a tecnologías de información de la
propia institución. Cabe mencionar que hoy en día ha existido una constante actualización de
éstos, en donde es posible destacar la futura implementación del sistema de autenticación LDAP.
De igual forma, se han agregado otro tipo de servicios como es el gestor de directorio
Relay [2.4], el cual se encarga de organizar todos los datos y archivos de un usuario, para que
éste pueda acceder de forma remota y con una interfaz adecuada.
Universidad de Chile [2.5]: La Dirección de Servicios de Tecnologías de Información (STI),
tiene como misión prestar servicios especializados en tecnologías de información y
comunicaciones, buscando permanentemente nuevas y mejores prácticas en donde éstas
propicien un cambio. El objetivo es apoyar a la Universidad de Chile en su gestión y realización
más eficiente de las labores y servicios que presta a la sociedad.
El “Pasaporte uchile”, es uno de los servicios más utilizados por la gente de la
universidad, ya que éste unifica la mayoría de las soluciones informáticas orientadas al ámbito
11
académico con un nombre de usuario y contraseña único por cada individuo. Lo anterior es
posible gracias a instalación de servidores LDAP, los que mantienen registro de todas las
personas que poseen este pasaporte junto con los privilegios que éstos poseen dentro de la red.
Con respecto al acceso remoto, los usuarios pueden ingresar vía VPN [2.6] (Red Privada
Virtual) la cual permite una extensión de la red local sobre una red pública, con el fin de tener a
mano todos los servicios que esta última ofrece. Lo anterior, es una de soluciones más utilizadas
por este tipo de instituciones ya que permite una conexión transparente entre un usuario y la
información que posee.
2.2 Situación en el mundo
El manejo avanzado de redes computacionales ha llevado a que instituciones
educacionales de nivel mundial, implementen una amplia cantidad de servicios informáticos para
mantener los altos estándares de seguridad de la información de cada uno de los usuarios que
estas entidades poseen. Es el caso de la Universidad de Berkeley en California, que a nivel de
autenticación de usuario ofrece el servicio Calnet [2.7]. Este sistema subdivide el tipo de
autenticación según la funcionalidad por la que se va a optar, por lo que se encuentra destinada a
proporcionar a los departamentos del campus un medio centralizado por el cual es posible la
validación de usuarios que necesiten acceder a aplicaciones internas, como obtener información
autorizada del resto de los usuarios. Los servicios ofrecidos por Calnet son los siguientes:
Kerberos [2.8]: Es el sistema que posee todos los identificadores y contraseñas del tipo Calnet.
Esto permite utilizar una sola identificación para todos los servicios informáticos entregados por
la universidad de Berkeley. Lo anterior puede llevar a problemas de sincronismo dado a la alta
concurrencia de usuarios, por lo que se ha desarrollado un software de sincronismo para
solucionar cualquier contratiempo de este tipo.
Central Autenticación Service (CAS): Este sistema permite una vez autenticado correctamente
a través de Kerberos, el poder acceder a todas las aplicaciones web disponibles que necesiten
alguna identificación. Con esto se logra unificar las cuentas de usuarios dependiendo del tipo de
servicio ofrecido. La idea que todo desarrollador perteneciente a la universidad, y que quiera que
los usuarios utilicen su sistema, inscriban el sitio en CAS.
LDAP Directory Service: Su uso es comparable con un directorio telefónico, ya que la
institución lo utiliza con el fin de encontrar información personalizada de cada uno de los
usuarios pertenecientes al dominio, por ejemplo: el número de empleado, el identificador de
alumno, dirección de correo electrónico. El directorio contiene información sobre los
estudiantes, maestros, empleados, afiliados y otros campos designados. Los datos se almacenan
como atributos que pueden ser propiedad de los sistemas que proporcionan diferentes campos de
información. Existen atributos de carácter público, a los que se puede acceder usando un enlace
de carácter anónimo. Por ende no es necesario habilitar una cuenta especial, por lo que una
aplicación puede realizar búsquedas sobre los usuarios públicos y recuperar la información
requerida.
12
Dado al análisis de otras instituciones, es posible discernir que en su mayoría los
servicios ofrecidos por sus de departamentos de tecnología de información son similares entre sí.
Cabe mencionar que en el extranjero se han desarrollado técnicas de autenticación mucho más
sofisticadas que en Chile. Por lo que es recomendable tomarlas en cuenta para futuros
desarrollos, ya que permitirían un mejor manejo de los servicios de redes que se pueden ofrecer.
2.3 Solución Propuesta
Al ver cada una de las soluciones que poseen las instituciones anteriores, se entrega una
propuesta de análisis y plan de acción al momento de actualizar los servicios de autenticación y
acceso remoto que tiene el Departamento de Electrónica. A continuación se listan las tareas
fundamentales a realizar para llevar a cabo este informe.
Estudiar y analizar dos tecnologías orientadas al servicio de directorio y autenticación
como son ActiveDirectory y OpenLDAP. Ambas trabajan bajo el protocolo LDAP, por lo
que se ahondará en el funcionamiento de éste.
Estudiar y analizar dos tecnologías de acceso remoto que permitan una mayor fluidez de
este servicio para los usuarios del Departamento de Electrónica. Entre ellas se investigará
sobre el uso de servidores X y servidores VPN.
Al momento de elegir una de las alternativas para cada caso, es decir, servidor de
directorios y acceso remoto, se propondrá un plan de acción para una implementación
futura por parte del Administrador de Red de turno, ya que ésta se encuentra sujeta a la
obtención de requerimientos adicionales como servidores, equipos de conectividad o
licencias de aplicaciones.
Finalmente se implementarán servidores de pruebas y máquinas virtuales que permitirán
corroborar el funcionamiento de las tecnologías escogidas y demostrar las mejoras con
respecto al sistema actual.
13
Capítulo 3
LDAP - Protocolo Ligero de Acceso a Directorio
Este capítulo tiene como objetivo entregar un mejor entendimiento del protocolo LDAP,
utilizado en los servidores de directorio y autenticación que se analizarán. Para ello se explicará
su arquitectura, su funcionamiento y cómo es relacionado con los sistemas de bases de datos.
Comúnmente, se hace la analogía entre LDAP y una guía telefónica, ya que ambos almacenan
información detallada sobre ciertos usuarios, pertenecientes a un grupo determinado. En el caso
de LDAP, puede contener nombres, direcciones, contraseñas, ubicación de directorio de datos,
entre otros aspectos, haciendo fácil la integración de ésta información con los sistemas de
autenticación. Los aspectos avanzados sobre el protocolo LDAP, se encuentran descritos en el
Anexo A1.
3.1 Servicio de Directorio
En términos informáticos, un directorio es una base de datos especializada, también
llamada repositorio de datos, el cual almacena información clasificada y ordenada acerca de los
objetos manipulados. Por ejemplo, un directorio particular podría listar información acerca de las
impresoras en forma específica, indicando su ubicación, rapidez en páginas por minuto y el flujo
de datos de impresión soportados.
Los directorios permiten tanto a usuarios como a las aplicaciones, encontrar recursos que
tienen características necesarias para una tarea en particular. Una muestra de ello es cuando un
listado de usuarios puede usarse para buscar las direcciones de correo electrónico de personas en
un cliente de correo, como también puede ser utilizado para aplicaciones de comercio electrónico
y determinar en qué servidor se encuentra la información de facturación de un determinado
cliente.
Usualmente son asociados con una base de datos, pero en realidad corresponde a una del
tipo especializada, con características que lo diferencian de las bases de datos relacionales de
propósito general. Una particularidad de los directorios es que pueden ser accedidos con alta
frecuencia para lecturas o búsquedas, en vez de actualizaciones o modificaciones de datos. Por
ello, es que los servidores de directorio están optimizados para accesos de lectura. Con lo
anterior se justifica el hecho de que estén diseñados para almacenar información relativamente
estática, por lo que no debiesen ser usados para modificaciones varias.
Cabe mencionar que los directorios no tienen la capacidad de soportar transacciones. Una
transacción es una serie de operaciones, que deben ser completadas en su totalidad o anuladas,
como es el caso de los movimientos bancarios. La descripción anterior complicaría la
implementación de un directorio, desviando el esfuerzo de lo esencial del producto, que sea
prioritariamente de lectura y rápido acceso, más aun en ciertas ocasiones es aceptable cierta
inconsistencia temporal, ya que el directorio no debe contar con un alto número de
14
actualizaciones. Por lo anterior, es que no es recomendable remplazar una base de datos de
propósito general por un directorio, si es que la consistencia de los datos, debido a numerosas
transacciones, es un aspecto crítico para el correcto funcionamiento del sistema computacional
en cuestión.
Otra diferencia entre un directorio y una base de datos relacional, es el tipo de datos que
se almacena en cada una de estos sistemas. En los administradores de base de datos relacionales,
existen una gran variedad de tipos que incluso varían según el proveedor, como también del uso
que se le vaya a dar. En un directorio en cambio, los tipos de datos son limitados (aunque pueden
extenderse), pero la información es abierta para cualquier aplicación que lo requiera. De este
modo, si bien se puede hacer que la información almacenada sea específica para adecuarse a una
aplicación o sistema, puede llegar a ser escalable al momento de entregar servicios a otras
aplicaciones que lo requieran.
En cuanto al lenguaje de acceso en las bases de datos, éste depende del proveedor de ésta,
haciendo cada uno su propia versión del lenguaje SQL (Structured Query Lenguage). Las
sentencias pueden llegar a ser muy complejas para realizar tareas específicas, involucrando
anidamiento, actualizaciones, entre otras características. Lo anterior conlleva a un alto
procesamiento y/o verificaciones de consistencia sobre los datos, aumentando la complejidad del
código del servidor de base de datos. En cambio un directorio, desde su inicio fue pensado para
ser liviano, y para responder consultas relativamente sencillas y unitarias, aunque puede permitir
complejas sentencias de filtros que son poco frecuente. El lenguaje utilizado es un protocolo
estandarizado, por lo que cualquier servidor debería responder de la misma manera ante una
consulta de un cliente estándar, optimizando a ambos al mismo tiempo.
3.2 Definición de LDAP
LDAP es un protocolo de la capa aplicación el cual permite el acceso a un servicio de
directorio ordenado y distribuido para buscar diversa información en un entorno de red. Como
anteriormente se mencionó también es considerado como una base de datos, aunque su sistema
de almacenamiento puede ser diferente.
Un árbol de directorio LDAP a veces refleja varios límites políticos, geográficos u
organizacionales, dependiendo del modelo elegido. Los despliegues actuales de LDAP tienden a
usar nombres de Sistema de Nombres de Dominio para estructurar los niveles más altos de la
jerarquía. Conforme se desciende en el directorio pueden aparecer entradas que representan
personas, unidades organizacionales, impresoras, documentos, grupos de personas o cualquier
cosa que representa una entrada dada en el árbol.
Habitualmente, almacena la información de autenticación y es utilizado para aquella
acción aunque es posible almacenar otra información, como datos de contacto del usuario,
ubicación de diversos recursos de red, permisos y certificados.
15
3.3 Los Modelos de LDAP
LDAP define cuatro modelos básicos que marcan su operación, la información que puede ser almacenada en directorios LDAP, y lo que se puede hacer con esa información. A continuación se presentan cada uno de ellos.
3.3.1 Modelo de Datos de LDAP
Los directorios en LDAP utilizan un modelo de datos que representa la información como una jerarquía de objetos. Esto no implica que el protocolo sea una base de datos orientada a objetos. Como se ha señalado anteriormente, LDAP es un protocolo que permite el acceso a un servicio LDAP habilitado que no define como se almacenan los datos, pero las primitivas operacionales como lectura, escritura y modificación, operan sobre un modelo de datos que tiene características orientadas a objetos.
Estructura de Árbol de Objetos
En un directorio LDAP los objetos son representados de forma jerárquica, donde cada uno de ellos es conocido como una entrada. El resultado de la estructura de árbol de objetos es llamado Árbol de Información de Datos (Data Information Tree – DIT). La punta de este árbol es comúnmente llamada raíz, base, o sufijo. Cada entrada en el árbol tiene una entrada padre y una o más entradas hijos, las cuales interactúan como objetos. A la vez cada entrada hijo es posible que posea más entradas hermanas. Además cada una de ellas está compuesta de (o es una instancia de) uno o más objectClasses. Los objectClasses contienen cero o más atributos, los que poseen nombre (y a veces abreviaciones o alias) y típicamente contienen datos. Las características de los objectClasses y sus atributos son descritas por las definiciones ASN.1 [3.1]. A continuación la Figura 1.1 muestra las relaciones entre los tópicos descritos anteriormente.
Figura 1.1: DIT – Data Information Tree
16
Atributos
Como se dijo anteriormente cada atributo posee un nombre y a la vez es capaz de
almacenar información. Éstos son siempre asociados con uno o más ObjectClasses. Es posible
mencionar algunas de las características de los atributos.
Todos los atributos son miembros de una o más objectClasses.
Cada atributo define un tipo de datos que éste puede contener.
Pueden ser opcionales (optional) o del tipo obligatorio (mandatory) como es descrito en
las definiciones ASN.1 para los objectClasses del cual ello son miembros. Un atributo
puede ser opcional en un objectClass y obligatorio en otro, ya que el este último
determina su propiedad.
Los atributos pueden tener uno o múltiples valores. Los del tipo simple significan, que
solo un valor de dato puede estar presentado en el atributo. En cambio los del tipo
múltiple pueden tener uno o más valores para el atributo.
También tienen nombres y a veces alias o abreviaciones. Por ejemplo commonName es
un miembro del objectClass llamado persona (y muchos otros) y tiene un nombre
abreviado cn. Ambos pueden ser usados para referenciar este atributo.
Cada nivel en la jerarquía de datos contenido en un atributo único debe ser capaz de
identificar a la entrada. Puede ser uno o una combinación de atributos para cada entrada.
Como ejemplo es posible notar un directorio de páginas amarillas que contienen
nombres, numero de teléfonos, direcciones y correos electrónicos, entre otros. Para solo
identificar una entrada se puede escoger el nombre de la persona (el atributo commoname
o cn). Si el nombre no es el único en el directorio LDAP, el sistema retornará todas las
entradas con el nombre en cuestión. Para funciones de búsqueda y lectura lo anterior
puede ser aceptable o incluso deseable, en cambio para escritura y actualización no lo es.
Por tanto es necesario seleccionar otro atributo que es absolutamente único llamado
nombre relativo único (Relative Distinguished Name - RDN). Es perfectamente
permisible usar más de un atributo para acceder a los datos dependiendo del contexto.
17
La Tabla 1.1, muestra algunos atributos utilizados en el protocolo LDAP, con sus
respectivos objectClasses:
Abreviación Nombre ObjectClass Descripción
c countryName country Definido en ISO
3166
cn commonName person
organizationalPerson
organizationalRole
groupOfNames
applicationProcess
applicationEntity
posixAccount
device
Nombre común en el
DIT. Revisar tamaño
font
dc domainComponent dcObject Cualquier parte del
nombre de dominio.
Por ejemplo
elo.utfsm.cl
gn givenName inetOrgPerson Primer nombre o
apellido.
o organizationName Organization Nombre de la
organización.
ou organisationalUnitName organizationUnit Usualmente un
departamento o
cualquier sub
entidad
perteneciente a una
mayos.
sn Surname person Apellido de una
persona.
userPassword - organization
organizationalUnit
person
dmd
simpleSecurityObject
domain
posixAccount
Password para
algunos controles de
acceso.
uid userid account
inetOrgPerson
posixAccount
Valor único de un
usuario.
Tabla 1.1: Atributos más utilizados.
18
ObjectClasses
Son esencialmente paquetes de atributos. Hay un número determinados de objectclasses
pre definido. Es posible destacar dos características.
Definen donde un miembro atributo debe (mandatory) o puede (optional) estar presente.
Pueden ser parte de jerarquía, donde hereda todas las características de sus objectclasses
parientes.
Posee un nombre global único.
Generalmente se considera un contenedor de atributos, pero a la vez es visto como uno de
ellos al momento de realizar una búsqueda.
Uno o más objectClass debe estar presente en una entrada LDAP.
3.3.2 Modelo de Nombramiento
Como ya se ha mencionado, un directorio se encuentra organizado de forma jerárquica,
formando lo que se conoció como el Árbol de Información del Directorio (DIT), en el cual cada
una de sus entradas está identificada por sus atributos destacando el Nombre Distintivo
(Distinguished Name – DN). El anterior está compuesto por la concatenación del Nombre
Distintivo Relativo (Relative Distinguished Name – RDN) con los de sus superiores, hasta llegar
a la raíz del árbol. El RDN tiene como partes un nombre del atributo, un signo igual y su valor;
por ejemplo, “cn= Braulio Vásquez”.
Cabe mencionar que el RDN debe ser único dentro de las entradas que comparten el
mismo padre, lo cual asegura que cada una de ellas tenga un DN único en el directorio. Lo
mencionado no siempre ocurre, ya que algunas aplicaciones no lo soportan. Un ejemplo de ellos
es cuando éstas esperan que los RDN sean de la forma “uid= Braulio Vásquez”, no pudiendo
distinguir en que rama del árbol se encuentran.
La forma que tiene el DIT es conocida como espacio de nombres (namespace), que puede
estar formado de muchas formas. En sus inicios el estándar X.500 seguía un esquema de
nombramiento basado en países, regiones, y otras características geográficas. Más tarde se
delegó un nuevo sistema de nombramiento basado en DNS, que es lo que se ocupa hasta estos
días; por ejemplo, “dc=elo, dc=utfsm, dc=cl”.
19
3.3.3 Modelo Funcional
Este tipo de modelo describe la forma de navegar en el directorio para así obtener la
información necesaria. Básicamente son tres grupos de operaciones que se diferencian según su
funcionalidad. Por ejemplo, la operación de interrogación busca y obtiene información del
directorio. En cambio la operación de actualización realiza cambios en los datos almacenados
previamente. Por último la operación de autenticación maneja la parte de control de acceso por
parte de los usuarios como también características de la sesión. En la versión posterior de LDAP
(Versión 3), se agrega el concepto de operación extendida.
A continuación se detalla las características de cada una de estas operaciones y la
influencia en el correcto funcionamiento del protocolo.
Operación de Interrogación
La palabra clave de esta operación es la búsqueda que desea realizar un usuario en el
DIT. Aquella acción es manejada por los siguientes parámetros:
baseDN: Representa el punto del DIT o nodo de donde se comenzará la búsqueda de
información.
Filter: Como lo dice su nombre, es un filtro para realizar la búsqueda. Por ejemplo,
podría ser como un atributo dentro del DIT como “uid=bvasquez”, o también utilizando
búsquedas lógicas.
Scope: Aquí es posible abarcar tres sub-niveles, los cuales son: base, one-level o subtree.
Si fuese base solo busca lo que se destacó en baseDN. En cambio, para one-level, se
abarcan los hijos de baseDN. Finalmente para subtree, se buscará en todas las entradas en
el árbol que se forma bajo baseDN.
También es posible la utilización de otros parámetros de interrogación como los atributos
a retornar de una entrada, límites de tiempo y tamaño, entre otros.
Operación de Modificación
Este tipo de operación abarca la parte de escritura sobre el directorio. Para ello existen
cuatro parámetros utilizados. La operación add y delete, ambas se usan para agregar y eliminar
entradas respectivamente. Por otro lado, modifyDN permite renombrar y/o mover una entrada en
el árbol. Finalmente la operación modify, hace cambios sobre una entrada ya creada con
anterioridad, permitiendo agregar o quitar atributos.
Un aspecto importante a recalcar, es que recordando que los directorios no poseen
mecanismos avanzados de transacciones como las bases de datos generales, los cambios que se
hacen en las entradas son atómicos, esto quiere decir que se hacen completamente.
20
3.3.4 Modelo de Seguridad
Este modelo tiene una gran importancia en la utilización del protocolo en sí, ya que es
necesario dar aspectos de seguridad al momento de obtener información de un directorio que
involucra a un grupo de usuarios con diversos privilegios, dentro de una misma unidad
organizacional. Es sabido que LDAP es orientado a la conexión, es decir que los usuarios abren
una conexión al servidor, y realizan todas las manipulaciones dentro de esa misma. Con ello el
cliente debe autenticarse antes de iniciar la sesión, para así obtener mayores o menores
privilegios según sus características como usuario, los cuales durarán hasta que termine aquella
instancia.
Por parte del usuario, la autenticación es el proceso por el cual se le dice al servidor que
él es una entidad en particular. En cambio, desde el punto de vista del servidor, la parte de
autenticación involucra la aceptación de la identidad y las credenciales dadas por el cliente y la
verificación de que éste es quién dice ser.
Para profundizar en este modelo, se mencionan los diversos métodos de autenticación que
soporta el protocolo LDAP, los cuales poseen diversas cualidades según el uso o grado de
importancia que posea la unidad organizacional.
Anónimo
Este perfil es utilizado generalmente, cuando el tipo de información que se desea
encontrar es de carácter público, por lo que no es necesario que el usuario se autentique en el
servidor. Lo anterior, puede llevar a una sobrecarga de éste debido a que no es necesaria la
creación de perfiles para cada uno de los clientes que ingresan al sistema, pero aporta con una
solución más simple a las necesidades de éstos. Cabe mencionar que el estado es conocido como
anonymous, el cual el usuario siempre posee al momento antes de generar la conexión,
independiente si hay autenticación o no.
Contraseña de Texto Plano
La mayor desventaja de las contraseñas de este tipo, es que son fáciles de captar por los
usuarios maliciosos. Cualquier persona que esté entre el cliente y el servidor, verá entre otras
cosas la contraseña, incluso realizar modificaciones sobre ella, como también en las entradas
guardadas. El procedimiento típico de negociación entre el usuario y el servidor, usando este tipo
de contraseña es el siguiente:
1) El servidor solicita al usuario su nombre de usuario y contraseña.
2) El cliente responde a lo solicitado.
3) El servidor compara la contraseña con el valor almacenado para el usuario específico.
21
Contraseña sobre SSL
Esta es una forma más segura del uso de contraseñas para la autenticación en un servidor
LDAP. Ya que acá se involucra el uso de Secure Socket Layer (o su sucesor Transport Layer
Security – TLS) para proteger la conexión sobre la que se transmitirá la contraseña en texto
plano. Esto permite que la simplicidad de usar contraseñas pueda ser almacenada en ambientes
de alta seguridad, sin riesgos de intercepción de información de alto valor.
Todos estos aspectos de seguridad, tienen un costo relacionado a la sobrecarga de
servidores y usuarios. Es necesario un certificado para el servidor (no para los clientes) y
renovarlo cada vez que sea necesario. Además, se debe tener en cuenta que muchos usuarios sin
certificados se deseen conectar.
Autenticación con certificado, sobre SSL
Esto proporciona sin duda mayor seguridad, pero incorpora mayor sobrecarga en las
máquinas como complejidad al sistema. Se debe crear un sistema PKI (Public Key
Infrastructure), donde se almacenarán los certificados. Es complejo, puesto que además de tener
un servidor de directorio, donde se podrían guardar los certificados, hay que implementar alguna
entidad certificadora que maneje y administre los certificados durante su ciclo de vida.
Una vez ya decidido como el usuario ingresará es necesario abarcar las métricas de
protección de la información en el DIT. Esta es proporcionada por lo que se conoce como
controles de acceso, permitiendo a entidades específicas el ingreso a cierto tipo de información.
Cada implementación tiene su propia manera de realizar el control de acceso. La idea es
que sea jerárquico en el directorio, es decir, que sea hereditario. Por ejemplo, si una entrada
permite solo lectura y búsqueda a accesos anónimos, este control de acceso debe aplicarse
también a todo el sub- árbol formado por esta entrada. En general, independiente del modelo, las
instrucciones de control de acceso debiesen estar constituidas por:
Uno o más recursos del directorio, es decir, a los objetos que se les controlará el acceso.
Uno o más clientes accediendo a los recursos.
Uno o más derechos de acceso, que corresponden a las acciones que las entidades pueden
hacer sobre el objeto controlado.
22
Capítulo 4
Sistemas de Acceso Remoto
Hoy en día el Departamento de Electrónica cuenta con variadas formas de acceso remoto
para sus usuarios. Entre ellas es posible mencionar vía SSH o por X-Ming el cual permite la
utilización de aplicaciones con entorno gráfico mediante la conexión al servidor “Aragorn”. Esta
última opción se encuentra sujeta a una serie de inconvenientes, debido a las restricciones de
acceso que tienen los alumnos, con el fin de no saturar el ancho de banda asignado al
departamento. Por esto nace la inquietud de encontrar una solución que permita entregar mayor
cantidad de servicios remotos para los usuarios, permitiendo un uso eficiente de la red.
Con esta opción tanto alumnos como profesores, podrían dar un mejor uso de las
herramientas tecnológicas existentes, para así integrarlas con los planes de los cursos impartidos
por el Departamento de Electrónica. Cabe mencionar que hoy en día un alto porcentaje de
usuarios tiene a su disposición equipos personalizados (laptops, equipos de escritorio, etc.)
siendo un argumento sustancial para la implementación de este tipo de tecnología. Este capítulo
abarca el estudio de dos de las herramientas de acceso remoto, el servidor de ventanas X y la red
VPN. Con esto se dará un enfoque de la mejor opción posible para una implementación futura en
el Departamento de Electrónica.
4.1 Sistema de Ventanas X
El sistema de ventanas X es un software desarrollado por el MIT para dotar de una
interfaz gráfica a los sistemas Unix. Este protocolo permite la interacción gráfica en red entre un
usuario y una o más computadoras haciendo que la red sea transparente para éste. Generalmente
se refiere a la versión 11 de este protocolo, X11, el que está en uso actualmente. X es el
encargado de mostrar la información gráfica de forma totalmente independiente del sistema
operativo.
X fue diseñado primariamente para implementar clientes ligeros, donde mucha gente
usaba simultáneamente la capacidad de procesamiento de un mismo computador trabajando en
tiempo compartido. Cada persona usaba un terminal en red que tenía capacidades limitadas para
dibujar la pantalla y aceptar la entrada del usuario. Debido a la ubicuidad del soporte para el
software X en Unix, éste es usado en computadores personales incluso cuando no hay necesidad
del tiempo compartido.
El sistema de ventanas X distribuye el procesamiento de aplicaciones especificando
enlaces cliente-servidor. El servidor provee servicios para acceder a la pantalla, teclado y ratón,
mientras que los clientes son las aplicaciones que utilizan estos recursos para interacción con el
usuario. De este modo mientras el servidor se ejecuta de manera local, las aplicaciones pueden
ejecutarse remotamente desde otras máquinas, proporcionando así el concepto de transparencia
23
de red. Debido a éste esquema cliente-servidor, se puede decir que X se comporta como un
terminal gráfico virtual.
El hecho que exista un estándar definido para X permite que se desarrollen servidores X
para distintos sistemas operativos y plataformas, lo que hace que el código sea muy portable. Por
ejemplo, permite tener clientes X ejecutándose en un potente servidor Unix mientras los
resultados son visualizados en una computadora de escritorio con cualquier otro sistema
operativo funcionando. La comunicación entre el cliente X y el servidor se realiza por medio de
un protocolo conocido como Xprotocol [4.1], que consiste en una serie de bytes interpretados
como comando básicos para generar ventanas, posicionarlas, o controlar eventos. Los clientes X
acceden a este protocolo mediante el uso de una biblioteca llamada Xlib [4.2], que evita al
programador de clientes tener que lidiar con el código binario de Xprotocol. Sin embargo, los
aspectos de decoración y manejo de ventanas no están definidos en esta biblioteca.
Es importante destacar que X no es un gestor de ventanas, ya que necesita del usuario
para controlar el manejo de éstas. Lo anterior, conlleva a la ventaja que X pase a ser
estrictamente un sistema gráfico, de tal modo que un cliente podría estar enviando un gráfico a
una pantalla, a una impresora o a cualquier otro hardware sin darse cuenta, flexibilizando la
salida gráfica. Por otro lado, la desventaja es que no posee un único entorno de uso, por lo que
los programadores deben definir con anterioridad cual elegir, llevando a ciertas restricciones de
uso para los usuarios que deben poseer las bibliotecas específicas.
4.1.2 Diseño del Servidor X
Como ya se dijo con anterioridad, el sistema de ventanas X utiliza el modelo cliente-
servidor. Un programa servidor X se ejecuta en un computador con una interfaz gráfica y se
comunica con varios programas clientes. El servidor acepta pedidos para salidas gráficas y envía
señales de entrada del usuario. El servidor se ejecuta en computador del usuario, mientras que los
clientes pueden ejecutarse en computadores distintos. Esto es exactamente al revés de la
configuración usual de los sistemas cliente-servidor. Esta inversión resulta confusa para nuevos
usuarios de X. La terminología de X Window toma el punto de vista del programa, en lugar del
punto de vista del usuario o el hardware: los programas remotos se conectan a la interfaz gráfica
del servidor X que se ejecuta en el computador local, y por lo tanto actúan como clientes; la
interfaz gráfica X local acepta el tráfico de ingreso, y por lo tanto trabaja como un servidor.
24
Figura 4.1: Ejemplo del Servidor X
En la Figura 4.1 es posible notar que el servidor X recibe la entrada de un teclado y de un ratón de forma local exhibiendo el resultado en la pantalla. Un navegador web y un emulador de terminal se ejecutan en la estación de trabajo del usuario y una aplicación de actualización de software se realiza en un computador remoto, pero es controlado y monitoreado desde la misma máquina del usuario.
El protocolo de comunicaciones entre el servidor y el cliente opera transparente a la ubicación del cliente, ya que ambos pueden ejecutarse en la misma o diferentes máquinas, posiblemente con diferentes arquitecturas y sistemas operativos. También pueden comunicarse con seguridad sobre Internet haciendo una conexión túnel sobre una sesión cifrada de la red. La comunicación entre ellos se hace mediante intercambio de paquetes sobre un canal. La conexión se establece por el cliente. Éste también envía el primer paquete, que contiene el orden del byte a ser utilizado y la información sobre la versión del protocolo y el tipo de autenticación que el cliente espera que el servidor use. La respuesta de este último mediante un paquete de vuelta indica la aceptación o el rechazo de la conexión, o con una solicitud de una autenticación adicional. Si la conexión es aceptada, el paquete de aceptación contiene los datos que el cliente debe usar en la interacción posterior con el servidor.
Después que se establece la conexión, cuatro tipos de paquetes son intercambiados entre las máquinas sobre el canal de comunicación:
Petición: El cliente pide información al servidor o solicita que éste realice una acción. Respuesta: El servidor responde a una petición. No todas las peticiones generan
respuestas.
25
Evento: El servidor informa al cliente de un acontecimiento, tal como la entrada del teclado o del ratón, que una ventana está siendo movida, redimensionada, expuesta, etc.
Error: El servidor envía un paquete de error si una petición es inválida. Puesto que las respuestas están en cola, estos paquetes generados pueden no enviarse inmediatamente.
Figura 4.2: Conexión cliente-servidor X
Los paquetes de la petición y de la respuesta tienen una longitud diversa, mientras que los paquetes de eventos y de error tienen una longitud fija de 32 bytes. Los paquetes de petición son numerados secuencialmente por el servidor tan pronto como los recibe: la primera petición de un cliente se numera 1, la segunda 2 y así sucesivamente. Los 16 bits menos significativos del número secuencial de una petición se incluyen en los paquetes de la respuesta y del error. También son incluidos en los paquetes de eventos, para indicar el número secuencial de la petición que el servidor está actualmente procesando o acaba de terminar de procesar.
4.1.3 Interfaces de Usuario
El servidor de ventanas X es primariamente una definición de primitivas de protocolo y gráficas, y deliberadamente no contiene especificaciones de diseño de interfaz de usuario, como estilos de botón, menú, barra de título para las ventanas. En vez de eso, un software de aplicación, tal como los manejadores de ventana, definen y proporcionan tales detalles. Como resultado, no hay interfaz X típica y varios ambientes de escritorio han sido populares entre los usuarios.
Un manejador de ventana controla la colocación y la apariencia de las ventanas de aplicación. Esto puede resultar en interfaces semejantes a las de Microsoft Windows o Macintosh o tener controles radicalmente diferentes. Estos abarcan en sofisticación y complejidad desde los más simples hasta los ambientes de escritorio más completos.
26
Muchos usuarios usan X con un ambiente de escritorio, que incluyen varias aplicaciones
usando una interfaz de usuario consistente. GNOME y KDE y Xfce [4.3] son los ambientes de
escritorio más populares. El ambiente estándar de Unix es Common Desktop Environment [4.4]
Puesto que el X es responsable de la interacción entre el teclado y el ratón con el
escritorio gráfico, ciertas combinaciones de teclas han llegado a estar asociadas con X. Control-
Alt-Backspace típicamente termina la sesión actualmente corriendo en X, mientras que el
Control-Alt conjuntamente con una tecla de función cambia a la consola virtual asociada. Sin
embargo, esto es un detalle dejado al diseño de una implementación de servidor X y no es
universal; por ejemplo, las implementaciones de servidor X para Windows y Macintosh
típicamente no proporcionan estos atajos de teclado.
Implementaciones
La implementación de X.Org es la implementación canónica de X. Debido al tipo
de licencia libre, han aparecido un número de variaciones, tanto libres como propietarias. Los
vendedores comerciales de UNIX han tendido a tomar la implementación de fuente abierta y a
adaptarla para su hardware, usualmente personalizándola y añadiendo extensiones propietarias.
Microsoft Windows no es comercializado con soporte para X, pero existen muchas
implementaciones de terceros de qué, tanto de software libre tales como Cygwin/X,
Xming y WeirdX; como de productos propietarios tales como Xmanager, Exceed, MKS
X/Server, Reflection X, y X-Win32.
Cuando un sistema operativo con un sistema de ventana nativo es anfitrión de X,
adicionalmente, el sistema X puede usar o no su propio escritorio en una ventana anfitriona
separada o puede ejecutarse de forma interna, significando que el escritorio X está oculto y el
ambiente anfitrión de ventana maneja la geometría y apariencia de las ventanas hospedadas en la
pantalla del anfitrión.
27
4.2 VPN, Red Privada Virtual
VPN corresponde a la sigla de Virtual Private Network, que significa Red Privada
Virtual, una VPN no es más que un servicio que permite conectar dos extremos remotos lejanos,
ya sean redes o hosts de una manera segura y confiable a través de la encriptación de los
mensajes y la autenticación de los extremos, logrando así una sola “red”; que se caracteriza por
ser “privada”, ya que solo los extremos remotos tienen acceso y permiso a ella y es “virtual”
porque no importa la ubicación física ni la forma de conexión a Internet de los extremos remotos
para ser una sola red. También se define como una red en que la conectividad entre varios sitios
lejanos se distribuye en una infraestructura compartida, con las mismas normas de acceso,
seguridad y administración que en una red privada. Es una emulación de una red privada sobre
una estructura compartida que abarca o cubre elementos ubicados en cualquier parte donde haya
conectividad a Internet usando cualquier tecnología de acceso. En la actualidad existen tres tipos
de VPN, las cuales son:
VPN de Internet: Son todas aquellas VPN que enlazan la sede o sucursal actual de una
empresa u organización, las oficinas remotas y las sucursales a una red interna sobre una
infraestructura compartida. La diferencia sustancial que posee con las VPN de extranet es
que el acceso es sólo para los empleados de la empresa cliente.
VPN de extranet: Son todas aquellas VPN que enlazan los clientes exteriores,
proveedores, socios o comunidades de interés a una red interna de una empresa cliente
sobre una infraestructura compartida. Las VPN de extranet se diferencian de las VPN de
Internet en que permiten el acceso a usuarios que no son de la empresa.
VPN de Acceso: Son todas aquellas VPN que proporcionan acceso remoto a Internet y
extranet de una empresa cliente sobre una infraestructura compartida. Las VPN de acceso
utilizan tecnologías analógicas, de acceso telefónico, RDSI, líneas de suscriptor digital
ADSL, IP móvil y de cable para conectar de forma segura usuarios móviles,
teletrabajadores y sucursales.
4.2.1 Elementos de una VPN
Una VPN está constituida por una serie de elementos generales, entre ellos:
Túnel Cifrado: Corresponde a una conexión lógica entre dos extremos que se desean
comunicar, sin importar el lugar en que se encuentren, ni la distancia ni la topología
existente entre ellos, dándole la impresión a los extremos de la comunicación que están
conectados directamente, o sea, se canalizan directamente los datos de un lugar a otro. La
idea del túnel, como muestra la Figura 4.3 no es solamente la de enviar los datos en
ambas direcciones de forma transparente, sino también agregarle a esa comunicación
seguridad y privacidad para que nadie en el trayecto pueda interceptarla. Para esto el
túnel es cifrado a través de una variedad de algoritmos simétricos y asimétricos de cifrado
y encriptación en el extremos transmisor.
28
Figura 4.3: Representación de túnel cifrado.
Extremos autenticados: Corresponde a las partes de la comunicación VPN, un host o bien una red que en el proceso transmisión debe autenticar el envío de los mensajes para asegurar que procedan de usuarios válidos. A estos se les garantiza el acceso, en cambio a los no válidos se les deniega. Es importante usar la autenticación de extremos ya que con esta se asegura que el usuario o red remota es quien dice ser.
Transporte Subyacente: Corresponde a la red o redes ya establecidas que se encuentran entre los extremos de comunicación VPN en donde se realiza la conexión y creación del enlace. En otras palabras es la ruta a tomar en una serie de caminos ya creados y operativos.
Hardware VPN: Son una serie de dispositivos electrónicos tales como módems, enrutadores VPN, puentes VPN, firewalls, scanner CS, sistema de detección de intrusos (CSIDS), servidores VPN y clientes VPN que permiten o se ven involucrados en el proceso de inicialización, mantención, encriptación, control y finalización de una conexión VPN entre un punto y otro.
Software VPN: Corresponden a una serie de aplicaciones tales como Cisco Works 2000 Cisco Secure Policy Mnager, herramientas de encriptación, llaves, generadores de claves y certificados, scripts de configuración y tantas otras que permiten o se ven involucradas en el proceso de inicialización, mantención, encriptación, control y finalización de una conexión VPN entre un extremo y otro.
Cliente VPN: Son los hosts o la misma red remota que inicia el proceso de creación de la VPN o aquel extremo que desea comunicarse con otro.
Servidor VPN: Corresponde al host o red remota que recibe la petición de comunicación desde otro host o red remota.
29
4.2.2 Topología VPN
Son conocidas como las diferentes formas de conexiones lógicas o físicas de las VPN que pueden existir. Se consideran tres tipos básicos de topologías VPN, dependiendo de qué tipo son los extremos, es decir, de host a host, host a red, o red a red.
Host – Host: Es una de las arquitecturas más sencillas entre todas las existentes, cada host de un extremo está inserto en una red. Entre ellos puede haber hubs, puentes, enrutadores, redes LAN, redes WAN, pero cada usuario de los terminales finales ve el sistema como si estuviera conectado directamente con el otro.
Conexión Lógica entre hosts
Router de
Acceso A
Router de
Acceso B
HOST A HOST B
RED A RED B
Internet
Figura 4.4: VPN “host - host”.
Host – Red: Esta arquitectura es un método fácil y óptimo para teletrabajadores o trabajadores viajeros que necesitan estar considerado como si estuvieran dentro de la red interna, cuando en realidad están en lugares remotos. Cada host se conecta en forma independiente con una puerta de enlace VPN, luego se autentican y los túneles VPN se inician para cada uno de ellos.
30
Puerta de
Enlace
Host Remoto
RED
Internet
Figura 4.5: VPN “host - red”.
Red – Red: Esta topología es una de las más complejas, es ideal para empresas con muchos POP (Puntos de presencia de empresas en regiones). La idea es conectar los POP con la oficina central o red corporativa a través de VPN utilizando Internet, para así ahorrarse la utilización de una línea dedicada. Este tipo de arquitecturas necesita operar con un alto grado de seguridad entre los extremos, con los mejores algoritmos de autenticación, codificación y uso de claves en la transmisión de datos. Opera para cualquier tipo de red, solo basta que sea escalable para el usuario en la red, ya que el enlace lo ve de forma transparente.
Puerta de
Enlace
RED B
Puerta de
Enlace
RED A
Internet
Figura 4.6: VPN “red - red”.
31
4.2.3 Ventajas de una VPN
Como toda tecnología nueva, es importante considerar las variadas ventajas que permiten
al administrador de red el implementar una red VPN como una solución conveniente por sobre
las demás. Entre ellas se describen:
Factor Económico: Utilizar una VPN para conectar POP‟s remotos distantes
geográficamente o para incorporar equipos remotos a la red, utilizando un servicio ya
contratado por la empresa como lo es Internet, permite a las empresas ahorrarse dinero al
contratar una línea dedicada y/o incorporar un sistema RAS [4.5]. Si se utiliza una VPN,
sólo se tiene costos en la inversión inicial ya que el servicio de Internet se seguiría
cancelando se tenga o no VPN, en comparación con otras soluciones del mercado que son
mucho más costosas.
Transparencia: Una de las mayores características de las VPN, es que el usuario final
que utiliza un host no ve la real conexión de los otros hosts o redes a la cual se está
asociando, sino que son enlaces transparentes, por lo que el usuario siempre creerá que
está conectado directamente. Con este tipo de implementación se ahorra tiempo y dinero
en capacitación de personal en el área de redes y en la no variación, actualización y
reemplazo de las aplicaciones utilizadas.
Seguridad de Tráfico única: Las VPN también sobresalen debido a su capacidad de
asegurar flujos de comunicación utilizando un solo mecanismo, como es el cifrado y
autenticación de la comunicación. Además es posible la factibilidad de tráfico Web,
correo electrónico, transferencia de archivos, videoconferencia, voz sobre IP, telefonía IP
y cualquier conexión que utilice el protocolo TCP/IP.
Seguridad mejorada: Las VPN ofrecen múltiples elementos de seguridad para mejorar
las redes, ya que mitigan los riesgos externos como el falseamiento de IP, el sniffing
pasivo, la pérdida de confidencialidad, la inyección de paquetes y protección de virus que
se propagan a través de hosts accesibles desde Internet.
Facilidad en la administración: Para los ingenieros a cargo de la implementación de
VPN y de la configuración de ésta, no la verán como algo imposible. La configuración es
bastante sencilla y no variaría de la típica configuración de routing y switching ya
existentes en la red.
4.2.4 Desventajas de una VPN
Como toda nueva tecnología, el uso de las VPN también tiene sus defectos. Es importante
considerar cada uno de los factores que en la administración de redes permiten no considerara la
utilización de una VPN como una solución conveniente sobre las demás, entre ellas:
32
Poca seguridad interna: Las VPN no se consideran como un método completamente
seguro, la mayor desventaja en cuanto a seguridad de una VPN, es que no se protege a los
hosts internos de ataques provenientes desde el interior de Internet, ya que por la
infección de alguno de ellos existiría una propagación inminente.
Larga Implementación: Las implementaciones de VPN pueden ser difíciles y consumir
demasiado tiempo si son realizadas por administradores de poca experiencia o bien en
redes de variadas topologías y tecnologías, lo que lleva a que la planificación de la
configuración, la administración de las claves y la redistribución de direcciones IP,
pueden convertirse en una tarea muy difícil.
Dificultad al solucionar problemas: Como en los enlaces VPN existe autenticación de
los extremos y codificación del tráfico, la falta de sincronización de las claves, los
paquetes eliminados y la sobrecarga de la puerta de enlace, son problemas que bajan el
rendimiento de la VPN, los cuales pueden ser muy difícil de detectar.
4.2.5 Medidas de seguridad
Dentro de las muchas opciones que caracterizan a las VPN con respecto a medida de
seguridad, es importante tener en cuenta una serie de factores necesarios para darle completa
seguridad a la red VPN, para eso lo primero que se debe considerar es la utilización de firewalls
bien configurados, por lo que ellos deben aportar la protección suficiente ante filtraciones no
deseadas.
Similar a los firewall se pueden utilizar routers VPN, switch VPN y HUBS VPN, con los
que se pueden obtener los mismos resultados de seguridad que utilizando un firewall.
Otra gran medida de seguridad a tener en cuenta en la implementación de una VPN, es la
tenencia de un algoritmo de cifrado adecuado y muy seguro, que sea invulnerable y lo más
complejo posible para evitar que terceros puedan acceder los datos reales transmitidos. El
software de generación de claves públicas y privadas dentro de la VPN debe ser creado con la
característica de tener suficiente entropía al generar los números aleatorios de las claves.
Finalmente, hay que tener un control excesivo con los usuarios remotos portátiles, ya que
éstos pueden ser generalmente atacados para tener acceso a la Intranet de una empresa.
Generalmente cuando un usuario se encuentra en una red ajena se conecta a través de una VPN
para acceder a su red, entonces es ahí donde es más vulnerable el portátil.
33
Capítulo 5
Comparación de Tecnologías
5.1 Análisis y Comparación de Servidores de Directorio
En la actualidad existen variadas alternativas en lo que respecta a servidores de directorio
y sistemas de autenticación para redes del tipo institucional. Ya que a medida van aumentando
los usuarios resalta la necesidad de un control más exhaustivo de ellos. Son cada vez más las
aplicaciones y sistemas que se integran con directorio, puesto que es relativamente simple y
abierto, independiente del proveedor. Obviamente debido a las necesidades del mercado, existen
diferencias en los estándares que utilizan cada una de ellas, entregando ciertas ventajas y
desventajas que se acomodarán según la necesidad de la empresa o institución que lo requiera. Es
posible identificar que la base de utilización de los diversos programas es la misma, como las
entradas de LDAP mencionadas en el capítulo 3. Pero gracias a los avances y a las solicitudes de
usuarios expertos en el tema, los propietarios han permitido la integración de estos servicios cosa
de satisfacer al máximo las necesidades del usuario.
Con lo mencionado se hace una tarea menos complicada el elegir qué tipo de tecnología a
utilizar, pero de igual forma influyen ciertos factores que hacen discernir entre una y otra. Por
tanto importante analizar cuáles son estos factores y que aplicación los satisface de mejor forma,
cosa que la solución implementada no pase a ser un problema más. Cabe mencionar que el tema
de mantención de la información y migración puede ser traumática debido quizás a
particularidades de los sistemas propietarios.
Por otro lado, se debe tener en cuenta que a medida que pasa el tiempo las organizaciones
crecen, y los sistemas junto con ellas. Por ello, se debe tener en cuenta los límites de este
crecimiento. Si se piensa en una solución que involucre un servidor de directorio, este no debe
convertirse en ningún caso en el cuello de botella de la red.
Para este capítulo se abarcarán los diversos tópicos a evaluar, el por qué son necesarios
para satisfacer la problemática para la red del Departamento de Electrónica, y cómo influyen y
solucionan la disyuntiva las alternativas consideras.
5.1.1 Tópicos de Evaluación
Un servidor de directorio puede ser usado para muchos fines, y dependiendo de éstos, son
las características que a un administrador de redes le gustaría potenciar. Para una correcta
elección del producto que se adapte a sus necesidades, se deben identificar cuáles son las tareas
críticas que se realizarán. Generalmente un servidor de directorio es utilizado con un mismo fin:
el centralizar la información de los usuarios; pero éste a la vez puede ser usado para satisfacer
34
otros requerimientos como el ser parte de un sistema de integración para la autenticación de
usuarios.
Estándares
Para abarcar este punto es necesario formularse las siguientes inquietudes: ¿qué pasa si en
el futuro se desea cambiar el servidor de directorio por uno de otro fabricante?, ¿o la empresa
llegase a cambiar de plataforma?, entre otras preguntas. Las anteriores parecen muy obvias, pero
la mayoría de las veces no se hacen causando serios problemas en el proceso migratorio de los
sistemas, como ocurre en esto días en el departamento de electrónica. Por esto es muy importante
que la aplicación elegida se apegue lo más posible a los estándares, de ese modo se puede contar
con una mayor probabilidad de interoperabilidad. Por tanto la idea es seleccionar un servidor de
directorio que se apegue lo más posible a las necesidades propias, y tenga alto grado de facilidad
al instante de realizar una migración.
Grados de seguridad
Como en la actualidad uno de los aspectos más mencionados y tratados en el área de
administración de redes es la seguridad, cabe inminente considerarla como tópico de análisis. En
el caso de un servidor de directorio, el requerimiento principal de seguridad viene dado por la
calificación estratégica de la información que almacena. Ésta, en algunos casos, no debería ser
publicada por ningún motivo, o sólo ser modificada por un grupo de usuarios seleccionados. Tal
es el caso de un ISP, al cual le gustaría delegar la actualización de algún dominio en particular a
entidades de ése dominio. Por ejemplo, si se integra DNS dentro de un servidor de directorio y se
usa una interfaz que se comunique externamente mediante este protocolo, no se debiese necesitar
herramientas adicionales para mantener la seguridad.
Existe la alternativa de mantener una determinada red bajo altos estándares de seguridad,
es decir con cortafuegos debidamente configurado de acuerdo a las listas de accesos
predeterminadas para los usuarios. Lo anterior conlleva que éste tipo de solución se considera
muy amplia, ya que además abarca otras necesidades de seguridad de la red, por lo que no
garantiza que la información esté asegurada.
Finalmente uno de los puntos que se está tocando en la mayoría de las aplicaciones de
éste tipo es la seguridad interna del servidor, es decir mediante el modelo de autenticación y
modelo de control de acceso, utilizando protocolos como SSL.
Facilidad de administración
Éste aspecto también se considera como parte del análisis, ya que la idea es implementar
una aplicación estándar para una correcta administración cosa de reducir los tiempos de
mantención y así el sistema sea mantenga en pie gran parte del tiempo. Lo anterior se toma en
cuenta dado que en el departamento de electrónica existen alumnos ayudantes lo cuales realizan
tareas relacionadas a la administración de cuentas, y por motivos de facilitar su trabajo junto con
reducir los tiempos de espera para los usuarios es necesario tomar en cuenta éste punto.
35
En este tópico también se encuentra incluida la facilidad de detectar problemas y poder
resolverlos. Para ello el producto debería contar con las herramientas necesarias para proveer al
administrador de la información que pudiera ser relevante para tales efectos.
Costos y soporte
Aunque la decisión no debiese partir por éste punto, el tema de costos es muy importante
al momento de tener en manos dos productos con características similares y que cumplas las
funcionalidades requeridas por la institución. Para ello es necesario un análisis exhaustivo de las
aplicaciones, y no quedarse con una descripción general acerca de lo que hace o no. El cambio
posterior de un sistema de directorio a otro puede resultar dramático si no se consideran estos
aspectos.
El tema del soporte que pueden proveer los desarrolladores de las aplicaciones es
generalmente oculto y poco específico. Esto incluye la realización de continuas actualizaciones y
no solo de abrir casos por problemas específicos e inmediatos. También incluye información
para los administradores, en temas diversos en torno al producto, que pudiesen dar nuevas ideas,
o alertar sobre posibles problemas.
Integración con otros productos
La integración de la aplicación seleccionada con otros productos, es demasiado
importante ya que influirá el uso de todas las aplicaciones que se involucran en la red. El uso de
sistemas de directorio, generalmente se evoca a la unificación de cuentas de usuarios para
diversas plataformas disponibles en la red. Entre ellas es posible mencionar sistemas web, acceso
a redes inalámbricas, autenticación en máquinas disponibles en la red, dualidad de sistemas
operativos. El administrador de red debe tener la suficiente abstracción para determinar que
sistemas podrían verse beneficiados al integrarse con un servidor de directorio.
Se expondrán los principales sistemas que a menudo se integran con un servidor de
directorio y la dificultad con la que se podría encontrar al integrarse con alguno de los sistemas
de directorios evaluados.
5.1.2 Productos a comparar
Dentro de los objetivos del presente trabajo es realizar una comparación de las
tecnologías existentes en el mercado que puedan satisfacer la problemática de autenticación e
integración de sistemas para el departamento de electrónica. Durante el proceso de investigación
se realizaron diversas búsquedas, incluyendo software privativo como de código abierto, y de
acuerdo a la obtención de resultados se tomaría la decisión de cuál es el indicado para su
posterior instalación.
Entre las variadas soluciones encontradas se tomó la decisión de basarse en dos de ellas,
las cuales representan con creces la utilización del protocolo LDAP, que ha sido estudiado como
sistema base para el servicio de directorio. Finalmente se procede a realizar un cuadro
36
comparativo de estos programas, de acuerdo a las necesidades o tópicos que se consideraron en
la sección anterior, además de otros aspectos técnicos de acuerdo a la investigación de cada una
de las aplicaciones.
A continuación se hace una breve descripción de las características de cada una de ellas,
mencionando su funcionamiento y su arquitectura principal.
OpenLDAP
OpenLDAP es una implementación de código abierto que utiliza las definiciones de
LDAP mencionadas en el capítulo 3. Esta aplicación posee una arquitectura principal dividida en
cuatro partes específicamente:
Un servidor LDAP stand-alone (demonio slpad).
Un servidor de replicación LDAP stand-alone (demonio slurpd).
Un kit de desarrollo (SDK).
Utilidades y herramientas relacionadas con LDAP.
Originalmente el desarrollo de éste proyecto comenzó en la Universidad de Michigan la
cual realizó la primera implementación del protocolo antes mencionado. La primera versión fue
escrita para proveer un acceso básico a los directorios X.500 vía TCP/IP, publicado en 1992. La
segunda versión, también conocida como SLAPD (standalone LDAP daemon), fue publicada en
1995 como parte del proyecto U-M-LDAP 3.2. La diferencia con la versión anterior fue el que el
estándar de directorio X.500 no fue requerido. El proyecto U-M LDAP fue finalizado en 1996, y
desde ahí el nuevo proyecto OpenLDAP continuó hasta donde había quedado el anterior.
OpenLDAP está licenciado bajo la Licencia Pública OpenLDAP, el cual es un software
libre perteneciente a la familia BSD. Esto implica que el código fuente puede ser modificado,
también que estas versiones modificadas pueden ser distribuidas y los binarios resultantes
pueden ser distribuidos sin el código fuente.
Históricamente la arquitectura del servidor OpenLDAP (slapd, Standalone LDAP
Daemon) fue dividida entre una sección frontal que maneja las conexiones de redes y el
procesamiento del protocolo, y una base de datos dorsal o de segundo plano (backend) que trata
únicamente con el almacenamiento de datos. La arquitectura es modular y una variedad de
backends está disponible para interactuar con otras tecnologías, no sólo bases de datos
tradicionales.
En versiones antiguas (1.x), los términos "backend" y "database (base de datos)" podían
intercambiarse. Para ser precisos, un "backend" es una clase de interfaz de almacenamiento, y
una base de datos es una instancia de un backend. El servidor slapd puede utilizar arbitrariamente
varios backends en una sola vez, y puede tener arbitrariamente muchas instancias de cada
backend, por ejemplo varias bases de datos activas por vez.
37
Active Directory
Active Directory está basado en una serie de estándares X.500. Los dominios y
subdominios se identifican utilizando la misma notación de las zonas DNS, razón por la cual
Active Directory requiere uno o más servidores DNS que permitan el direccionamiento de los
elementos pertenecientes a la red, como por ejemplo el listado de equipos conectados; y los
componentes lógicos de la red, como el listado de usuarios.
Un ejemplo de la estructura descendente, es que si un usuario pertenece a un dominio,
será reconocido en todo el árbol generado a partir de ese dominio, sin necesidad de pertenecer a
cada uno de los subdominios.
A su vez, los árboles pueden integrarse en un espacio común denominado bosque, que
por lo tanto no comparten el mismo nombre de zona DNS entre ellos, y establecer una relación
de «trust» o confianza entre los participantes. De este modo los usuarios y recursos de los
distintos árboles serán visibles.
El servicio de directorio Active Directory (A.D.) provee un sin número de servicios
relacionados almacenaje organizado de los recursos de red. Los siguientes puntos destacan
algunas de las características de ésta potente aplicación.
Enfoque organizado: A.D. facilita el orden en una red determinada ya que organiza de forma
eficiente los recursos de red, tales como las cuentas de usuario, cuentas de grupo, carpetas
compartidas, impresoras, entre otros. Con A.D. los usuarios pueden encontrar fácilmente la
información que necesitan.
Remueve las Topologías para los Usuarios: Gracias a esta aplicación los usuarios no saben qué
tipo de topologías se encuentran. Ya que ellos no tienen por qué saber que servidor sostiene los
servicios o donde se encuentran los recursos en la red, solamente encontrar lo necesario para
ellos.
Reducción de dominios de red: Una de las mayores metas de A.D. es hacer que las redes más
grandes sean mejor manejables, por ende reducir de forma lógica los dominios pertenecientes a
esta. Como A.D no tiene límites en la creación de cuentas de usuario, las topologías de red solo
necesitarán el dominio de Windows.
Control de Redes: A.D ofrece un buen nivel de administración de red, en términos de
administración de servidores y equipos de escritorio. Además es posible controlar los recursos
de forma segura e incluso delegar tareas administrativas a otras personas mediante la Delegación
de Control.
Replicación: Una vez que se instala A.D correctamente, éste maneja su propia topología de
replicación. También incluye mayores servicios internos que ayudan a manejar y controlar sus
propios procesos, incluyendo la replicación. Esta característica mantiene a los administradores
fuera de los detalles engorrosos y habilita el software para realizar tareas de replicación cuando
sea necesario.
38
5.1.3 OpenLDAP v/s Active Directory
La idea principal de esta sección es lograr un análisis de los tópicos de evaluación
mencionados en la sección 5.1.2 de éste capítulo para cada una de las tecnologías mencionadas.
El lector se preguntará por qué solamente se eligieron dos aplicaciones, siendo que en el mercado
existen muchas más alternativas que pueden satisfacer las necesidades de la Red del
Departamento de Electrónica. La razón es muy simple; ambas son las más utilizadas en estos
días por las instituciones que poseen redes con alta cantidad de usuarios, y además permiten la
integración de sistemas computacionales externos de forma fácil y segura. A continuación se
procederá a la evaluación de cada una de ellas, para finalizar con un cuadro comparativo y así
lograr identificar de forma más sencilla las diferencias entre estas.
Evaluación en OpenLDAP
Estándares
Una vez instalado el servidor no existe un usuario administrador por lo que se comienza
con un árbol de información DIT vacío, cosa que al agregar la primera entrada ésta pasaría a ser
root del directorio. Lo anterior se transforma en una característica diferenciadora con respecto a
otros productos, incluso en una desventaja en el ámbito de seguridad.
En el archivo de configuración slapd.conf, hay que ser muy cuidadoso al momento de
definir los esquemas de entrada, ya que deben ser puestas en orden ya que no hay que hacer
definiciones de clases de objetos (objectClasses) antes de integrar los atributos que la componen.
En comparación a otros productos, OpenLDAP es bastante estricto en la definición de
atributos. Por ejemplo, al incorporar un atributo seeAlso en una entrada, su valor debe ser una
referencia del tipo DN a otra entrada. Lo anterior genera mayor consistencia, pero es de esperar
que la aplicación haga verificaciones de existencia en la entrada referida, ya que puede ser
engorroso al momento de ingresar en desorden.
Grados de Seguridad
El tema de la seguridad en OpenLDAP es abarcado por dos aspectos de vital importancia.
Uno de ellos es la forma en que acceden los usuarios a un servidor de directorios, y la otra se
refiere a la manipulación de datos que éste posee. Para el primero, como se mencionó en el
capítulo 3, es posible realizar el ingreso a partir de tres métodos: encriptación de contraseñas
mediante texto plano, encriptación mediante SSL o TLS, y certificación sobre SSL.
En cambio al momento de manipular la información del servidor de directorio, existe lo
que se conoce como Control de Acceso. Capacidad que tiene OpenLDAP para discriminar entre
los usuarios según los privilegios que a estos se les han asignado, mediante el archivo de
configuración slapd.conf. La política de control de acceso por omisión permite privilegios de
lectura a todos los clientes. Dependiendo de qué política se encuentre definida el usuario rootdn
tiene todos los privilegios sobre el sistema (autenticación, búsqueda, comparación, lectura y
escritura).
39
Facilidad de Administración
Como OpenLDAP es una aplicación de código abierto, se encuentra orientado para
sistemas operativos UNIX/LINUX, donde prima el uso de línea de comandos. Lo anterior
permite amplias capacidades de administración ya que el proyecto OpenLDAP entrega la
documentación necesaria para todos sus archivos de configuración, como también los que
permiten poblar la base de datos. Con esto para un administrador de redes que tiene a cargo una
red basada en sistemas UNIX/LINUX, le facilita el trabajo de forma ya que mantiene su estilo de
operar.
Cabe mencionar que en la actualidad existen herramientas que permiten manejar el
servidor LDAP, como poder mantenerlo, realizar cambios en las entradas del DIT, y todo de
forma gráfica, como se si estuviese aplicando en Windows. Es el caso de Apache Directory
Studio, un programa desarrollado en Java el cual muestra el contenido del servidor LDAP
pudiendo ingresar de forma remota a la máquina. Otra de ellas es el servidor Webmin, el cual se
instala como proceso aparte de OpenLDAP y permite administrar de forma paralela variados
protocolos de administración de redes, entre ellos LDAP. Con este último se pueden realizar
cambios de contraseñas, manejo de información sobre las sub-arboles que se encuentran en la
red, entre otras operaciones.
Costos y Soporte
Con respecto al tema de costos, al momento de implementar la aplicación en una red
institucional no es necesario recurrir a gastos por licencia de OpenLDAP. Esto se debe a que es
un software de código libre bajo el licenciamiento OpenLDAP Public License, lo cual permite
realizar modificaciones según sea necesario. Con lo anterior se tiene una gran ventaja dado los
requerimientos del Departamento, además de alivianar valores monetarios que pudiesen ser
utilizados en la adquisición de equipamiento como máquinas servidoras y estaciones de trabajo,
llevando a una utilización eficiente del sistema. Es importante resaltar que ésta ventaja no
debiese ser determinante al momento de elegir una tecnología.
La documentación que entrega el proyecto OpenLDAP, como la proyección de
actualización que éste tiene para su producto de servidor de directorio es altamente beneficiosa al
momento de querer utilizarla. Esto se debe a que en la actualidad hay una comunidad avanzada
que tiene como sistema de autenticación OpenLDAP. Además la portabilidad de sistemas
operativos es excelente para redes basadas en sistemas UNIX/LINUX.
Integración de tecnologías
OpenLDAP ofrece un excelente soporte para la integración con otras tecnologías. Entre
ellas se encuentra Samba [5.1] aplicación que permite la dualidad de sistemas operativos para la
integración de cuentas de usuarios bajo un mismo nombre de dominio. A la vez como la idea de
LDAP es unificar la autenticación para los usuarios bajo una cuenta única, esto es aplicable para
aplicaciones web, como sistemas educacionales o académicos, portales de práctica, servicios de
40
correo electrónico, entre otros. Lo anterior es posible gracias a técnicas de programación que
permiten embeber un lenguaje como PHP, PERL, o protocolos como IMAP un sistema web a un
servidor diseñado en OpenLDAP.
Dada la investigación realizada también es posible mencionar que hoy en día es factible
la integración de OpenLDAP junto a Active Directory, para el caso en que una empresa por
ejemplo necesitara tener ambas tecnologías funcionando de forma paralela. Por motivos de
complejidad, en éste estudio no se ha considerado aquel escenario.
Otro aspecto a considerar es la migración del sistema presente como servidor de
directorio que es NIS+. El cual se encuentra instalado bajo un entorno Solaris y con conexión a
clientes en Debian. Al momento de tratar de migrar el sistema es una complicación dada la
antigüedad que posee NIS+ en el Departamento de Electrónica. Por lo que se consideraron
técnicas y procedimientos de migración los cuales serán descritos en el capítulo 6.
Evaluación en Active Directory
Estándares
El bloque de construcción básico de Active Directory es el objeto, un conjunto de
atributos diferenciado y con nombre que representa un recurso de la red. Los atributos del objeto
son características de objetos del directorio. Los objetos se pueden organizar en clases, que a la
vez son agrupaciones lógicas de los del mismo tipo. Los usuarios, grupos y equipos son ejemplos
de clases de objeto diferentes.
Existe el concepto de hoja el cual representa una entidad individual en la red, como
también el de contenedor el cual puede almacenar a múltiples hojas. Ambos, sólo pueden existir
dentro de un dominio. Los dominios se usan para agrupar objetos relacionados con el fin de
reflejar la red de una organización. Cada dominio que se crea almacena información acerca de
los objetos que contiene, únicamente. Actualmente, el límite admitido para el número de objetos
que puede mantener en un dominio es de un millón.
Cuando agrupa dominios relacionados para permitir el uso compartido de los recursos
globales, está creando un árbol. Aunque un árbol se puede componer de un único dominio, se
pueden combinar varios dentro del mismo espacio de nombres en una estructura jerárquica. Los
dominios del árbol se conectan de forma transparente a través de relaciones de confianza de dos
sentidos con seguridad basada en Kerberos. Estas confianzas son permanentes, y no se pueden
eliminar, y transitivas. En otras palabras, si el dominio A confía en el dominio B y el dominio B
confía en el dominio C, entonces el dominio A confía en el dominio C.
Muchos de los atributos que están estandarizados como multi-valuados acá se presentan
como mono-valuados. Esto involucra a atributos importantes como cn, givenName,
telephoneNumber y mail. El hecho es que estos atributos frecuentemente tienen múltiples
valores. Por último cabe mencionar que acá no se incluye la clase de objeto inetOrgPerson por
omisión.
41
Grados de Seguridad
En esta tecnología cada dominio representa un límite de seguridad. El acceso a los
objetos dentro de cada dominio se controla mediante entradas de control de acceso (ACE, Access
Control Entries) contenidas en listas de control de acceso (ACL, Access Control Lists). Estas
opciones de seguridad no cruzan los límites de los dominios. La seguridad basada en Kerberos
proporciona las relaciones de confianza entre los árboles.
El esquema de seguridad usado en Active Directory es el de los más personalizados en el
mercado. Posee una gran cantidad de permisos y combinaciones, permitiéndole al administrador
adecuarse a todos los requerimientos. Ahora bien, la documentación sobre la seguridad no es
muy amplia, ni tampoco sobre la migración a otros productos dado que ésta es una aplicación
privativa.
Facilidad de Administración
Como ésta es una herramienta desarrollada por Microsoft la administración está basada
completamente de forma gráfica. Es decir el uso de ventanas y herramientas visuales le entregan
al administrador de red todo lo que necesita. Desde el punto de vista de la información de lo que
está haciendo el servidor, no es muy buena. Esto porque sus mensajes de error llegan a ser muy
limitados y no proporcionan la cantidad suficiente de información como para determinar el tipo
de problema que está ocurriendo.
Por otro lado Active Directory, tiene la ventaja de que es posible desarrollar módulos
propios para realizar las tareas que el administrador desee sobre el servidor. Estos pueden ser
hechos en C++ o Visual Basic. La replicación también se hace mediante el uso de consolas, lo
cual provee mayor manejo del servidor de directorio.
Costos y Soporte
Nuevamente dadas las características de su fabricante el software es del tipo privativo,
donde el licenciamiento puede ser del tipo usuario o servidor. Más detalles se resaltarán en el
cuadro final comparativo.
La documentación de la aplicación es correcta por parte de los desarrolladores. Cabe
mencionar que esta es permitida solo para ambientes donde se trabaje con Windows, lo cual pasa
a ser una desventaja ante la situación en la Red del Departamento de Electrónica, donde la
mayoría de los sistemas se basan en Linux. La proyección de actualización de Active Directory
es amplia por lo que si se desease realizar algún cambio total sería una excelente alternativa dada
la facilidad de administración permitiendo solucionar problemas con un mejor uso del tiempo.
42
Integración de tecnologías
Como Active Directory es un PDC (Primary Domain Controller) no necesita integración
alguna, menos aún ya que las demás tecnologías en su mayoría están basadas en ambientes
UNIX/LINUX. También permite una integración con DNS, ya que presta aquel servicio
facilitando el llenado de las bases de datos para el caso de las unidades organizacionales. En la
actualidad se han hecho pruebas experimentales donde se ha logrado integrar OpenLDAP junto
con Active Directory.
Para el caso de la migración posterior, resulta difícil ya que ésta es una aplicación
desarrollada por Microsoft, lo cual limita al administrador de red a mantener aquel servidor de
directorio o adquirir comercialmente el próximo que aparezca en el mercado.
43
5.1.4 Cuadro Comparativo
En esta sección se realizará un cuadro comparativo el cual remarca los aspectos más
importantes de cada una de las tecnologías elegidas. Lo anterior llevará a elegir cual aplicación
implementar, de acuerdo a las necesidades que el Departamento de Electrónica tiene hoy en día.
Característica Active Directory OpenLDAP
Fabricante Microsoft Grupo OpenLDAP
Tipo de Licencia Por usuario o Servidor Uso público
Estándares LDAP v3, DNS LDAP, DNS
Plataformas Soportadas Windows Linux, Unix, Windows (Requiere
Samba)
Grados de Seguridad Kerberos Kerberos, SSL, TLS, Certificado
sobre SSL
Autenticación Soportada SSL/TLS Texto Plano, SSHA, SSL/TLS
Administración Externa Software Propietario de Windows. Webmin, Apache Directory Studio.
Migración Sistemas
Similares
No soporta Soporte NIS, NIS+, Novell
Netware.
Integración DNS Sí soporta Sí soporta
Soporte de protocolos y
lenguajes de integración
IMAP, PHP, PERL, JAVA PHP, IMAP, PERL, JAVA, C++
Tabla 5.1: Comparación de servidores de directorio según tópicos de evaluación.
44
Al interpretar la Tabla 5.1, es posible notar algunas diferencias sustanciales entre ambas
aplicaciones. Uno de estas son los estándares soportados por cada uno de éstos. En el caso de
Active Directory (A.D.) en su versión más reciente trabaja con el protocolo LDAP v3, en cambio
para OpenLDAP maneja todas las versiones anteriores a ésta. Por tanto entrega un mayor grado
de flexibilidad para al administrador de red. Lo mismo ocurre con las plataformas soportadas, ya
que A.D por ser propietario de Microsoft solo soporta el uso de sistemas operativos Windows, en
cambio OpenLDAP además de éste con integración Samba, se puede instalar sobre Linux y
Unix. Para el Departamento de Electrónica es una gran ventaja, debido a que la mayoría de los
sistemas, como servidores, aplicaciones web, entre otras, se encuentran bajo licencia pública.
Sólo es posible mencionar las estaciones de trabajo en el los laboratorio que mayoritariamente se
encuentran bajo Windows XP.
Así sucesivamente se pueden observar mayores ventajas en la implementación de
OpenLDAP con respecto a Active Directory, dado que en algunos puntos de evaluación
compatibilizan entre ellas, pero en aspectos de bajo nivel, como la seguridad, el tema de la
autenticación soportada, encriptación de contraseñas difieren con notoriedad. Como ya se había
dicho con anterioridad una diferencia que es importante pero no determinante al momento de
elegir qué implementar, es el costo que tiene para el Departamento el uso de una de ellas. Para
A.D al ser desarrollado por Microsoft y poseer licencia pagada de acuerdo al uso del programa
requiere incurrir en un valor determinado por cada una de las licencias utilizadas. En cambio
OpenLDAP en cualquiera de sus versiones a utilizar no es necesario.
Tal vez el lector se preguntará el por qué no se hicieron pruebas de rendimiento en cada
una de las aplicaciones; esto es porque la idea del trabajo era cumplir la mayoría de los
requerimientos de la Red del Departamento de Electrónica, que consistían en su generalidad
realizar una actualización de los sistemas actuales y realizar una migración satisfactoria y
transparente para los usuarios. Dada la capacidad de equipos en Electrónica y los servicios que
están disponibles para el público, no se considera inminente realizar un análisis de tiempos de
lectura/escritura por ejemplo ya que la aplicación será utilizada por un grupo de personas no muy
alto, no influyendo en sobrecargas de la red.
Con estas aseveraciones quien presenta este trabajo recomienda la implementación de
código abierto OpenLDAP en su versión 2.4, fundamentándose en la evaluación previa, además
de la facilidad al integrar con las tecnologías existentes en el departamento como son el sitio de
práctica, la autenticación en los equipos de red, el sitio de solicitud de memos, y la escalabilidad
que entrega el software para futuros desarrollos.
45
5.2 Análisis y Comparación de Sistemas de Acceso Remoto
Como en la sección de análisis de servidores de directorios para la autenticación se
plantearon los puntos a evaluar, en ésta parte del trabajo se realizará la misma acción. Esto, ya
que se cree necesario imponer los requerimientos principales al momento de decidir que
aplicación instalar. A continuación se hará una breve descripción de cada uno de ellos, para
luego aplicarlos a los softwares seleccionados.
5.2.1 Tópicos de Evaluación
Sobrecarga de la red
Uno de los puntos más importantes al momento de dar permisos de acceso remoto a un
usuario es la sobrecarga de la red a la cual se conecta. Esto se debe a que el flujo de información
que corre puede ser demasiado lo cual provocaría una saturación del sistema en general, incluso
provocando la caída total. Muchas de las aplicaciones analizadas consideran éste tópico, pero de
igual forma se ven afectadas por agentes externos como la conexión fuera de la institución, el
proveedor de internet ISP, o la misma red interna que no se encuentra operando correctamente.
Por tanto es de vital relevancia la asignación de permisos a cierto tipo de usuarios, con
respecto a la manipulación de datos, o a la utilización de aplicaciones interactivas que necesitan
demasiado ancho de banda, que a veces se pueden ver sobrepuesto por el ya asignado.
Seguridad Informática
Básicamente trata de abarcar el tema de seguridad al momento que se realiza una
conexión fuera de la red local, ya que existen muchas formas para poder interrumpir el flujo de
información y así realizar captación de contraseñas o datos, que por vulnerabilidad de software
no se encuentran cifrados. Es por esto que de acuerdo al tipo de red en la que se está trabajando y
la información que se maneja en ella, es posible determinar qué aplicación instalar.
También es necesario recalcar que al hablar de seguridad en la red, es necesario hacer una
vista globalizada sobre qué está pasando en la red en general. Esto, porque no es suficiente
implementar altos estándares de seguridad a la aplicación de acceso remoto, sino que ver que
pasa dentro de la red, dado que siempre pueden existir usuarios maliciosos.
46
Acceso y manipulación de cuentas
Como ya se ha dicho anteriormente es siempre beneficioso para un sistema de este tipo,
que los privilegios de usuario estén claramente asignados. Lo anterior se ve reflejado que al
momento de querer acceder remotamente se pueden realizar manipulaciones de cuentas ajenas al
usuario que ha ingresado, pudiendo causar perdida de información relevante, cambios indeseados
de contraseñas, entre otros inconvenientes.
Es tarea del administrador de red el lograr una correcta asignación de permisos y siempre
regirse bajo las normas de la red sobre la cual se está trabajando. Se hace hincapié a esto ya que
no sería correcto dejar a personas ajenas a la red local realizar cambios o actualizaciones de
forma remota bajo un sistema de acceso remoto.
Requerimientos externos
Finalmente y no menos importante, es imperante analizar la necesidad de requerimientos
ajenos a la aplicación. Entre ellos considerar la instalación de servidores con alta capacidad de
procesamientos, asignación de mayor ancho de banda, instalación y configuración de equipos de
conectividad como firewalls y routers que limiten el acceso a usuarios que impartan técnicas
maliciosas y poco beneficiosas para la red.
Se entregará recomendación de que tipo de dispositivos se instalarán de acuerdo a lo
requerido por la aplicación mencionada, como también cambios en la topología de red actual si
fuese necesario.
5.2.2 Productos a comparar
Como se estudió en el capítulo 4, en la sección de sistemas de acceso remoto, existen
variadas alternativas que pueden satisfacer las necesidades para los usuarios para el
Departamento de Electrónica. Es por ello que se tomará en cada uno de los tipos planteados con
anterioridad, es decir una aplicación que cumpla con ser del tipo escritorio remoto, otra que sea
VNC, y finalmente una que permita implementar una VPN.
Al haber planteado los tópicos de evaluación anteriormente, y no haber mencionado el
tema de costos de la aplicación, se optará por elegir programas que sean de código abierto o
gratuitos, y evocarse directamente en los aspectos de relevancia que puedan determinar la
instalación de una aplicación en vez de otra.
Los programas elegidos para el estudio como sistemas de acceso remoto son los
siguientes:
47
XMing
Xming es una implementación portátil del sistema de ventanas X para sistemas
operativos Microsoft Windows XP, 2003, Vista y Seven. El servidor X Xming está basado en el
servidor X.Org, cruzado en Linux con el compilador MinGW y Pthreads-Win32. Está disponible
con soporte Mesa 3D, soporta una gran variedad de lenguajes y al contrario que Cygwin/X, no
requiere de bibliotecas Cygwin. Para realizar conexiones con servidores remotos utiliza el
protocolo Secure Shell (SSH) para asegurar sesiones X11. Soporta PuTTY y ssh.exe, y tiene una
versión de PuTTY's plink.exe.
Cabe destacar que esta herramienta es capaz de trabajar completamente independiente del
registro de Windows cuando se utiliza la aplicación Xming-portablePuTTY.
6 Instaladores en Windows.
La instalación de éste programa es muy simple al ser realizada por un usuario novato, ya
que es totalmente interactiva, y realizable a través de unos pocos clics. También posee la opción
de instalación y desinstalación vía línea de comandos. A continuación se muestran algunas
imágenes del asistente de instalación.
Figura 5.1: Screenshots del asistente de instalación
Existen tres tipos de instaladores para el programa. Entre ellos es posible encontrar a
Xming, el cual incluye el asistente XLaunch y de forma opcional direcciones hacia clientes SSH
compatibles con Xming. Para lo que es la reproducción 3D utiliza las aplicaciones Mesa,
Microsoft WGL y OpenGL. También provee de Xming-fonts y Xming-portablePutty.
7 Usando Xming.
A continuación se procede a listar una serie de usos de ésta herramienta para lograr el
acceso a sistemas remotos.
Desarrollar un proyecto GUI con servidor de ventanas X en un ambiente Microsoft, por
lo que ésta máquina sería un cliente ligero de un sistema Unix/Linux.
Realizar una ampliación de fuentes como las TrueType en una máquina Windows,
fundamentales que llevaron a la aplicación a ser una de las mejores soluciones, ya que ninguna
solución antecesora lo había logrado. Además hay que considerar que es la solución que menos
problema da en cuanto a los routers que hay entre las conexiones, ya que solo debe estar abierto
el puerto que se ocupa y no depender de que el hardware soporte la tecnología como en el caso
de PPTP o IPSEC. Otra de las utilidades que posee es dar seguridad a las comunicaciones
inalámbricas en redes poco seguras, ya que se usa como puente Ethernet, como comunicación
segura para la autenticación y encriptación entre extremos de una misma red, o de redes
diferentes.
Finalmente OpenVPN no necesita ni depende de tantas librerías o programas como otras
aplicaciones, tan sólo requiere del modulo TUN/TAP antes mencionado. Para administrar
seguridad es posible utilizar la librería “OpenSSL” y para la compresión de información, la
librería “Izo”.
5.2.3 Evaluación de los productos.
Para realizar la evaluación y poder llegar a la decisión final de qué producto implementar
se tomará en cuenta los tópicos mencionados en las secciones anteriores.
Evaluación en Xming
Sobrecarga de la red.
Dado que ésta aplicación permite el acceso de forma remota a un servidor determinado, la
influencia que tiene en lo que respecta a congestión en la red debido al alto tráfico de
información es determinante al momento de elegir la tecnología. Cabe mencionar que ya es
posible utilizar esta aplicación para realizar conexiones con ventanas X al servidor Aragorn del
Departamento de Electrónica. Con esto se pueden acceder a aplicaciones como Matlab para el
uso vía externa por parte de los alumnos. Dado las pruebas realizadas mediante un enlace de 6
MB de velocidad de internet, con VTR como proveedor de servicio, la velocidad con que se
puede utilizar la aplicación es nefasta. La investigación indica que es debido a dos factores
predominantes. Uno de ellos es el tipo de servidor al cual se está conectando y qué sistema
operativo se encuentra instalado en él. En el caso de Aragorn se tienen las siguientes
características:
Intel (R) Xeon (TM) CPU 2.8 GHz
4 Gb en Ram
Debian 3.1
Los datos anteriores demuestran que el servidor Aragorn posee buenas capacidades de
hardware, pero es imperante la actualización del sistema operativo, ya que podría ser una de las
causas de latencias al momento de utilizar Xming. El otro factor corresponde a la topología de
red en la que se encuentra el servidor al que se accede. Como se sabe la topología en la red es de
tipo bus, donde en cada una de las ramas de ésta se encuentran firewalls debidamente
configurados, además cabe tener en cuenta que la asignación de ancho de banda por parte de
50
DCSC (Dirección Central de Servicios Computacionales –UTFSM) es restringida para no sobre
cargar la red institucional. Lo anterior es un aspecto a analizar al momento de implementar un
sistema de acceso remoto.
Seguridad Informática.
Este aspecto se encuentra directamente relacionado con el anterior, ya que pueden existir
usuarios maliciosos quienes realicen operaciones no deseadas para el resto de los usuarios,
produciendo problemas como borrado de cuentas, bloques de autenticación, captación de
contraseñas, saturación total de la red. Para no caer en este error es necesaria una infraestructura
acorde a prevenir los ataques anteriores. Para ello una buena configuración de firewall, con sus
debidas listas de acceso y zonas desmilitarizadas bien configuradas deberían soportar el accionar
negativo de algunos usuarios.
Acceso y manipulación de cuentas.
Como Xming es un entorno de escritorio remoto, es totalmente transparente el tema de
privilegios que cada uno de los usuarios posee. Ya que de ello se encarga el sistema Unix, o el
mismo servidor NFS que ya se encuentra instalado, en conjunto con el sistema de autenticación
que se procederá a actualizar.
Requerimientos externos.
Como requerimientos externos es válido evaluar la compra de servidores más avanzados
para poder implementar el servicio de acceso remoto como corresponde, como así también la
actualización del sistema operativo al cual se pretende dejar como máquina servidora. Además
de esto, es conveniente en llegar a un consenso con el DCSC, para realizar un cambio en las
políticas de asignación de ancho de banda, y así beneficiar y facilitar la implementación de estos
sistemas en el Departamento de Electrónica.
Evaluación en OpenVPN
Sobrecarga de la red.
Para esta herramienta la sobrecarga de la red, es el punto más sensible al momento de
querer implementarla. Esto se debe a que el protocolo VPN da la capacidad de unificar dos redes
distintas que se encuentren en cualquier parte geográfica, lidiando con definiciones de control de
tráfico, routers y firewalls externos (ISP), entre otros aspectos, lo cual genera un amplio uso del
ancho de banda al momento de realizar una conexión. Para el caso del cliente no hay problema,
ya que es decisión de él o no el conectarse a través de VPN, en cambio para la topología que
contiene al servidor, ella puede estar sujeta a otros procesos que dependen de un ancho de banda
ya asignado.
51
Seguridad Informática.
Como OpenVPN trabaja con los protocolos de seguridad SSL/TLS es altamente
recomendable al momento de realizar una implementación de este tipo. Con esto es posible
evitar captación de información o autenticación por usuarios intermedios que son los que
realizan acciones maliciosas en contra de la red institucional. Las técnicas de mensaje cifrado
que utiliza el protocolo VPN son una herramienta potente si se desea privilegiar la seguridad en
la red y así mantener el uso eficiente de ésta.
La gran ventaja que tiene OpenVPN es que si al realizar una correcta instalación y
configuración del sistema, asegura que toda la información que se transmite a través de las redes
involucradas viajará de forma seguro y con baja probabilidad de vulnerabilidad.
Acceso y manipulación de cuentas.
Antes de poder ingresar como usuario a una red determinada, se requiere una previa
autenticación la que depende del sistema Unix en cuestión, del sistema de red de archivos, o el
servidor de directorio que permite autenticar, con cierto tipo de encriptación estipulada. Con ello
de acuerdo a los privilegios de cada uno de los usuarios en el servidor al que se quiere acceder, el
protocolo VPN permitirá manejar la información contenida en su directorio como si estuviese en
la misma red. Para ello es totalmente beneficioso, ya que la universidad provee ciertos servicios
institucionales como la lectura de investigaciones de la IEEE, a los cuales no se pueden acceder
fuera de la universidad. En cambio VPN podría solucionar este problema, ya que asigna a la
interfaz virtual de red en el cliente una dirección IP de la red que posee el servidor VPN.
Requerimientos externos.
Como requerimientos externos hay que hacer hincapié en la correcta configuración de
equipos de conectividad de red, cosa de que esta se encuentre operativa al máximo porcentaje
posible. Además de ser cuidadoso con los servicios adicionales como servicios web,
autenticación, manejo de cuentas de usuario, etc, ya que se si encuentran administrados
incorrectamente conllevarán a una conexión lenta para los que deseen conectarse de forma
remota a través de esta vía.
52
5.2.4 Cuadro Comparativo.
La tabla 3 muestra una vista más específica para tomar la decisión sobre que herramienta
elegir. Esta elección será de acuerdo los requerimientos planteados con anterioridad que son los
que influyen directamente en el departamento de electrónica.
Características Xming OpenVPN
Fabricante
X.Org Fundation OpenVPN Project.
Tipo de Licencia
GPL v2 GPL
Plataformas
Soportadas
Windows Unix/Linux, Windows
Grados de
Seguridad
No especifica protocolos SSL/TLS, certificado
SSL, mensajes cifrados.
Sobrecarga de Red
Alta Alta
Manejo de Cuentas
Permite abrir
aplicaciones
gráficamente
App gráficas, montaje de
disco, asignación de IP
local.
Protocolos de
Comunicación
TCP/IP, SSH TUN/TAP
Requerimientos
Adicionales
Servidor de alto nivel,
equipos de conectividad.
Equipos de conectividad
Tabla 5.2: Comparación Sistemas de Acceso Remoto.
53
Al analizar el cuadro anterior es posible identificar varios factores que influyen en la
implementación de un sistema de acceso remoto para el Departamento de Electrónica. Uno de
los más importantes es la seguridad que hay que mantener al momento de que usuarios externos
ingresen a la red, es por ello que OpenVPN cumple con las expectativas, ya que es la única
aplicación que entrega en detalle qué protocolos de seguridad maneja, en comparación a las
otras.
Una de las características de OpenVPN que se sobrepone ante las demás analizadas, es
que al momento de realizar una conexión de éste tipo, el usuario que se encuentra remotamente,
pasa a tener una dirección IP local, lo cual le permite acceder a variados servicios sólo utilizables
para el departamento de electrónica. Cabe mencionar, que hoy en día existen técnicas a través del
protocolo SSH, realizando túneles con puertos de escucha, pudiendo así hacer lo que se
mencionaba con anterioridad, pero no es considerado un método transparente para los usuarios.
Como hoy es posible acceder a través de Xming al servidor de alumnos “Aragorn”, la
conexión remota no es totalmente suficiente debido a que la asignación de ancho de banda no
acompaña a que ésta aplicación funcione correctamente. Es por esto que se recomienda el uso de
esta aplicación sólo de forma local. En cambio dadas las características que tiene OpenVPN, el
uso masificado en grandes redes institucionales, quien presenta este trabajo recomienda el uso de
esta tecnología. En el año 2001 se realizó el trabajo de título “Implementación de una VPN sobre
Linux para la red de computadores del Departamento de Electrónica” [5.2] donde se analiza la
implementación de una red VPN en el Departamento de Electrónica. Por ende, se propone el
estudio y aplicación de esta tecnología, a través de un futuro trabajo de título utilizando
distribuciones de Linux actuales y así poder hacer uso de sus recursos eficazmente.
54
Capítulo 6
Resultados
El presente capítulo abarca variados aspectos sobre la implementación final que se
realizará en el departamento de electrónica junto con el plan de acción a seguir por el
administrador de red de turno al momento de realizar la migración del sistema de autenticación
actual (NIS+) por OpenLDAP. Además entrega información sobre lo que podría ser
implementado como sistema de acceso remoto para los usuarios, es decir alumnos, profesores y
funcionarios.
Cabe mencionar que los resultados presentados no han sido puestos en marcha en la red
de electrónica por diversos motivos. Entre ellos, la necesidad de adquirir nuevo hardware, como
también realizar el cambio una vez que haya un menor uso de la red, y así evitar caídas que
puedan comprometer a los usuarios. Lo anterior se tomó en cuenta, al momento de realizar el
plan de acción para la implementación y migración final.
6.1 Sistema de Autenticación
Esta sección describe principalmente las aplicaciones y el hardware necesario para la
migración del sistema NIS+, que hoy en día se encuentra obsoleto, ya que dificulta la realización
de las actualizaciones que influyen en el desarrollo de los cursos impartidos por el
Departamento. Además se destacan lo scripts realizados por quien presenta éste trabajo, ya que
con ellos será posible la migración del sistema. Lo anterior es de mucha importancia, ya que en
la actualidad no existen aplicaciones que permitan realizar un cambio desde NIS+ (bajo Solaris
8) a OpenLDAP + Samba (bajo FreeBSD 7.2).
6.1.1 Recursos de Hardware y Software
Al momento de realizar la implementación de prueba, que es de la que se tratará esta
sección, se utilizaron diversos recursos. A continuación se procederá a especificar cada uno de
ellos, para así interiorizar al lector al momento de realizar la instalación final.
Dell Inspiron 1464: Esta herramienta permitió la implementación de diversas máquinas
virtuales, que sirvieron como servidor/clientes de pruebas para la instalación del sistema
pensado. Sus características son:
Procesador Intel Core i5 2.4 Ghz.
4 GB de Memoria Ram.
Sistema Operativo Base Windows 7 Home Edition.
Disco duro 500 GB.
55
PC Lab Kleinrock: El equipo mencionado permitió implementar un servidor, bajo una
dirección Ip pública dentro de la universidad, al cual se puede acceder dentro de la intranet. Su
propósito es la conexión con el servidor IMAP actual, para tener acceso a las cuentas de usuarios
de Electrónica. Sus características son:
Procesador Intel Core 2 Duo 2.0 Ghz.
1 GB de Memoria Ram.
Sistema Operativo FreeBSD 7.2
Disco Duro de 120 GB.
Sistemas Operativos: Los S.O utilizados fueron los siguientes:
FreeBSD 7.2 – para la instalación del servidor de directorio y autenticación central.
Ubuntu 10.10 – como cliente de acceso bajo el licenciamiento Linux.
Windows XP – como cliente de acceso bajo el licenciamiento Windows.
Windows 7 – S.O base al momento de virtualizar las máquinas.
Perl 5.8: Lenguaje de programación en el cual se basa la mayor parte de la aplicación smbldap-
tools, ya que sus scripts se encuentran desarrollados en él. Cabe mencionar que además los
programas realizados para la migración del sistema se hicieron en Perl.
OpenLDAP 2.3: Aplicación de servidor de directorio y autenticación utilizada como sistema
final para la migración y actualización de las cuentas de los usuarios del Departamento. Como se
mencionó en el capítulo 4, posee licenciamiento de uso público, además cumple con altos
estándares de seguridad, tanto en el ámbito de conexiones como de encriptación de contraseñas.
Para el primero cabe mencionar, que hace uso de SSL o TLS, en cambio para el segundo, utiliza
protocolos como MD5 y SHA.
Samba 3.4: Aplicación que permite la compartición de archivos y cuentas de usuario dentro de
redes Windows/Linux. Lo anterior fue un factor determinante al momento de elegir la aplicación
a instalar, ya que uno de los requerimientos base de este trabajo es que se permita dualidad de
sistemas operativos en las máquinas clientes de la red de Electrónica.
Smbldap Tools: Esta herramienta fue muy necesaria, ya que cuando se deseen hacer manejo de
los usuarios de la red, es decir, agregarlos, borrarlos, cambiar sus permisos, cambiar sus
contraseñas, estas opciones se vean reflejadas de forma inmediata tanto en el servidor LDAP
como en el servidor Samba, evitando tener dos procesos distintos y dando transparencia para los
usuarios involucrados.
Módulo PAM: Este modulo es el que permite la migración de las cuentas Unix a las de LDAP y
Samba, ya que para que se haga efectivo el uso de éstos servicios la adquisición de nombres de
usuarios, contraseñas y el acceso vía SSH es posible gracias a la utilización de éste modulo en el
servidor principal.
56
Postfix: Servidor de correo electrónico, utilizado en este caso para integrar los sistemas web del departamento correspondientes al sitio de prácticas y al de solicitud de memos. Para ello se instaló en el servidor de prueba y así lograr acceso a las cuentas creadas en el servidor LDAP.
Apache Directory Studio: Es una aplicación desarrollada en Java, la cual permite visualizar conexiones a diversos servidores LDAP. Ésta muestra el árbol de información de directorio (DIT), de cada uno de ellos, incluyendo información de los usuarios y grupos pertenecientes a la red, junto a sus atributos.
6.1.2 Proceso de Implementación
El proceso de implementación de prueba, permitirá sentar las bases para la instalación del sistema final, abarcando todos los detalles necesarios para tal tarea. Entre estos es posible mencionar las aplicaciones necesarias junto a sus versiones específicas, los permisos que se deben otorgar a cada una de ellas, entre otros aspectos que se mencionarán más adelante. La Figura 6.1 representa los procedimientos realizados para lograr una correcta actualización del sistema.
Figura 6.1: Procedimiento de implementación servidor LDAP + Samba.
El esquema anterior fue subdividido en varias fases las que se proceden a explicar.
Fase de Planificación: En esta instancia se planificó junto con el administrador de la red, cómo sería el árbol de información de directorio (DIT) para el servidor LDAP. Esta etapa es muy importante ya que permitió tener una visión general de la estructura del servidor de directorio, y así poder asignar los permisos de usuario de acuerdo a las necesidades de cada uno de ellos.
Fase de instalación I: Consiste en la instalación de todos los servidores para hacer factible el sistema de integración de cuentas. Esta se diferencia con la siguiente etapa, ya que en caso de cualquier falla de la instalación, por ejemplo, en el servidor OpenLDAP es necesaria la reinstalación del sistema operativo base o realizar un análisis exhaustivo de las dependencias del
Definición
del DIT
Instalación Servidor
LDAP
Instalación Servidor Samba
Instalación Servidor Postfix
Agregando
Usuarios
Agregando Máquinas Clientes
Casos De
Prueba
Migración
Fase de planificación Fase de instalación I
Fase de instalación II Fase Final
57
programa. Además al momento de instalar el módulo PAM, hay que ser extremadamente
cuidadoso ya que si no se hace de forma correcta no será posible acceder a la máquina servidora.
Fase de instalación II: Estando en ésta etapa, no es necesaria la reinstalación del sistema
operativo si es que se llega a cometer un error. Por ende se destaca que es acá donde se realice la
agregación de usuarios o casos de uso para el sistema.
Fase Final: Una vez probado todo el sistema instalado, y habiendo agregado algunos usuarios,
es posible realizar los casos de uso designados, para finalizar con la migración de los usuarios
actuales del departamento de electrónica.
En las siguientes secciones se procederá a detallar cada uno de los procesos realizados,
mostrando imágenes e indicaciones que permitan al Administrador de Red de turno realizar una
implementación exitosa.
58
Definición del árbol de información de directorio (DIT)
El árbol de información de directorio, es capaz de mostrar una subdivisión de los usuarios presentes en una red del tipo institucional. La figura 6.2 representa la situación en el Departamento de Electrónica.
Figura 6.2: DIT diseñado para el departamento de electrónica.
La figura 6.2 es el DIT planificado para la implementación del servidor de directorio OpenLDAP en el Departamento de Electrónica. Con éste se hace una subdivisión principal de acuerdo a lo que representa cada usuario para la institución. Además esto se ve reflejado en los servicios a los cuales cada uno de ellos puede acceder. Por ejemplo, en la actualidad el servidor “Aragorn”, es accesible tanto por usuarios como por profesores, en cambio los últimos también poseen un servidor dedicado para uso académico exclusivo.
Dc=elo, dc=utfsm, dc=cl
Ou=People
Ou=Groups
Ou=Computers
Ou=Idmaps
root
Alumnos
ELO
Alumnos TEL
Profesores
Staff
Alumnos ELI
Otros Usuarios
Alm96 ….. ……
Alm2010
Tel2004 ….. ……
Tel2010
prof
staff
ramos
otros
59
De acuerdo a como se plantea un DIT bajo el protocolo LDAP, en el apartado de
“personas”, se localizan todos los usuarios pertenecientes a la red, en cambio es en la sección
“grupos” donde se diferencian cada uno de ellos. Para la implementación de este proyecto se
realizó la siguiente asignación:
Prof: profesores del departamento de electrónica tanto de planta como de jornada parcial.
Alm96 – Alm2010: Alumnos de las carreras Ingeniería Civil Electrónica e Ingeniería en
Ejecución Electrónica desde los años 1996 al 2010. En Alm2003 se incluyen a los
alumnos de Ingeniería Civil Telemática con ingreso en el año 2003.
Tel2004 – Tel2010: Alumnos de Ingeniería Civil Telemática desde los años 2004 al
2010.
Staff: Incluye a las secretarias del departamento de electrónica, gente de taller y pañol.
Eli: Incluye a los alumnos de la carrera Ingeniería Civil Eléctrica.
Otros: Incluye a alumnos de otras carreras que cursan ramos del departamento de
electrónica.
Ramos: Cuentas designada para ciertos ramos del Departamento de Electrónica, las
cuales son comunitarias para los alumnos que cursan las respectivas asignaturas.
Cabe mencionar, que la estructura anteriormente ilustrada representa en gran parte como
hoy están organizados los usuarios en el departamento de electrónica mediante NIS+. No se
realizaron muchas modificaciones, para facilitar la migración y la asignación de directorios para
cada uno de ellos.
Servidor OpenLDAP
OpenLDAP 2.3 es la aplicación seleccionada para la implementación del servidor de
directorio y sistema de integración de cuentas. Como se ha mencionado en capítulos anteriores
ésta es de licencia pública por lo que es totalmente modificable de acuerdo a las necesidades del
Administrador de Red. Uno de sus archivos principales es “slapd.conf”, el cual contiene todas las
configuraciones pertinentes para su correcto funcionamiento. Dentro de sus varias opciones es
posible mencionar la asignación de un usuarios administrador del servidor LDAP, el cual posee
todos los privilegios de creación, eliminación y modificación de cuentas de usuarios. Como
OpenLDAP maneja variados tipos de encriptación de contraseñas, es posible incluir la del este
usuario privilegiado de forma cifrada por efectos de seguridad.
Dentro de los otros parámetros que se agregan en “slapd.conf” se puede nombrar los tipos
de índices que el servidor manejará. Esto quiere decir, los atributos que se le asignarán a cada
uno de los usuarios o máquinas que se agregarán a la red. Finalmente una de las características
más importantes de éste archivo, que es acá en donde se indican la ubicación de las librerías que
hacen posible la integración con programas externos a LDAP, como por ejemplo el módulo de
autenticación PAM y el módulo Samba que permitirá la integración entre ambos. En la figura 6.3
se muestra un segmento del archivo mencionado.
## Librerías externas a LDAP.
include /usr/local/etc/openldap/schema/core.schema
60
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/misc.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/openldap.schema
include /usr/local/etc/openldap/schema/samba.schema
## Nombre de dominio Base.
suffix "dc=elo,dc=utfsm,dc=cl"
## Usuario administrador de LDAP
rootdn "cn=Manager,dc=elo,dc=utfsm,dc=cl"
rootpw {SSHA}2pCGrVMhMh3cC+LakUXApebb9jwICf5e
## Indices y atributos en LDAP
index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUID eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
Figura 6.3: Extracto de archivo de configuración slapd.conf
Otra aplicación necesaria al momento de instalar un servidor OpenLDAP es la aplicación
“nss-ldap” descrita en el RFC2307, la cual permite traducir información como nombres de
usuarios, contraseñas, directorios de usuarios, almacenadas en un sistema Unix al lenguaje
manejado por el protocolo LDAP. Es acá donde se indican las unidades organizacionales bases
del servidor, que luego han sido subdivididas de acuerdo al DIT descrito en la sección anterior.
La figura 6.4 muestra una parte del archivo “nss_ldap.conf”.
Para que un usuario pueda ingresar a una máquina con Windows XP, mediante
autenticación LDAP, es necesaria la implementación de Samba. Este programa permite integrar
redes de sistemas Unix/Linux con los de Microsoft. Para ello se instala la herramienta “smbldap-
tools”, aplicación para FreeBSD que permite crear usuarios para el servidor LDAP y Samba
simultáneamente. La Figura 6.5 grafica el recuadro de autenticación para un usuario que desea
ingresar a su cuenta.
Figura 6.5: Autenticación de usuario en Windows.
En la figura anterior es posible apreciar el dominio al cual se conecta el usuario, el cual
en este caso es ELONT. Una vez autenticado, ingresa a una sesión de Windows XP donde es
posible acceder a su disco virtual, que en realidad es un espacio en el servidor
OpenLDAP/Samba y no uno en la máquina a la cual está accediendo. La Figura 6.6 muestra
como se crea la unidad mencionada.
63
Figura 6.6: Disco virtual en cliente Windows XP
Hasta acá si el usuario ha realizado la autenticación como corresponde, puede realizar
todas sus tareas en cualquiera de las máquinas pertenecientes al dominio ELONT, almacenando
toda la información en el servidor principal.
2) Ingreso a cliente Linux
Como uno de los requerimientos era la dualidad de sistemas operativos en las estaciones
de trabajo de la Red del Departamento de Electrónica, el servidor de directorio debe soportar
autenticación a clientes con Linux. Para este caso se usó Ubuntu Desktop 10.10, además para su
funcionamiento es necesario instalar en cada uno de los clientes la librería “nss-ldap” que
permite realizar conexión con el servidor principal. Además para el proceso de autenticación se
requiere implementar el módulo PAM (Pluggable Authentication Module) mencionado en las
secciones anteriores. La Figura 6.7 muestra el recuadro de autenticación para ingresar a un
cliente Linux.
64
Figura 6.7: Autenticación de usuario en Linux
Con lo anterior el usuario puede ingresar a una máquina con sistema operativo Ubuntu
10.10, en cual puede realizar todas sus tareas y almacenando la información de forma local y
replicándose al servidor de directorio.
3) Ingreso por SSH
Para hacer posible el ingreso de los usuarios al servidor OpenLDAP vía SSH, es
necesaria la instalación y configuración del módulo PAM descrito en el Anexo A3. La
configuración que se realiza es muy rigurosa, ya que si se hace de forma incorrecta, es posible no
volver a tener acceso al servidor llevando a la tarea de reinstalar el sistema operativo. La Figura
6.8 presenta el método de prueba para el acceso SSH. Para ello se utilizó el programa SSH
Security Shell, que permite conectarse a un servidor de forma remota a través del protocolo SSH.
65
Figura 6.8: Autenticación en servidor OpenLDAP vía SSH
Una vez que el usuario ingresa a su cuenta en el servidor, tiene acceso a las aplicaciones
basadas en Unix, de acuerdo a los privilegios asignados. Con esto es posible realizar tareas de
compilación códigos fuentes, exportación de ventanas X dependiendo de la aplicación que se
quiera hacer correr, entre otras funcionalidades.
Figura 6.9: Consola Unix que dispone el usuario
La Figura 6.9 grafica la consola que dispondrá el usuario, junto a la ruta que le pertenece
para almacenar sus datos. De acuerdo a los permisos asignados por el administrador, un usuario
66
del tipo alumno, profesor o administrativo sólo podrá acceder a su carpeta personal, sin poder
alterar la de los demás.
4) Integración de Sistemas Web
Este tópico se refiere a la posibilidad de unificación de cuentas de usuarios, para la
realización de variadas tareas dentro de la red. Una de ellas es poder integrar las cuentas en el
servidor OpenLDAP con los sistemas web existentes en el Departamento y entregar una pauta
para futuros desarrollos. En la actualidad existen dos aplicaciones Web en Electrónica que
utilizan las cuentas de usuarios en el servidor NIS+ para lograr autenticación. Para ello se
conectan al servidor de correos IMAP el cual pasa a ser un puente entre el sistema Web y el
servidor NIS+.
Uno de los objetivos de este trabajo es facilitar el desarrollo de este tipo de aplicaciones
con respecto a la autenticación, por lo que el sistema propuesto, es decir OpenLDAP, permitirá
que los programadores se conecten directamente a él. A continuación se presentarán tres casos de
pruebas realizados para corroborar la unificación de cuentas, los cuales se pueden tomar como
recomendaciones de desarrollos futuros.
Sitio de prueba – conexión PHP/LDAP
Para este caso se utilizó un servidor Ubuntu 10.10 con el software LAMP instalado, el
cual incluye PHP5, MySQL y Apache2, además se necesitó instalar la librería “ldap-utils” la que
convierte al servidor web en un cliente LDAP, y así poder utilizar todos los comandos de éste
último. También se instaló la librería “PHP5-LDAP”, la cual entrega soporte de PHP para
LDAP, y así realizar todas las sentencias de conexión y manipulación en el código fuente.
La Figura 6.10 muestra la página principal donde el usuario puede autentificarse, de
acuerdo a los datos almacenados en el servidor OpenLDAP.
67
Figura 6.10: Vista de autenticación contra OpenLDAP
Una vez que el usuario ingresa sus datos, éste puede haberlo hecho de forma incorrecta
por lo que el sitio de prueba se lo avisará. La Figura 6.11 muestra el caso en que el usuario haya
ingresado los datos incorrectamente o no exista.
Finalmente existe el caso en que el usuario logra autenticarse contra OpenLDAP, en
donde se pueden obtener todos los datos de él que se encuentran almacenados en el servidor de
directorio, lo que puede ser útil en caso de realizar un sistema Web relacionado a los ramos que
imparte el departamento, donde cada uno de los alumnos inscritos tiene que estar autenticado. La
Figura 6.12 muestra el caso en que el usuario se realizó una autenticación exitosa.
68
Figura 6.11: Autenticación incorrecta contra OpenLDAP
Figura 6.12: Autenticación correcta contra OpenLDAP
Cabe mencionar que como este trabajo no tiene como objetivo el desarrollo de un sistema
web, el sitio de prueba que se desarrolló fue bien simple, con el fin de dar a entender que es
exitosa la autenticación contra OpenLDAP. A continuación se muestra un segmento del archivo
“slapd.log” correspondiente a las acciones que realiza el servidor OpenLDAP.
Figura 6.13: Log de conexión contra OpenLDAP
La Figura 6.13 muestra información del servidor OpenLDAP al momento que el usuario
“bvasquez” se conecta a éste, mostrando a que sección del DIT pertenece. En ningún muestra la
contraseña que utilizó para identificarse.
69
Figura 6.14: Código fuente PHP para conexión LDAP
Finalmente la Figura 6.14 grafica el código fuente utilizado para la conexión de un cliente
o servidor Web contra el servidor OpenLDAP que se encuentra en este caso bajo la dirección Ip
192.168.220.143 con el puerto 389 abierto para este tipo de conexión. Cabe mencionar que el
puerto 389 es el de omisión para la conexión LDAP.
70
Sitio de prueba – conexión IMAP/LDAP
Como se mencionó anteriormente tanto el Sitio de Prácticas como el de Solicitud de
Memos realizan la autenticación en contra del servidor IMAP, quien luego se autentica contra
NIS+, por ende para no realizar cambios en la programación de estos sistemas, es necesario que
con OpenLDAP pueda realizar lo mismo. Es decir, primero el usuario se autentica contra IMAP
para después hacerlo contra OpenLDAP.
Para que lo anterior fuese posible, en el servidor OpenLDAP de prueba se instaló
Dovecot, con Postfix. La explicación de cada uno de los pasos se encuentra en el Anexo A5. De
igual forma que para el caso de prueba anterior se desarrolló un sitio de autenticación hecho en
PHP, pero la conexión se realiza contra el servidor IMAP quien a contiene en sus registros los
datos del servidor OpenLDAP. La Figura 6.15 muestra la página en la que el usuario se
autenticará.
Figura 6.15: Vista de autenticación contra IMAP
Las vistas de autenticación correcta e incorrecta son iguales que en la Figura 12 y
Figura11 respectivamente.
Finalmente para dar un mejor entendimiento al lector de cómo es posible mediante PHP,
conectarse a un servidor IMAP, se entrega un segmento de código fuente el cual hace posible
esta acción. La Figura 6.17 representa el código de conexión de IMAP donde la dirección IP
192.168.220.135 corresponde a la dirección del servidor OpenLDAP + IMAP, en el cual se hizo
la prueba.
71
Figura
6.17: Código fuente PHP para conexión IMAP
Al lograr interpretar el código anterior, es posible darse cuenta que en ningún momento
se interactúa con conexiones directas hacia el servidor OpenLDAP, sino que solamente hacia
IMAP. Para que esto sea posible, IMAP tiene que estar configurado de manera tal que se integre
con el servidor OpenLDAP, lo cual está descrito claramente en el Anexo A5
72
Sitio de Solicitud de Memos – conexión IMAP/LDAP
Para probar la autenticación de usuarios bajo OpenLDAP en el sitio de solicitud de
memos, se implementó un servidor de prueba con la dirección IP 200.1.17.47/128 el cual se
encuentra dentro de la red de Electrónica. Para ello se realizó un cambio en el código Perl que
permite la autenticación contra IMAP en la actualidad. La Figura 6.18 corresponde a la vista de
usuario para realizar la autenticación y así solicitar memo para el uso de la sala B-351.
Figura 6.18: Vista de autenticación Sitio de Solicitud de Memos
Al observar la Figura 6.18, en el indicador de “password” se indica introducir la
contraseña Unix. Esto debido a que en la actualidad la contraseña de Unix y Samba
eventualmente pueden ser distintas, cosa que con la implementación de OpenLDAP y Samba se
integran de forma automática.
Para entregar una referencia de la modificación que se hizo en el sitio de Solicitud de
Memos, la Figura 6.20 muestra un segmento del código modificado. Este cambio refiere sólo a la
dirección IP del donde se encuentra el servidor IMAP junto con OpenLDAP.
73
Figura 6.20: Código fuente Perl para conexión IMAP
Para el caso anterior se crea una variable llamada $imap, la cual llama a la librería
“Imap::Client”, para poder hacer conexión con el servidor dada una dirección IP o un nombre.
Luego procede a la autenticación mediante las variables $user y $pass, las cuales son pasadas
desde el HTML mostrado en la Figura 6.18.
Todos los scripts de prueba desarrollados para la utilización de OpenLDAP con sitios
web, se encuentran en el Anexo A6.
74
Sistema de Gestión de Prácticas – conexión IMAP/LDAP
Para realizar las pruebas pertinentes en el Sistema de Gestión de Prácticas (SGP) del
Departamento, se utilizó la aplicación de respaldo, es decir, el SGP2, la cual tiene como objetivo
realizar pruebas de desarrollo para su mejoramiento. De igual forma que con el sitio de Solicitud
de Memos, los cambios a realizar son muy pequeños, y radican directamente en la dirección IP
del servidor IMAP + OpenLDAP, que para este caso sigue siendo 200.1.17.57. La Figura 6.21
corresponde a la vista de autenticación de usuario al momento de ingresar al sitio.
Figura 6.21: Vista de autenticación SGP 2
Finalmente se entrega un extracto del código fuente el cual permite la conexión con el
servidor de correo. La Figura 6.23 muestra la modificación en la variable $MAILSERVER,
donde se asigna la dirección IP 200.1.17.57, en el puerto 143 utilizado por el servidor de correo.
75
Figura 6.23: Código fuente PHP para conexión IMAP
Además se puede destacar las funciones “imap_open”, donde se pasan los parámetros
necesarios para establecer conexión y autenticarse contra el servidor.
76
6.1.4 Migración de cuentas de usuario
Esta sección explica el procedimiento para realizar la migración de las cuentas de los usuarios del Departamento de Electrónica, desde el servidor con NIS+ al nuevo servidor que almacenará la aplicación OpenLDAP. Uno de los principales desafíos es que este proceso sea, en su mayor parte, transparente para los usuarios involucrados, y así evitar las incomodidades que conlleva un proceso de actualización del sistema. Cabe mencionar que los scripts involucrados en el proceso se encuentran en el Anexo A7 junto al modo de utilización de éstos y los programas necesarios para que funcionen correctamente.
Se utilizaron tres archivos que se encuentran en el Anexo A7. A continuación se describe la funcionalidad de cada uno de ellos:
Cuentas.txt: Archivo que contiene todas las cuentas de usuario Unix, desde el año 1996 al 2010. Facilitado por el Administrador de Red del Departamento de Electrónica.
Usuarioldif.pl: Script desarrollado en Perl, el cual capta el archivo cuentas.txt, hace separación de los parámetros de acuerdo al patrón “:”, agrega las sentencias necesarias de la aplicación “smbldap-tools”, y los agrega para cada uno de los usuarios
almacenándolos en el archivo migración.sh. Migracion.sh: Script desarrollado en Bash, el cual contiene las sentencias de smbldap-
tools para cada uno de los usuarios, que al ejecutarse se cargan en el DIT diseñado previamente.
La Figura 6.24 presenta el proceso de desarrollo de los scripts de migración que harán posible la actualización del sistema de autenticación.
Figura 6.24: Proceso de Migración de Usuarios
Archivo Cuentas.txt
Archivo Usuarioldif.pl
Archivo Migración.sh
Mediante la función Split() perteneciente a Perl, se
almacenan en un arreglo los parámetros del archivo cuentas.txt, que están
separados por el patrón “:”
El script usuarioldif.pl escribe en el archivo migración.sh
todos las sentencias de smbldap-tools para la
creación de usuarios y así los carga en el DIT
77
Una vez creado el script migración.sh con las sentencias de smbldap-tools para cada uno de los usuarios del Departamento, se realizan tres procesos para cada usuario que son descritos en la Figura 6.25.
Figura 6.25: Proceso de carga de usuario en DIT
Los programas “smbldap_useradd”, “smbldap_passwd” y “smbldap_groupmod”,
pertenecen a la herramienta “smbldap-tools”. El modo de utilización y las opciones disponibles
se encuentran explicados en el Anexo A7.
Otro de los aspectos considerados al momento de realizar la migración, es que las contraseñas originalmente guardadas en el archivo cuentas.txt, se encuentran encriptados bajo MD5, el cual es compatible con OpenLDAP, pero al realizar las pruebas pertinentes existían ciertas inconsistencias, lo cual se debe al UID con que fue creado el usuario en la máquina con NIS+, que es distinto al que se le asigna por omisión en la máquina con OpenLDAP. La solución que se planificó a éste problema, fue la creación de un portal Web, que se encontrará en el sitio http://rce.elo.utfsm.cl, y que por efectos de seguridad solo se podrá acceder dentro del Departamento de Electrónica.
Para hacer factible la solución propuesta, todos los usuarios ingresarán al sitio a través de su cuenta Unix actual (la de NIS+), donde luego se procederá a cargar la contraseña que el usuario desee en el servidor OpenLDAP. La Figura 6.26 corresponde a la vista de autenticación.
Figura 6.26: Vista de login para migración de cuentas
Luego si el usuario se ha autenticado correctamente ingresará a la página mostrada en la Figura 6.27, en donde se le pide ingresar la nueva contraseña dos veces por efecto de seguridad, y así evitar que las actualice de forma errónea. Por temas de seguridad el código sólo se entregará al Administrador de Red de turno.
Figura 6.27: Vista de de usuario correctamente autenticado
El proceso lógico que tiene la aplicación que cargará las nuevas contraseñas en el servidor OpenLDAP será el siguiente:
Figura 6.28: Proceso de Actualización de Contraseñas
Los cuadros rellenos en azul, corresponden al accionar del usuario al enfrentarse al sitio web de actualización de cuentas, en cambio los que se encuentran en verde son parte del procesamiento interno de la aplicación, que no será descrito en detalles por efectos de seguridad del resto de los usuarios del Departamento de Electrónica. Para mayor información sobre el proceso de implementación del sistema de autenticación y la migración desde NIS+ a OpenLDAP, revisar los anexos propuestos.
Autenticación IMAP
Datos cargados en OpenLDAP
Ingreso de Usuario
Usuario actualiza cuenta
79
Capítulo 7
Conclusiones y Trabajo Futuro
El presente trabajo entrega una representación del proceso preliminar de migración de
cuentas de usuarios del Departamento de Electrónica. Para ello se incluyen propuestas de
implementación en servidores de pruebas, que cumplen en su mayoría con los requerimientos
actuales de Electrónica. Se abarcaron dos tópicos principales, el estudio de un nuevo sistema de
autenticación/directorio, y el de acceso remoto. Para el primero se logró una implementación que
corresponde al uso de la herramienta OpenLDAP integrado con el servidor Samba. Con esto es
posible cumplir requerimientos como la dualidad de sistemas operativos en las estaciones de
trabajo de los laboratorios, la integración de los sistemas Web existentes y los próximos a
desarrollarse en el Departamento, la utilización de protocolos como SSH utilizando las cuentas
creadas en OpenLDAP. Con lo mencionado se entrega una propuesta de migración de las cuentas
de usuario en NIS+ (sistema de autenticación actual) a las de OpenLDAP. Para ello se
desarrollaron scripts que permiten realizar las modificaciones pertinentes, y un pequeño sistema
Web para la actualización de las contraseñas de los usuarios de Electrónica.
En el caso del sistema de acceso remoto, se estudió la posibilidad de seguir utilizando
sistemas de ventanas X, lo cual producía un alto consumo de la red, por lo que se optó por
recomendar la implementación de una red VPN, bajo la aplicación de código abierto OpenVPN.
Para este caso se utilizaron las recomendaciones dadas en la memoria “Implementación de una
VPN sobre Linux para la red de computadores del Departamento de Electrónica”, dejando la
opción como trabajo futuro.
Con todo lo realizado es necesario mencionar la importancia de la actualización de los
sistemas informáticos de Electrónica, dado que a medida que pasa el tiempo muchos de los
requerimientos de los usuarios como también de las asignaturas impartidas en el Departamento
se han visto limitadas a los recursos actuales. Es el caso del servidor de alumnos “Aragorn”,
donde no es posible utilizar gran parte de las herramientas actuales para el área de redes de
computadores y sistemas operativos, debiéndose a lo obsoleto de su distribución y sus
características de hardware.
Con respecto a los trabajos futuros relacionados al tema estudiado, es posible mencionar
la implementación final del nuevo sistema de autenticación. Este proceso se recomienda
realizarlo en periodo de vacaciones de alumnos y funcionarios, ya que se podría incurrir en
problemas de acceso para ellos. Además se pretende comprar servidores nuevos, que sean
compatibles con el sistema operativo FreeBSD 7.2, distribución utilizada para la implementación
de prueba. Lo anterior se desataca, debido a que el sistema base de autenticación NIS+ se
encuentra en Solaris 8. Con respecto a la migración de las cuentas es necesario dar un periodo de
actualización d contraseñas, cosa que los usuarios puedan ingresar sin ningún problema después
que el servicio OpenLDAP esté funcionando.
80
Se recomienda que el trabajo de implementar un servidor OpenVPN para el
Departamento de Electrónica sea realizado como un trabajo de título complementario al que ya
existe, realizado el año 2001. Esto, debido a que en la actualidad existen sistemas operativos más
sofisticados y con muchas mejoras con respecto a Debian 3.1, distribución utilizada en el
proyecto “Implementación de una VPN sobre Linux para la red de computadores del
Departamento de Electrónica”. Cabe destacar que el concepto de una red VPN es el mismo, con
ciertas variaciones en aspectos de seguridad, pero de igual forma permite un uso eficiente de los
recursos de red del Departamento accediendo de forma remota.
81
Referencias
[1.1] Soporte Microsoft. Introducción a Active Directory [en línea] <
Lightweight Directory Access Protocol (v3): UTF-8 Strign Representation of
Distinguished Names [RFC 2253]
The String Representation of LDAP Search Filters [RFC 2254]
The LDAP URL Format [RFC 2255]
A Summary of the X.500(96) User Schema for use with LDAP v3 [RFC 2256]
Cabe mencionar que LDAP Versión 3 extiende a su predecesor en las siguientes áreas:
Referencias: Un servidor que no almacene la información pedida, puede enviar al cliente
una referencia hacia otro servidor.
Seguridad: Autenticación extensiva usando el mecanismo de Simple Authentication and
Security Layer (SASL)[RFC 2222]
Internacionalización: Soporte de UTF-8 para caracteres internacionales.
Extensibilidad: Nuevos tipos de objetos y operaciones pueden ser definidos
dinámicamente, y el esquema publicado de una manera estándar.
A1.2 Distribución y Delegación en LDAP
Una de los aspectos más poderosos de LDAP es la inherente habilidad dentro del diseño
de delegar la responsabilidad para el mantenimiento de una parte del directorio sin dejar de verlo
como un todo coherente. Por lo tanto, una unidad organizacional puede crear una delegación de
responsabilidad a un departamento en particular de todo el DIT, esto se conoce como
referencias. Dado lo anterior, LDAP refleja con esto el concepto de delegación que provee DNS.
A diferencia del sistema DNS, no hay ninguna opción en las normas para decir al servidor
LDAP como debe realizar la referencia, ya que se deja que el cliente LDAP se contacte
directamente con el servidor usando la referencia dada. Del mismo modo, debido a que el
estándar no define la organización de datos en LDAP, esto no se contrapone a que un servidor
siga o resuelva un enlace, además algunas implementaciones realizan esta función
automáticamente usando un proceso que suele llamarse cadena.
85
Otra funcionalidad conocida es la replicación la que permite a una o más copias de un directorio (DIT) ser esclavos de un maestro simple, lo cual creará una estructura más robusta para el sistema en general.
Nuevamente es importante recalcar la diferencia entre LDAP y una base de datos del tipo transaccional. Cuando una actualización es realizada en un servidor maestro LDAP habilitado, ésta puede tomar algún tiempo (en términos computacionales) para actualizar a todos los esclavos; lo anterior conlleva a que los maestros y esclavos pueden ser asíncronos durante un tiempo.
En el contexto de LDAP, una falta de sincronización del DIT es considerada poco importante. En el caso de una base de datos transaccional, en cambio, incluso una pequeña falta en la sincronización de datos entre maestros y esclavos se considera catastrófica, dado el tipo de información que éstas manejan. Esto recalca que entre LDAP y una base de datos transaccional, hay una gran diferencia en lo que respecta a la información almacenada. A1.2.1 Referencias en LDAP
Cuando este concepto es aplicado, el servidor consultado entrega al cliente un puntero referenciando a otro servidor para que la búsqueda continúe en caso de no ser exitosa en la primera iteración. El cliente debería seguir la cadena de referencias hasta llegar al servidor que administra la información que él requiere. Todas estas operaciones deberían ser transparentes para el usuario que maneja al cliente LDAP. La Figura A1.1, muestra el uso de referencias entre un cliente y varios servidores con diversos grupos y subgrupos.
Figura A1.1: Solicitud resuelta por servidor LDAP1
86
El esquema anterior muestra una petición realizada por el cliente, la cual fue resuelta por el servidor LDAP 1, ya que éste tenía dentro de su DIT la información requerida. La solicitud fue la siguiente: “dn:cn=thingie,o=widgets,dc=example,dc=com”.
Figura A1.2: Solicitud que genera referencia a los servidores LDAP 2 y LDAP3
En cambio, para la Figura A1.2, la solicitud realizada por el cliente no fue totalmente satisfecha por LDAP1, por lo que tuvo que seguir la cadena de referencia hacia las siguientes máquinas, quienes respondieron a la petición inicial.
En términos generales, cuando se implementa bajo este sistema, todos los clientes comienzan su consulta con un directorio global, que en este caso está almacenado en el servidor LDAP1. Si esta máquina se encuentra configurada para realizar encadenamiento (seguir las referencias), luego una simple respuesta será entregada al cliente.
A1.2.2 Replicación en LDAP
Las características de replicación permiten a las actualizaciones realizadas en el DIT ser copiadas en uno o más sistemas LDAP por temas de respaldo y/o rendimiento. En este contexto vale la pena destacar que la replicación funciona a nivel del DIT, y no del servidor LDAP en sí. Ésta se produce periódicamente, y es conocida como tiempo de ciclo de replicación. En general, existen métodos que reducen este tiempo mediante configuración en el servidor, pero con la desventaja que produce una sobrecarga con impacto en rendimiento y uso de la red. Existen dos posibles configuraciones de replicación y múltiples variaciones en cada una de ellas.
87
Maestro – Esclavo
En este tipo de configuración un árbol de información simple es capaz de ser actualizado,
y estas actualizaciones son replicadas o copiadas a uno o más servidores designados como DITs
esclavos. Estas máquinas son copias de solo lectura del DIT maestro. Esto quiere decir que solo
los usuarios con privilegios de solo lectura pueden acceder a estos DITs, sin realizar
modificaciones en las entradas. Esta configuración tiene dos obvios inconvenientes:
i) Si todos o la mayoría de los usuarios tienen la habilidad o necesidad de actualizar el
DIT, tendrán dos opciones. Una de ellas es acceder a un servidor esclavo para el
accedo normal de escritura, y luego realizar la escritura en el maestro; o
alternativamente podrán apuntar siempre al servidor que está corriendo al DIT
maestro. En este último caso la replicación proporciona una funcionalidad de copia de
seguridad.
ii) Dado que hay sólo un servidor que contiene un DIT maestro, representa un punto
único de fallo, causando un colapso total del sistema.
Maestros Múltiples.
Para este caso uno o más servidores están corriendo DITs maestros que pueden ser
actualizados, por lo que el resultado de esta acción es propagada entre todas las máquinas
maestras.
Una de las aplicaciones que utilizan el protocolo LDAP, conocido como OpenLDAP en
su versión 2.4, introduce la capacidad de maestros múltiples. En este contexto vale la pena
destacar dos variantes específicas del problema genérico de actualización de todas las
configuraciones de varios maestros identificados por OpenLDAP, y que caen en todos los
sistemas que usan el protocolo:
i) Value – contention: Si dos atributos son actualizados al mismo tiempo con
diferentes valores, luego, dependiendo del tipo de atributo (simple – múltiple) el
resultado de la entrada puede ser incorrecto o quedar en estado inutilizable.
ii) Delete – contention: Si un usuario agrega una entrada hijo el mismo tiempo que otro
usuario borra la entrada original, luego la entrada borrada reaparecerá produciendo
inconsistencia.
88
Figura A1.3: Configuración de Replicación
La Figura A1.3, describe los posibles DIT dentro de un sistema de directorio, bajo la configuración de replicación. Nótese que se tienen uno o más esclavos para diversos servidores LDAP, de acuerdo a los requerimientos de la unidad organizacional, siempre considerando aspectos de rendimiento y sobrecarga de la red al momento de realizar operaciones de lectura/escritura. En el esquema aparecen las abreviaciones RO (read only – solo lectura) y RW (read/write – lectura/escritura), diferenciando el tipo de operaciones a realizar sobre el directorio, de acuerdo a los privilegios de usuario previamente establecidos.
Cabe mencionar la utilización de balanceos de carga entre servidores, los cuales vienen implícitos en las aplicaciones que acceden en el directorio, o mediante agentes externos. La primera tiene relación con algunos sistemas que ofrecen incluir varios servidores a los cuales se les puede consultar; si no se obtiene respuesta alguna del primero, sigue con los restantes. En cambio la última trata sobre balanceadores como switch de capa 4, o aplicaciones sobre la topología de red estipulada.
89
Anexo A2
Instalación y Configuración de OpenLDAP 2.3 y Samba 3.4
sobre FreeBSD 7.2
A2.1 Descripción General
El presente anexo explica el proceso de instalación del servidor de autenticación
OpenLDAP 2.3 y el servicio de integración de sistemas Unix/Linux/Windows conocido como
Samba en su versión 3.4. Cabe mencionar que la puesta en marcha de éste servicio se realizó en
máquinas virtuales bajo la aplicación VMWare, corroborando su funcionamiento para una
implementación final en el Departamento de Electrónica. A continuación se detallarán cada uno
de los pasos a seguir por el Administrador de Red de turno.
A2.2 Datos del Servidor FreeBSD 7.2
Dirección IP : 192.168.220.143/24
Nombre Servidor : smb-server01
Dominio OpenLDAP : elo.utfsm.cl
Dominio Samba : ELONT
Password LDAP : very-secure-password
Password smbldap : braulio
Instalación Limpia : Crear usuario pero no dejarlo en ningún grupo, para uqe se cree
carpeta /usr/home
A2.3 Instalación de las Aplicaciones
Todos los archivos de configuración del proceso de instalación se encuentran en
vmfiles.tar guardado en http://alumnos.elo.utfsm.cl/~bvasquez/vmfiles.tar