Servicios LDAP UNAL (página 2)

OpenLDAP tiene cuatro componentes principales:

slapd – demonio LDAP
autónomo.

slurpd – demonio de replicación de actualizaciones LDAP
autónomo.

Rutinas de biblioteca de
soporte del protocolo
LDAP.

Utilidades, herramientas y
clientes.

Red Hat Directory Server

Directory Server es un servidor basado
en LDAP que centraliza configuración de aplicaciones,
perfiles de usuarios, información de grupos, políticas
así como información de control de acceso
dentro de un sistema operativo
independiente de la plataforma.

Forma un repositorio central para la infraestructura de manejo
de identidad,
Red Hat Directory
Server simplifica el manejo de usuarios, eliminando la
redundancia de datos y
automatizando su mantenimiento."[1]

Las ventajas de los
directorios LDAP

Tal vez la mayor ventaja de LDAP es que tu empresa puede
accedes al directorio LDAP desde casi cualquier plataforma de
computación, desde cualquier del numero
creciente de aplicaciones fácilmente disponibles para
LDAP. Es también fácil personalizar tus
aplicaciones internas de empresa para añadirles soporte
LDAP.

El protocolo LDAP es utilizable por distintas plataformas y
basado en estándares, de ese modo las aplicaciones no
necesitan preocuparse por el tipo de servidor en que se hospeda
el directorio. De hecho, LDAP esta encontrando mucha más
amplia aceptación a causa de ese estatus como
estándar de Internet. Los vendedores
están más deseosos de codificar en sus productos
integración con LDAP por que no tienen que
preocuparse de lo que hay al otro lado. Un servidor LDAP puede
ser cualquiera de un numero de los servidores de
directorio LDAP de código
abierto o comercial ( o incluso un servidor DBMS con una interfaz
LDAP), puesto que interactuar con cualquier servidor LDAP
verdadero acarrea el mismo protocolo, paquete de conexión
cliente y
comandos de
consulta. Por contraste, los vendedores que intentan integrar
directamente con un DBMS habitualmente deben personalizar sus
productos para trabajar con cada servidor de base de datos de
cada vendedor individualmente.

A diferencia de las bases de datos
relacionales, no tienes que pagar por cada conexión de
software cliente
o por licencia.

La mayoría de los servidores LDAP son simples de
instalar, fácilmente mantenibles y fácilmente
optimizables.

Los servidores LDAP pueden replicar tanto algunos de sus datos
como todos a través de métodos de
envío o recepción, lo que permite enviar datos a
oficinas remotas, incrementar tu seguridad y
demás. La tecnología de
replicación está incorporada y es fácil de
configurar. Por contraste, muchos de los vendedores de DBMS
cobran un extra por esta característica, y es bastante
más difícil de gestionar.

LDAP permite delegar con seguridad la lectura y
modificación basada en autorizaciones según tus
necesidades utilizando ACIs (colectivamente, una ACL, o Lista de
Control de Acceso por sus siglas en inglés). Por ejemplo, tu grupo de
facilidades puede dar acceso a cambiar la localización de
los empleados, su cubículo, o número de oficina, pero no
se permite que se modifiquen entradas de cualquier otro campo.
Las ACIs pueden controlar el acceso dependiendo de quien
está solicitando los datos, que datos están siendo
solicitados, dónde están los datos almacenados, y
otros aspectos del registro que
está siendo modificado. Todo esto hecho directamente a
través del directorio LDAP, así que no necesitas
preocuparte de hacer comprobaciones de seguridad en el nivel de
aplicación de usuario.

LDAP es particularmente utilizable para almacenar
información que desees leer desde muchas localizaciones,
pero que no sea actualizada frecuentemente. Por ejemplo, tu
empresa podría almacenar todos los datos siguientes en un
directorio LDAP:

• La listín de teléfonos de empleados de la
  empresa y el esquema organizacional
• Información de contacto de clientes externos
• Información de la infraestructura de servicios,
  incluyendo mapas NIS,
  alias de email, y demás
• Información de configuración para paquetes de
  software distribuidos
• Certificados públicos y claves de seguridad

La mayoría de los servidores LDAP están
fuertemente optimizados para operaciones de
lectura
intensivas. A causa de esto, típicamente uno puede ver un
orden de magnitud diferente cuando lee datos de un directorio
LDAP frente a la obtención de los mismos datos de una
base de datos
relacional optimizada para OLTP. Sin embargo, a causa de esta
optimización a la mayoría de los directorios LDAP
no les viene bien el almacenamiento de
datos donde los cambios son frecuentes. Por ejemplo, un servidor
de directorio LDAP es bueno para almacenar el directorio de
teléfonos internos de la empresa, pero
ni se te ocurra pensar en utilizarlo como repositorio de base de
datos para un sitio de comercio
electrónico de alto volumen.

Si las respuestas a cada una de las siguientes preguntas es
Sí, entonces, almacenar tus datos en LDAP es una buena
idea.

• ¿Te gustaría que tus datos estén
  disponibles a través de varias plataformas?
• ¿Necesitas acceso a estos datos desde un
  número de ordenadores o aplicaciones?
• ¿Los registros
  individuales que estás almacenado cambian unas pocas
  veces al día o menos, como media?
• ¿Tiene sentido almacenar este tipo de datos en una
  base de datos plana en lugar de una base de datos relacional?
  Esto es, ¿puede almacenar todos los datos, para un
  ítem dado, efectivamente en un solo registro?

Esta cuestión final a menudo hace que la gente tome una
pausa, porque es muy común acceder a un registro llano
para obtener datos que son relacionales en su naturaleza.
Por ejemplo, un registro para un empleado de una empresa puede
incluir el nombre de login del gerente de ese
empleado. Es bueno emplear LDAP para almacenar este tipo de
información. La prueba del algodón: si puedes imaginarte almacenado
todos tus datos en un Rodolex electrónico, entonces puedes
almacenar tus datos fácilmente en un directorio LDAP.

LA ESTRUCTURA DE
UN ÁRBOL DE DIRECTORIO LDAP

Los servidores de directorio LDAP almacenan sus datos
jerárquicamente. Si has visto las representaciones de
árboles
DNS
descendientes o directorios de ficheros UNIX, una
estructura de directorio LDAP te será un terreno familiar.
Como con los nombres de host en DNS, un registro Nombre
Distinguido (Distinguished Name en ingles, DN en corto) de un
directorio LDAP se lee desde su entrada individual,
recursivamente a través del árbol, hasta el nivel
más alto. Más sobre este punto después.

¿Por qué seccionarlas dentro de una
jerarquía? Hay un número de razones. He aquí
algunos escenarios posibles:

• Puedes querer enviar todos tus contactos de clientes con
  base en US a un servidor LDAP en la oficina de Seattle (que
  esta dedicada a ventas),
  mientras que probablemente no necesites enviar allí la
  información de gestión de los activos de
  la empresa.
• Puedes querer conceder permisos a un grupo de individuos
  basado en la estructura del directorio. En el ejemplo listado
  abajo, el equipo de gestión de activos de la empresa
  puede necesitar acceso completo a la sección
  activos-gest, pero no a otras áreas.
• Combinado con replicación, puedes hacer a la medida
  la expansión de tu estructura de directorio para
  minimizar la utilización de ancho de banda de tu WAN. Tu
  oficina en Seattle puede necesitar actualizaciones al minuto de
  los contactos de ventas en US, pero solo actualizaciones cada
  hora para la información de ventas Europeas.

Yendo a la raíz del asunto:

Tu DN base y tú El nivel superior de un
directorio LDAP es la base, conocido como el "DN base". Un DN
base, generalmente, toma una de las tres formas listadas
aquí. Asumamos que trabajo en una
empresa de comercio electrónico de US llamada FooBar,
Inc., la cual está en Internet en foobar.com.

o="FooBar, Inc.", c=US

(DN base en formato  X.500)

En este ejemplo, o=FooBar,inc. se refiere a la
organización, que en este contexto debería ser
tratada como un sinónimo del nombre de la empresa. c=US
indica que el cuartel general de la empresa está en los
US. Erase una vez en que éste fue el método de
especificar tu DN base. Los tiempos y las modas cambian, sin
embargo; estos días, la mayoría de las empresas
están (o planean estar) en Internet. Y con la globalización de Internet, utilizar un
código de país en el base DN probablemente haga las
cosas más confusas al final. Con el tiempo, el
formato X.500 ha evolucionado a otros formatos listados
más abajo.

o=foobar.com

(DN base derivado de la presencia en Internet de la
empresa)

Este formato es bastante sencillo, utilizando el nombre de
dominio de la
empresa como base. Una vez has pasado la porción o= (la
cual viene de organization= ), cualquiera en tu empresa
debería saber de dónde viene el resto. Este fue,
hasta hace poco, probablemente el más común de los
formato usados actualmente.

dc=foobar, dc=com

(DN base derivado de los componentes de dominio DNS de la
empresa)

Como el formato previo, este utiliza el nombre de dominio DNS
como su base. Pero donde el otro formato deja en nombre de
dominio intacto (y así legible para las personas), este
formato está separado en componentes de dominio:
foobar.com deviene dc=foobar, dc=com. En teoría,
esto puede ser levemente más versátil, aunque es un
poco más duro de recordar para los usuarios finales. A
modo de ilustración, consideremos foobar.com.
Cuando foobar se fusiona con gizmo.com, simplemente empiezas a
pensar en "dc=com" como el DN base. Pon los nuevos registros en
tu directorio existente bajo dc=gizmo, dc=com y listo para
seguir. (Por supuesto, esta aproximación no ayuda si
foobar.com se fusiona con wocket.edu) Este es el formato que
recomiendo para cualquier instalación nueva. Oh, si
estás planeando utilizar Active Directory, Microsoft ya
ha decidido por ti que éste es el formato que
necesitas.

Tiempo de ramificar: cómo organizar tus datos en tu
árbol de directorio

En un sistema de
ficheros UNIX, el nivel más alto es el raíz. Por
debajo de la raíz tienes muchos ficheros y directorios.
Como mencione anteriormente los directorios LDAP están
configurados en gran parte de la misma manera.

Debajo de tu base de directorio, querrás crear
contenedores que separen lógicamente tus datos. Por
razones históricas (X.500), la mayoría de los
directorios configuran estas separaciones lógicas como
entradas OU. OU vienen de "Unidades Organizacionales"
(Organizational Units, en ingles), que en X.500 eran utilizadas
para indicar la organización funcional dentro de la
empresa: ventas, finanzas,
etcétera. Actualmente las implementaciones de LDAP han
mantenido la convención del nombre ou=, pero separa las
cosas por categorías amplias como ou=gente (ou=people),
ou=grupos (ou=groups), ou=dispositivos (ou=devices), y
demás. Los niveles inferiores de OUs son utilizados a
veces para separar categorías por debajo más lejos.
Por ejemplo, un árbol de directorio LDAP (sin incluir
entradas individuales) podría parecerse a esto:

    dc=foobar, dc=com 

       
ou=customers 

           
ou=asia 

           
ou=europe 

           
ou=usa 

       
ou=employees 

        ou=rooms 

        ou=groups 

       
ou=assets-mgmt 

       
ou=nisgroups 

       
ou=recipes  
« [2]

METODOLOGÍA

Para poder realizar
la presente actividad se utilizo la metodología orientada a prototipos y se
desarrollo de
la siguiente forma:

·                    
Instalación de Windows XP
sobre el único computador
usado.

·                    
Instalación de un software de máquinas
virtuales sobre el Windows XP del
punto anterior, para el cual se eligió VMware Workstation
por haber sido usado con anterioridad en actividades
académicas.

·                    
Creación de 4 Máquinas virtuales para instalar el
servidor LDAP en Linux SuSE 10.3,
Oracle 10g en
Linux 10.3, ASE 15.2 en un Microsoft Windows 2003 Server e
Instalación de Microsoft SQL Server
sobre Microsoft Windows 2003 Server.

Open Suse 10.3 como máquina virtual.

Windows 2003 Server corriendo como
máquina virtual

Al tener 2 máquinas virtuales abiertas el sistema se
vuelve lento por lo que se trata de configurar y hacer pruebas con
una máquina al tiempo solamente, éstas son las
estadísticas y, como podemos ver, nos queda
menos del 10% de memoria ram.

Estadísticas del Sistema con 2
máquinas virtuales.

REQUERIMIENTOS
TECNOLÓGICOS

·        Computador
Clon

o        Borrad MSI
k9vgm

o        Procesador AMD
4000+

o        Memoria 1GB

o        DD 160GB

o        Conexión
Internet 1mb Telecom

·         Conexión
al VPN de la
Universidad
para acceder al servidor ldap

Resumen de la Configuración del equipo
usado.

ACCESO A VPN UNAL

Para acceder al servicio vpn
de la Universidad Nacional ingresamos a https://vpn.unal.edu.co/
para lo cual nos pedirá nombre de usuario y
contraseña que siempre usamos dentro de la
Universidad.

Pantallazo de inicio autenticación VPN
UNAL

Luego nos dará la indicación del cuadro de
diálogo
que nos aparecerá mostrándonos el certificado de
encriptación, para lo cual nos sugiere que demos en
aceptar o SI

Luego de aceptar el cuadro de diálogo nos volvera a
aparecer el certificado y nuevamente confirmación para lo
que en ambos casos debemos aceptar

Este es el cuadro de diálogo que nos da
los datos del certificado que vamos a aceptar para conectarnos al
vpn

Después de esto esperamos unos segundos y estaremos
conectados

Si damos doble clic sobre esta llave podemos ver la
configuración de la conexión que hemos
realizado

ACCEDIENDO AL
ÁRBOL DE DIRECTORIO ACTIVO DE LA UNIVERSIDAD
NACIONAL

Ingresamos a http//www.dnic.unal.edu.co/clave lo cual nos
redireccionará a https://metadirectorio.unal.edu.co/

En este momento nos solicita nombre de usuario y
contraseña de nuestra cuenta de directorio activo de la
Universidad.

Como podemos observar, el mismo sistema que nos permite
cambiar nuestra contraseña nos da una idea del
árbol en que se encuentran los usuarios ldap.

PRUEBAS DE ACCESO Y

DOCUMENTACIÓN SOBRE EL ÁRBOL
DE DIRECTORIO ACTIVO

Con la herramienta Softerra Ldap Administrador 3.5
intentamos ingresar con la siguiente configuración

Host: undirectorio.unal.edu.co puerto:389 BASE DN=unal.edu.co
y en las credenciales ubicamos la información que
obtuvimos en la pagina anterior dando nuestros datos de
conexión.

Al hacer una búsqueda de la cuenta que hemos usado nos
damos cuenta de que nos muestra toda la
información de la cuenta, como así:

CONFIGURACIÓN ORACLE
10G SOBRE LINUX

TAREAS REALIZADAS PARA LA
ENTREGA 1

Se tiene la información de acceso al ldap UNAL desde
afuera con vpn.

Se instalo las 3 máquinas virtuales con los respectivos
sistemas
operativos

En el Linux se instalo oracle 10g y postgress

En el Windows 2003 se instalo ASE 15

En el otro Windows se instalo MSSQL

Primeras pruebas de conexión a ldap con oracle, ASE y
MSSQL sin tener éxito
para ninguna de las tres.

BITÁCORA DE CONEXIÓN SYBASE –
LDAP

La versión utilizada para las pruebas fue ASE 15, sobre
un máquina virtual con Windows 2003 server.

Lo primero que hay que hacer en sybase para activar la
autenticación en ldap es usar el procedimiento
almacenado sp_configure. Se tienen 2 métodos de
autenticación al ldap y se logran mediante el
procedimiento almacenado sp_configure usando los
parámetros 'enable ldap user auth' seguido de una coma y
un número que indican el modo de acceso, así:

sp_configure 'enable ldap user auth' , 0

sp_configure 'enable ldap user auth' , 1

sp_configure 'enable ldap user auth' , 2

Tabla. Parámetros usados con
sp_configure

Lo que sigue es utilizar el procedimiento almacenado
sp_ldapadmin configurando la URL, BASEDN, USER, PASSWORD y
ACTIVATE así:

sp_ldapadmin    set_primary_url,  

               
'ldap://localhost:389/ou=People,dc=unal,dc=edu,dc=co',??sub?cn=*'

En esta instrucción lo que se hace es dar el nombre del
ldap://servidor:puerto/ubicacion_de_los_usuarios_a_ingersar??sub?campo_con_el_nombre_de_la_cuenta.

Aquí especificamos un usuario administrador y su
respectiva contraseña.

sp_ldapadmin    set_access_acct,  

               
'ldap://localhost:389/cn=Administrator,dc=unal,dc=edu,dc=co',
'secret'

sp_sp_ldapadmin   set_access_acct,  
usuario_admin , password

sp_ldapadmin    set_dn_lookup_url,  

               
'ldap://localhost:389/ou=People,dc=unal,dc=edu,dc=co',??sub?cn=*'

En esta instrucción lo que se hace es dar el nombre del
ldap://servidor:puerto/ubicacion_de_los_usuarios_a_ingersar??sub?campo_con_el_nombre_de_la_cuenta.

BITÁCORA DE AUTENTICACIÓN LDAP
– POSTGRESS

La versión utilizada para las pruebas fue
Postgress-8.3.1.18, sobre un openSuSE 11.0.

Para la autenticación de postgres hay un
archivo en

/usr/lib/pgaccess/data/pg_hba.conf

que debemos modificar y contiene la siguiente
forma:

local    
           
base_de_datos    usuario(s)
      metodo_de_autenticacion

local all postgres trust    //podemos ver que
el usuario postgres se autentica en cualquier base de datos
cuando se usa de la máquina local sin
contraseña.

(1)  local all all ldap
"ldap://localhost:389/dc=unal,dc=edu,dc=co;cn=;,ou=People,dc=unal,dc=edu,dc=co"

(2)     host all all 127.0.0.1/32 ldap
"ldap://localhost:389/dc=unal,dc=edu,dc=co;cn=;,ou=People,dc=unal,dc=edu,dc=co"

Con (1) y con (2) indicamos que todos los usuarios que se
conectente a todas las bases de datos de postgress de forma
local(1) o desde la direccion 127.0.0.01/32 (2) (puede ser via
web) deben
autenticarse por ldap, teniendo en cuenta que los usuarios deben
estar creados tanto en ldap para su autenticación como en
postgress para sus debidos permisos.

BITÁCORA DE
AUTENTICACIÓN  SQL
SERVER  – LDAP

La versión utilizada para las pruebas fue MS-SQL Server
2000 Enterprise, MS-SQL Server 2005 Express, sobre un
máquina virtual con Windows 2003 server.

Para autenticar los usuarios de sql server con ldap de la
Universidad Nacional de Colombia la
solución propuesta es autenticar en el dominio de la
Universidad la máquina servidor que contiene el servicio
de base de datos y usar el servidor de Directorio Activo que se
usa actualmente para agregar los usuarios a la base de datos,
así logramos una mayor compatibilidad entre productos
Microsoft y aprovechamos una herramienta ya instalada  y
funcionando en la Universidad.

BITÁCORA DE
AUTENTICACIÓN  ORACLE  – LDAP

Una de las características de OBI EE 10.1.3.3 / 2 es su
capacidad de influencia OID / autenticación LDAP. I was
trying this one out today and thought i would document it.
Veremos cómo configurar la autenticación OID. In
the next article we would see how to pass on group credentials to
users from OID.

1. Open the repository in Online Mode using the
   Administrator. 1. Abra el repositorio en línea
   utilizando el Modo Administrador. Go to Manage and click on
   Security. Ir a Administrar y haga clic en Seguridad. Click on
   Action-New-LDAP Server Haga clic en Acción-Nuevo-LDAP Server

2.   Enter the Oracle Internet Directory
details like hostname and the Base DN. 2. Introduzca el Oracle
Internet Directory detalles como nombre de host y la Base DN. And
test the
connection. Y prueba de la conexión.

3.   Right click on the LDAP server and click
on import. 3. Haga clic derecho en el servidor LDAP y haga clic
en la importación. You should be seeing the users
that are under OID. Usted debe ver a los usuarios que se
encuentran bajo OID.

4. Once this is done, the next step is to create an
   initialization block that would basically use the OID server
   created above and set a system session variable called USER. 4.
   Una vez hecho esto, el siguiente paso es crear un bloque de
   inicialización que básicamente utiliza el
   servidor de OID creado anteriormente y establece un sistema
   período de sesiones variable llamada USUARIO. This USER
   variable would be used during authentication. Este usuario
   variable se utiliza durante la autenticación.
5. Go to Manage->Variables to
   open up the variable manager. Ir a Administrar-> Variables
   para abrir el administrador de variables. Click on
   Action->New->Sesion->Initialization Block Haga clic en
   Acción-> Nuevo-> Sesion-> Bloque de
   inicialización

Enter any name, say OID, and click on edit data source.
Introduzca cualquier nombre, por ejemplo OID, y haga clic en
editar las fuentes de
datos. Select the OID/LDAP server that we created in the 1st 3
steps. Seleccione la OID / servidor LDAP que hemos creado en la 1
ª 3 pasos. Then click on edit target and click on new
variable. A continuación, haga clic en editar objetivo y
haga clic en nueva variable. Enter USER as the name of the
variable and click ok. Ingresar usuario como el nombre de la
variable y haga clic en Aceptar.

Edit the variable and add the uid as the LDAP variable.
Modificar la variable y añadir el uid LDAP como la
variable.

Test the initialization block as orcladmin. Prueba de la
inicialización de bloque como orcladmin.

You must see orcladmin username set for the USER variable.
Usted debe ver orcladmin nombre de usuario establecido por la
variable de usuario. If you see that then steps that you have
done so far are correct. Si logra verloe entonces  los pasos
que usted ha hecho hasta ahora son correctos. Remember to set the
Required for Authentication check box. Recuerde establecer la
casilla como requerida para la autenticación.

Check in the changes and save the repository. Compruebe en los
cambios y guardar el repositorio. Log into Answers as orcladmin.
Acceda a respuestas como orcladmin. We should be able to see all
the public dashboards. Deberíamos ser capaces de ver todos
los paneles públicos.

La versión utilizada para las pruebas fue oracle
Express 10g, sobre OpenSuSE 11.0.

Se usó lo siguiente  para comprobar la
conexión con ldap.

SET SERVEROUTPUT ON SIZE 1000000

DECLARE

  — Adjust as necessary.

  l_ldap_host    VARCHAR2(256) :=
'localhost';

  l_ldap_port    VARCHAR2(256) :=
'389';

  l_ldap_user    VARCHAR2(256) :=
'cn=Administrator,dc=unal,dc=edu,dc=co';

  l_ldap_passwd  VARCHAR2(256) := 'secret';

  l_ldap_base    VARCHAR2(256) :=
'dc=unal,dc=edu,dc=co';

  l_retval      
PLS_INTEGER;

  l_session     
DBMS_LDAP.session;

  l_attrs     
  DBMS_LDAP.string_collection;

  l_message     
DBMS_LDAP.message;

  l_entry       
DBMS_LDAP.message;

  l_attr_name    VARCHAR2(256);

  l_ber_element  DBMS_LDAP.ber_element;

  l_vals        
DBMS_LDAP.string_collection;

BEGIN

  — Choose to raise exceptions.

  DBMS_LDAP.USE_EXCEPTION := TRUE;

  — Connect to the LDAP server.

  l_session := DBMS_LDAP.init(hostname =>
l_ldap_host,

                             
portnum  => l_ldap_port);

  l_retval :=
DBMS_LDAP.simple_bind_s(ld     =>
l_session,

          
                           dn    
=> l_ldap_user,

                                     
passwd => l_ldap_passwd);

  — Get all attributes

  l_attrs(1) := '*'; — retrieve all attributes

  l_retval :=
DBMS_LDAP.search_s(ld       =>
l_session,

           
                     base    
=> l_ldap_base,

                                
scope    => DBMS_LDAP.SCOPE_SUBTREE,

                                
filter   => 'objectclass=*',

                                
attrs    => l_attrs,

                      
          attronly
=> 0,

                                
res      => l_message);

  IF DBMS_LDAP.count_entries(ld => l_session, msg
=> l_message) > 0 THEN

    — Get all the entries returned by our
search.

    l_entry := DBMS_LDAP.first_entry(ld 
=> l_session,

                                    
msg => l_message);

    << entry_loop >>

    WHILE l_entry IS NOT NULL LOOP

      — Get all the attributes for
this entry.

     
DBMS_OUTPUT.PUT_LINE('—————————————');

      l_attr_name :=
DBMS_LDAP.first_attribute(ld       
=> l_session,

                                              
ldapentry => l_entry,

                                              
ber_elem  => l_ber_element);

      << attributes_loop
>>

      WHILE l_attr_name IS NOT NULL
LOOP

        — Get all the
values for this attribute.

        l_vals :=
DBMS_LDAP.get_values
(ld        =>
l_session,

                                       
ldapentry => l_entry,

                                       
attr      => l_attr_name);

        <<
values_loop >>

        FOR i IN
l_vals.FIRST .. l_vals.LAST LOOP

         
DBMS_OUTPUT.PUT_LINE('ATTIBUTE_NAME: ' || l_attr_name || ' = ' ||
SUBSTR(l_vals(i),1,200));

        END LOOP
values_loop;

        l_attr_name :=
DBMS_LDAP.next_attribute(ld
       => l_session,

                                               
ldapentry => l_entry,

                                               
ber_elem  => l_ber_element);

      END LOOP attibutes_loop;

      l_entry :=
DBMS_LDAP.next_entry(ld  => l_session,

                                     
msg => l_entry);

    END LOOP entry_loop;

  END IF;

  — Disconnect from the LDAP server.

  l_retval := DBMS_LDAP.unbind_s(ld => l_session);

  DBMS_OUTPUT.PUT_LINE('L_RETVAL: ' || l_retval);

END;

/

BITÁCORA DE CONFIGURACIÓN DB2

Instalamos el DB2 normalmente

Ahora establecemos las variables

   Db2set db2ldap_enable=yes

   Db2set db2ldap_host =localhost

   Db2set db2ldap_basedn=dc=unal,dc=edu,dc=co

   Db2ldcfg -u
"cn=Administrador,dc=unal,dc=edu,dc=co" -w secret

Y registramos las instancias que queramos que se conecten

Db2 register db2 server in ldap as prueba protocol tcpip

CONCLUSIONES

l        Debido al gran
crecimiento de las TI se generan bastantes servicios que
requieren autenticación y tenemos que  desde un
principio ir centralizando para ir creciendo a la par.

l        La
autenticación de usuarios en sybase la hace el motor y
simplemente usa el ldap para verificar la contraseña y el
login del usuario que se encuentra ya inscrito, asi mismo se hace
con postgres caso contrario sucede con oracle y db2 que guardan
la información de roles y permisos en LDAP siendo
necesario modificar el servidor LDAP para agregar sus propios
esquemas.

l        La continuidad de
este trabajo puede evitar modificar el LDAP de la Universidad
Nacional para poder autenticar los usuarios de db2 y oracle se
puede tratar de configurar una replica del LDAP actual y agregar
los esquemas necesarios.

BIBLIOGRAFÍA

http://swik.net/OpenLDAP/del.icio.us%2Ftag%2Fopenldap

http://www.sybase.com/content/1026313/SYSD1039LDAP_WP.pdf

http://www.idevelopment.info/data/Oracle/DBA_tips/LDAP_OID_9.2.0/LDAP_8.shtml

http://www.psoug.org/reference/net_services.html

http://www.sybase.com/detail?id=1051287

• OReilly.PHP.Pocket
  Reference – 2nd Edition
• OReilly.linux_poster
• OReilly.Oracle.8i Interal Service
• Microsoft.Press.Microsoft.SQL.Server.2000.DTS.Step.by.Step.eBook-LiB
• Premier.Press.Microsoft.Windows.XP.Professional.Administrators.Guide.eBook-LiB
• Sybex.MCSA.MCSE.Windows.Server.2003.Network.Security.Administration.Study.Guide.70-299.Jul.2004.eBook-DDU

Autor:

Andres Mauricio Pardo Agudelo

Presentado a:

Ing. ISMAEL CASTAÑEDA

UNIVERSIDAD NACIONAL DE COLOMBIA

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE SISTEMAS

2008

[1]
http://es.wikipedia.org/wiki/LDAP

[2]
http://www.ldapman.org/articles/sp_intro.html