estudio e implementación de nuevo sistema de · pdf filelos servicios de...
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.
Palabras Claves: Autenticación, acceso remoto, migración.
4
Índice
Resumen ................................................................................................................................................. 3
1.Introducción ......................................................................................................................................... 6
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
2.3 Solución Propuesta ...................................................................................................................... 12
3.LDAP - Protocolo Ligero de Acceso a Directorio ............................................................................... 13
3.1 Servicio de Directorio .................................................................................................................. 13
3.2 Definición de LDAP .................................................................................................................... 14
3.3 Los Modelos de LDAP ................................................................................................................ 15
3.3.1 Modelo de Datos de LDAP ................................................................................................... 15
3.3.2 Modelo de Nombramiento ..................................................................................................... 18
3.3.3 Modelo Funcional ................................................................................................................. 19
3.3.4 Modelo de Seguridad ............................................................................................................ 20
4.Sistemas de Acceso Remoto ............................................................................................................... 22
4.1 Sistema de Ventanas X ................................................................................................................ 22
4.1.2 Diseño del Servidor X .................................................................................................... 23
4.1.3 Interfaces de Usuario ...................................................................................................... 25
4.2 VPN, Red Privada Virtual ...................................................................................................... 27
4.2.1 Elementos de una VPN ................................................................................................... 27
4.2.2 Topología VPN .............................................................................................................. 29
4.2.3 Ventajas de una VPN ...................................................................................................... 31
4.2.4 Desventajas de una VPN................................................................................................. 31
4.2.5 Medidas de seguridad ..................................................................................................... 32
5.Comparación de Tecnologías .............................................................................................................. 33
5.1 Análisis y Comparación de Servidores de Directorio .............................................................. 33
5.1.1 Tópicos de Evaluación .................................................................................................... 33
5.1.2 Productos a comparar ..................................................................................................... 35
5.1.3 OpenLDAP v/s Active Directory .................................................................................... 38
5.1.4 Cuadro Comparativo ...................................................................................................... 43
5
5.2 Análisis y Comparación de Sistemas de Acceso Remoto ........................................................ 45
5.2.1 Tópicos de Evaluación .................................................................................................... 45
5.2.2 Productos a comparar. .................................................................................................... 46
5.2.3 Evaluación de los productos. .......................................................................................... 49
5.2.4 Cuadro Comparativo....................................................................................................... 52
6.Resultados .......................................................................................................................................... 54
6.1 Sistema de Autenticación ............................................................................................................. 54
6.1.1 Recursos de Hardware y Software ......................................................................................... 54
6.1.2 Proceso de Implementación ................................................................................................... 56
6.1.3 Casos de Prueba .................................................................................................................... 61
6.1.4 Migración de cuentas de usuario ............................................................................................ 76
7.Conclusiones y Trabajo Futuro ........................................................................................................... 79
Referencias............................................................................................................................................ 81
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,
añadiéndose al servidor X.
48
Utilizar Xming como un servidor X portable, copiándolo a una memoria USB, sin
necesidad de instalarlo en el equipo que se esté trabajando.
Usarlo como KVM sustituto, ya que no necesita un hardware de alto costo.
Se puede usar el servidor X Xming, de forma local junto con otras aplicaciones del
mismo tipo como coLinux, Cywin, SFU o UWIN.
También es posible utilizar la aplicación en cuantas pantallas se desee.
Y una de las características más poderosas es poder realizar actualizaciones del kernel
sobre una máquina remota con „make xconfig‟
La figura 15 muestra el funcionamiento de Xming en Windows, con una pantalla única y
con ambos monitores.
Figura 5.2: Funcionamiento de Xming
OpenVPN
Es considerada una de las mejores soluciones VPN en la actualidad, superando con creces
a sus similares como FreeSWAN, cIPe, Tinc y VTun. OpenVPN pretende ser la solución
universal de VPN, tanto a nivel de OpenSource como de soluciones VPNC, por eso es soportado
por muchos sistemas operativos, tales como Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac
OS, Windows 2000/XP, y plataformas de 64 bits como FreeBSD y Alpha Linux.
Una de las mejores características de OpenVPN en comparación a otras soluciones, es su
simplicidad de configuración y de instalación, su alto grado de flexibilidad para cubrir diferentes
escenarios de VPN, su robustez como solución cubriendo necesidades que ninguna otra
herramienta Linux abarca, su alto grado de seguridad y su demostrada y comprobada eficiencia y
estabilidad que dan cada vez más el respaldo a que OpenVPN será una de las soluciones más
eficientes como sistemas de acceso remoto.
OpenVPN fue diseñado para trabajar con el módulo TUN/TAP ídem, que permite crear
interfaces virtuales, existente en casi todos los sistemas operativos, logrando con esto crear
tarjetas o interfaces virtuales para tener con una sola interfaz (real) diferentes tipos de conexiones
a la vez, es decir con una sola interfaz de red y usando aquel módulo se puede tener habilitadas al
mismo tiempo diferentes conexiones de red usando diferentes direcciones IP.
Una de las grandes ventajas que tiene OpenVPN, es que entrega soluciones efectivas para
instalaciones en donde se use DHCP, NAT y Proxy. Esto es una de las características
49
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”.
## Unidades organizacionales bases de LDAP-ELO.
nss_base_group ou=Groups,dc=elo,dc=utfsm,dc=cl?one
nss_base_passwd ou=People, dc=elo,dc=utfsm,dc=cl?one
nss_base_passwd ou=Computers, dc=elo,dc=utfsm,dc=cl?one
nss_base_shadow ou=People, dc=elo,dc=utfsm,dc=cl?one
Figura 6.4: Extracto del archivo nss_ldap.conf
Es necesario mencionar que en el Anexo A2 se indica el procedimiento exacto de
instalación del servidor OpenLDAP, detallando cada uno de los pasos para así evitar conflictos
en la Fase de Instalación I.
61
Servidor Samba
Samba es una implementación libre del protocolo de archivos compartidos de Microsoft
Windows para sistemas de tipo UNIX. De esta forma, es posible que ordenadores
con GNU/Linux, Mac OS X o Unix en general se vean como servidores o actúen como clientes
en redes de Windows. Además permite validar usuarios haciendo de controlador principal de
dominio (PDC), como miembro de dominio e incluso como un dominio Active Directory para
redes basadas en Windows; aparte de ser capaz de servir colas de impresión, directorios
compartidos y autentificar con su propio archivo de usuarios. Entre los sistemas tipo Unix en los
que se puede ejecutar Samba, están las distribuciones GNU/Linux, Solaris y las diferentes
variantes BSD que es el caso de este proyecto.
Esta aplicación, al igual que el servidor OpenLDAP, existen archivos de configuración
determinantes al momento de querer levantar el servicio Samba. Uno de ellos es “smb.conf”, el
cual se especifica información como el dominio Windows/Linux, rango de direcciones IP
aceptables por el servidor, los scripts respectivos para la agregación, eliminación y modificación
de cuentas de usuario “ldap-samba”. Para este último es necesario instalar el módulo “smbldap-
tools”, el cual permite integrar finalmente los servidores LDAP y Samba. En el Anexo A2 se
presentan las configuraciones específicas.
6.1.3 Casos de Prueba
Para los casos de pruebas realizados se definieron ciertos parámetros que son comunes
para cada uno de ellos. Estos son los siguientes:
Máquina Nombre Dirección IP Dominio
OpenLDAP
Dominio
Samba
Directorio
Usuarios
Servidor
OpenLDAP
Smb-server01 192.168.220.143/24 elo.utfsm.cl /usr/home
Servidor
Samba
Smb-server01 192.168.220.143/24 ELONT /usr/home
Cliente
Windows
XP
clienteXP Automática por
DHCP
elo.utfsm.cl ELONT Disco
virtual H:
Cliente
Linux
clienteUbuntu Automática por
DHCP
elo.utfsm.cl /home/
Tabla 6.1: Descripción de máquinas involucradas
A continuación se procede a describir cada uno de los casos de pruebas realizados una
vez que el servidor de autenticación LDAP y Samba estuvo funcionando.
62
1) Ingreso a cliente Windows XP
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
Agregar Usuario Smbldap_useradd
Crear contraseña Smbldap_passwd
Agregar Grupo Smbldap_groupmod
78
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] <
http://support.microsoft.com/kb/196464/es>
[1.2] Wikipedia. OpenLDAP [en línea] < http://es.wikipedia.org/wiki/OpenLDAP>
[1.3] Webmin Home Page. ¿Qué es Webmin? [en línea] < http://www.webmin.com/>
[2.1] Escuela de Ingeniería Pontificia Universidad Católica. Obtención de disco remoto. [en
línea] < http://www.ing.puc.cl/esp/infgeneral/ssi/enlaces/disco_remoto.html>
[2.2] Sitio Oficial de WinSCP [en línea] < http://winscp.net/eng/docs/lang:es>
[2.3] Departamento de Computación, Universidad de Valparaíso. < http://redes.decom-
uv.cl/index.php?name=servicios>
[2.4] Departamento de Computación, Universidad de Valparaíso. < http://redes.decom-
uv.cl/index.php?name=servicios>
[2.5] Dirección de Servicios de Tecnología de Información STI, Universidad de Chile <
http://www.sti.uchile.cl/>
[2.6]Wikipedia. VPN (Virtual Private Network) <
http://en.wikipedia.org/wiki/Virtual_private_network>
[2.7] University of California, Berkeley. Calnet - Identity and Access Management <
https://wikihub.berkeley.edu/display/calnet/CalNet+Identity+and+Access+Management>
[2.8] MIT. Kerberos: The Network Authentication Protocol. < http://web.mit.edu/kerberos/>
[3.1] Wikipedia. ASN.1 < http://es.wikipedia.org/wiki/ASN.1>
[4.1] Scheifler, Robert W. Massachusetts Institute of Technology. X Windows System Protocol
< http://www.alleystoughton.us/eXene/X-protocol.pdf>
[4.2] Gettys, James. Cambridge Research Laboratory. Xlib – C Language X Interface <
http://www.xfree86.org/current/xlib.pdf>
[4.3] XFCE Home Page. XFCE Desktop Environment. < http://www.xfce.org/>
[4.4] Oracle, Common Desktop Environmente (CDE).
<http://www.sun.com/software/solaris/cde/>
82
[4.5] Wikipedia. Remote Access Service – RAS.
<http://en.wikipedia.org/wiki/Remote_Access_Service>
[5.1] Vernooij, Jelmer R., The Official Samba 3.4 Reference Guide.
<http://www.samba.org/samba/docs/Samba3-HOWTO.pdf>
[5.2] Landeros Cartes, Carlos Antonio. Implementación de una VPN sobre Linux para la red de
computadores del Departamento de Electrónica. Memoria para optar al título de Ingeniero Civil
Electrónico. Universidad Técnica Federico Santa María. Año 2005.
83
Anexo A1
Aspectos Avanzados del Protocolo LDAP
A1.1 Un poco de historia
En el año 1989, a un grupo de estudiantes de la Universidad de Michigan que trabajaba
en tecnologías emergentes de internet, se le dio la tarea de crear un servicio de directorio para la
universidad. Se volcaron hacia el protocolo X.500, el cual organiza las entradas del directorio en
un espacio de nombres jerárquico, capaz de soportar grandes cantidades de información y definir
poderosas capacidades de búsqueda para hacer más fácil la obtención de ésta. En aquellos
tiempos, ya existía una implementación de disponibilidad pública, llamada Quipu (en honor al
sistema de mensajería utilizado por los Incas). Los trabajos se enfocaron en hacer de éste más
escalable y adecuado para ser usado en una organización tan amplia como una Universidad.
Tiempo después se dieron cuenta que existían limitaciones fundamentales en el protocolo
mismo, las que tenían que ver con que X.500 fue pensado para trabajar sobre una infraestructura
OSI, lo que dejaba fuera a muchas máquinas pequeñas en la cuales no podían ser implementada.
En este punto, se comenzó a concebir LDAP, pero sólo como front-end de X.500.
A mediado de los 90‟s, Tim Howes de la Universidad de Michigan comenzó a trabajar en
el precursor de LDAP, DIXIE (Directory Interface to X.500 Implemented Eficiently). Esta
implementación ayudó a mucha gente que lidiaba con X.500, ya que no poseía clientes para
poder utilizarlo. Al mismo tiempo creó la base para implementar clientes con un acceso más
simplificado vía TCP/IP, y a menor costo. DIXIE comenzó a ser ampliamente usado, y dado
esto, sus desarrolladores siguieron con el proceso de estandarización en IETF (Internet
Engineering Task Force). En 1991 se publicó el RFC 1249, que habla acerca de DIXIE.
Por otro lado Steve Kille trabajaba en un grupo de la IETF, con Open Systems
Interconnection Directory Services (OSI-DS), tratando de darle mejor funcionalidad a X.500
sobre internet. Steve se unió Tim Howes, y junto a Wengyik Yeong trabajaron en desarrollar la
especificación original de LDAP, apareciendo esta a principios de 1992. Se agregó
posteriormente al grupo Colin Robbins, puesto que para la definición de la sintaxis de LDAP se
basó mucho en lo que él había hecho con Quipu. En la Universidad de Michigan en tanto, se
siguió trabajando, obteniéndose a fines de ese año la implementación de un servidor LDAP, y
bibliotecas para clientes, liberándose finalmente de forma pública.
En 1993 apareció el primer documento RFC sobre LDAP versión 2 [RFC1487]
[RFC1488]. La versión 1 nunca se convirtió en un RFC, y sólo quedó como un Internet Draft.
Este RFC fue el X.500 Lightweight Access Protocol [RFC 1487], el cual fue posteriormente
reemplazado por Lightweight Directory Access Protocol [RFC 1777].
El RFC 1777 define el protocolo LDAP, junto con los siguientes:
The String Representation of Standard Attribute Syntaxes [RFC 1778]
84
A String Representation of Distinguished Names [RFC 1779]
An LDAP URL Format [RFC 1959]
A String Representation of LDAP Search Filters [RFC 1960] define a LDAP Versión 2,
alcanzando el estado de estándar de la IETF.
Luego de eso vino la aparición de LDAP Versión 3. Éste fue definido por Lightweight
Directory Access Protocol (v3) [RFC 2251]. Los RFC‟s que fueron actualizados a la versión 3
son los siguientes:
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions [RFC 2252]
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
Actualizar el árbol de ports:
#portsnap fetch
#portsnap extract
Realizar los cambios en /etc/hosts
::1 localhost localhost.smbdomain.local
127.0.0.1 localhost localhost.smbdomain.local
192.168.220.143 smb-server01.elo.utfsm.cl smb-server01
192.168.220.143 smb-server01.elo.utfsm.cl.
90
Ports Necesarios
Perl 5.12 (Dejar opciones por omisión)
Desinstalar antes perl 5.8 (por make deinstall)
# cd /usr/ports/lang/perl5.12
# make install clean
OpenLDAP 23 (Dejar Opciones por omisión)
# cd /usr/ports/net/openldap23-server
# make install clean
Cups-base (Ser paciente con la instalación)
# cd /usr/ports/print/cups-base
# make install clean
Dato Extra:
- Cuando ghostscript pregunte por las opciones, no seleccionar las opciones de X Windows.
- Cuando arroje un error de paquete de png, ir /usr/ports/graphics/png, hacer make deinstall y
luego make reinstall para llevarlo al paquete mas nuevo.
- Asegurarse de que la instalación finalice correctamente.
Samba34
# cd /usr/ports/net/samba34
# make install clean
Dejar la siguiente configuración:
+--------------------------------------------------------------------+
| Options for samba34 3.4.9 |
| +----------------------------------------------------------------+ |
| | [X] LDAP With LDAP support | |
| | [X] ADS With Active Directory support | |
| | [X] CUPS With CUPS printing support | |
| | [X] WINBIND With WinBIND support | |
| | [ ] SWAT With SWAT WebGUI | |
| | [X] ACL_SUPPORT With ACL support | |
| | [X] AIO_SUPPORT With Asyncronous IO support | |
| | [ ] FAM_SUPPORT With File Alteration Monitor | |
| | [X] SYSLOG With Syslog support | |
| | [X] QUOTAS With Disk quota support | |
| | [X] UTMP With UTMP accounting support | |
| | [X] PAM_SMBPASS With PAM authentication vs passdb backends | |
| | [ ] DNSUPDATE With dynamic DNS update(require ADS) | |
| | [ ] AVAHI With Bonjour service discovery support | |
| | [ ] EXP_MODULES With experimental modules | |
| | [X] POPT With system-wide POPT library | |
| | [ ] MAX_DEBUG With maximum debugging | |
| | [ ] SMBTORTURE With smbtorture | |
|-+----------------------------------------------------------------+-|
| [ OK ] Cancel |
+--------------------------------------------------------------------+
91
Dato Extra:
Es importante habilitar la opción PAM, ya que es el módulo que permitirá el acceso vía SSH.
Nss_ldap (dejar opciones por omisión)
# cd /usr/ports/net/nss_ldap/
# make install clean
SmbLdap_tools(dejar opciones por omisión)
# cd /usr/ports/net/smbldap-tools
# make install clean
A2.4 Configuración de OpenLDAP 2.3
Se creará el password para openldap:
# slappasswd -s very-secure-password
Copiar y pegar el output en el parámetro rootpw de /usr/local/etc/openldap/slapd.conf
# vi /usr/local/etc/openldap/slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
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
loglevel 256
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
#moduleload back_bdb
#######################################################################
# BDB database definitions
#######################################################################
database bdb
92
suffix "dc=elo,dc=utfsm,dc=cl"
rootdn "cn=Manager,dc=elo,dc=utfsm,dc=cl"
#rootpw = very-secure-password
rootpw {SSHA}2pCGrVMhMh3cC+LakUXApebb9jwICf5e
directory /usr/local/var/db/openldap-data
# Indices to maintain
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
Se necesita copiar el siguiente link (samba.schema)
# cp /usr/local/share/examples/samba34/LDAP/samba.schema
/usr/local/etc/openldap/schema/
Se necesita la creación de algunos archivos como la creación del directorio donde se almacenará
la base de datos. /usr/local/var/db/openldap-data.
# mkdir -p /usr/local/var/db/openldap-data
# cp /usr/local/etc/openldap/DB_CONFIG.example /usr/local/var/db/openldap-
data/DB_CONFIG
# chown -R ldap:ldap /usr/local/var/db/openldap-data
# chown -R ldap:ldap /usr/local/etc/openldap/
# chmod -R 0700 /usr/local/var/db/openldap-data
# chmod 0400 /usr/local/etc/openldap/slapd.conf
Ahora se hará que syslog arroje notificaciones sobre slapd en /etc/syslog.conf
!slapd
*.* /var/log/slapd.log
Ahora creamos el archivo y reiniciamos en demonio syslogd
# touch /var/log/slapd.log
# /etc/rc.d/syslogd restart
Asegurarse que el archivo /usr/local/etc/nss_ldap.conf se vea de la siguiente forma:
uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap:// 192.168.220.143/ ldap://127.0.0.1/
base dc=elo,dc=utfsm,dc=cl
93
bind_policy soft
bind_timelimit 10
host localhost
idle_timelimit 3600
ldap_version 3
nss_base_group ou=Groups,dc=elo,dc=utfsm,dc=cl?one
nss_base_passwd ou=People, dc=elo,dc=utfsm,dc=cl?one
nss_base_passwd ou=Computers, dc=elo,dc=utfsm,dc=cl?one
nss_base_shadow ou=People, dc=elo,dc=utfsm,dc=cl?one
nss_connect_policy persist
nss_paged_results yes
pagesize 1000
port 389
scope one
timelimit 30
Se hace un link simbólico desde
/usr/local/etc/nss_ldap.conf a /usr/local/etc/openldap/ldap.conf
# rm /usr/local/etc/openldap/ldap.conf
# ln -s /usr/local/etc/nss_ldap.conf /usr/local/etc/openldap/ldap.conf
# ln -s /usr/local/etc/nss_ldap.conf /usr/local/etc/ldap.conf
Modificar /etc/rc.conf para que el demonio slapd inicie al momento de encender el servidor:
#enable slapd
slapd_enable="YES"
slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap://127.0.0.1/
ldap://192.168.220.143/"'
slapd_sockets="/var/run/openldap/ldapi"
Ahora se inicia slapd y se comprueba que el proceso esté corriendo:
# /usr/local/etc/rc.d/slapd start
Starting slapd.
# ps ax | grep slap
11383 ?? Ss 0:00,01 /usr/local/libexec/slapd -h ldapi://%2fvar
11385 p2 S+ 0:00,00 grep slap
Finalmente edite /etc/nsswitch.conf de la siguiente forma:
group: files ldap
group_compat: nis
hosts: files dns
networks: files
passwd: files ldap
passwd_compat: nis
94
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
A2.4 Configuración de Samba 3.4
Todos los archivos relacionados a samba quedarán almacenados en el
directorio /usr/local/var/samba
# mkdir /usr/local/var/samba
También se creará el archivo user map, que contendrá el nombre de root:
# vi /usr/local/var/samba/usermap
root = administrator
Para crear el siguiente /usr/local/etc/smb.conf es necesario borrar el anterior. Por tanto
quedará de la siguiente forma:
# rm /usr/local/etc/smb.conf
# vi /usr/local/etc/smb.conf
# Global parameters
[global]
workgroup = ELONT
server string = Samba Server
netbios name = smb-server01
hosts allow = 192.168.220. 127.
interfaces = bge0, lo
bind interfaces only = Yes
# passwd backend
encrypt passwords = yes
passdb backend = ldapsam:ldap://smb-server01.elo.utfsm.cl/
enable privileges = yes
pam password change= Yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*UNIX*password* %nn *ReType*new*UNIX*password* %nn *
passwd:*all*authentication*tokens*updated*successfully*
unix password sync = Yes
# Log options
log level = 1
log file = /var/log/samba34/%m
max log size = 50
syslog = 0
# Name resolution
name resolve order = wins bcast host
95
# misc
timeserver = Yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
use sendfile = yes
veto files = /*.eml/*.nws/*.{*}/
veto oplock files = /*.doc/*.xls/*.mdb/
deadtime = 120
# Dos-Attribute
map hidden = No
map system = No
map archive = No
map read only = No
store dos attributes = Yes
# printers - configured to use CUPS and automatically load them
load printers = Yes
printcap name = CUPS
printing = cups
cups options = Raw
show add printer wizard = No
# scripts invoked by samba
add user script = /usr/local/sbin/smbldap-useradd -m %u
delete user script = /usr/local/sbin/smbldap-userdel %u
add group script = /usr/local/sbin/smbldap-groupadd -p %g
delete group script = /usr/local/sbin/smbldap-groupdel %g
add user to group script = /usr/local/sbin/smbldap-groupmod -m %u
%g
delete user from group script = /usr/local/sbin/smbldap-groupmod -x %u
%g
set primary group script = /usr/local/sbin/smbldap-usermod -g %g
%u
add machine script = /usr/local/sbin/smbldap-useradd -w %m
# LDAP-Configuration
ldap delete dn = Yes
ldap ssl = off
ldap passwd sync = Yes
ldap suffix = dc=elo,dc=utfsm,dc=cl
ldap machine suffix = ou=Computers
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=Manager,dc=elo,dc=utfsm,dc=cl
idmap backend = ldap:ldap://smb-server01.elo.utfsm.cl
idmap uid = 10000-20000
idmap gid = 10000-20000
# logon options
logon script = logon.bat
logon path = \%L\profiles\%u
logon path =
96
logon home = \%L\%U
logon drive = H:
# setting up as domain controller
username map = /usr/local/var/samba/usermap
preferred master = Yes
wins support = Yes
domain logons = Yes
domain master = Yes
local master = Yes
os level = 64
map acl inherit = Yes
unix charset = UTF8
#============================ Share Definitions
==============================
[netlogon]
comment = Network Logon Service
path = /usr/local/var/samba/netlogon
guest ok = yes
locking = no
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[Profiles]
comment = Network Profiles Service
path = /usr/local/var/samba/profiles
read only = No
profile acls = yes
hide files = /desktop.ini/ntuser.ini/NTUSER.*/
profile acls = Yes
[printers]
comment = All Printers
path = /var/spool/samba
browseable = No
guest ok = Yes
printable = Yes
use client driver = Yes
default devmode = Yes
[print$]
comment = Printer Drivers
path = /usr/local/var/samba/printer-drivers
browseable = yes
guest ok = no
read only = yes
write list = root
[data]
97
comment = Data Directory
path = /usr/local/var/samba/data
write list = @elont
read only = No
create mask = 0777
directory mask = 0777
Dato Extra: Los puntos en rojos son las opciones cambiables de acuerdo a los requerimientos de
la organización.
Se crearán los siguientes directorios: netlogon, profiles, printer-drivers and the share data.
# mkdir /usr/local/var/samba/netlogon
# mkdir /usr/local/var/samba/profiles
# mkdir /usr/local/var/samba/printer-drivers
# mkdir /usr/local/var/samba/data
# chmod 777 /usr/local/var/samba/profiles
Ahora se corroborará el correcto funcionamiento de smb.conf mediante:
# testparm /usr/local/etc/smb.conf
Si se obtiene lo siguiente:
Load smb config files from /usr/local/etc/smb.conf
max_open_files: sysctl_max (14745) below minimum Windows limit (16384)
rlimit_max: rlimit_max (14745) below minimum Windows limit (16384)
Crear el archivo /boot/loader.conf
# Samba 34
kern.maxfiles="20480"
Ahora se necesita guardar el password ldap, en el secret.tdb:
/usr/local/etc/rc.d/slapd stop
Stopping slapd.
Waiting for PIDS: 49851.
#
# smbpasswd -w very-secure-password
Setting stored password for "cn=Manager,dc=testdomain,dc=com" in secrets.tdb
Ahora Samba se configura en /etc/rc.conf e iniciamos el demonio:
#enable Samba
nmbd_enable="YES"
smbd_enable="YES"
winbindd_enable="YES"
cupsd_enable="YES"
98
Se procede a iniciar Samba
# /usr/local/etc/rc.d/samba start
Removing stale Samba tdb files: ....... done
Starting nmbd.
Starting smbd.
Starting winbindd.
Probar que Samba inició
# ps -ax | grep mbd
1093 ?? Ss 0:00.03 /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf
1095 ?? I 0:00.00 /usr/local/sbin/nmbd -D -s /usr/local/etc/smb.conf
1100 ?? Ss 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf
Para asegurarse que Samba inicie después que el Servidor LDAP, es necesario modificar el script
de samba, ubicado en /usr/local/etc/rc.d/samba
# PROVIDE: nmbd smbd
# PROVIDE: winbindd
# REQUIRE: NETWORKING SERVERS DAEMON ldconfig resolv
# REQUIRE: cupsd slapd
# BEFORE: LOGIN
# KEYWORD: shutdown
A2.5 Configuración de Smbldap-tools
Esta herramienta permite integrar las configuraciones del servidor OpenLDAP con el
servidor Samba, lo que permitirá que cada usuario tenga una cuenta única al momento de
autenticarse tanto en máquinas Windows, como Linux/Unix.
Se graba el SID del servidor:
net getlocalsid
SID for domain SMB-SERVER01 is: S-1-5-21-663278506-2669211824-1328585615
Ahora se modifica el archivo /usr/local/etc/smbldap-tools/smbldap.conf (copiar en el
directorio anterior el que se encuentra en vmfiles.tar)
Modificar el archivo /usr/local/etc/smbldap-tools/smbldap_bind.conf
############################
# Credential Configuration #
############################
# Notes: you can specify two differents configuration if you use a
# master ldap for writing access and a slave ldap server for reading access
# By default, we will use the same DN (so it will work for standard Samba
# release)
masterDN="cn=Manager,dc=testdomain,dc=com"
masterPw="very-secure-password"
99
Se inicia nuevamente el demonio de slapd (ya que anteriormente se había terminado)
# /usr/local/etc/rc.d/slapd start
Ahora se poblará la base de datos a modo de prueba:
# smbldap-populate -u 10000 -g 10000 -r 10000
Populating LDAP directory for domain TESTDOMAIN (S-1-5-21-663278506-
2669211824-1328585615)
(using builtin directory structure)
adding new entry: dc=testdomain,dc=com
adding new entry: ou=People,dc=testdomain,dc=com
adding new entry: ou=Groups,dc=testdomain,dc=com
adding new entry: ou=Computers,dc=testdomain,dc=com
adding new entry: ou=Idmap,dc=testdomain,dc=com
adding new entry: uid=root,ou=People,dc=testdomain,dc=com
adding new entry: uid=nobody,ou=People,dc=testdomain,dc=com
adding new entry: cn=Domain Admins,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Domain Users,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Domain Guests,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Domain Computers,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Administrators,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Account Operators,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Print Operators,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Backup Operators,ou=Groups,dc=testdomain,dc=com
adding new entry: cn=Replicators,ou=Groups,dc=testdomain,dc=com
adding new entry: sambaDomainName=TESTDOMAIN,dc=testdomain,dc=com
Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password:
Retype new password:
Donde se preguntará la password de Samba que no necesariamente es la misma de openldap (en
este caso braulio).
A2.6 Configuración de Winbind
Antes de configurar, verificar si todos los demonios están corriendo como también agregar en
/etc/rc.conf hostname=”smb-server01”.
Y luego realizar:
# net rpc join -S smb-server01 –U root
Enter root's password:
Joined domain TESTDOMAIN.
Dato Extra: Este paso sólo funciona si lo anterior se ha hecho correctamente.
100
A2.7 Agregando usuarios al DIT
Ahora se puede crear una cuenta de usuario Windows (opción -a), se le crea su carpeta personal
(opción -m), especificando que no tenga una ruta Profile (opción -F) y se le asigna una
contraseña. También se procede a agregar el usuario al grupo organizacional:
smbldap-useradd –a -m –d /usr/home/<unidadorg>/<usuario> –S “<Nombre
Usuario>” –P usuario
smbldap-groupmod –m <usuario> <unidadorg>
101
Anexo A3
Integración de SSH con OpenLDAP, mediante PAM
A3.1 Descripción General
Este anexo explica cómo se integrará el módulo PAM, para que los usuarios puedan tener
acceso vía SSH al servidor OpenLDAP. Los pasos que se describirán a continuación tienen que
ser seguidos con mucha precaución, ya que cualquier error puede causar que no se pueda volver
acceder a éste.
A3.2 Instalación y Configuración
Instalar el modulo PAM
Realizar un link simbólico para que el .so se pueda usar automáticamente
Modificar el archivo /usr/local/etc/nss_ldap.conf ya que este se replicará para los links
simbólicos de ldap.conf
Agregar al DIT, el siguiente archivo computers_pam.ldif:
Luego se agrega con la siguiente sentencia:
#cd /usr/ports/security/pam_ldap/
binddn cn=pam_ldap,ou=Computers,dc=elo,dc=utfsm,dc=cl
bindpw secret
pam_password exop
# ln -s /usr/local/lib/pam_ldap.so /usr/lib
dn: cn=pam_ldap,ou=Computers,dc=testdomain,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: secret
ldapadd -H ldap://smb-server01 -x -D "cn=Manager,dc=testdomain,dc=com"
-f /archivos/archivos/computers_pam.ldif -w very-secure-password
102
A continuación se modifica el archivo /etc/pam.d/sshd. Dato Extra: Sólo esto es posible
cuando usuarios reales pueden ingresar via SSH, es decir no se puede acceder via root.
A continuación se modifica el archivo /etc/pam.d/passwd
# auth
auth sufficient pam_opie.so no_warn
no_fake_prompts
auth requisite pam_opieaccess.so no_warn
allow_local
#auth sufficient pam_krb5.so no_warn
try_first_pass
#auth sufficient pam_ssh.so no_warn
try_first_pass
auth required pam_ldap.so
#auth required pam_unix.so no_warn
try_first_pass
# account
account required pam_nologin.so
#account required pam_krb5.so
account required pam_login_access.so
account required pam_ldap.so
#account required pam_unix.so
# session
#session optional pam_ssh.so
session sufficient pam_ldap.so
session required pam_permit.so
# password
#password sufficient pam_krb5.so no_warn
try_first_pass
password required pam_ldap.so
#password required pam_unix.so no_warn try_first_pass
# password
#password requisite pam_passwdqc.so enforce=users
###password required pam_unix.so no_warn try_first_pass nullok
password required pam_ldap.so
103
También se modifica el archivo /etc/pam.d/system
Finalmente se reinicia el demonio slapd. # /usr/local/etc/rc.d/slapd restart
#
# System-wide defaults
#
# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth sufficient pam_ldap.so
auth required pam_unix.so no_warn try_first_pass
nullok
# account
#account required pam_krb5.so
account required pam_login_access.so
account sufficient pam_ldap.so
account required pam_unix.so
# session
#session optional pam_ssh.so
session required pam_ldap.so
session required pam_lastlog.so no_fail
# password
#password sufficient pam_krb5.so no_warn try_first_pass
password required pam_unix.so no_warn try_first_pass
104
Anexo A4
Agregando máquinas al dominio LDAP/Samba
A4.1 Descripción General
El siguiente anexo describe los pasos a seguir al momento de agregar máquinas o
estaciones de trabajos, con sistemas operativos Windows XP y Linux (Ubuntu 10.10). Para las
máquinas Linux, se puede utilizar cualquier distribución acorde.
A4.2 Agregando Máquinas Windows XP
Los pasos a seguir son los siguientes:
Clic derecho en el icono de «Mi PC».
Seleccionar «Propiedades»
Haga clic en la pestaña de «Identificación de red» o «Nombre del
sistema».
Clic en el botón de «Propiedades».
Clic en el botón «Miembro de dominio»
Ingrese el nombre del dominio (en este caso ELONT) y el nombre de la
máquina y haga clic en el botón de «Aceptar»
Aparecerá un diálogo que preguntará por una cuenta y clave de acceso con
privilegios de administración en el servidor. Especifique el
usuario: Administrator y la clave de acceso que se le asignó (en este caso
braulio).
Espere algunos segundos.
Deberá mostrarse un mensaje emergente de confirmación que dice
«Bienvenido a ELONT»
Reinicie el sistema
Acceda con un usuario que haya sido creado con smbldap-useradd en el
directorio LDAP, o una cuenta de usuario que pertenezca a la OU=Domain
Admins
A4.2 Agregando Máquinas Linux
Para agregar las máquinas bajo sistemas operativos Linux, se hace uso de un script el cual
instala las librerías necesarias para éste cliente, y así poder realizar todos los comandos
necesarios para su correcta utilización.
105
#!/bin/bash
#Actualizar y instalar los paquetes necesarios
apt-get update
apt-get install libnss-ldap libpam-ldap nscd
#Reconfigurar la libreria.
dpkg-reconfigure libnss-ldap
clear
#Enviar las modificaciones a los diferentes ficheros en pam.d
echo “account required pam_unix.so” > /etc/pam.d/common-account
echo “account sufficient pam_ldap.so” >> /etc/pam.d/common-account
echo “auth sufficient pam_unix.so” > /etc/pam.d/common-auth
echo “auth sufficient pam_ldap.so try_first_pass” >> /etc/pam.d/common-auth
echo “auth required pam_unix_auth.so” >> /etc/pam.d/common-auth
echo “password required pam_unix.so nullok obscure min=4 max=8 md5″ > /etc/pam.d/common-
password
echo “password sufficient pam_unix.so use_authtok md5 shadow” >> /etc/pam.d/common-
password
echo “password sufficient pam_ldap.so use_authtok” >> /etc/pam.d/common-password
echo ” session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 ” >
/etc/pam.d/common-session
echo ” session required pam_unix.so ” >> /etc/pam.d/common-session
echo ” session optional pam_ldap.so ” >> /etc/pam.d/common-session
# Modificar el Nsswitch.
echo “passwd: compat ldap” > /etc/nsswitch.conf
echo “group: compat ldap” >> /etc/nsswitch.conf
echo “shadow: compat ldap” >> /etc/nsswitch.conf
echo “hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4″>> /etc/nsswitch.conf
echo “networks: files” >> /etc/nsswitch.conf
echo “protocols: db files” >> /etc/nsswitch.conf
echo “services: db files” >> /etc/nsswitch.conf
echo “ethers: db files” >> /etc/nsswitch.conf
echo “rpc: db files” >> /etc/nsswitch.conf
echo “netgroup: nis” >> /etc/nsswitch.conf
echo “Ahora puede iniciar con su sesion de Dominio”
echo “Disfrutelo: Grupo Administracion”
exec /etc/init.d/nscd restart
106
Dato Extra: Antes de hacer correr el script es necesario respaldar los archivos que contiene el
directorio pam.d, con la siguiente sentencia #cp -va /etc/pam.d/ pam.d.FILES. Además mediante
algún cliente LDAP como Apache Directory Studio cambiar el loginShell de cada usuario a
/bin/sh
107
Anexo A5
Instalación y Configuración del Servidor de Correo
A5.1 Descripción General
Se realizará la instalación del servidor de correo como método de prueba, para poder
comprobar la utilización de los sistemas Web existentes en el Departamento de Electrónica, estos
son, el SGP (Sistema de Gestión de Prácticas) y el Sistema de Solicitud de Memos. Como se
explicó en el capítulo 6, se desea implementar una solución que sea transparente a las
aplicaciones Web de Electrónica ya realizadas, por ende el servidor OpenLDAP debe
acomodarse a lo que ya está hecho.
A5.2 Instalación y Configuración Dovecot
Instalación de Dovecot mediante ports:
La configuración al momento de instalar es la siguiente:
El siguiente es el archivo de configuración de dovecot, ubicado en /usr/local/etc/dovecot.conf
ubicado en vmfiles.tar.
Se copia el archivo imap de vmfiles.tar, en /etc/pam.d/imap, donde se agrega el modulo de
pam_ldap.so
#/usr/ports/mail/dovecot
#make install clean
[X] KQUEUE
[X] SSL SSL support
[X] MANAGESIEVE ManageSieve support
[ ] GSSAPI GSSAPI support
[ ] VPOPMAIL VPopMail support
[ ] BDB BerkleyDB support
[X] LDAP OpenLDAP support
[ ] PGSQL PostgreSQL support
[X] MYSQL MySQL support
[ ] SQLITE SQLite support
108
Como se está usando local7 para dovecot, se debe configurar el servicio y además crear el
archivo dovecot.log.
Se agrega a syslog.conf la siguiente línea:
Se configura Dovecot para que arranque desde el inicio en #/etc/rc.conf
Se inicia el servicio:
Se procede a verificar si los puertos están abiertos:
touch /var/log/dovecot.log
local7 /var/log/dovecot.log
dovecot_enable="YES"
/usr/local/etc/rc.d/dovecot start
#sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
dovecot imap-login 49041 4 tcp4 192.168.49.2:143 *:*
dovecot imap-login 49016 4 tcp4 192.168.49.2:143 *:*
dovecot imap-login 49015 4 tcp4 192.168.49.2:143 *:*
root dovecot-au 49013 5 tcp4 192.168.49.2:27813
192.168.49.2:389
root dovecot-au 49012 8 tcp4 192.168.49.2:11954
192.168.49.2:389
root dovecot 49011 7 tcp4 192.168.49.2:143 *:*
root smbd 88886 9 tcp4 192.168.49.2:34457
192.168.49.2:389
root smbd 88880 9 tcp4 192.168.49.2:34457
192.168.49.2:389
root nmbd 88873 9 udp4 192.168.49.2:137 *:*
root nmbd 88873 10 udp4 192.168.49.2:138 *:*
ldap slapd 88590 7 tcp4 192.168.49.2:389 *:*
ldap slapd 88590 11 tcp4 192.168.49.2:389
192.168.49.2:34457
ldap slapd 88590 16 tcp4 192.168.49.2:389
192.168.49.2:11954
ldap slapd 88590 19 tcp4 192.168.49.2:389
192.168.49.2:27813
ldap slapd 88590 24 tcp4 192.168.49.2:389
192.168.49.2:46517
109
Se procederá a probar la autenticación de usuario. Ya teniéndolos creados mediante OpenLDAP,
Dovecot puede acceder al directorio de cada uno de ellos. Se verifica que los permisos estén
correctamente asignados.
Se procede a revisar el directorio del usuario donde se crea la carpeta Maildir.
telnet 192.168.220.143 143
Trying 192.168.220.143...
Connected to mail.elo.utfsm.cl.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE AUTH=PLAIN AUTH=LOGIN] OK.
*Se procede a autenticarse con un usuario existente*
a login alara alara //usuario:alara, password:****
a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND
UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1
CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
LIST-STATUS] Logged in
b select inbox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1272323541] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
b OK [READ-WRITE] Select completed.
Ctrl+]
smb-server01# cd /usr/home/alara
smb-server01# ll
total 2
drwx------ 5 test2 Domain Users 512 Apr 26 23:12 Maildir
smb-server01# cd Maildir/
smb-server01# ll
total 12
drwx------ 2 test2 Domain Users 512 Apr 26 23:12 cur
-rw------- 1 test2 Domain Users 17 Apr 26 23:12 dovecot-uidlist
-rw------- 1 test2 Domain Users 8 Apr 26 23:12 dovecot-uidvalidity
-rw------- 1 test2 Domain Users 0 Apr 26 23:12 dovecot-
uidvalidity.4bd61dd5
-rw------- 1 test2 Domain Users 156 Apr 26 23:12 dovecot.index.log
drwx------ 2 test2 Domain Users 512 Apr 26 23:12 new
drwx------ 2 test2 Domain Users 512 Apr 26 23:12 tmp
110
A5.3 Instalación y Configuración Postfix
Instalación de Postfix mediante ports:
La configuración al momento de instalar es la siguiente:
Copiar el archivo de main.cf de vmfiles.tar en /etc/postfix/main.cf, con las configuraciones del
servidor, donde se cambiaran los nombres del servidor y la red en la que se está trabajando.
Crear el archivo en la ruta indicada:
Creación de base de datos tipo bdb:
Agregar a Postfix para arrancarlo al inicio (tiene que ser antes que Dovecot):
Se inicia la aplicación:
#/usr/ports/mail/postfix
#make install clean
[X] PCRE Perl Compatible Regular Expressions
[X] TLS Enable SSL and TLS support
[X] MYSQL MySQL maps (choose version with WITH_MYSQL_VER)
[X] NIS NIS maps lookups
[X] VDA VDA (Virtual Delivery Agent 32Bit)
[X] INST_BASE Install into /usr and /etc/postfix
touch /etc/aliases
#/usr/sbin/postmap hash:/etc/aliases
postfix_enable="YES"
/etc/rc.d/postfix start
111
Finalmente se verifica si los puertos han quedado habilitados:
#sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
dovecot imap-login 17451 4 tcp4 192.168.220.143:143 *:*
postfix qmgr 1870 8 tcp4 192.168.220.143:26455 192.168.220.143:389
postfix pickup 1869 8 tcp4 192.168.220.143:43595 192.168.220.143:389
root master 1858 12 tcp4 192.168.220.143:25 *:*
root sshd 56266 3 tcp4 192.168.220.143:4576 189.220.35.217:1938
root sshd 56266 4 tcp4 192.168.220.143:63718 192.168.220.143:389
dovecot imap-login 49554 4 tcp4 192.168.220.143:143 *:*
dovecot imap-login 49016 4 tcp4 192.168.220.143:143 *:*
root dovecot-au 49013 5 tcp4 192.168.220.143:56388 192.168.220.143:389
root dovecot-au 49012 8 tcp4 192.168.220.143:11954 192.168.220.143:389
root dovecot 49011 7 tcp4 192.168.220.143:143 *:*
root smbd 88886 9 tcp4 192.168.220.143:34457 192.168.220.143:389
root smbd 88880 9 tcp4 192.168.220.143:34457 192.168.220.143:389
root nmbd 88873 9 udp4 192.168.220.143:137 *:*
root nmbd 88873 10 udp4 192.168.220.143:138 *:*
ldap slapd 88590 7 tcp4 192.168.220.143:389 *:*
ldap slapd 88590 11 tcp4 192.168.220.143:389 192.168.220.143:34457
ldap slapd 88590 16 tcp4 192.168.220.143:389 192.168.220.143:11954
ldap slapd 88590 20 tcp4 192.168.220.143:389 192.168.220.143:63718
ldap slapd 88590 24 tcp4 192.168.220.143:389 192.168.220.143:43595
ldap slapd 88590 28 tcp4 192.168.220.143:389 192.168.220.143:26455
ldap slapd 88590 29 tcp4 192.168.220.143:389 192.168.220.143:56388
112
Anexo A6
Códigos Fuentes de Sitios Web de Autenticación
A6.1 Descripción General
El presente anexo describe los códigos fuentes utilizados para las pruebas de integración
entre el servidor de autenticación OpenLDAP y un servidor Web determinado. Se mostrarán
cada uno de los casos de pruebas descritos en el capítulo 6. Antes de comenzar, el servidor Web,
que para este caso está en Ubuntu 10.10 debe tener los siguientes paquetes instalados:
LAMP : Incluye PHP5, MySQL, Apache2.
LDAP-utils : Cliente LDAP, que permite utilizar los comandos de conexión y utilización del
servidor OpenLDAP.
PHP5-LDAP : Soporte de LDAP para el desarrollo de aplicaciones en PHP, necesario para los
códigos fuentes que accedan al servidor OpenLDAP.
A6.2 Códigos Fuentes
El siguiente código muestra el sitio de autenticación en HTML, que representa la vista
que tendrá el usuario al momento de autenticarse.
<html>
<table>
<tr><td></td></tr>
</table>
<center><br><br><br><br>
<table cellspacing="0" cellpadding="0">
<tr><td colspan="2" align="center" class="texto_items">
<div>
Sitio de Autenticación LDAP
<div class="text_mat">por bvasquez</div>
</div>
</td>
<td width="10"></td>
<td width="1" bgcolor="#CCCCCC"></td>
<td width="10"></td>
<td>
<table>
<form action="verifica.php?accion=verificacion" method="POST">
<tr><td class="texto_items">Usuario</td><td><input class="texto_inputs"
type="text" name="usuario" size="20" class="imputbox"></td><tr>
<tr><td class="texto_items">Clave</td><td><input class="texto_inputs"
type="password" name="clave" size="20" class="imputbox"></td>
</tr>
113
El siguiente cuadro muestra el código fuente en PHP utilizado para la autenticación en el
servidor OpenLDAP. Su nombre es verifica.php, al cual se le pasa por el método POST el
nombre de usuario y contraseña.
<tr><td colspan="2" align="center">
<div class="text_error"><?echo $error_LDAP;?></div>
<input name="submit" type="submit" value=" Entrar " class="botones">
</td>
</tr>
</table>
</td></tr>
</table>
<br>
<div class="text_mat"><font color=666666>OpenLDAP | Autenticacion en PHP
+ LDAP | Pruebas en Red ELO</font>
</div>
</html>
<?php
// variables de autenticacion y LDAP
$ldap['user'] = $_POST["usuario"];
$ldap['pass'] = $_POST["clave"];
$ldap['host'] = '192.168.220.143'; // nombre del host o
servidor
$ldap['port'] = 389; // puerto del LDAP en el servidor
$ldap['dn'] =
'uid='.$ldap['user'].',ou=People,dc=elo,dc=utfsm,dc=cl'; // modificar
respecto a los valores del LDAP
$ldap['base'] = ' ';
// conexion a ldap
$ldap['conn'] = ldap_connect( $ldap['host'], $ldap['port'] );
ldap_set_option($ldap['conn'], LDAP_OPT_PROTOCOL_VERSION, 3);
// match de usuario y password
$ldap['bind'] = ldap_bind( $ldap['conn'], $ldap['dn'], $ldap['pass'] );
if ($ldap['bind']){
session_start();
session_cache_limiter('nocache,private');
$_SESSION['usuario']=$_POST["usuario"];
$_SESSION['clave']=$_POST["clave"];
$_SESSION['usuario_fecha']= date("Y-n-j H:i:s");
$pag=$_SERVER['PHP_SELF'];
url=asegurada.php\"></head>";
echo "Estas autenticado como ";
echo $ldap['user'] ;
}else{
echo "Usuario o contraseña Incorrecta";
exit();
}
?>
114
El código fuente presentado a continuación, representa una conexión a un servidor de
correos que utiliza el protocolo IMAP, y éste luego se autentica contra OpenLDAP como se
describió en el Anexo A5. La idea de éste es representar lo que ocurre en el Sistema de Gestión
de Prácticas, que se autentica contra IMAP, y luego con NIS+.
Por efectos de seguridad, no se entregarán los códigos fuentes modificados en los Sitios de
Autenticación de Prácticas ni el de Solicitud de Memos del Departamento de Electrónica.
<?php
$login=$_POST["usuario"];
$password=@make_safe($_POST["clave"]);
$MAILSERVER="192.168.220.143";
if($enlace=@imap_open($MAILSERVER,$login,$password)){
$sesion = @session_start();
$cache = @session_cache_limiter('nocache,private');
$_SESSION['usuario']=$_POST["usuario"];
$_SESSION['clave']=$_POST["clave"];
$_SESSION['usuario_fecha']=@date("Y-n-j H:i:s");
$pag=$_SERVER['PHP_SELF'];
//echo "<head><meta http-equiv=\"refresh\" content=\"0;
url=asegurada.php\"></head>";
echo "Estas autenticado como ";
echo $login ;
}else{
echo "Usuario o Password Incorrecto";
exit();
}
?>
115
Anexo A7
Códigos Fuentes para la Migración de Usuarios desde NIS+
a OpenLDAP
A7.1 Descripción General
En el capítulo 6 se describió el proceso de migración recomendado, para llevar las
cuentas que se encuentran bajo la aplicación NIS+ al servidor de directorio y autenticación
OpenLDAP. En este anexo se hace referencia a los scripts diseñados para tal tarea. Para ello se
utilizó un archivo base llamado cuentas.txt. Este último fue otorgado por el Administrador de
Red del Departamento de Electrónica, y contiene todas las cuentas de usuario con la siguiente
nomenclatura:
Username Password UID GID Nombre Homedir Shell
Bvasquez ******** 2488 210 Braulio
Vásquez
/home/tel2004/bvasquez /usr/local/bin/bash
Cabe mencionar que en el archivo original cada uno de los parámetros se encuentra
separados por el signo “:”.
A7.2 Código Fuente de Migración
El siguiente cuadro muestra el código fuente desarrollado en Perl, que toma desde el
archivo cuentas.txt, los valores de cada uno de los usuarios, y los traspasa al formato necesario,
para ser agregado mediante la herramienta smbldap-tools. Básicamente el script hace separación
mediante “:” y “/” almacenando cada uno de los valores en un arreglo.
#!/usr/bin/perl
#Abro Archivos de Lectura/Escritura de Usuarios
open (LECTURA, "<cuentas.txt")|| print "Lo siento el archivo no se
puede abrir";
open (FILE,">migracion.sh");
while ($linea = <LECTURA>){
@arr_linea = split(":",$linea);
@directorio=split("/",$arr_linea[5]);
print FILE "smbldap-useradd -a -m -d
/usr/home/$directorio[2]/$arr_linea[0] -S ".'"'."$arr_linea[4]".'"'."
$arr_linea[0]\n";
print FILE "echo nuevapass | smbldap-passwd -p $arr_linea[0]\n";
print FILE "smbldap-groupmod -m $arr_linea[0] $directorio[2]\n";
print FILE "echo USUARIO $arr_linea[0] OK!!\n\n";
}
close LECTURA;
close FILE;
116
Finalmente se tiene el archivo migración.sh que hace uso de las siguientes herramientas
de smbldap-tools:
Smbldap-useradd : Agrega usuarios al dominio LDAP/SAMBA.
Smbldap-passwd : Agrega password al usuario creado anteriormente.
Smbldap-groupmod : Agrega al usuario a un grupo o unidad organizacional determinada.
El cuadro anterior presenta los comandos para un solo usuario. Las opciones usadas son
las siguientes:
Smbldap-useradd: -a Agrega al usuario a la cuenta Windows.
-m Crea el directorio home del usuario.
-d Establece la ruta del directorio home.
-S Establece el nombre del usuario.
Smbldap-passwd: -p Agrega la contraseña en background.
Smbldap-groupmod: -m Agrega al usuario en el grupo determinado.
#!/usr/local/bin/bash
smbldap-useradd -a -m -d /usr/home/alm97/klos -S "Yerko Alejandro
Jaramillo Vega" klos
echo nuevapass | smbldap-passwd -p klos
smbldap-groupmod -m klos alm97
echo USUARIO klos OK!!