proyecto clave unica: ibero puebla (ldap). algoritmo global sybase: 1.revisa si existe cambio de...
TRANSCRIPT
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.
