Servidores de Dominio: LDAP y Kerberos

Propuesta de pasos para crear un servidor de dominio

en linux en la alcaldia del municipio de Puerto
Fernandez

Integrantes:
Samuel Hervas Franco 211008702
Eimer Quintanilla Nava Polo 211014818
Brayan Jacome Guzman 211009199
Erick Rivero Aguilera 200868713
Arnold Villarroel Fuentes 200838849
Materia: Gestión y Administración de Redes
Docente: Ing. Leonardo Vargas
Fecha: 4 de mayo del 2016
Introducción
Las redes de computadoras son hoy parte indispensable de las instituciones que cuentan con un
número considerable de ordenadores en operación, frecuentemente alejadas entre sí, con los
objetivos de compartir recursos (Información, Aplicaciones, Periférico), proveer de confiabilidad
y de lograr comunicación entre las distintas estaciones de trabajo. El trabajo en red ofrece
numerosas ventajas como son: la reducción de costos al compartir información y periféricos, la
adquisición de datos oportunamente, mejoría para la organización y la comunicación de las
empresas, mantener bases de datos actualizadas instantáneamente y accesibles desde distintos
puntos, facilitar la copia de respaldo de los datos, etc.
En las redes institucionales, en muchas ocasiones, es de interés contar con un directorio
centralizado de cuentas de usuarios y contraseñas con el objetivo, primero, de que cada usuario
pueda abrir sesión en las distintas computadoras del dominio sin necesidad de crear las cuentas
localmente en cada una de ellas, tener mejor control de los usuarios que se van agregando y
desagregando a la red, así como un mejor control sobre los recursos a los que se va a acceder.
Este trabajo presenta un método de integración de una red heterogénea con múltiples clientes,
y donde cada uno de ellos pueda tener sistemas operativos diferentes, sobre los cuales pueden
operar una infinidad de usuarios contra una base de datos común, utilizando un directorio LDAP
para almacenar la información relativa a los usuarios.
El proyecto de la Alcaldía del Municipio de Puerto Fernández, permite explorar nuevos temas
como la creación de un servidor de dominio utilizando un sistema operativo de Linux.
Para poder cumplir los objetivos de la propuesta del servidor de dominio de la Alcaldía de Puerto
Fernández, es importante aclarar que es un servidor de dominio.

El problema
La Alcaldía del Municipio de Puerto Fernández requiere controlar:

 El acceso a sus equipos.

 Uso de dispositivos de almacenamiento.
 El acceso a sitios web no autorizado.
 El ingreso de software mal intencionado que pueda afectar el funcionamiento tanto de
los equipos como de la misma red.
 El direccionamiento estático utilizado en las instalaciones.
Actualmente no hay ninguna restricción para los usuarios y funcionarios en la Alcaldía de
Dosquebradas, también se requiere dar direcciones ip de forma ordenada a nivel de cada
dependencia.
 Se escogió trabajar con un sistema operativo basado en Linux no solo por el presupuesto sino
también porque sería algo nuevo para agregar a los conocimientos obtenidos a través de la
carrera de ingeniería en sistemas y telecomunicaciones.

Objetivos
-Objetivo General
Elaborar una propuesta de diseño, estructura y creación de un servidor de dominio en la
Alcaldía del Municipio de Dosquebradas.

-Objetivos Específicos
 Identificar los diferentes problemas a resolver con el servidor de dominio.
 Establecer políticas para la creación del servidor de dominio Elaborar la propuesta de
Diseño y Estructura para la creación del servidor de dominio, teniendo encuentra las
políticas ya establecidas anteriormente.
 Creación de un servidor de dominio funcional basado en un sistema operativo Linux
(ubuntu)

Metodología

Servidores de Dominio
Un servidor de dominio básicamente es el encargado de la administración de todos los equipos
previamente vinculados al servidor, es el encargado de controlar o administrar el DHCP, el DNS,
aplicaciones, etc.
El servidor de dominio, debe poder mantener de una manera ordena el direccionamiento ip
dentro de las instalaciones, debe ayudar a mejor y controlar aspectos de seguridad a nivel
interno de la red y de los equipos que la componen

DHCP
Definición del termino DHCP
DHCP significa Protocolo de configuración de host dinámico. Es un protocolo que permite que
un equipo conectado a una red pueda obtener su configuración (principalmente, su
configuración de red) en forma dinámica (es decir, sin intervención particular). Sólo tiene que
especificarle al equipo, mediante DHCP, que encuentre una dirección IP de manera
independiente. El objetivo principal es simplificar la administración de la red.
El protocolo DHCP sirve principalmente para distribuir direcciones IP en una red, pero desde sus
inicios se diseñó como un complemento del protocolo BOOTP (Protocolo Bootstrap), que se
utiliza, por ejemplo, cuando se instala un equipo a través de una red (BOOTP se usa junto con
un servidor TFTP donde el cliente encontrará los archivos que se cargarán y copiarán en el disco
duro). Un servidor DHCP puede devolver parámetros BOOTP o la configuración específica a un
determinado host.

Funcionamiento del protocolo DHCP

Primero, se necesita un servidor DHCP que distribuya las direcciones IP. Este equipo será la
base para todas las solicitudes DHCP por lo cual debe tener una dirección IP fija. Por lo tanto, en
una red puede tener sólo un equipo con una dirección IP fija: el servidor DHCP.
El sistema básico de comunicación es BOOTP (con la trama UDP). Cuando un equipo se inicia no
tiene información sobre su configuración de red y no hay nada especial que el usuario deba
hacer para obtener una dirección IP. Para esto, la técnica que se usa es la transmisión: para
encontrar y comunicarse con un servidor DHCP, el equipo simplemente enviará un paquete
especial de transmisión (transmisión en 255.255.255.255 con información adicional como el
tipo de solicitud, los puertos de conexión, etc.) a través de la red local. Cuando el DHCP recibe
el paquete de transmisión, contestará con otro paquete de transmisión (no olvide que el cliente
no tiene una dirección IP y, por lo tanto, no es posible conectar directamente con él) que
contiene toda la información solicitada por el cliente.
Se podría suponer que un único paquete es suficiente para que el protocolo funcione. En
realidad, hay varios tipos de paquetes DHCP que pueden emitirse tanto desde el cliente hacia el
servidor o servidores, como desde los servidores hacia un cliente:
DHCPDISCOVER (para ubicar servidores DHCP disponibles)
DHCPOFFER (respuesta del servidor a un paquete DHCPDISCOVER, que contiene los parámetros
iniciales)
DHCPREQUEST (solicitudes varias del cliente, por ejemplo, para extender su concesión)
DHCPACK (respuesta del servidor que contiene los parámetros y la dirección IP del cliente)
DHCPNAK (respuesta del servidor para indicarle al cliente que su concesión ha vencido o si el
cliente anuncia una configuración de red errónea)
DHCPDECLINE (el cliente le anuncia al servidor que la dirección ya está en uso)
DHCPRELEASE (el cliente libera su dirección IP)
DHCPINFORM (el cliente solicita parámetros locales, ya tiene su dirección IP)
El primer paquete emitido por el cliente es un paquete del tipo DHCPDISCOVER. El servidor
responde con un paquete DHCPOFFER, fundamentalmente para enviarle una dirección IP al
cliente. El cliente establece su configuración y luego realiza un DHCPREQUEST para validar su
dirección IP (una solicitud de transmisión ya que DHCPOFFER no contiene la dirección IP) El
servidor simplemente responde con un DHCPACK con la dirección IP para confirmar la
asignación. Normalmente, esto es suficiente para que el cliente obtenga una configuración de
red efectiva, pero puede tardar más o menos en función de que el cliente acepte o no la
dirección IP.

Concesiones
Para optimizar los recursos de red, las direcciones IP se asignan con una fecha de inicio y de
vencimiento para su validez. Esto es lo que se conoce como "concesión". Un cliente que detecta
que su concesión está a punto de vencer, puede solicitarle al servidor una extensión de la
misma por medio de un DHCPREQUEST. Del mismo modo, cuando el servidor detecta que una
concesión va a vencer, enviará un DCHPNAK para consultarle al cliente si desea extenderla. Si el
servidor no recibe una respuesta válida, convertirá la dirección IP en una dirección disponible.
Esta es la efectividad de DHCP: se puede optimizar la asignación de direcciones IP planificando
la duración de las concesiones. El problema es que si no se liberan direcciones, en un momento
determinado no se podrá cumplir con nuevas solicitudes DHCP debido a que faltarán
direcciones que puedan distribuirse.
En una red en la cual muchos equipos se conectan y desconectan permanentemente (redes de
escuelas o de oficinas de ventas, por ejemplo), es aconsejable ofrecer concesiones por períodos
cortos. En cambio, para una red compuesta principalmente por equipos fijos que se reinician
rara vez, las concesiones por períodos largos son más que suficientes. No se olvide que DHCP
trabaja principalmente por transmisión y que puede ocupar ancho de banda en redes pequeñas
con alta demanda.
DNS
Definición de DNS
DomainNameSystem o DNS (en español: sistema de nombres de dominio) es un sistema de
nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a Internet
o a una red privada. Este sistema asocia información variada con nombres de dominios
asignado a cada uno de los participantes. Su función más importante, es traducir (resolver)
nombres inteligibles para los humanos en identificadores binarios asociados con los equipos
conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos
mundialmente.
El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena información
asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es
capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la
asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo
electrónico de cada dominio.
La asignación de nombres a direcciones IP es ciertamente la función más conocida de los
protocolos DNS. Por ejemplo, si la dirección IP del sitio FTP de prox.mx es 200.64.128.4, la
mayoría de la gente llega a este equipo especificando ftp.prox.mx y no la dirección IP. Además
de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por
muchas razones, sin que tenga que cambiar el nombre.

Componentes de DNS
Para la operación práctica del sistema DNS se utilizan tres componentes principales:
Los Clientes DNS: Un programa cliente DNS que se ejecuta en la computadora del usuario y que
genera peticiones DNS de resolución de nombres a un servidor DNS (Por ejemplo: ¿Qué
dirección IP corresponde a nombre.dominio?)
Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores recursivos
tienen la capacidad de reenviar la petición a otro servidor si no disponen de la dirección
solicitada.
Las Zonas de autoridad: porciones del espacio de nombres de dominio que almacenan los
datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si
estos últimos no son delegados a otras zonas de autoridad.
Tipos de servidores DNS
Preferidos: Guardan los datos de un espacio de nombres en sus ficheros.
Alternativos: Obtienen los datos de los servidores primarios a través de una transferencia de
zona.
Locales o caché: Funcionan con el mismo software, pero no contienen la base de datos para la
resolución de nombres. Cuando se les realiza una consulta, estos a su vez consultan a los
servidores secundarios, almacenando la respuesta en su base de datos para agilizar la
repetición de estas peticiones en el futuro continuo o libre.

SAMBA
Samba es un programa Open Source que nos permite compartir archivos e impresoras desde
una computadora Linux a PC con MS Windows como si fuera una mas de ella, lo cual es muy útil
ya que podemos tener un servidor de archivos y de impresión basado en Linux colocado en una
red donde se conectan PC con Windows.

TERMINAL SERVICES
UTILIDAD DE TERMINAL SERVICES
Con Terminal Services se puede acceder a un servidor de terminales desde la red corporativa o
desde Internet.
Es importante que tengamos claros cuáles son los roles de los servicios que se tienen en
Terminal Services:

 Terminal Server: Servicio que habilita un servidor para que se puedan correr
aplicaciones remotas o dar acceso al escritorio. Los usuarios se conectan al servidor que
tiene este rol para acceder a las aplicaciones que estén instaladas en él, guardar
archivos o bien usar cualquiera de los recursos de la red que estén disponibles. Los
usuarios acceden a este servidor usando Remote Desktop Connection o bien programas
RemoteApp.
 TS RemoteApp: Son aplicaciones que se ejecutan a través de Terminal Services pero se
comportan como si estuvieran corriendo localmente en la estación de trabajo del
usuario. Para el usuario es como si la aplicación estuviera instalada en su máquina al
igual que otra aplicación local. Si el usuario corre varias aplicaciones del mismo servidor
de Terminal Services, todas ellas correrán en la misma sesión para ahorrar sesiones y
lograr mayor velocidad de acceso a las mismas.
  TS Web Access: Servicio que permite acceso al servidor desde un sitio Web (Internet o
Intranet). También incluye el Remote Desktop Web Connection el cual le permite a un
usuario conectarse a cualquier computadora donde tengan acceso con RemoteDesktop .
 TS Licensing: Este servicio maneja las licencias de acceso de cliente (o CAL como se le
conoce en inglés) para cada usuario o dispositivo que se conecta al servidor. Este
servicio se encarga de instalar, otorgar y monitorear la disponibilidad de CAL’s de TS en
el servidor. Para poder usar Terminal Services, debe tener por lo menos un servidor de
licencias. En instalaciones pequeñas de TS, puede poner juntos los roles de TS y de
Licencia en el mismo servidor. En instalaciones grandes se recomienda separar estos
roles en diferentes servidores. Este servicio debe ser configurado apropiadamente para
que los clientes puedan conectarse al TS.
 TS Gateway: Permite a usuarios remotos autorizados a conectarse a recursos en una
red corporativa o interna desde cualquier dispositivo conectado a Internet que pueda
correr el Remote Desktop ConnectionClient. El TS Gateway encapsula el protocolo RDP
(Remote Desktop Protocol) dentro de RPC y este a su vez dentro de HTTP sobre una
conexión de SSL, permitiendo que los usuarios se conecten en una forma encriptada y
segura desde Internet. Esta funcionalidad le permitirá implementar acceso remoto a
Terminal Services sin necesidad de implementar una VPN.
 TS SessionBroker: Este rol mantiene el control de las sesiones cuando se tiene
configurado Terminal Services con Load Balancing. La base de datos de este servicio
guarda la información del estado de cada sesión que incluye el Session ID, usuario y el
nombre del servidor donde reside cada sesión. Esto permite que el usuario siempre sea
dirigido al servidor que tiene su sesión evitando así crear una nueva sesión en otro
servidor de la granja. El servicio también lleva el control de cuántas sesiones hay en cada
servidor para mantener siempre balanceada la granja de servidores.

Protocolo ligero de acceso a directorios (LDAP)

El Protocolo ligero de acceso a directorios (en inglés, Lightweight Directory Access Protocol,
LDAP) es un conjunto de protocolos abiertos usados para acceder información guardada
centralmente a través de la red. Está basado en el estándar X.500 para compartir directorios,
pero es menos complejo e intensivo en el uso de recursos. Por esta razón, a veces se habla de
LDAP como "X.500 Lite." El estándar X.500 es un directorio que contiene información de forma
jerárquica y categorizada, que puede incluir nombres, directorios y números telefónicos.
X.500 es un conjunto de estándares de redes de ordenadores de la ITU-T sobre servicios de
directorio, entendidos estos como bases de datos de direcciones electrónicas (o de otros tipos).
El estándar se desarrolló conjuntamente con la ISO como parte del Modelo de interconexión de
sistemas abiertos, para usarlo como soporte del correo electrónico X.400.
Como X.500, LDAP organiza la información en un modo jerárquico usando directorios. Estos
directorios pueden almacenar una gran variedad de información, permitiendo que cualquiera
pueda acceder a su cuenta desde cualquier máquina en la red acreditada con LDAP.
Sin embargo, en la mayoría de los casos, LDAP se usa simplemente como un directorio telefónico
virtual, permitiendo a los usuarios acceder fácilmente la información de contacto de otros
usuarios. Pero LDAP va mucho más lejos que un directorio telefónico tradicional, ya que es capaz
de propagar su consulta a otros servidores LDAP por todo el mundo, proporcionando un
repositorio de información ad-hoc global. Sin embargo, en este momento LDAP se usa más
dentro de organizaciones individuales, como universidades, departamentos del gobierno y
compañías privadas.
LDAP es un sistema cliente/servidor. El servidor puede usar una variedad de bases de datos para
guardar un directorio, cada uno optimizado para operaciones de lectura rápidas y en gran
volúmen. Cuando una aplicación cliente LDAP se conecta a un servidor LDAP puede, o bien
consultar un directorio, o intentar modificarlo. En el evento de una consulta, el servidor, puede
contestarla localmente o puede dirigir la consulta a un servidor LDAP que tenga la respuesta. Si
la aplicación cliente está intentando modificar información en un directorio LDAP, el servidor
verifica que el usuario tiene permiso para efectuar el cambio y después añade o actualiza la
información.

Ventajas de usar LDAP

La mayor ventaja de LDAP es que se puede consolidar información para toda una organización
dentro de un repositorio central. Por ejemplo, en vez de administrar listas de usuarios para cada
grupo dentro de una organización, puede usar LDAP como directorio central, accesible desde
cualquier parte de la red. Puesto que LDAP soporta la Capa de conexión segura (SSL) y la
Seguridad de la capa de transporte (TLS), los datos confidenciales se pueden proteger de los
curiosos.
LDAP también soporta un gran número de bases de datos back-end en las que se guardan
directorios. Esto permite que los administradores tengan la flexibilidad para desplegar la base de
datos más indicada para el tipo de información que el servidor tiene que diseminar. También, ya
que LDAP tiene una interfaz de programación de aplicaciones (API) bien definida, el número de
aplicaciones acreditadas para LDAP son numerosas y están aumentando en cantidad y calidad.
Terminología LDAP
Cualquier discusión sobre LDAP requiere un entendimiento básico del conjunto de términos
específicos de LDAP:

• Entrada : Una entrada es una unidad en un directorio LDAP. Cada entrada se identifica por su
único Nombre distinguido (Distinguished Name (DN)).

• Atributos : Los atributos son piezas de información directamente asociada con la entrada. Por
ejemplo, una organización puede ser representada como una entrada LDAP. Los atributos
asociados con la organización pueden ser su número de fax, su dirección, etc. En un directorio
LDAP las entradas pueden ser también personas, con atributos comunes como el número de
teléfono y la dirección de e-mail.
Algunos atributos son obligatorios mientras que otros son opcionales. Una definición objectclass
determina qué atributos se requieren y cuáles no para cada entrada. Las definiciones de
objectclass se encuentran en varios archivos de esquema, dentro del directorio
/etc/openldap/schema/.
LDIF — El Formato de intercambio de datos de LDAP (LDIF) es una representación de texto ASCII
de entradas LDAP. Los archivos usados para importar datos a los servidores LDAP deben estar en
formato LDIF. Una entrada LDIF se ve similar al ejemplo siguiente:
[<id>] dn: <distinguished name> <attrtype>: <attrvalue> <attrtype>: <attrvalue>
<attrtype>: <attrvalue>
Una entrada puede contener tantos pares <attrtype>: <attrvalue> como sean necesarios. Una
línea en blanco indica el final de una entrada. Todas las parejas <attrtype> y <attrvalue>
deben estar definidas en el archivo esquema correspondiente para usar esta información.
Cualquier valor comprendido dentro de < y > es una variable y puede ser configurado cuando se
cree una nueva entrada LDAP. Sin embargo, esta regla no se aplica a <id>. El <id> es un número
determinado por la aplicación que se usa para modificar la entrada.
Funcionamiento de LDAP
• El servicio de directorio LDAP se basa en un modelo cliente-servidor.
• Uno o más servidores LDAP contienen los datos que conforman el árbol de directorio LDAP o
base de datos troncal, el cliente LDAP se conecta con el servidor LDAP y le hace una consulta. El
servidor contesta con la respuesta correspondiente, o bien con una indicación de donde puede
el cliente hallar más información. No importa con que servidor LDAP se conecte el cliente ya que
siempre observará la misma vista del directorio; el nombre que se le presenta a un servidor LDAP
hace referencia a la misma entrada a la que haría referencia en otro servidor LDAP.
• Directorios de información. Por ejemplo bases de datos de empleados organizados por
departamentos (siguiendo la estructura organizativa de la empresa) ó cualquier tipo de páginas
amarilla.
• Sistemas de autenticación/autorización centralizada.
◦ Active Directory Server, para gestionar todas las cuentas de acceso a una red corporativa y
mantener centralizada la gestión del acceso a los recursos.
◦ Sistemas de autenticación para páginas Web, algunos de los gestores de contenidos más
conocidos disponen de sistemas de autenticación a través de LDAP.
◦ Sistemas de control de entradas a edificios, oficinas .
• Sistemas de correo electrónico. Grandes sistemas formados por más de un servidor que
accedan a un repositorio de datos común.
• Sistemas de alojamiento de páginas web y FTP, con el repositorio de datos de usuario
compartido.
• Sistemas de autenticación basados en RADIUS, para el control de accesos de los usuarios a una
red de conexión o ISP.
• Servidores de certificados públicos y llaves de seguridad.
• Autenticación única ó “single sign-on” para la personalización de aplicaciones.
• Perfiles de usuarios centralizados, para permitir itinerancia ó “Roaming”
• Libretas de direcciones compartidas.
Ejemplos de uso de LDAP
• Sistema de correo electrónico
Cada usuario se identifica por su dirección de correo electrónico, los atributos que se guardan de
cada usuario son su contraseña, su límite de almacenamiento (quota), la ruta del disco duro
donde se almacenan los mensajes (buzón) y posiblemente atributos adicionales para activar
sistemas anti-spam o anti-virus.
Como se puede ver este sistema LDAP recibirá cientos de consultas cada día (una por cada email
recibido y una cada vez que el usuario se conecta mediante POP3 o webmail). No obstante el
número de modificaciones diarias es muy bajo, ya que solo se puede cambiar la contraseña o dar
de baja al usuario, operaciones ambas que no se realizan de forma frecuente.

• Sistema de autenticación a una red

Cada usuario se identifica por un nombre de usuario y los atributos asignados son la contraseña,
los permisos de acceso, los grupos de trabajo a los que pertenece, la fecha de caducidad de la
contraseña...
Este sistema recibirá una consulta cada vez que el usuario acceda a la red y una más cada vez que
acceda a los recursos del grupo de trabajo (directorios compartidos, impresoras...) para
comprobar los permisos del usuario.
Frente a estos cientos de consultas solo unas pocas veces se cambia la contraseña de un usuario
o se le incluye en un nuevo grupo de trabajo.

Administración de Sistemas LDAP

Arquitectura de Funcionamiento
Backends, Vision General
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 un 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.
Actualmente 16 diferentes backends son proporcionados en la distribución de OpenLDAP, y
varios proporcionados por terceros son conocidos para mantener otros backends de manera
independiente. Los backends estándar están organizados de manera imprecisa en tres
categorías:
• Backends de almacenamiento de datos (Data Storage backends) - estos realmente
almacenan información .
• Proxy backends - actúan como puertas de enlace a otros sistemas de almacenamiento
de datos .
• Backends dinámicos - estos generan datos sobre la marcha .
Backends de almacenamiento de datos (Data Storage backends) - estos realmente almacenan
información
• back-bdb: el primer backend transaccional para OpenLDAP, construido en base a
BerkeleyDB
• back-hdb: una variante de back-bdb que es totalmente jerárquica y soporta
renombrado de subárboles
• back-ldif: construido en archivos LDIF de texto plano • back-ndb: un backend
transaccional construido en base al motor de cluster NDB de MySQL
Backends dinámicos - estos generan datos sobre la marcha
• back-config: configuración del servidor slapd vía LDAP • back-dnssrv: localiza servidores
LDAP vía DNS
• back-monitor: estadísticas de slapd vía LDAP • back-null: un backend nulo, análogo a
/dev/null en Unix
• back-perl: invoca arbitrariamente módulos de perl en respuesta a peticiones LDAP
• back-shell: invoca scripts de shell para peticiones LDAP
• back-sock: redirige peticiones LDAP sobre IPC a demonios de manera arbitraria

Arquitectura de Overlays
Generalmente una petición LDAP es recibida por el frontend, decodificada y luego transferida a
un backend para procesamiento. Cuando el backend completa la petición, devuelve un resultado
al frontend, quien luego envía el resultado al cliente LDAP. Un overlay es una pieza de código que
puede ser insertada entre el frontend y el backend.
Es entonces capaz de interceptar peticiones y lanzar otras acciones en ellas antes de que el
backend las reciba, y puede también actuar sobre los resultados del backend antes de que éstos
alcancen el frontend. Overlays tiene acceso completo a las interfaces de programación (APIs)
internas del servidor slapd, y por tanto pueden invocar cualquier llamada que podrían realizar el
frontend u otros backends. Múltiples overlays pueden ser usados a la vez, formando una pila de
módulos entre el frontend y el backend.
Proxy backends - actúan como puertas de enlace a otros sistemas de almacenamiento de datos
• back-ldap: proxy simple a otros servidores LDAP • back-meta: proxy con características de
meta-directorio • back-passwd: usa un sistema basado en Unix de datos passwd y group • back-
relay: internamente redirige a otros backends de servidores slapd • back-sql: establece
conexiones a bases de datos SQL

Introducción a la estructura de árbol

Tradicionalmente se han usado las estructuras de árbol para jerarquizar la información contenida
en un medio. El ejemplo más claro es la estructura de carpetas (directorios) de un sistema
operativo. Esta organización nos permite ordenar la información en subdirectorios que contienen
información muy específica.

Introducción a la estructura de árbol – Entradas

El modelo de información de LDAP está basado en entradas. Una entrada es una colección de
atributos que tienen un único y global.
Nombre Distintivo (DN). El DN se utiliza para referirse a una entrada sin ambigüedades. Cada
atributo de una entrada posee un tipo y uno o más valores. Los tipos son normalmente palabras
nemotécnicas, como “cn” para common name, o “mail” para una dirección de correo.
La sintaxis de los atributos depende del tipo de atributo. Por ejemplo, un atributo cn puede
contener el valor “Jose Manuel Suarez”. Un atributo email puede contener un valor
“jmsuarez@ejemplo.com”. El atributo jpegPhoto ha de contener una fotografía en formato JPEG.

Introducción a la estructura de árbol – Atributos

Los datos del directorio se representan mediante pares de atributo y su valor. Por ejemplo el
atributo commonName, o cn (nombre comun), se usa para almacenar el nombre de una persona.
Puede representarse en el directorio a una persona llamada José Suarez mediante:
• cn: José Suarez
Cada persona que se introduzca en el directorio se define mediante la colección de atributos que
hay en la clase de objetos person. Otros atributos:
• givenname: José - --Atributo Requerido
• surname: Suarez
• mail: jmsuarez@ejemplo.com
Los atributos requeridos son aquellos que deben estar presentes en las entradas que utilicen en
la clase de objetos. Todas las entradas precisas de los atributos permitidos son aquellos que
pueden estar presentes en las entradas que utilicen la clase de objetos. Por ejemplo, en la clase
de objetos person, Se requieren los atributos cn y sn.
Los atributos description (descripción), telephoneNumber (número de teléfono), seealso (véase
también), y userpassword (contraseña del usuario) se permiten pero no son obligatorios.
Introducción a la estructura de árbol – Tipos de Atributos
Una definición de tipo de atributo especifica la sintaxis de un atributo y cómo se ordenan y
comparan los atributos de ese tipo.
Los tipos de atributos en el directorio forman un árbol de clases. Por ejemplo, el tipo de atributo
"commonName" es una subclase del tipo de atributo "name".
La estructura de árbol - El Archivo LDIF
Para importar y exportar información de directorio entre servidores de directorios basados en
LDAP, o para describir una serie de cambios que han de aplicarse al directorio, se usa en general
el archivo de formato conocido como LDIF (formato de intercambio de LDAP).
Un archivo LDIF almacena información en jerarquías de entradas orientadas a objeto. Todos los
servidores LDAP que incluyen una utilidad para convertir archivos LDIF a formato orientadas a
objeto. Normalmente es un archivo ASCII.

La estructura de árbol - Clases de Objetos

En LDAP, una clase de objetos define la colección de atributos que pueden usarse para definir
una entrada. El estándar LDAP proporciona estos tipos básicos para las clases de objetos:
1. Grupos en el directorio, entre ellos listas no ordenadas de objetos individuales o de grupos de
objetos.
2. Emplazamientos, como por ejemplo el nombre del país y su descripción.
3. Organizaciones que están en el directorio.
4. Personas que están en el directorio.
Una entrada determinada puede pertenecer a más de una clase de objetos. Por ejemplo, la
entrada para personas se define mediante la clase de objetos person, pero también puede
definirse mediante atributos en las clases de objetos inetOrgPerson, groupOfNames y
organization. La estructura de clases de objetos del servidor determina la lista total de atributos
requeridos y permitidos para una entrada concreta
Kerberos

Varios mecanismos han sido desarrollados con el propósito de evitar los posibles ataques a los
que se expone la información al viajar en una red abierta (por ej. ser capturada, lo cuál es
inaceptable cuando se trata de información sensitiva o en el caso de información de
autenticación) pero segmentar la red y el uso de passwords de una vez obstruyen el paso no solo
a los usuarios no autorizados sino también a los usuarios legítimos. KERBEROS es un servicio de
autenticación desarrollado por el MIT a mediados de los ’80, fue usado por mas de 5 años en
varias organizaciones de gobierno, educación y comerciales para autenticar el acceso de los
usuarios a los recursos dentro de los confines de la organización. Sin embargo el problema de
autenticación entre organizaciones en un área de red grande, tal como Esnet llevó a que se siga
trabajando. Hoy la versión V5 es considerada el estándar- desarrollada en 1989-. El nombre
KERBEROS proviene del mitológico perro de tres cabezas guardián de la entrada del infierno; el
sistema de seguridad Kerberos sería el guardián de las transmisiones electrónicas que viajan a
través de Internet, autenticando tanto a usuarios como servidores con el uso de claves y
encriptado. Es decir, que hace que la autenticación sea mas confiable, ya no basta que un usuario
“diga” quién es para creerle (Authentication by assertion).
Por ejemplo, un usuario que hace un rlogin, no necesitaría reingresar su password para loguearse
en la nueva máquina, ya que ésta confiaría en su identidad por estar logueado en una máquina
que ya lo ha verificado, pero “otro” podría estar haciéndose pasar por el verdadero usuario.
Hacer que el usuario reingrese su password cada vez que necesita un servicio tiene otros
inconvenientes: por un lado lleva tiempo al usuario, además es inseguro cuando el servicio está
en una máquina remota. KERBEROS evita tener que divulgar esta información privada, se basa
en el modelo de distribución de claves de Needhan y Schroeder. Otras características de
KERBEROS son el uso de timestamps, el ticket-granting service que permite hacer la autenticación
sin tener que reingresar el pasword cada vez., y otros procedimientos de cross-realm
authentication.
Con el uso de claves se encripta un mensaje (texto plano), y se obtiene el texto cifrado, cualquiera
que lo vea pensará que es basura ya que no podrá entenderlo. Solo con una rutina de
desencriptación sobre el texto cifrado y usando una clave para ello, se obtendrá el texto plano
nuevamente. En KERBEROS ambas claves son la misma, similar a la encriptación tradicional; en
cambio en la criptografía de clave pública hay dos claves, una usada durante la encriptación y la
otra en el proceso inverso, pero no hay forma de obtener una a partir de la otra.
El protocolo KERBEROS consiste de varios sub-protocolos (o exchanges). Hay dos métodos por
los cuales un cliente puede pedir su credencial a los servidores KERBEROS. En el primero el cliente
manda en texto plano una solicitud por un ticket para un servidor dado al authentication
server(AS). La respuesta vuelve encriptada con la clave del usuario. Usualmente esta solicitud es
por el ticket-granting ticket (TGT) que luego podrá usarse con el ticket-granting server(TGS). En
el segundo caso el cliente manda un request al TGS igual que si estuviera tratando de conectar
un servidor de aplicación cualquiera que requiere credenciales. La respuesta va encriptada con
la clave de sesión que va en el TGT. Una vez obtenidas las credenciales pueden usarse para
verificar la identidad del principal en una transacción, para asegurar la integridad de los mensajes
intercambiados en ellas o para preservar la privacidad de los mensajes. La aplicación verá que
tipo de protección necesita. Para verificar la identidad del principal en una transacción, el cliente
manda el ticket al server. Pero para evitar que el ticket sea captado y vuelto a usar por otro, es
necesaria información adicional para probar que el mensaje fue enviado por el principal para el
cuál el ticket fue creado. Esta información es el autenticador que incluye un timestamp y va
encriptado con la clave de sesión. Con el timestamp se asegura que el mensaje fue generado
recientemente y no está siendo reutilizado. Como la clave de sesión solo la conocen el servidor y
el principal que hizo el requerimiento, se garantiza la identidad del cliente. La integridad de los
mensajes intercambiados entre el cliente y servidor también puede ser garantizada usando la
clave de sesión. En los mensajes iría un checksum (encriptado con la clave de sesión) que
permitiría detectar alteraciones. Se podría lograr privacidad e integridad encriptando los datos
con la clave de sesión.
Estos intercambios mencionados antes, requieren un acceso de solo lectura a la base de datos
de KERBEROS. Sin embargo algunas veces es necesario cambiar alguna clave o agregar otra en
caso por ej. de un nuevo usuario. Esto se hace usando un protocolo entre un cliente y un tercer
servidor KERBEROS: el Servidor de Administración de Kerberos (KAS).
Funcionamiento de Kerberos

KERBEROS se parece a un carnet de conductor, reúne una cantidad de información, algunos datos
serán únicos para cada uno, puede haber también alguna restricción (en el ejemplo edad mayor
que 21) y un lapso de vida o de validez. Este método de autenticación será usado cada vez que
un usuario de una red, solicite un servicio de red y éste necesite verificar la identidad del cliente.
El usuario recibe desde el authentication server un ticket (análogo a la licencia de conducir) que
servirá para que el verifier compruebe su identidad. El ticket debe llevar el password del usuario
para identificarlo unívocamente.
Un atacante que capte el ticket no debe poder obtener información sobre el usuario que luego
le permita enmascararse. Kerberos lo evita usando encriptado. Agrega también el uso de
timestamps, y el ticket-granting service para soportar subsecuentes autenticaciones de un
usuario sin que tenga que reingresar su password. Kerberos hace algunas Asunciones sobre el
medio en el que puede funcionar apropiadamente:
∗ Los ataques que producen la denegación de servicios no son tratados por Kerberos. Un intruso
podría afectar la participación de una aplicación en el proceso de autenticación.
∗ Las claves deben ser mantenidas en secreto, tanto de los usuarios como de los servidores, para
que un atacante no logre enmascararse.
∗ Los password no son malos, así no se considera el problema de que sean adivinados.
∗ Cada host debe tener un reloj cercanamente sincronizado con los de los otros host, para poder
distinguir el reenvío de los mensajes.
Verificar que un usuario es quién dice ser, es ver que conoce el password (que a la vez es la clave
de encriptación) que solo él puede saber y el authentication server (AS). El AS tiene
registrados a todos los usuarios; de cada uno guarda una clave que obtiene desde su
password. Además cada application server comparte una clave con el AS: server key.
Kerberos se basa en el método de encriptación DES, los datos son desencriptados con la
misma clave con la que se los encriptó (si no se conoce la clave o los datos fueron
alterados no se logra desencriptar: integridad y confiabilidad).
En rasgos generales podemos describir los pasos que lleva a cabo el método de autenticación:
1. El usuario manda un mensaje al AS diciendo qué usuario es y cuál es el servicio que quiere.
2. El AS recibe el mensaje y crea una clave, que será compartida entre cliente y servidor: session
key .
3. El AS pone una copia de la session key en un mensaje, junto con el nombre del servidor y un
tiempo de expiración fuera del cuál la session key no será valida, y encripta todo con la
clave del usuario (podemos verlo como una caja: C1, que cierra con una llave).
4. Toma una segunda copia de la session key mas el nombre del usuario, y encripta con la clave
del servidor (C2 cerrada con otra llave).
5. Envía las dos cajas al usuario.
6. Con su clave el usuario puede abrir la C1 donde lee el nombre del servidor.
7. La caja C2 no la puede abrir, así crea una tercera caja donde pone la hora actual y encripta con
la session key que obtuvo al abrir la C1. Envía las cajas 2 y 3 al server.
8. El server recibe las cajas, con su clave puede abrir la 2 y leer el nombre del usuario, ahora con
la session key abre la tercera y ve la hora que allí se indica. De esta forma ha comprobado
la identidad del usuario.
La hora que lleva C3 sirve por si mas tarde un atacante intenta usar una copia de C2, ya no será
valida.

En KERBEROS la caja 2 es el “ticket” y la 3 el “authenticator”: éste contiene otra información

como un checksum, tiempo actual y una clave de encriptación opcional (que serviría para los
sucesivos diálogos entre el cliente y el servidor).
Gráficamente el intercambio de mensajes:

En algunas aplicaciones el cliente necesita autenticar también al server, así éste crea el
application response en el que incluye información (como el tiempo que venía en el
auntheticator), y lo envía todo encriptado con la session key. El cliente necesita un ticket y
session key por cada servicio con el que se quiera comunicar, y lo obtiene a través de una solicitud
al AS, para luego mandar su request al verifier. Tenemos así el protocolo básico de autenticación:
authentication request and response y application request and response. Vemos que cada vez
que el usuario quiera contactar un nuevo server debe enviar un request al AS, presentando así,
cada vez, su password; lo que amenaza su seguridad, ya que puede ser robado. Aunque el ticket
y la clave asociada tienen un tiempo de expiración corto, el password del usuario podría ser usado
para obtener nuevos tickets y lograr así el enmascaramiento. Kerberos soluciona el problema
incorporando otro elemento, el ticket granting server (TGS). Cuando el usuario quiera obtener
un servicio, primero debe autenticarse ante el TGS. Se pide un ticket para el TGS, igual que se
hace para cualquier servicio, obteniéndose el ticket granting ticket (TGT). Una vez hecho esto,
cada vez que el usuario quiera pedir un servicio, le pide un ticket al TGS, no al AS: la respuesta
ahora no va encriptada con la clave del usuario sino con la session key que el AS mandó para usar
con el TGS. Así se evita que el usuario esté reingresando su password cada vez y que pueda ser
robado. Además el TGT es válido por un tiempo corto (no así el password).

En la figura se ve el protocolo completo, los mensajes 1 y 2 solo ocurren cuando el usuario se

loguea con el sistema, el 3 y 4 cada vez que se deba autenticar a un verifier. Cross Realm
Authentication
Cuando la red crece mucho, el AS / TGS pueden volverse un cuello de botella en el proceso de
autenticación . Es decir que se ve afectada la escalabilidad, uno de los principales objetivos de los
sistemas distribuidos. Además, cuando un sistema sobrepasa los límites organizacionales, no es
apropiado tener a todos los usuarios registrados en el mismo servidor de autenticación. El
protocolo KERBEROS fue diseñado para operar aún entre límites organizacionales. Un cliente
dentro de una organización puede ser autenticado ante un servidor en otra organización. Cada
organización con su propio servidor KERBEROS establece su “Realm”. El nombre del realm al que
pertenece un cliente es parte de su propio nombre y puede ser usado por el servidor para decidir
brindar el servicio o no. Entonces la alternativa es dividir la red, cada uno con su AS y TGS
responsables de una parte de los usuarios y servers. A un subconjunto de éstos lo llamamos
Realm. Estableciendo claves “inter-realm”, los administradores de dos realms pueden permitir
que los clientes autenticados en uno de ellos puedan usar su autenticación en el realm remoto.
El intercambio de claves inter-realm requiere registrar el ticket-granting service de cada realm en
el otro. Así un cliente es capaz de obtener un TGT para el ticket-granting service remoto(RTGS)
desde su realm local. Cuando el ticket-granting ticket es usado, el ticket-granting service remoto
usa la clave inter-realm para desencriptar el TGT y autenticar al usuario, los ticket para los
servicios que él provea dirán que el cliente pertenece a otro realm. Ahora a nuestro protocolo
de comunicación se agrega un nuevo intercambio de mensajes. Primero el usuario contacta al AS
para acceder al TGS. Luego contacta al TGS para acceder al RTGS, y finalmente se contacta con
éste para llegar al service. En la versión 4 de KERBEROS era necesario que cada server se registre
con cada realm con el que necesite Cross realm authentication, lo que hace que el número de
interconexiones crezca exponencialmente (dos realm se podían comunicar si compartían un clave
inter-realm, o si entre ambos existía un realm intermedio). En la versión 5 en cambio existe un
jerarquía entre los realms, cada uno comparte una clave con sus hijos y padre; por ello, para
contactar un service de otro realm puede ser necesario atravesar varios realms intermedios. Hay
también mecanismos que permiten acortar el camino en el proceso de autenticación para
mejorar la performance. Cada verifier hace la validación del ticket analizando el camino de realms
que se ha atravesado (ya que se van registrando en el ticket)

Los tres pasos de KERBEROS:

1. Intercambio de mensajes para la autenticación: Esta comunicación entre el cliente y el
servidor de autenticación de Kerberos comienza cuando el cliente solicita una credencial
de autenticación. La clave del cliente es usada para la encriptación y desencriptación.
Generalmente este paso se da al comienzo de una sesión para obtener la credencial para
acceder al ticket-granting service y así a través de él obtener los tickets que permitan usar
otros servicios sin tener que volver a ingresar el password del usuario. También sirve para
obtener credenciales que sirvan para acceder a servicios que no requieran al
ticketgranting service como intermediario (por ej. el password-changing service). En el
request el cliente manda en texto plano su identidad, la respuesta (en la que va el ticket
y la clave de sesión) está encriptada con la clave del usuario. Otra información que va en
el mensaje de vuelta sirve para detectar los reúsos. En verdad el servidor de autenticación
no sabe si el cliente que hizo el request se corresponde con el nombre de usuario dado,
pero no le afecta ya que si no es, no le va a servir la respuesta porque no conocerá la clave
para desencriptarlo.
2. Intercambio de mensajes con el Ticket-Granting Service (TGS): Se llega a esta etapa cuando
un cliente quiere obtener un ticket para algún servicio y ya posee el ticketgranting ticket.
El intercambio de mensajes es similar al anterior, solo que ahora no se usa como clave de
encriptación el password del cliente sino la clave de sesión que se ha obtenido junto con
el ticket-granting ticket. En el request va información de autenticación, que en este caso
es el ticket. La respuesta va encriptada con la clave de sesión para este servicio y llevará
la credencial solicitada. Antes de enviar su request el cliente debe ver en que realm el
servidor está registrado. Si el cliente no posee un ticket-granting ticket apropiado para el
realm debe primero obtener uno, así un ticket de estos es requerido al realm destino
 desde el realm local (se puede tener que atravesar varios realms intermedios hasta
obtener finalmente el TGT deseado). Una vez conseguido puede solicitar el ticket para el
servicio que quiera. Al recibir la solicitud el ticket-granting service hace algunos chequeos
mas, por un lado debe ver cuál es el servicio solicitado para determinar la clave con que
debe desencriptar. En general se trata del ticket-granting service por lo que usa la clave
del TGS, pero si el mensaje es remoto debe usar una clave inter-realm. Una vez
desencriptado el ticket obtiene la clave de sesión con la que desencripta el autenticador
y comprueba la identidad del usuario. En la respuesta envía el ticket para el servicio
solicitado encriptado con la clave para éste. Si el request es para un ticket-granting ticket
para un realm remoto, y no se comparte una clave con él, se elige el realm mas “cercano”
con el que se comparte una clave y se lo usa.
3. Comunicación cliente-servidor : Este intercambio de mensajes es usado por las aplicaciones
de red para autenticar a los clientes frente a los servidores y viceversa. El cliente para esto
ya debe haber obtenido el ticket desde el AS y el ticket para el servicio desde el TGS. La
información que va en el request es el ticket, un autenticador y alguna información extra.
El autenticador servirá para que otros no puedan reutilizar tickets haciéndose pasar por
el cliente legítimo que lo obtuvo (ya que solo éste puede conocer la clave de sesión). El
cliente puede reusar los tickets hasta su expiración, pero creará cada vez un autenticador
(lleva la hora, un número de secuencia inicial que se elige aleatoriamente, etc.) todo
encriptado con la clave de sesión. El servidor desencripta el ticket con su clave (debe ver
cuál usar por el caso de que la solicitud provenga de un realm remoto). Ahora que ha
obtenido la clave de sesión puede desencriptar el autenticador y comprobar la identidad
del usuario (comparando el nombre del cliente y su realm), controla también la hora.
En todos los mensajes request desde un cliente a cualquiera de estos servidores se pueden setear
ciertas banderas para solicitar ciertas características de los tickets, por ej. una bandera que
indique que un ticket es renovable, etc.

Aplicaciones Kerberizadas
Las aplicaciones cliente/servidor deben ser modificadas para soportar el uso de Kerberos para la
autenticación. Las aplicaciones deben generar y enviar Kerberos application request al server de
aplicación, y éste debe verificar la información de autenticación. En versiones recientes de
Kerberos, existe la Generic Security Application Programmer Interface (GSSAPI). GSSAPI provee
una interface de programación estándar independiente del mecanismo de autenticación. Esto
permite al programador de aplicación diseñar una aplicación y protocolo de aplicación que puede
usar tecnologías de autenticación diferentes (incluso Kerberos).
Las aplicaciones deben :
1. Obtener la identidad del usuario.
2. Obtener la credencial para el usuario.
3. Verificar si existe un ticket para un servicio dado.
4. Si no está presente usar el TGT y la clave de sesión para pedir uno.

Conclusión
La autenticación es una parte crítica de los Sistemas de Computadoras, donde es necesario
conocer la identidad de un principale para decidir responder a una operación o no. Los métodos
de autenticación tradicionales no son útiles en redes de computadoras, ya que los atacantes
pueden estar monitoreando el tráfico de la red e interceptar passwords, para luego
enmascararse como un usuario legítimo. Kerberos es un sistema de autenticación especialmente
diseñado pensado en éstos ambientes. Inicialmente fue desarrollada la versión 4 del protocolo,
luego a través del uso y la detección de inconvenientes y nuevas necesidades se evolucionó a la
actual versión 5 .
La V5 a la vez abarca cuestiones para seguir siendo compatible con aplicaciones que usan la
versión anterior. Además Kerberos es totalmente transparente para el usuario a no ser que la
autenticación falle. Para las aplicaciones también es muy flexible ya que según las necesidades
se pueden solicitar características especiales en los tickets. La V5 seguirá evolucionando ya que
se tienen en mentes nuevos objetivos a alcanzar en los que se está trabajando, y todavía quedan
cuestiones que resolver y mejorar. A pesar de esto los investigadores indican que Kerberos es
una tecnología capaz de permitir a los usuarios compartir recursos e información sin
comprometer la integridad de sus sistemas y datos.
Como se ve en el diálogo de 4 escenas, Kerberos fue evolucionando lentamente a medida que
se descubrían problemas y se inventaban soluciones a ellas, a la vez surgían nuevas cuestiones
que resolver llevando a reformular, corregir y mejorar el diseño del protocolo. Hoy se ha llegado
a la V5, que es un ingenioso método que logra a través del intercambio de mensajes y haciendo
uso de la encriptación, autenticar de manera segura tanto a usuarios como a servidores. Aún
quedar puntos por tratar y mejorar, y mas aún aparecen a medida que se siga usando y aplicando
Kerberos. El futuro para este protocolo de autenticación parece ser una constante evolución,
pero indudablemente se puede decir que será de mucho uso mas aún a medida que siga
adaptándose a las necesidades y requerimientos de los usuarios.

Ambos sistemas operativos son buenos y estables a la hora de crear el servidor de dominio, la
principal diferencia es la forma de la creación del mismo, en Windows se hace todo de forma
gráfica y en Linux con código.
La decisión sobre en que sistema operativo se instalara el servidor de dominio depende del gusto
del administrador del servidor y de si posee o no la capacidad económica para adquirir una
licencia de Windows server o si desea trabajar sobre un sistema operativo free como lo es
Ubuntu.
La herramienta samba de unix, es esencial para compartir documento, impresoras etc. Utiliza
para ello un protocolo conocido como SMB/CIFS compatible con sistemas operativos UNIX o
Linux, como Ubuntu, pero además con sistemas Windows (7, vista, XP, NT, 98), OS/2 o incluso
DOS.