proyecto clave unica: ibero puebla (ldap). algoritmo global sybase: 1.revisa si existe cambio de...

PROYECTO CLAVE UNICA:

IBERO PUEBLA

(LDAP)

ALGORITMO GLOBAL Sybase:

1. Revisa si existe cambio de contraseña

2. Si Revisión = Null GO FIN

3. Else Revisión = True

4. Genera Archivo en base a estructura Predefinida Aleph V14 para Z308 tipo *.TXT

5. Envía FTP Server Aleph Monterrey y deposita en el siguiente subdirectorio:

cd /exlibris/u50_5/cia50/files

6. FIN

ALGORITMO GLOBAL ALEPH v14:

1. Ejecuta shell PROCESO1.SH

1. Encabezado general : #!/bin/sh

2. Cambio de Subdirectorio: cd /exlibris/u50_5/cia50/files

3. Asignación de Variables Globales:FILE="z308.txt“DATE=`date +%Y-%m-%d:%R`

4. Inicio Ciclo if: if test -f $FILE donde: “Si existe en el subdirectorio el archivo contenido en la variable “$FILE”

5. Entonces: “then”

6. 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

7. Pausa ejecución siguiente comando: sleep 300

8. Mueve archivo a subdirectorio de respaldo y agrega variable $DATE:

mv $FILE /exlibris/u50_5/cia50/files/z308resp/$FILE$DATE

9. En caso contrario: ELSE

10. Salir de ejecución sin activar proceso de actualización: exit 0

11. Fin: fi

Sybase Aleph 500 V14

#!/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

UIA PUEBLAAvantel

Monterrey

FTTP

00153729-2 1477 00153729-2 ACN

01153729 1477 00153729-2 ACN

00146064-2 AZUL 00146064-2 ACN

01146064 AZUL 00146064-2 ACN

Z308.txtproceso1.sh*

IBERO PUEBLA

ACTIVE DIRECTORY

ALEPH V16.

LDAP PROTOCOL

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.

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.

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 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: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 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.

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.

Cliente LDAP

ALEPH 500 V16

[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

CONTENIDO ORIGINAL

LDAP.CONF

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

ORIGINAL

IBERO

[general]

[general]

host_name = metalib02

host_name = 10.0.0.50

port = 389

port = 389

dn_suffix = uid=USERNAME, ou=staff, o=CityUniv, dc=comdn_suffix = uid=USERNAME, ou=students, o=CityUniv,dc=com

init_bind_dn = cn=ad_access,ou=Admin,ou=estudiantes,dc=uia,dc=edu,dc=mx

[xml setting]

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

xml_root_node = bor_authenticate

[attributes mapping]

[attributes mapping]

cn = z303_user_namemail = z304_email_address

displayName = z303_namemail = z304_email_address

Esto nos permite que:• 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.

POR SU ATENCION

GRACIAS

marcoantonio.romero@iberopuebla.edu.mx