How to tickets - Protocolos de Comunicación

UNIVERSIDAD DE EL SALVADOR
FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE
DEPARTAMENTO DE INGENIERIAY ARQUITECTURA
PROTOCOLOS DE COMUNICACIÓN
ASESOR DE PROYECTO:
ING. JUAN CARLOS PEÑA
TEMA:
SISTEMA DETICKET'S BASADOS EN CORREO ELECTRÓNICO
SANTA ANA 21 DE JUNIO DE 2013
ACERCA DE

PROYECTO REALIZADO POR:
- CHÁVEZVIGIL, LUIS JOSUÉ
- CRUZ MARTÍNEZ, ERICK STANLEY
- CISNEROS CENTE, ROLANDO ALEXIS
- IBARRA BONILLA, LUIS ARMANDO
- ORELLANAAGUIRRE, JOSUÉ DANIEL
CONTACTOS:
- cobaincv.21@gmail.com
- escm.1990@gmail.com
- roland.centino@gmail.com
- lichitoah@gmail.com
- jdorellana207@gmail.com

Configuración del Servicio DNS (Bind9)
Para empezar la configuración del DNS hay que instalar el paquete bind9, bind9 es una distribución
libre y mayormente se usa para mover DNS.
Hay que iniciar una terminal en modo root e instalar el paquete bind9:
Se debe tener conexión a Internet para instalar el paquete. En este caso, ya estaba instalado y es la
razón del por que aparece que bind9 ya esta instalado en su versión mas reciente.
Ya que estén instalados los archivos de configuración estarán en el directorio /etc/bind, acá estarán
contenidos todos los archivos de configuración que se utilizan en este proyecto.
Se edita el archivo named.conf.local para agregar las zonas de autoridad y crearemos una carpeta de
nombre proyecto para crear los archivos de configuración de las zonas usando:
# mkdir /etc/bind/proyecto
Procedemos a editar el archivo named.conf.local lo abrimos usando:
# nano /etc/bind/named.conf.local
O usando algún editor de textos como gedit y hasta abajo colocamos nuestras zonas.

Se agregan 2 zonas, una de nombre callues.com que es la principal y otra de nombre
254.168.192.in-addr.arpa, que se utiliza cuando al DNS se haga una petición preguntando por el
dominio usando la dirección ip:192.168.254.X y los archivos de configuración de éstas zonas estarán
en /etc/bind/proyecto.
Ahora se crea el archivo de configuración db.proyeto en la carpeta /etc/bind/proyecto usando el
editor de texto de consola:
# nano /etc/bind/proyecto/db.proyecto
Y se escribe lo siguiente:
Nota: Se recomienda copiar un archivo de configuración que viene por defecto cuando se instala
bind9 llamado db.local al directorio /etc/bind/proyecto y renombrarlo como db.proyecto usando el
comando:
# cp /etc/bind/db.local /etc/bind/proyecto/db.proyecto
Ello permite hacer más fácil su configuración.

Se agregan 7 FQDNs para el dominio (ns1, ldap, interno, db, nfs y dos mail) y un registro de tipo MX
con parámetro 10 que servirá para aceptar peticiones que son de correos usando los protocolos SMTP
e IMAP. Cabe mencionar que, como requerimiento del proyecto, se han agregado dos registros para
el nombre “mail”, y solo existe un registro MX. Ello permite generar redundancia entre esos
servidores y de ese modo, al fallar un servidor, el segundo permanece disponible y respondiendo
como si fuese el primer servidor.
Ahora se procede a crear el archivo db.proyectorev la cual sera la inversa. Se crea este archivo de la
misma manera que el anterior al directorio /etc/bind/proyecto usando el editor de texto de consola:
# nano /etc/bind/proyecto/db.proyectorev

En este archivo se agregan 7 punteros indicando que las peticiones que se hagan por IP al servidor
DNS se les devolverán el FQDN correspondiente.
Ahora se debe probar si las zonas están correctas y reiniciar el servicio.
Ahora, se debe probar si se alcanza al dominio. Para eso se asigna una IP en la interfaz por la que se
escucharan las peticiones con el comando:
# ifconfig eth0 192.168.254.1/24 up
Luego, se edita el archivo resolv.conf mediante:

# nano /etc/resolv.conf
Se debe escribir la siguiente línea:
nameserver 127.0.0.1
Luego, como se muestra en la siguiente imagen, se trata de obtener información del dominio
mediante nslookup:
Finalmente, se prueba de forma rápida la conexión al servidor:
Si se muestra la información desplegada en la imagen, entonces el servidor DNS ya esta habilitado y
funcionando correctamente.

Instalación del Servidor SMTP (Postfix)
1. Instalación
Postfix es el servidor que nos permite ejecutar el protocolo SMTP. Vamos a instalarlo desde consola
de la siguiente manera:
# apt-get install postfix postfix-ldap
Ahora bien, en la consola aparecerá la siguiente ventana en esta parte se debe escoger SITIO DE
INTERNET:
Luego se define el dominio de correo. Para este proyecto será callues.com
Luego de unos cuantos mensajes más, se habrá instalado el servidor smtp en el ordenador.

2. Configuración
Ahora se deben modificar algunos archivos de configuración para que el servidor smtp funcione. Sin
embargo, antes de comenzar a tocar cualquiera de los archivos de postfix, hay que hacer lo siguiente:
Primero, crear en el sistema el grupo vmail: # groupadd – g 1005 vmail
Luego, crear el usuario vmail, que fungirá como cartero de correo: # useradd – g 1005 -u 1005 vmail
El primer archivo que vamos a instalar es /etc/postfix/main.cf
No son muchos los cambios generados en este archivos; las modificaciones que se hacen a este
archivo son los siguientes:
always_bcc=admin@callues.com
dovecot_destination_recipient_limit = 1
#TLS parameters
smtpd_tls_cert_file=/var/certs/CA/server.crt
smtpd_tls_key_file=/var/certs/CA/server.key
smtpd_use_tls=yes
smtp_use_tls=yes
smtpd_tls_security_level = encrypt
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_CAfile = /var/certs/CA/ca.crt
smtp_tls_CAfile = /var/certs/CA/ca.crt
smtpd_tls_loglevel = 2
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
###Virtual Configurations
virtual_mailbox_domains = callues.com
virtual_mailbox_maps = ldap:/etc/postfix/usuarios-ldap
virtual_mailbox_base = /home/mail
virtual_uid_maps = static:1005
virtual_gid_maps = static:1005
virtual_alias_maps = regexp:/etc/postfix/virtualaliases
virtual_transport=dovecot
###limitaciones
smtpd_helo_required=yes
smtpd_helo_restrictions=reject_invalid_helo_hostname,permit
smtpd_sasl_auth_enable = yes

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
### Sasl options
queue_directory=/var/spool/postfix
smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=yes
broken_sasl_auth_clients=yes
smtpd_sasl_security_options=noanonymous
smtpd_sasl_tls_security_options=$smtpd_sasl_security_options
smtpd_sasl_local_domain=$myhostname
Posteriormente se modifica el archivo /etc/postfix/master.cf y se descomentará lo siguiente:
smtp inet n - - - - smtpd
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
### AGREGAMOS ESTAS LINEAS
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
Se crea un archivo /etc/postfix/virtualaliases que contendrá lo siguiente (licky es un usuario que se
creará posteriormente en el árbol):
/^mailer-daemon@callues.com$/ licky@callues.com
/^postmaster@callues.com$/ licky@callues.com
/^abuse@callues.com$/ licky@callues.com
/^(.*)@callues.com$/ ${1}@callues.com
Se guarda el archivo y se le aplica postmap.
Ahora es momento de conectarse al árbol LDAP. Se crea un archivo /etc/postfix/usuarios-ldap
server_host = localhost
version = 3
search_base = cn=gerencia,ou=grupos,dc=callues,dc=com
scope = sub
query_filter = mail=%s
result_attribute = mailbox
ldap_bind = no
Finalmente se edita /etc/postfix/sasl/smtpd.conf y lo único que llevará el archivo es
pwcheck_method: saslauthd

Instalación del Servidor IMAP (Dovecot)
1. Instalación
Dovecot es un servidor que permite el envío de correo a través del protocolo IMAP.
# apt-get install dovecot-common dovecot-imapd dovecot-ldap
Cuando se instala, pide que se verifique la instalación y aparece en la consola el listado de archivos
que se van creando dentro del directorio /etc/dovecot
2. Configuración
Entramos en el archivo /etc/dovecot/dovecot.conf y descomentamos lo siguiente:
!include_try /usr/share/dovecot/protocols.d/*.protocol
listen = *, ::
login_greeting = Dovecot ready.
!include conf.d/*.conf
!include_try local.conf
Creamos un enlace simbólico dentro de /etc/dovecot
#ln -s /etc/dovecot/dovecot-ldap.conf.ext /etc/dovecot/dovecot-ldap-userdb.conf.ext
Entramos en el archivo /etc/dovecot/dovecot-ldap-userdb.conf.ext y editamos las siguientes líneas
de este archivo:
hosts = ldap.callues.com
dn = cn=admin,dc=callues,dc=com
dnpass = ldap123
debug_level = 1
auth_bind = yes
auth_bind_userdn = cn=noreply,ou=correo,dc=callues,dc=com
ldap_version = 3
base = ou=correo,dc=callues,dc=com
scope = subtree
user_attrs = mailbox=mail=maildir:/home/mail/%$
user_filter = (&(objectClass=CourierMailAccount)(uid=%u))
pass_attrs = uid=user,userPassword=password
pass_filter = (&(objectClass=CourierMailAccount)(mail=%u))
Posteriormente se dirige al fichero /etc/dovecot/local.conf (si no existe se crea) y se edita en el lo
siguiente:

protocol lda {
postmaster_address = licky@callues.com
}
disable_plaintext_auth = yes
ssl = required
ssl_cert=</var/certs/CA/server.crt
ssl_key=</var/certs/CA/server.key
Una vez realizado este paso, se procederá a modificar el archivo /etc/dovecot/conf.d/10-auth.conf
disable_plaintext_auth = yes
auth_username_format = %Lu
auth_mechanisms = plain
#!include auth-system.conf.ext
!include auth-ldap.conf.ext
Ahora se modificará el fichero /etc/dovecot/conf.d/10-master.conf y se le añade el siguiente bloque
de código:
unix_listener /var/spool/postfix/private/auth {
mode = 0660
# Assuming the default Postfix user and group
user = postfix
group = postfix
}
El archivo /etc/dovecot/conf.d/dovecot-ldap-conf.ext, en un bloque llamado userdb lleva lo
siguiente:
default_fields = uid=1005 gid=1005
Instalación de SASlAUTHD (Seguridad)
1. Instalación
Se procede a instalar saslauthd, con la cual se permite que se inicie TLS cuando se inicie el servicio de
postfix.
# apt-get install libsasl2-2 libsasl2-modules sasl2-bin
2. Configuración
Se modifica el archivo /etc/default/saslauthd y únicamente hay que buscar una línea llamada
START=no y se cambia esto por START=yes. Luego, se reinicia el servicio con:·
# /etc/init.d/saslauthd restart.

Configuración del servidor NSF (Sistema de archivos de red)
NFS permite que una colección arbitraria de clientes comparta un sistema de archivos común,
soportando sistemas heterogéneos, con clientes y servidores que tal vez ejecuten diferentes sistemas
operativos con un hardware distinto.
NFS se encarga de crear una abstracción que permite a usuarios y programas acceder a archivos
ubicados en máquinas remotas como si fueran locales.
Configuración del Servidor NFS:
El servidor nfs almacenara los correos entrantes, para lo cual se realizara una simulación de cluster
pues los servidores propiamente realizaran su función de servidor y los archivos los maildir y los
archivos de correo serán almacenados en el servidor NFS, con esto se tendrá optimización en cuando
al uso de almacenamiento y uso de recursos y sobrecarga de los servidores
Instalamos los siguientes paquetes:
# apt-get install nfs-common nfswatch nfs-kernel-server
Se crea la carpeta que se compartirá:
root@LuchoPC:/home/lichito# mkdir /var/correos

Se edita el archivo /etc/exports (se utilizara en este caso el editor en consola llamado “nano”), se
agrega la ip, mascara de subred y permisos en este caso la carpeta que se compartirá sera
/var/correos en esta carpeta se almacenaran los correos entrantes la red sera 192.168.254.0/24 y los
permisos serán (rw) lectura/escritura y (syn) mantener sincronizada la transferencia estos cambios se
ven en la siguiente captura:

Se tendrá que otorgar permisos para los usuarios en este caso:
# chmod -R 777 /var/correos
Se edita el archivo /etc/idmapd.conf en este archivo se especifica el dominio del servidor o la
direccion ip del mismo en este caso se colocara la direccion ip del servidor la cual es: 192.168.254.2

Se reinician los servicios siguientes:
root@LuchoPC:/home/lichito# /etc/init.d/nfs-kernel-server restart
root@LuchoPC:/home/lichito# /etc/init.d/rpcbind restart

Las otras configuraciones se hacen en el cliente:
se instala nfs-common
Se edita el archivo /etc/idmapd.conf donde se colocara la ip del servidor; la cual es: 192.168.254.2

Montamos la carpeta en el cliente dicha carpeta sera la carpeta compartida en la red para ello
introducimos el siguiente comando :
# mount -t nfs 192.168.254.2:/var/correos /home/mail
En este caso /home/mail sera la carpeta que el usuario vera en su estructura de directorios, contendra
los correos del cliente, dichos archivos fisicamente estan en el servidor NFS
Luego se realiza un ejemplo de copia de archivo a la carpeta compartida, esto se muestra en la
captura siguiente:
Si todo se ha realizado bien, se verá el archivo copiado en /var/correos del Servidor:

Creación de Certificados con OpenSSL.
En esta etapa del proyecto se explica paso a paso la manera de crear certificados para la organización.
Estos certificados permiten a los sistemas a integrar trabajar con opciones de seguridad mejoradas,
encriptado la información entre clientes y servidores.
1. Instalación
La instalación de OpenSSL es algo sencillo. Basta con escribir en la terminal (usando sudo, su o la
consola de Root):
# apt-get install openssl
2. Creación del certificado de la CA
La CA (Autoridad Certificadora) es la entidad que permite firmar certificados a otras organizaciones y
permite a los servicios confirmar que el origen de la conexión es una entidad confiable.
Recomendación: Si un mismo equipo servidor utiliza muchos procesos que requieran SSL, se
recomienda definir una carpeta de trabajo para los archivos del CA y otra para los certificados de los
demás servicios teniendo por seguro que las cuentas de usuario correspondientes a cada servicio
tengan al menos permisos de lectura sobre los objetos.
En este proyecto se trabaja como el usuario “Root”, por lo que, con esa cuenta hay que crear una
estructura de directorios (por ejemplo, dentro de /var) mediante los comandos:
# mkdir /var/certs
# mkdir /var/certs/CA
# mkdir /var/certs/<nombre del servicio>
Nota: Se recomienda que <nombre del servicio> sea un nombre corto pero que indique el propósito
del directorio, por ejemplo, www para un servicio HTTPS.
Ya con los directorios necesarios creados, se procede a crear los certificados de la CA:
# cd /var/certs/CA
# openssl genrsa [-des3] –out CA_Key.pem 4096
El comando opcional “-des3” es para indicar un método de cifrado en el cual, el certificado se protege
con una contraseña (aunque usando esta opción, al utilizar un certificado que implemente des3 en un
servicio, obliga a utilizar la contraseña al momento de reiniciar el servicio. En este ejemplo no se usa
des3.
Lo siguiente es crear la solicitud de certificado. Para ello ha de ejecutarse:

# openssl req -new -key CA_Key.pem -out CA.csr
En esta etapa se pide que se ingrese alguna información sobre la CA, basta solamente con definir el
país (es el código de dos letras correspondiente a cada país, en este ejemplo, se escribe SV), la
provincia y la localidad (que dependen del país donde se ubique la organización), el nombre de la
organización, la unidad de la organización y un nombre común o propio.Todos los demás datos
pueden obviarse sin problema.
Finalmente se debe auto-firmar el certificado de la CA mediante:
# openssl x509 -req -days <dias> -in -CA.csr -signkey CA_Key.pem -out CA_Cert.pem
Se recomienda que el parámetro <días> sea lo suficientemente grande respecto de los certificados de
los servicios restantes (que se crean posteriormente). En este ejemplo <días> tiene un valor de 3650
días (10 años).
Se puede notar que, si se ha usado el cifrado des3 a la hora de generar la llave, se pide la clave
ingresada para proteger la llave. Si no se utiliza des3, solo es de esperar que la salida arroje un
mensaje diciendo “Signature ok”.
3. Creación de los certificados para los servicios
El proceso para estos certificados es similar a los de la CA, salvo que, a la hora de crear la solicitud
(archivo CSR), se utiliza la llave destinada al servicio, y a la hora de firmar el certificado se utilizan los
parámetros para firmar con la llave y el certificado de la CA. Sin embargo, se puede crear un
certificado auto-firmado para el servicio, de modo similar al de la CA, en este ejemplo se crea un
certificado firmado con la CA.
A modo de ejemplo, se crea el certificado correspondiente al servicioWeb (referido como www)
comenzando por la llave:
# cd /var/certs/www
# openssl genrsa -out WWW_Key.pem 4096
Luego, se crea la solicitud (de modo similar al de la CA, se llenan los datos correspondientes) con el
siguiente comando:
# openssl req -new -key WWW_Key.pem -out WWW.csr
Y finalmente basta ya con firmar el certificado utilizando a la CA:
# openssl x509 -req -days 365 -CA /var/certs/CA/CA_Cert.pem -CAkey /var/certs/CA/CA_Key.pem
-CAcreateserial -in WWW.csr -out WWW_Cert.pem
Si todo sale bien, se muestra el mensaje “Signature ok” y con ello finaliza el proceso de creación de
certificados. Si hay otros servicios en el mismo equipo, se debe repetir el paso 3 dependiendo de la
cantidad de procesos.

Instalación del servidor Web Apache2 y PHP5
1. Instalación del servicio de Apache
El servidor Apache es el responsable de la publicación de los sitiosWeb de la organización. Sin
embargo, este proyecto busca el acceso a un sitio web tanto desde fuera de la organización (Internet)
como desde dentro de la misma (Intranet).
Las librerías de PHP5 son un conjunto de módulos adaptables para Apache, los cuales permiten
dinamizar el contenido de un sitioWeb.
PHP5 tiene conjuntos de paquetes para establecer conexión con diversos orígenes, los cuales
incluyen LDAP y MySQL (que posteriormente se utilizaran en este proyecto).
Para la instalación de Apache, basta con entrar a la consola como usuario Root y ejecutar el siguiente
comando:
# apt-get install apache2-mpm-prefork
Lo siguiente es ver si el sitio web por defecto funciona. Para ello con el navegador que esté disponible
se debe ingresar a la dirección http://localhost y el resultado debería verse como el siguiente:

Por defecto, el sitio web se almacena en /var/www (Para que Apache pueda leer el contenido hay que
asegurarse que otros usuarios puedan acceder a los archivos del sistema (posteriormente se
configura Apache para prevenir acceso a ciertas zonas del sitioWeb).
La forma de asegurarse es abrir el explorador del sistema de archivos instalado en el equipo (En este
ejemplo, Nautilus) y verificar que en la pestaña “Permisos” la sección “Otro” especifique que se puede
acceder a archivos como se muestra en la siguiente imagen.
2. Instalación del modulo PHP5
Lo siguiente es instalar el paquete PHP5 desde la terminal mediante:
# apt-get install php5
Al finalizar, siempre como el usuario Root, lanza el editor de texto que este instalado en el sistema y
debe modificarse el archivo /var/www/index.html, borrar todo su contenido y escribir lo siguiente:
<?php phpinfo(); ?>
Luego, siempre en con el editor de texto, abrir el archivo /etc/apache2/sites-available/default y en la
sección presentada a continuación, se debe agregar la linea en negritas:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
DirectoryIndex index.php
AllowOverride None
Order allow,deny
allow from all
</Directory>
Se cierra el editor de texto y se ejecuta en la terminal:
# /etc/init.d/apache2 restart
Ya reiniciado el servicio de Apache, lo siguiente es ir al navegador y recargar la página http://localhost
para ver el siguiente resultado:
Si el navegador muestra esa pantalla, PHP5 esta correctamente instalado.
El sitio web, por el momento, no requiere ser retocado, pues hacen falta otros servicios que agregar,
como LDAP y MySQL. Cuando ambos estén configurados, se procede a configurar el sitio web y a
agregar los módulos restantes de PHP5.

Instalación y Configuración de OpenLDAP
OpenLDAP es la implementación del protocolo LDAP (Protocolo Ligero de Acceso a Directorios), el
cual funciona como una base de datos mucho mas veloz que una base de datos relacional y que a su
vez, es utilizada por otros servicios, como SMTP e IMAP y HTTP.
1. Instalación del servicio OpenLDAP
Para instalar OpenLDAP se debe instalar el paquete slapd, desde terminal y como usuario Root
mediante:
# apt-get install slapd ldap-utils
Nótese que hay dos paquetes a instalar. El paquete ldap-utils es un conjunto de herramientas de
configuración del servicio OpenLDAP.
Para resumirlo, LDAP es un protocolo que almacena y comparte la información de un dominio
mediante una estructura jerárquica llamada árbol, la cual se compone de ramas, las cuales a su vez,
pueden ser hojas (si no tienen un nodo hijo) o simplemente rama.
Al instalar OpenLDAP, se pide la contraseña del usuario raíz (del árbol LDAP), por ahora no es
importante y se puede escribir cualquier cosa. Al llegar a esa etapa, la terminal se mostrara asi:

Ya con el servicio instalado, basta re configurar el paquete slapd mediante:
# dpkg-reconfigure slapd
Debe responder antes de establecer el dominio si desea omitir la configuración, a lo que se debe
responder con “No”.
Ahora pregunta por el dominio de la organización. Puede escribir el nombre del dominio en su
formato de FQDN o, como en este ejemplo, escribir: callues.com
Nota: Para este proyecto (este es el dominio de la organización) y el equipo que cuente con el
servicio de LDAP debe contar con un DNS que contenga la zona de autoridad para el dominio a usar.
Luego se pregunta por el nombre de la organización (no dominio), a lo que, en este proyecto, se
responde con “CallUES” (sin comillas).
Ahora se pregunta por la contraseña del administrador, y debe confirmarse. Cuando se haga, se
escribe en la base de datos del árbol dicha contraseña para el usuario (hoja en el árbol)
cn=admin,dc=callues,dc=com.
Para el motor de base de datos, se recomienda utilizar el “hdb”.
Lo siguiente es si desea que se borre la base de datos cuando se purgue (elimine del sistema) el
paquete slapd, se puede responder que si. Luego, se debe decir que se mueva la base de datos
anterior para evitar problemas de configuración.
Luego debe indicar que no debe utilizarse el protocolo LDAP versión 2. Esto obliga al servicio a
utilizar la versión 3.
Y con ello termina la re configuración del paquete slapd.
3. Instalación de Jxplorer
Lo siguiente es instalar el entorno visual para trabajar con slapd, instalando el paquete jxplorer
(requiere tener instalado el JDK7 de Oracle) mediante el comando de terminal:
# apt-get install jxplorer
Una vez que se haya instalado jxplorer, para ejecutarlo desde la terminal de Root se utiliza el
comando:
# jxplorer
Ya dentro de jxplorer, se debe iniciar una conexión con slapd, haciendo click en File y luego en
Connect y aparecerá el siguiente dialogo:

Hay que llenar los datos tal y como se muestra en la imagen para iniciar la conexión. Una vez hecho
click en OK, se muestra el árbol LDAP:

El objeto “admin” que se muestra en el árbol, no es otro más que el “root” del servicio LDAP. Sin
embargo, se puede eliminar del árbol sin problemas, pues en la base de datos de configuración
permanece seguro y libre de modificaciones desde el exterior. Para eliminarlo solo se debe hacer click
derecho sobre admin y luego click en Delete.
Con ello se puede proceder a la siguiente estapa: el motor de bases de datos. Para ello se utilizara el
motor PostgreSQL 9.2.4.

Instalación de PostgreSQL
El servicio de base de datos permite complementar al servicio LDAP con elementos que no pueden
tratarse fácilmente con un árbol LDAP. En esta etapa se muestra como instalar el servicio de bases de
datos relacionales.
1. Descarga e instalación de PostgreSQL
Para obtener la última versión de PostgreSQL, hay que seguir el siguiente enlace:
Ahora, en consola, hay que dirigirse al directorio donde se descargó el archivo y ejecutar el comando:
# ./postgresql-9.2.4-1-linux-x64.run
Nota: El nombre de archivo puede variar dependiendo de si se cambia en la descarga o la versión.
Ya iniciado el asistente, se muestra una pantalla como la siguiente:

En el siguiente paso se deja el directorio de instalación tal y como aparece por defecto. Se debe hacer
del mismo modo para el directorio de datos.
El siguiente paso pide la contraseña del administrador de PostgreSQL. Hay que escribirla, confirmarla
y continuar al siguiente paso.

Luego se pide el puerto, por defecto debe dejarse el puertoTCP 5432, la configuración regional se
deja intacta y se procede a la instalación.
Al finalizar pedirá la instalación de Stack Builder, pero solo hay que decir que no se quiere instalar y se
finaliza.
2. Configuración de la instancia de PostgreSQL
El instalador de PostgreSQL incluye una herramienta visual para monitorear las bases de datos del
sistema, llamada pgAdmin3. Mediante lanzadores puede ser ubicado y ejecutado, de modo que se
muestra la siguiente ventana:

Para probar una conexión hay que hacer click derecho en la instancia por defecto (aparece con una X
roja) y luego en la opción “Connect”. Pedirá la contraseña que se asignó en la instalación y si la
contraseña es correcta, se verá el esquema de la base de datos, indicando que PostgreSQL está
correctamente instalado.

Al explorar en la instancia se puede ver el esquema por defecto, llamado public. Es ahí donde
posteriormente se agregaran las tablas a utilizar en este proyecto.
Con estos servicios instalados, se procede a planificar la forma en que deben funcionar. En este
proyecto, con respecto a los servicios de OpenSSL, Apache2, PHP5, OpenLDAP y PostgreSQL se
deben cumplir los siguientes objetivos:
Para OpenSSL (ver seccion “Creacion de Certificados con OpenSSL):
* Crear certificados de laCA
* Crear certificados para los sitiosWeb
Para Apache2:
* Habilitar un sitio público usando la interfaz (adaptador de red) que tenga acceso a Internet
* Habilitar un sitio interno utilizando la interfaz destinada a labores dentro de la organización
(Intranet)
* Utilizar el certificado destinado para el servicioApache y acceder a ambos sitiosWeb utilizando
HTTPS
* Habilitar el uso de AJAX
Para PHP5:
* Permitir la ejecución de contenido dinámico (scripts de PHP) en ambos sitiosWeb
* Permitir a los sitios Web conectarse al servicio OpenLDAP
* Permitir a los sitios Web conectarse al servicio PostgreSQL
* Permitir a los sitios Web el envío y lectura de eMail
Para OpenLDAP:
* Crear el árbol del dominio callues.com
* Configurar la cuenta raíz y una cuenta de lectura para acceder al árbol
* Agregar el esquema “authldap.schema” para manipular cuentas de eMail
Para PostgreSQL:
* Crear una estructura de datos que permita el soporte de los datos que OpenLDAP no puede
soportar, esto incluye: eventos, etapas, servicios, etc.
Dado que los certificados (ver sección “Creación de Certificados con OpenSSL”) ya deberían existir, se
procede a la configuración de los servicios para lograr los objetivos descritos anteriormente.

Configuración de Servicios Web, LDAP y de Bases de Datos
1. Definición del sitio público y el sitio interno
Al instalar el servicio de Apache, en el directorio /etc/apache2/sites-available existen 2 sitios: default
y default-ssl. El primer paso es editar el archivo default-ssl y crear dos copias, una para el sitio
público y otra para el sitio interno.
Utilizando el explorador del sistema de archivos instalado en el sistema, como usuario Root, hay que
examinar el directorio /var/www y dentro de el hay que crear 2 carpetas: interno y público. Dentro de
cada una de las carpetas hay que copiar el archivo index.php que se encuentra dentro de /var/www y
al copiarlo a ambos directorios, se debe eliminar del directorio original (eliminar de /var/www), con lo
que se debe tener una estructura de directorios como la siguiente:
/var/www
|------ publico
| |------- index.php
|
|------ interno
|------- index.php
Utilizando (como usuario Root) el editor de texto que más convenga, se abre el archivo default-ssl y
debe agregarse o editarse lo que a continuación a aparecer en negritas:
<VirtualHost 192.168.1.6:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/publico
<Directory /var/www/publico>
Options Indexes FollowSymLinks MultiViews
DirectoryIndex index.php
AllowOverride None
Order allow,deny
allow from all
</Directory>
Y luego, en el mismo archivo hay que definir los certificados tanto de la CA como los destinados al
servicio Apache. Para ello hay que modificar las líneas que se muestran a continuación:
Para los certificados del servicio Apache:
SSLCertificateFile /var/certs/www/WWW_Cert.pem
SSLCertificateKeyFile /var/certs/www/WWW_Key.pem

Para los certificados de la CA (Estas líneas aparecen comentadas con un símbolo # al inicio, hay que
quitar dicho símbolo para que hagan efecto):
SSLCACertificatePath /var/certs/CA
SSLCACertificateFile /var/certs/CA/CA_Cert.pem
Hecho todo eso, se guarda el archivo como publico-ssl dentro del directorio
/etc/apache2/sites-available. Para el sitio interno se sigue el mismo procedimiento, reemplazando la
palabra público por interno, por lo que sites-available debe tener los archivos público-ssl e
interno-ssl.
Luego de haber realizado este procedimiento, hay que editar el archivo ports.conf del directorio
/etc/apache2 comentando (escribiendo el símbolo # al inicio) la línea:
#NameVirtualHost *:80
Listen 192.168.1.6:443
Listen 192.168.254.2:443
Las últimas dos líneas en negrita deben ser agregadas. Dentro del mismo archivo debe editarse la
sección que se muestra a continuación, agregando o modificando las líneas en negrita:
<IfModule mod_ssl.c>
# If you add NameVirtualHost *:443 here, you will also have to change
# theVirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
NameVirtualHost 192.168.1.6:443
NameVirtualHost 192.168.254.2:443
#Listen 443
</IfModule>
Lo siguiente, dentro de la terminal como Root, es deshabilitar el sitio web por defecto mediante:
a2dissite default
Luego hay que habilitar los dos sitios ssl que se acaban de crear mediante:
a2ensite público-ssl
a2ensite interno-ssl
Habilitar el modulo SSL mediante:
a2enmod ssl
Y al final, reiniciar el servicio apache2 mediante:

/etc/init.d/apache2 restart
Hecho esto, se procede a abrir en el navegador los sitios. En este proyecto, a modo de prueba, se
utiliza la dirección https://HYPERLINK "https://192.168.254.2/" 192.168.254.2 para el sitio interno y la
dirección https://HYPERLINK "https://192.168.0.17/"
192.168.https://192.168.0.17/1https://192.168.0.17/.https://192.168.0.17/6 para el sitio público.
Accediendo a cualquiera de esas direcciones, el navegador dará aviso de que no conoce a la entidad
que emite el certificado. En este ejemplo, utilizando Mozilla Firefox se muestra la detección del
certificado:
Al ver la opción “Añadir excepción...” se puede ver que se ha obtenido un certificado en lo y al hacer
click en “Ver...” se muestran los datos de la CA (cuadro verde) y del servicioWeb (cuadro rojo):

Al confirmar la excepción de seguridad (agregar el certificado a la lista de certificados de confianza
del navegador), ya se puede ver que hay acceso al sitio al que se ha accedido, en este ejemplo, al sitio
Interno:

Si se muestra la página inicial del sitio al que se pretenda acceder, entonces se ha configurado
correctamente el modulo SSL del servicio Apache, y ya debe contar con acceso a los dos sitios Web,
es decir, el público y el interno.
El siguiente objetivo de la configuración de Apache, es que los sitios soporten AJAX. Esto tiene 2
propósitos clave; el primero, enviar consultas asíncronas mediante el método GET y el método POST
y el segundo, acceder a funciones escritas en PHP que la interfazWeb no mostrara.
El proceso es muy sencillo: en la carpeta de cada sitio se crea una nueva carpeta a la que, en este
ejemplo, ha de llamarse “js” y dentro de ella se agrega un archivo llamado ajax.js que contiene el
siguiente código:
// Crea un objeto AJAX dependiendo del explorador. Si no es posible devuelve null.
function CrearAJAX()
{
var ajaxRequest = null;
try
{
ajaxRequest = new XMLHttpRequest();
}
catch (e)
{
try
{
ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e)
{
try
{
ajaxRequest = newActiveXObject("Microsoft.XMLHTTP");
}
catch (e)
{
ajaxRequest = null;
}
}
}
return ajaxRequest;
}
//Envía una petición AJAX via HTTP POST. Devuelve el resultado de la petición como texto.
function EnviarPOST(AjaxObj, Url, Params)
{

if (AjaxObj != null)
{
AjaxObj.open("POST", Url, true);
AjaxObj.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
AjaxObj.send(Params);
}
else
alert('Este navegador no soporta AJAX. Intente accesar a este sitio usando un navegador más
reciente.');
}
//Envia una petición AJAX via HTTP GET. Devuelve el resultado de la petición como texto.
function EnviarGET(AjaxObj, Url)
{
if (AjaxObj != null)
{
AjaxObj.open("GET", Url, true);
AjaxObj.send(null);
}
else
alert('Este navegador no soporta AJAX. Intente accesar a este sitio usando un navegador mas
reciente.');
}
La primer función crea un objeto que trabaja con AJAX, dependiendo del navegador. Esta función ha
sido probada en Internet Explorer 7+, Mozilla Firefox 16+, Google Chrome 17+ y Opera 11+. La
segunda función permite enviar parámetros a un script (en este proyecto, script escrito en PHP)
usando el método GET (enviando consultas asíncronas con los parámetros en la URL) y la tercera
envía consultas usando el método POST (consultas asíncronas con los parámetros ocultos).
Lo siguiente es configurar los servicios OpenLDAP y PostgreSQL y agregar al servicio Apache el
soporte para ambos mediante PHP5.

2. Instalación de los módulos LDAP, PostgreSQL e IMAP para PHP5
Este proceso es realmente breve, pues solamente requiere ejecutar un solo comando en la terminal
como Root:
# apt-get install php5-ldap php5-imap php5-pgsql
Posteriormente se detalla un poco mas el uso de estos módulos pero por el momento se describe su
contenido:
php5-ldap: permite el acceso a servidores LDAP, lo que será vital a la hora de trabajar con la cuentas
de correo de este proyecto, pues se almacenaran en un árbol LDAP.
php5-imap: permite acceder a un servidor IMAP, con el cual, se pueden obtener los mensajes de
eMail del usuario deseado cuya cuenta se encuentre en el árbol LDAP.
php5-pgsql: contiene funciones para trabajar con el servidor PostgreSQL, lo que es importante a la
hora de trabajar con los servicios de la organización.
3. Creación del árbol LDAP y configuración del esquema Courier
El esquema “courier” es un archivo que contiene la definición de unos tipos de objetos que permiten
almacenar información sobre cuentas de eMail. Para este proyecto, se ha ubicado una copia de dicho
archivo de esquema en el siguiente enlace:
http://www.mediafire.com/?1evvy78pcuum5b5
Debe ser descargado y posteriormente hay que copiarlo (como usuario Root) al directorio
/etc/ldap/schema para su inclusion. Antes de proseguir hay que recordar que en esta etapa del
proceso todo lo que se haga debe hacerse como usuario Root.
El primer paso es crear con un editor de texto un archivo temporal (se recomienda hacerlo en el
directorio donde este ubicada la terminal) llamado courier.conf que contenga lo siguiente:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/authldap.schema
Lo siguiente es crear un directorio de salida para la prueba de configuración de esquemas de LDAP
mediante:

# mkdir /var/slapd.d
Y ya con ello, ejecutar la prueba de configuración mediante el comando:
# slaptest -f courier.conf -F /var/slapd.d/
Si el comando tuvo éxito, se muestra un mensaje diciendo “config file testing succeeded”. Con lo
que resta copiar la nueva configuracion al directorio original de OpenLDAP.
Posteriormente hay que desplazarse al directorio de pruebas mediante:
# cd /var/slapd.d/cn=config/cn=schema/
Mediante un comando ls hay que verificar que exista un archivo cuyo nombre termina en
authldap.ldif, hay que copiar tal archivo al directorio de OpenLDAP mediante:
# cp "/var/slapd.d/cn=config/cn=schema/cn={4}authldap.ldif"
"/etc/ldap/slapd.d/cn=config/cn=schema/cn={4}authldap.ldif"
Nota: El nombre del archivo ldif comienza con cn={4}, pero ello puede cambiar dependiendo de los
esquemas instalados. Por lo tanto, al copiar al destino, hay que asegurarse que el número entre llaves
no choque con alguno ya existente. Si hay un archivo con el mismo número, se debe cambiar el
número del archivo de destino por el número más alto encontrado mas uno, es decir, si ya existe un
archivo 4, el archivo destino debe ser el 5, quedando al final del comando como cn={5}authldap.ldif.
Hecho esto, lo siguiente es desplazarse al directorio de OpenLDAP mediante:
# cd "/etc/ldap/slapd.d/cn=config/cn=schema/”
Y posteriormente ejecutar los comandos:
# chown openldap: cn={4}authldap.ldif
# /etc/init.d/slapd restart
Para comprobar si el proceso ha tenido éxito, hay que abrir Jxplorer como Root e iniciar sesion como
el administrador del árbol (ver seccion “Instalacion y Configuracion de OpenLDAP”, parte 3).
Ya iniciada la sesion, hay que hacer click en la ficha Schema y buscar las clases marcadas en rojo en la
siguiente imagen:

Si estas tres clases aparecen en el listado, entonces el esquema Courier ha sido instalado
correctamente.Valga mencionar que, en caso de que se vuelva a configurar el servicio de OpenLDAP,
este esquema se pierde, por lo que para rehabilitarlo, hay que ejecutar todo el proceso de instalación
del esquema de nuevo.
Ya dentro de Jxplorer, hay que preparar el árbol agregando los siguientes elementos:
* Una unidad organizacional (OU) llamada “correo”
* Una unidad organizacional (OU) llamada “grupos”, que contenga a los grupos “ingenieros”,
“técnicos” y “gerencia”
*Una unidad organizacional (OU) llamada “clientes”
* Una cuenta de correo (CourierMailAccount + inetOrgPerson) llamada noreply, cuya dirección de
eMail sea noreply@callues.com y que solamente pueda ser modificada por el usuario raíz del árbol o
el mismo.
* Un objeto de tipo inetOrgPerson llamado “lector” que solo pueda obtener acceso de lectura a todo
el árbol y que solamente pueda ser modificado por el usuario raíz del árbol o el mismo.
*Permitir que las cuentas de correo puedan modificarse con su misma credencial, pero que no
puedan leer el resto del árbol.
La estructura del árbol (dc=callues, dc=com) hasta el momento es la siguiente:
com
|--- callues
Y se desea obtener algo como lo siguiente:
com
|--- callues
|--- clientes
|

|--- correo
| |--- noreply
|
|--- grupos
| |--- ingenieros
| |--- técnicos
| |--- gerencia
|
|--- lector
Para comenzar a agregar un nodo a una rama, basta con seleccionar el nodo contenedor (en este
caso se selecciona el nodo “callues”) y se presiona Ctrl+N (o se hace click derecho y luego click en la
opción New. A continuación se muestra la pantalla para agregar nuevos elementos:

Describiendo los parámetros de la pantalla se tiene que:
Parent DN (donde DN significa Nombre Distinguido) es el nodo contenedor del nuevo objeto. En
este caso, el contenedor es, como se esperaba, dc=callues,dc=com.
Enter RDN (Donde RDN significa Nombre Distinguido Relativo) es el identificador del objeto a crear.
Cuando se crea una unidad organizacional, el RDN comienza con ou=<nombre de la OU> y <nombre
de la OU> es un nombre arbitrario. Como primer ejemplo, puede ser la OU llamara “correo”.
Available Classes es el listado de clases (obtenidas desde los esquemas instalados) disponibles. Para
agregar una clase, se debe seleccionar una de la lista de la izquierda y presionar el boton Add. Si en la
lista de la derecha hay una clase que no fuese necesaria, basta con seleccionarla y presionar el boton
Remove.
Para crear una OU:
Con los parámetros mencionados, para crear una OU basta con hacer lo siguiente en la pantalla
mostrada en la imagen anterior (tomando como ejemplo la OU llamada “correo”):
* Escribir como RDN: ou=correo
* Buscar la clase “organizationalUnit”, marcarla y presionar Add
* Presionar OK
Una vez hecho esto, aparecerá una tabla como la siguiente:
Como se puede apreciar, el objectClass es “organizationalUnit”, aunque hay un valor duplicado que
dice “top”. Ello es, porque organizationalUnit “hereda” los atributos de la clase top, de modo similar a
la programacion orientada a objetos, salvo que LDAP permite que un atributo tenga más de un valor.

Por el momento, los datos se dejan intactos y se presiona el boton Submit para agregar la OU al árbol
(panel izquierdo de la ventana de Jxplorer).
Se realiza el mismo proceso para la OU llamada “grupos” a modo de obtener una estructura como la
siguiente:
Para crear al usuario “lector”:
El proceso es el mismo que para las OU, con la diferencia que la clase a agregar no es
organizationalUnit, sino que se utiliza la clase “inetOrgPerson”. El RDN del usuario lector debe ser
cn=lector y debe agregarse en el nodo callues. Cuando se cree, se debe llenar la tabla de la siguiente
forma:

Se puede apreciar un campo llamado userPassword. Cuando se intente editar ese campo, pedirá una
contraseña y su verificación además de un método de encriptación. Se recomienda utilizar el método
MD5 y al escribir la contraseña, confirme el cambio y para que el lector aparezca en el árbol, se hace
click en Submit, bajo la tabla.
Para crear los grupos:
De igual modo que con las OU, los grupos siguen el mismo proceso, salvo que debe agregarse en el
nodo “grupo” en vez del nodo “callues” y la clase a utilizar no es organizationalUnit, sino que se debe
utilizar o bien sea groupOfNames o groupOfUniqueNames.
A la hora de definir cuál clase utilizar se debe considerar que al utilizar groupOfUniqueNames no se
permite definir permisos en el árbol para objetos de esta clase, aunque posee la ventaja de que
verifica automáticamente si un nodo ya existe en el grupo.
En este ejemplo, se utilizara la clase groupOfNames, pues hay que establecer permisos que
solamente con esta clase se pueden lograr.A modo de ejemplo, se crea el grupo “ingenieros”
Se crea el grupo como cuando se inicia la creación de una OU, asegurándose que el Parent DN sea
ou=grupos,dc=callues,dc=com, que el RDN sea cn=ingenieros y que la clase sea groupOfNames.
Una vez hecho esto deben llenarse los datos como se muestra en la siguiente imagen:

Se puede notar que el campo “member” (que es multivaluado, es decir, puede almacenar mas de un
solo valor), debe tener al menos un valor, por lo que, aprovechando que ya existe el usuario “lector”
se utiliza el DN completo de dicho usuario. Para hacerlo se hace click derecho en el usuario “lector” y
se selecciona Copy DN y se pega el valor en el campo “member” (para agregar un nuevo valor a
member, en la tabla, se hace click derecho sobre el campo “member” y se selecciona “Add another
value”).
Nota: Hay que recordar que el valor member debe contener solamente DN completos. No pueden
utilizarse Parent DN ni componentes individuales de un DN.
Hecho esto, se presiona Submit y el grupo “ingenieros” aparece ya en el árbol dentro del nodo
“grupos”.
Para los otros grupos (técnicos y gerencia) se sigue el mismo procedimiento.
Para la cuenta noreply:
El proceso es exactamente el mismo que para el usuario “lector” con dos diferencias: debe agregarse
en el nodo “correo” y además de la clase inetOrgPerson debe contener la clase CourierMailAccount.
El RDN para el correo noreply es cn=noreply. Se presiona OK y se llena la tabla tal como se muestra
en la siguiente imagen:

Notese que ya existen los 3 grupos (gerencia, ingenieros y tecnicos). Debe llenarse lo que se muestra
en la imagen para el correo noreply, aunque, los campos homeDirectory y mailbox no se utilizan por
el momento, por lo que solo solamente basta con dejar indicados unos valores temporales. Se
presiona Submit y el correo noreply esta ya en el árbol.
Para finalizar la configuracion del servicio OpenLDAP hay que configurar los permisos de acceso al
árbol.
En el directorio /etc/ldap/slapd.d/cn=config existe el archivo olcDatabase={1}hdb.ldif. Dicho archivo
contiene las directivas de control y acceso del árbol de callues.com.
Los permisos se configuran en las directivas olcAccess: {indice} donde índice corresponde a un
número correlativo que, aunque no es necesario, se recomienda escribirlo para una mejor
comprensión de los permisos.
En dicho archivo, hay que eliminar todas las directivas olcAccess (se recomienda crear un respaldo
del archivo primero) y escribir las siguientes directivas que serán los sustitutos:
olcAccess: {0}to *
by self write
by dn="cn=admin,dc=callues,dc=com" write
by dn="cn=lector,dc=callues,dc=com" read
by * none
Lo que esto significa es que, al momento de accesar al árbol, si quien accede es el usuario que hizo
login y examina su propia cuenta, puede modificarse; si quien acceda es el usuario raíz del árbol

(cn=admin), puede escribir y leer todo el árbol; si acceda el lector, puede modificar su propia cuenta
pero solo puede leer las demás cuentas y si quien acceda es cualquier otro usuario, no tiene permiso
para nada más que su propia cuenta. Hecho eso, se guarda el archivo original y se ejecuta en la
terminal:
# /etc/init.d/slapd restart
Posteriormente se comprueba que los permisos se han hecho efectivos.
Al finalizar todo, el árbol LDAP debería lucir así:
EL servicio restante por configurar es el PostgreSQL. Este proyecto exige trabajar con datos que
LDAP no puede utilizar, por lo que una base de datos relacional es un complemento que se adecua a
los requerimientos del proyecto.

4. Definición de la Base de Datos de PostgreSQL
A modo de resumir, se muestra la estructura de la base de datos implementada en el servidor
PostgreSQL.
Dado que el servicio OpenLDAP posee estructuras que permiten almacenar datos de los clientes, las
estructuras de las tablas son bastante sencillas. A continuación se define el contenido y el propósito
de cada tabla:
Cliente: Contiene solamente el identificador del cliente (Id) y un campo llamado Cliente de tipo texto,
que almacena el eMail del cliente dentro de la base de datos. Esta tabla es vital pues es el cliente
quien genera el ticket (implementado en las tablas Evento y Etapa).
Servicio: Es cualquier servicio que el cliente pueda solicitar mediante el sistema. Consta de un
identificador (Id) que identifica al servicio, un identificador secundario (Pid) que indica si el servicio es
una parte de otro servicio principal, un nombre y los detalles para dar una breve descripción del
servicio.
Evento: Es el ticket que el cliente genera al ingresar al sistema y solicitar un servicio. Solamente
cuenta con un identificador principal (Id), un identificador del cliente que lanzo el ticket, el
identificador del servicio para el cual fue lanzado el ticket, la fecha en que inicia el servicio solicitado y
la fecha en que finaliza el servicio.
Etapa: Es cada fase del servicio solicitado por el cliente, en el que se incluye el identificador del
usuario (empleado de la organización que brinda el servicio directamente), el identificador del evento
(ticket), identificador principal (Id), la fecha en que se inicia dicha etapa, un campo que indica si la
etapa actual fue la que finalizo el servicio, un nombre descriptivo (tipo) de la etapa y los detalles

(opcionales).
Solicitud: Esta tabla esta destinada a la labor de referir un servicio de un empleado a otro del mismo
rango o superior. Se define mediante un identificador principal y los identificadores del usuario
(empleado) solicitante (o quien brinda actualmente el servicio) y del destinatario (empleado a quien
se le asignara el servicio a brindar) y las fechas en que se realiza la solicitud y la fecha en que es
aprobada.
Usuario: Es la tabla que identifica a un usuario del árbol LDAP (ver la sección “Creación del árbol
LDAP y configuración del esquema Courier”) y, dado que ya existen las cuentas en el árbol LDAP, esta
tabla solamente contiene el identificador principal del usuario.

How to tickets - Protocolos de Comunicación

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (6)

Semelhante a How to tickets - Protocolos de Comunicación

Semelhante a How to tickets - Protocolos de Comunicación (20)

Último

Último (10)

How to tickets - Protocolos de Comunicación