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