PROYECTO CLAVE UNICA: IBERO PUEBLA (LDAP)

1. PROYECTO CLAVE UNICA: IBERO PUEBLA (LDAP)

2. ALGORITMO GLOBAL Sybase: • Revisa si existe cambio de contraseña • Si Revisión = Null GO FIN • Else Revisión = True • Genera Archivo en base a estructura Predefinida Aleph V14 para Z308 tipo *.TXT • Envía FTP Server Aleph Monterrey y deposita en el siguiente subdirectorio:cd /exlibris/u50_5/cia50/files • FIN

3. ALGORITMO GLOBAL ALEPH v14: • Ejecuta shell PROCESO1.SH • Encabezado general : #!/bin/sh • Cambio de Subdirectorio: cd /exlibris/u50_5/cia50/files • Asignación de Variables Globales:FILE="z308.txt“DATE=`date +%Y-%m-%d:%R` • Inicio Ciclo if: if test -f $FILEdonde: “Si existe en el subdirectorio el archivo contenido en la variable “$FILE” • Entonces: “then” • Ejecuta proceso nativo Aleph para actualización de datos de tabla z308:csh -f $aleph_proc/p_file_06 cia50,z308.txt,z308,UPDATE,NO-FIX,Y,N,0,00 • Pausa ejecución siguiente comando: sleep 300 • Mueve archivo a subdirectorio de respaldo y agrega variable $DATE:mv $FILE /exlibris/u50_5/cia50/files/z308resp/$FILE$DATE • En caso contrario: ELSE • Salir de ejecución sin activar proceso de actualización: exit 0 • Fin: fi

4. Avantel Monterrey UIA PUEBLA Sybase Aleph 500 V14 FTTP proceso1.sh* Z308.txt #!/bin/sh cd /exlibris/u50_5/cia50/files FILE="z308.txt“ DATE=`date +%Y-%m-%d:%R` if test -f $FILE then csh -f $aleph_proc/p_file_06 cia50,z308.txt,z308,UPDATE,NO-FIX,Y,N,0,00 sleep 300 mv $FILE /exlibris/u50_5/cia50/files/z308resp/$FILE$DATE Else exit 0 fi 00153729-2 1477 00153729-2 ACN 01153729 1477 00153729-2 ACN 00146064-2 AZUL 00146064-2 ACN 01146064 AZUL 00146064-2 ACN

5. IBERO PUEBLA LDAP PROTOCOL ACTIVE DIRECTORY ALEPH V16. LDAP ("Lightweight Directory Access Protocol") implementa un Servicio de directorio Jerárquico y Distribuido para acceder depósitos de información referente a usuarios, contraseñas y otras entidades en un entorno de red, ofreciendo una amplia capacidad de filtrado sobre la información que esta siendo solicitada.

6. Para aterrizar la posición que ocupa LDAP en la arquitectura de un sistema, LDAP funciona de una manera muy similar a DNS/BIND , esto es, esta diseñado y optimizado para ofrecer lectura y búsqueda de información a una gran cantidad de requisiciones simultaneas, sin embargo, se encuentra severamente limitado en cuanto a: actualizaciones y control de transacciones en Información , algo que debe ser delegado a una base de datos , lo anterior no implica que LDAP no es capaz de actualizar y controlar transacciones , sino que no esta optimizado para esto.

7. LDAP, contrastado con DNS que mantiene resoluciones de Nodos IP a dominios, es capaz de mantener cualquier tipo de información de una manera jerárquica, observe las similitudes: En LDAP:Empresa (Todos los atributos pertenecen a "Empresa") México México Brasil Brasil Venezuela drubio garaizal santos ffontes kpiment 3ffw12eg 2emndfs e334faf tert232 4fhlzpqa (52)-(6)- (52)-(5)- (55)-(11)- (55)-(21)- (58)-(2)- 3422321 2353312 8696446 7453242 4943421 En DNS .com, .edu, .mx, etc. (Todos los dominios son .com, .edu, .mx, etc) iberopuebla.edu.mx sun.com uia.mx www.iberopuebla.edu.mx www.java.sun.com www.solaris.sun.com En LDAP se mantiene un árbol jerárquico con diversos atributos; en la ilustración anterior todos los atributos pertenecen a empresa , de aquí se subdivide por países, dentro de cada país se encuentran: usuarios, contraseñas y teléfonos. Cabe señalar que los atributos pueden ser de cualquier tipo imaginable , desde hardware (impresoras,servidores,pc) hasta fotografías o información personal como el caso anterior, todo asociado en cierto punto de la jerarquía.

8. Es posible acceder toda esta jerarquía de información aplicando filtros y accesos de seguridad; lo anterior permite a LDAP operar de una manera muy similar a un Web-Site, básicamente permitiendo acceso a información partiendo de un nombre conocido (empresa=dominio (iberopuebla.edu.mx)) pero restringiendo el acceso a ciertos atributos como contraseñas, teléfonos en base a determinados filtros como: nodos IP de acceso, país de origen, departamento, etc.. LDAP también es capaz de replicar su información a otros puntos en la Red como DNS ( servidores slaves y cache en DNS ), esto facilita la disipación de información a diversos puntos Lo anterior suena como una panacea pero tiene sus detalles, de nuevo habría que regresar a los fundamentos de DNS para notar esto. Un Navegador ("Explorer" o "Netscape") esta diseñado para realizar búsquedas directamente en un "DNS Server", basta introducir una dirección: www.iberopuebla.edu.mx y el navegador intentará buscar en un "DNS Server", ahora bien, supongamos que desea implementar el caso mencionado anteriormente: una sola cuenta y contraseña de acceso para verificar usuarios de diversos países y/o ciudades. ¿Como y quien verifica esta contraseña ? Para esto se requiere un cliente LDAP que buscará en un "LDAP Server" la información.

9. Cliente LDAP ALEPH 500 V16

10. CONTENIDO ORIGINAL LDAP.CONF [general] host_name = metalib02 port = 389 dn_suffix = uid=USERNAME, ou=staff, o=CityUniv, dc=com dn_suffix = uid=USERNAME, ou=students, o=CityUniv, dc=com [xml setting] xml_root_node = bor_authenticate [attributes mapping] cn = z303_user_name mail = z304_email_address

11. Configuracion ldap.confIbero Puebla [general] host_name = 000.000.000.000 port = 389 init_bind_dn = cn=ad_access,ou=Admin,ou=estudiantes,dc=uia,dc=edu,dc=mx init_bind_password = XXXXXX search_base = ou=estudiantes,dc=uia,dc=edu,dc=mx search_filter = (sAMAccountName=USERNAME) [xml settings] xml_root_node= bor_authenticate [attributes mapping] displayName = z303_name mail = z304_email_address

12. ORIGINAL [general] host_name = metalib02 port = 389 dn_suffix = uid=USERNAME, ou=staff, o=CityUniv, dc=com dn_suffix = uid=USERNAME, ou=students, o=CityUniv,dc=com [xml setting] xml_root_node = bor_authenticate [attributes mapping] cn = z303_user_name mail = z304_email_address IBERO [general] host_name = 10.0.0.50 port = 389 init_bind_dn = cn=ad_access,ou=Admin,ou=estudiantes,dc=uia,dc=edu,dc=mx init_bind_password = xxxxxx search_base = ou=estudiantes,dc=uia,dc=edu,dc=mx search_filter = (sAMAccountName=USERNAME) [xml setting] xml_root_node = bor_authenticate [attributes mapping] displayName = z303_name mail = z304_email_address

13. El usuario solo tenga una clave única. La modificación de su clave pueda ser cambiada cuando lo necesite sin involucrar tantos procesos Es en tiempo real Involucra menos procesos mejorando el espacio en memoria del Server Genera menos trafico dentro de la misma red. Da un mejor control y restringe el uso indebido de esta utilidad. Esto nos permite que:

14. POR SU ATENCION GRACIAS marcoantonio.romero@iberopuebla.edu.mx