1 Introducción. Admintool

Facultad de Informática Informatika Fakultatea

Índice 1 Introducción...5 2 Documento de Objetivos de Proyecto...7 2.1 Objetivos...7 2.2 Método de trabajo...8 2.3 Alcance...9 2.3.1 Diagrama EDT...9 2.3.2 Entregas...9 2.3.3 Asignación de recursos...10 2.4 Planificación temporal...10 2.4.1 Diagrama de Gantt...13 2.4.2 Plan de contingencia...14 2.4.3 Factibilidad...16 3 Desarrollo técnico...19 3.1 Captura de requisitos...19 3.1.1 Casos de uso...20 3.1.2 Modelo de dominio...32 3.2 Análisis...34 3.3 Arquitectura del sistema...47 3.4 Relaciones de confianza...50 3.5 Unidades Organizativas...51 3.6 Estructura Física...52 3.7 Sitios...52 3.8 Controladores de dominio...53 3.9 Funciones de los controladores de dominio...53 3.10 Servidor de Catálogo Global...54 4 Elección tecnológica...57 5 Diseño...59 6 Implementación...65 6.1 Modelo de desarrollo...66 6.2 Gestión de Exchange 2007 (método y atributos)...69 6.2.1 Crear buzón de correo...71 6.2.2 Protocolos del buzón de correo...73 6.2.3 Restricciones del tamaño de los mensajes...73 6.2.4 Límites de almacenamiento del buzón (cuotas)...74 6.2.5 Ocultar usuario de la lista de correo del servidor...75 6.2.6 Añadir contacto...75 6.2.7 Redireccionar buzón de correo...76 6.2.8 Realizar consultas en el Directorio Activo...77 6.2.9 Trabajar con atributos del Directorio Activo...78 6.2.10 Ejemplos...79 7 Pruebas...83 7.1.1 Pruebas unitarias...83 7.1.2 Pruebas de integración...85 7.1.3 Pruebas de validación...85 7.1.4 Pruebas del sistema...85 7.2 Plan de Implantación...86 7.2.1 Seguridad...86 7.2.2 Utilidad...88 Página 3

8 Gestión del proyecto...90 8.1 Incidencias relevantes...90 8.2 Gantt planificado VS Gantt real...91 9 Conclusiones...97 10 Anexos...99 10.1 Anexo 1...99 10.2 Bibliografía...103 10.3 Manual de usuario...104 Página 4

1 Introducción Admintool es un proyecto desarrollado por David Salinas en y para la empresa Ibermatica Ciencia y Tecnología, situada en el parque tecnológico de Miramón, como Proyecto de Fin de Carrera para el curso académico 2009/2010. Siendo este proyecto la continuación de un proyecto anterior, Gestión del Directorio Activo, desarrollado por David Montero en el curso 2008/2009 en la misma empresa. Para este Proyecto de Fin de Carrera actúa como director en la Facultad de Informática de San Sebastián Germán Rigau y como responsable en la empresa Beñat Alonso. Admintool es una aplicación que es utilizada por los distintos Centros de Atención al Usuario (CAU) de Ibermática y que tiene como fin mejorar la seguridad y la gestión del directorio activo en un dominio. Para mejorar la seguridad se evita que los técnicos del CAU utilicen usuarios con permisos de administrador, siendo la propia aplicación la que posee esos permisos internamente. Al tener que utilizar las opciones que incluye la aplicación se minimiza el riesgo de cometer errores al gestionar el Directorio Activo y el servidor de correos Exchange Server 2007 y se mantiene un fichero log con las acciones realizadas, para poder comprobar en caso de necesidad qué acciones se han realizado. A pesar de que este proyecto ya había sido iniciado se han llevado acabo una serie de correcciones y mejoras, como es el rediseño de la interfaz de usuario. También se han añadido nuevas funcionalidades, como es la gestión del buzón de los clientes en el Exchange Server 2007. Finalizando con la configuración para su correcto funcionamiento e implantación en cada uno de los dominios cliente. Tratándose Admintool de un proyecto amplio que gestiona usuarios, carpetas, recursos compartidos, permisos, grupos de usuarios, transferencia de ficheros resulta imposible explicar cada uno de los casos. Es por ello que me centraré para este proyecto en la parte relacionada con la gestión del buzón de correo de Exchange Server 2007. Página 5

Página 6

2 Documento de Objetivos de Proyecto 2.1 Objetivos Mejorar la seguridad en la resolución de incidencias de los agentes del CAU mediante una aplicación, AdminTool. Permitiéndoles actuar en el dominio del cliente sin necesidad de conectarse directamente al servidor y sin utilizar una cuenta de usuario con privilegios de administrador. Garantizando así una mayor seguridad en el dominio del cliente y, en concreto, en el Directorio Activo al ser limitadas las opciones que los agentes del CAU pueden realizar mediante dicha aplicación. Crear o actualizar diferentes módulos de la aplicación en función de las tecnologías que han ido surgiendo desde el inicio del desarrollo de AdminTool. a. Creación de un módulo gestor para la gestión del buzón de correo de los usuarios en el servidor Exchange 2007. b. Actualizar el gestor de usuarios. c. Crear un gestor de rutas alternativo al Directorio Activo. d. Creación de un módulo gestor para la transferencia de ficheros entre equipos de un mismo dominio. Con el fin de facilitar las auditorias internas, todas las acciones que se lleven a cabo deben quedar registradas en un fichero indicando los parámetros oportunos según los requisitos exigidos por la entidad. Adaptar la aplicación a las necesidades de las entidades cliente donde será utilizado AdminTool. Revisar y corregir los fallos ya existentes en la aplicación. En la medida de lo posible mejorar la velocidad de funcionamiento de la aplicación. Página 7

2.2 Método de trabajo Para llevar a cabo el desarrollo de la aplicación se seguirá el Proceso Unificado de Desarrollo. Éste constará de varias fases en función del módulo gestor a realizar/actualizar. Fases: Fase 1: Gestor de usuarios. Fase 2: Gestor de directorios. Fase 3: Gestor de buzones (Exchange 2007). Fase 4: Gestor de la configuración del entorno. Fase 5: Gestor de transferencia de ficheros. Debido a que el desarrollo de la aplicación se realiza sobre un equipo remoto dentro del dominio de la entidad bancaria, que en algunos casos es compartido con el propio CAU, se debe coordinar con ellos el acceso al equipo remoto. Además, se coordinará con el departamento de sistemas de la entidad en cuestión y con su CAU las características que deberá incorporar o no AdminTool. En la fase de pruebas éstas serán realizadas en un primer momento por el desarrollador en su equipo remoto. Posteriormente AdminTool será instalado en uno de los equipos que el CAU dispone para resolver las incidencias en fase de pruebas. Donde un agente del CAU será el encargado de realizar las pruebas. Tras un breve periodo de tiempo, de haber fallos serán reportados y corregidos, para nuevamente realizar la fase de pruebas en dos tandas. Finalmente se eliminará la versión anterior de la aplicación, se implantará en el resto de equipos del CAU de la entidad en cuestión y se permitirá el uso a todos los agentes del CAU la nueva versión. Con el fin de averiguar el estado del desarrollo, aclarar dudas, identificar deficiencias y problemas que puedan surgir se realizarán reuniones puntuales con el tutor del proyecto, los agentes del CAU implicados y los responsables de la entidad bancaria. Página 8

2.3 Alcance 2.3.1 Diagrama EDT 2.3.2 Entregas Documento de Objetivos del Proyecto (DOP): 12/04/2010 Captura de requerimientos Análisis Diseño Primera iteración + pruebas Segunda iteración + pruebas Tercera iteración + pruebas Cuarta iteración + pruebas Quinta iteración + pruebas + Memoria Defensa del Proyecto de Fin de Carrera Página 9

2.3.3 Asignación de recursos Fase 1: DOP Fase 2: Captura de requerimientos Fase 3: Análisis Fase 4: Diseño Fase 5: Primera iteración + pruebas Fase 6: Segunda iteración + pruebas Fase 7: Tercera iteración + pruebas Fase 8: Cuarta iteración + pruebas Fase 9: Quinta iteración + pruebas + memoria Fase 10: Defensa del Proyecto de Fin de Carrera 2.4 Planificación temporal Se calcula por experiencias previas que para el desarrollo del proyecto se destinarán alrededor de 640 horas/persona. Teniendo en cuenta días festivos y diferencia de horario de trabajo entre el viernes (6,5 horas) y el resta de días laborales (8,5 horas) y tomando como aproximación 8 horas/día se puede hacer la suposición de que la duración será de 80 días. (640 horas/persona) / (80 días) = 8 horas/persona por día Fase 1: 1 día * 8 horas/persona por día = 8 horas/persona Fase 2: 5 días * 8 horas/persona por día = 40 horas/persona Fase 3: 5 días * 8 horas/persona por día = 40 horas/persona Fase 4: 6 días * 8 horas/persona por día = 48 horas/persona Fase 5: 12 días * 8 horas/persona por día = 96 horas/persona Fase 6: 10 días * 8 horas/persona por día = 80 horas/persona Fase 7: 18 días * 8 horas/persona por día = 144 horas/persona Fase 8: 5 días * 8 horas/persona por día = 40 horas/persona Fase 9: 15 días * 8 horas/persona por día = 120 horas/persona Fase 10: 3 días * 8 horas/persona por día = 24 horas/persona Total = 640 horas/persona Página 10

Fase 1: DOP 8 horas/persona Descripción Objetivos Método de trabajo Alcance Planificación temporal Plan de contingencia Factibilidad Reuniones Fase 2: Captura de requerimientos 40 horas/persona Modelos de uso Diagramas de casos de uso Casos de uso de alto nivel Casos de uso expandidos Modelo de dominio Glosario Diseño de pantallas Reuniones Fase 3: Análisis 40 horas/persona Diagramas de secuencia del sistema Contratos Reuniones Fase 4: Diseño 48 horas/persona Diagramas de interacción Diagramas de Clase Reuniones Fase 5: Primera iteración + pruebas + informe de situación 96 horas/persona Codificación Informe de situación Reuniones Página 11

Fase 6: Segunda iteración + pruebas + informe de situación 80 horas/persona Codificación Informe de situación Reuniones Fase 7: Tercera iteración + pruebas + informe de situación 144 horas/persona Codificación Informe de situación Reuniones Fase 8: Cuarta iteración + pruebas + informe de situación 40 horas/persona Codificación Informe de situación Reuniones Fase 9: Quinta iteración + Memoria 120 horas/persona Codificación Informe de situación Reuniones Fase 10: Defensa del Proyecto de Fin de Carrera 24 horas/persona Elaborar presentación Realizar ensayos Página 12

2.4.1 Diagrama de Gantt Página 13

2.4.2 Plan de contingencia Riesgos Gravedad Probabilidad Soluciones Pérdida del código fuente de la aplicación Alta 15,00% Copias de seguridad diarias en distintos equipos y en pendrive propio Problemas de electricidad Media 10,00% Avisar del fallo de suministro eléctrico Retraso de los plazos propuestos Ampliar la aplicación con nuevas funcionalidades Problemas durante el desarrollo Media 40,00% Realizar reunión para tratar la causa del retraso y ampliar la fecha de entrega propuesta Media/Alta 90,00% Estudiar si el coste de llevarlo a cabo es mayor que el beneficio obtenido. Decidir junto con el director del proyecto si realizar el desarrollo de la misma. Media/Alta 30,00% Comentar con el director del proyecto y el administrador del sistema implicado los problemas encontrados y buscar soluciones para subsanarlos. Fallo de hardware Baja 2,00% Avisar al servicio técnico para que revisen el hardware y reparen el fallo Fallo conexión de red/internet Alta 0,50% Revisar configuración de la interfaz de red. Si el error persiste hablar con el departamento de sistemas implicado y con comunicaciones. Fallo de software Media/Alta 15,00% Avisar al servicio técnico para que lleven a cabo la reparación/reinstalación pertinente. Virus Alta 25,00% Utilización de cortafuegos y antivirus Utilización del mismo equipo remoto Baja 90,00% Utilización del mismo usuario para evitar cerrar automáticamente las aplicaciones abiertas. Al usar otro usuario de sesión avisar para poder guardar y cerrar correctamente los programas abiertos. Página 14

Fallo teléfono Media 5,00% Avisar al servicio técnico. Fallo buzón de correo Media/Alta 0,50% Avisar al servicio técnico. Revisar espacio disponible. Privacidad Alta 0,50% Los equipos que se utilizarán para llevar a cabo el desarrollo del proyecto estarán protegidos por usuario y contraseña. Página 15

2.4.3 Factibilidad Teniendo en cuenta que se trata de un proyecto ya existente, que la cantidad aproximada de horas invertidas por persona es de 640 horas y que existe un plan de contingencias para el caso en el que surjan problemas durante el desarrollo, se puede considerar factible la realización de este proyecto de fin de carrera. Página 16

3 Desarrollo técnico 3.1 Captura de requisitos La ilustración 1 presenta los casos de uso del actor agente del CAU. El agente del CAU tendrá la posibilidad de llevar a cabo una serie de tareas específicas con el sistema, relacionadas con la gestión del buzón de los usuarios existentes en el Directorio Activo. Estas tareas tienen que ver con la creación y eliminación del buzón del usuario, redireccionar un buzón a otro usuario, gestionar la lista de contactos, gestionar las direcciones de correo de los usuarios, gestionar los protocolos que los usuarios pueden utilizar para acceder a su correo y gestionar las propiedades del buzón. Ilustración 1: Gestionar Buzón Página 19

3.1.1 Casos de uso Caso de uso: Gestionar Buzón Actores: Agente del CAU Resumen: Este caso de uso permite gestionar el buzón de correo de Exchange 2007 de los usuarios. Precondición: La aplicación AdminTool tiene permisos para crear, leer, modificar y eliminar ficheros, así como, para ejecutar los correspondientes scripts en función del caso de uso seleccionado. El usuario existe. Postcondición: Escenario principal (o curso normal de los acontecimientos) 1. Agente del CAU: El agente quiere gestionar un buzón de un usuario. 2. Sistema: El sistema muestra los casos de uso que extienden al caso de uso gestionar buzón. 3. Agente del CAU: Selecciona el caso de uso que desea. 4. Sistema: Extiende el caso de uso seleccionado. Página 20

Caso de uso: Crear Buzón Actores: Agente del CAU Resumen: Este caso de uso tiene su inicio cuando el agente del CAU está dentro del caso de uso obtener datos usuario y quiere habilitar el buzón de correo de un usuario. Precondición: La aplicación AdminTool dispone de los permisos necesarios para ejecutar los scripts.. El usuario existe y se muestran sus datos en una ventana y el buzón de correo está deshabilitado. Postcondición: Escenario principal (o curso normal de los acontecimientos) 1. Agente del CAU: Busca el usuario al que quiere habilitar su buzón de correo. 2. Sistema: Comprueba si el usuario existe, obtiene sus datos y checkea si el buzón del usuario existe colocando el botón en el estado correspondiente. 3. Agente del CAU: El agente pulsa el botón habilitar buzón. 4. Sistema: Habilita el buzón de correo para el usuario y muestra un mensaje informando del cambio. Extensiones (o cursos alternativos) Paso 2.A: El usuario no existe. 1.1. Sistema: Muestra por pantalla que el usuario no existe y aborta la operación de habilitar el buzón de correo. Paso 2.B: El buzón ya existe. 2.1. Sistema: Pone el botón en modo buzón habilitado. Paso 4: El sistema no puede habilitar el buzón de correo. 4.1. Sistema: Muestra por pantalla el error. Página 21

Caso de uso: Eliminar Buzón Actor: Agente del CAU Resumen: El agente quiere deshabilitar el buzón de correo de un usuario. Precondición: La aplicación AdminTool dispone de los permisos necesarios para ejecutar los scripts. El usuario existe y se muestran sus datos en una ventana y el buzón de correo está habilitado. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Pulsa el botón eliminar buzón. 2. Sistema: Pide confirmación para eliminar el buzón. 3. Agente del CAU: Confirma pulsando el botón aceptar. 4. Sistema: Procede a deshabilitar el buzón de correo del usuario. Extensiones (o curso alternativo) Paso 2: El agente del CAU no confirma la eliminación del buzón de correo del usuario. 1.1. Sistema: Aborta la eliminación del buzón de correo y vuelve a la pantalla donde se muestran los datos del usuari. Paso 4: Se produce un error al deshabilitar el buzón de correo. 4.1. Sistema: Muestra un mensaje por pantalla indicando el error. Página 22

Caso de uso: Crear Redirección Buzón Actores: Agente del CAU Resumen: Este caso de uso tiene su inicio cuando el agente del CAU está dentro del caso de uso obtener datos usuario y quiere redireccionar el buzón de un usuario a otro. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros y ejecutar los scripts necesarios. El usuario existe, el buzón del usuario existe y sus datos se muestran en una ventana. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Busca el usuario al que quiere crear la redirección su buzón de correo. 2. Sistema: Muestra los datos del usuario. 3. Agente del CAU: Pulsa el botón redireccionar buzón. 4. Sistema: Muestra el formulario para rellenar con el usuario destino. 5. Agente del CAU: Rellena los datos. 6. Sistema: Redirecciona el buzón del usuario de origen al usuario destino. Extensiones (o curso alternativo) Paso 2.A: El usuario no existe. 1.2. Sistema: Muestra por pantalla el error. Paso 2.B: El buzón no existe. 1.1. Sistema: Muestra por pantalla avisando del error. Paso 4: El usuario destino no existe. 4.1. Sistema: Muestra por pantalla el error y aborta redireccionar buzón. Paso 6: Error al redireccionar el buzón del usuario origen al usuario destino. 6.1. Sistema: Muestra por pantalla el error advirtiendo que no se ha podido llevar a cabo la operación. Página 23

Caso de uso: Eliminar Redirección Buzón Actores: Agente del CAU Resumen: Este caso de uso tiene su inicio cuando el agente del CAU está dentro del caso de uso obtener datos usuario y quiere quitarle la redirección del buzón de correo a un usuario. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros y ejecutar los scripts necesarios. El usuario existe, su buzón está habilitado y sus datos se muestran en una ventana. Postcondición: Escenario principal (o curso normal de los acontecimientos) 1. Agente del CAU: Busca el usuario al que quiere quitar la redirección de su buzón de correo. 2. Sistema: Muestra los datos del usuario. 3. Agente del CAU: Pulsa el botón verificar estado de la redirección. 4. Sistema: Obtiene el estado de la redirección. 5. Agente del CAU: El agente pulsa en el botón eliminar redirección. 6. Sistema: Quita la redirección del buzón de correo al usuario. Extensiones (o curso alternativo) Paso 2: El usuario no existe. 1.1. Sistema: Muestra por pantalla el error y aborta obtener los datos del usuario. Paso 4: No existe redirección. 1.1. Sistema: Activa el botón en modo crear redirección de buzón y activa los elementos visuales para mostrar que la redirección está deshabilitada. No se permite eliminar la redirección puesto que no existe. Se muestra que se puede crear. Paso 6: Error al quitar la redirección. 6.1. Sistema: Muestra por pantalla que la eliminación de la redirección ha fallado. Página 24

Caso de uso: Eliminar Dirección SMTP Actores: Agente del CAU Resumen: Este caso de uso tiene su inicio cuando el agente del CAU se encuentra dentro del caso de uso obtener datos usuario y quiere eliminar una de las direcciones de correo que tiene un usuario en su listado de direcciones. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros y ejecutar los scripts necesarios. El usuario existe, su buzón está habilitado y sus datos se muestran en una ventana. Postcondición: Escenario principal (o curso normal de los acontecimientos) 1. Agente del CAU: Busca el usuario al que quiere eliminar una dirección de correo. 2. Sistema: Muestra los datos del usuario. 3. Agente del CAU: Pulsa el botón obtener direcciones SMTP. 4. Sistema: Muestra las direcciones SMTP asociadas a ese usuario. 5. Agente del CAU: Selecciona la que quiere eliminar. 6. Sistema: Elimina la dirección SMTP del usuario. Extensiones (o curso alternativo) Paso 6: No se puede eliminar la dirección seleccionada. 6.1. Sistema: Muestra por pantalla un error advirtiendo de que no se ha podido eliminar la dirección SMTP seleccionada por el Agente del CAU. Página 25

Caso de uso: Obtener Direcciones SMTP Actor: Agente del CAU. Resumen: El agente del CAU quiere obtener las direcciones SMTP asociadas a un usuario determinado. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros y ejecutar los scripts necesarios. El usuario existe y sus datos se muestran en una ventana. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Pulsa el botón obtener direcciones SMTP. 2. Sistema: Muestra por pantalla el listado de las direcciones de correo asociadas a ese usuario. Página 26

Caso de uso: Crear Dirección SMTP Actor: Agente del CAU. Resumen: El agente del CAU quiere añadir una dirección de correo alternativa a la oficial en el servidor de correo Exchange 2007. Precondición: AdminTool tiene permisos para crear, modificar y eliminar ficheros en el equipo en el que se encuentra, así como, para ejecutar los scripts correspondientes. El usuario existe y sus datos son mostrados en una ventana. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Quiere añadirle a un usuario una dirección de correo distinta a la oficial. Pulsa en obtener direcciones SMTP. 2. Sistema: Muestra las direcciones SMTP asociadas a ese usuario. 3. Agente del CAU: Pulsa el botón crear para añadir una nueva dirección. 4. Sistema: Le muestra al agente del CAU un formulario donde introducir la dirección. 5. Agente del CAU: Introduce la dirección y pulsa aceptar. 6. Sistema: Añade la dirección SMTP a la lista de direcciones que tiene el usuario en el Servidor de correo Exchange 2007. Extensiones (o curso alternativo) Paso 6: La dirección SMTP ya existe. 6.1. Sistema: Muestra por pantalla un error advirtiendo que la dirección que se quiere añadir ya existe en el listado de direcciones. Página 27

Caso de uso: Crear Contacto Actor: Agente del CAU Resumen: : Este caso de uso tiene su inicio cuando el agente del CAU está dentro del caso de uso gestionar buzón.el agente del CAU quiere crear un nuevo contacto en el servidor de correo. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros, así como, para ejecutar los scripts necesarios. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Pulsa el botón para crear un nuevo contacto. 2. Sistema: Le muestra al agente el formulario para que éste lo rellene. 3. Agente del CAU: Introduce la dirección y acepta. 4. Sistema: Añade el contacto a la lista de contactos del servidor de correo. Extensiones (o curso alternativo) Paso 4.A: Falla al añadir el nuevo contacto. 4.1. Sistema: Muestra por pantalla del error indicando el motivo. Paso 4.B: El contacto ya existe. 4.1. Sistema: Muestra por pantalla que el contacto ya existe. Página 28

Caso de uso: Eliminar Contacto Actor: Agente del CAU Resumen: Este caso de uso tiene su inicio cuando el agente del CAU está dentro del caso de uso gestionar buzón. El agente quiere eliminar un contacto del servidor de correo. Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros, así como, para ejecutar los scripts necesarios. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Selecciona la opción eliminar contacto. 2. Sistema: Muestra todos los contactos disponibles para su eliminación. 3. Agente del CAU: Selecciona una entrada y pulsa el botón eliminar. 4. Sistema: Elimina de la lista de contactos del servidor de correo el contacto seleccionado. Extensiones (o curso alternativo de los eventos) Paso 4: Error al eliminar el contacto. 4.1. Sistema: Muestra por pantalla un error indicando el motivo. Página 29

Caso de uso: GestionarPropiedadesBuzón Actor: Agente del CAU Resumen: El agente del CAU quiere gestionar las propiedades de un buzón de un usuario (políticas, límites del tamaño de los buzones, cuotas, visibilidad...). Precondición: La aplicación tiene permisos para crear, modificar, eliminar ficheros, así como, para ejecutar los scripts necesarios. Además, el usuario existe y se muestran sus datos en una ventana. Postcondición: Escenario principal (o curso normal de los eventos) 1. Agente del CAU: Realiza los cambios en las políticas, límites del tamaño de los mensajes, visibilidad en la lista de correos y cuotas del buzón que cree necesarias. 2. Sistema: establece los protocolos del buzón, las restricciones en los mensajes, el límite de almacenamiento y establece la visibilidad en la lista de correo. Extensiones (o curso alternativo de los eventos) Paso 2: Error al establecer los protocolos del buzón. 2.1. Sistema: Muestra un error por pantalla indicando el motivo del fallo. Paso2: Error al establecer las restricciones en los mensajes. 2.1. Sistema: Muestra un error por pantalla indicando el motivo del fallo. Paso2: Error al establecer el límite de almacenamiento. 2.1 Sistema: Muestra un error por pantalla indicando el motivo del fallo. Paso 2: Error al establecer el límite de almacenamiento. 2.1 Sistema: Muestra un error por pantalla indicando el motivo del fallo. Paso 2: Error al establecer la visibilidad en la lista de correo. 2.1 Sistema: Muestra un error por pantalla indicando el motivo del fallo. Página 30

Caso de uso: Modificar Permisos Buzón Actores: Agente del CAU Resumen: Este caso de uso tiene su inicio en GestionarBuzón cuando el agente del CAU quiere modificar los permisos de un determinado usuario sobre un buzón de correo. Precondición: La aplicación AdminTool tiene permisos para gestionar los buzones de correo de los usuarios de Exchange Server 2007. El agente del CAU tiene permisos para ejecutar AdminTool. Postcondición: Escenario principal ( o curso normal de los eventos) 2. Agente del CAU: El agente del CAU quiere modificar los permisos de un usuario sobre un buzón de correo. 3. Sistema: Muestra por la pantalla con el formulario a rellenar por el agente del CAU. 4. Agente del CAU: El agente rellena el formulario. 5. Sistema: Modifica los permisos del usuario sobre el buzón de correo. Extensiones ( o cursos alternativos) Paso 3.1: El agente del CAU no rellena completamente el formulario. 1. Sistema: Muestra por pantalla el error avisando de que debe rellenar o seleccionar los campos obligatorios. Paso 3.2: El usuario introducido por el agente del CAU no existe. 1. Sistema: Muestra un error por pantalla advirtiendo al agente del CAU de la no existencia del usuario que ha introducido. Vuelve al formulario para que el agente rellene los datos de nuevo. Página 31

3.1.2 Modelo de dominio Este es un modelo de dominio aproximado, ya que el modelo real, el del Directorio Activo, es muy amplio y con muchos atributos. Así pues, aquí se recogen algunos de los atributos más habituales y básicos. Ilustración 2: Modelo de dominio aproximado Ilustración 3: Clases más utilizadas (aproximación) En la ilustración 3 podemos ver una aproximación del tipo de atributos que utilizan las clases almacenadas en el Directorio Activo. A través de la ilustración 2 podemos ver de una manera aproximada cuál es la relación existente entre cada una de las clases. De esta manera observamos que un usuario que pertenece al Directorio Activo tiene un puesto de trabajo, así como su Página 32

correspondiente carpeta de usuario y su buzón de correo. Además, puede pertenecer a distintos grupos de usuarios. Cada grupode usuarios tiene su propia configuración. Es decir, un grupo puede permitirle al usuario acceder de manera remota a un puesto de trabajo, otro grupo le puede permitir gestionar las carpetas de usuarios, otro grupo acceder a una parte de la red que de otra forma no podría, etc. La carpeta del usuario es identifacada por el nombre de usuario del propio usuario. Además, hay que tener en cuenta que a cada carpeta de usuario únicamente el propio usuario y algunos grupos de usuarios tienen permisos, como son, administradores, cau, system. El puesto identifica las máquinas a las que el usuario tiene acceso. En principio únicamente hay un buzón de correo por usuario. En la descripción aproximada de la clase podemos observar una serie de atributos a modo de ejemplo. Página 33

3.2 Análisis Caso de Uso: Gestionar Buzón Diagrama de Secuencia de Sistema: Página 34

Caso de uso: Crear Buzón Diagrama de Secuencia de Sistema Contratos: Nombre: existeusuario(idusuario):existe Responsabilidad: Operación encargada de comprobar en el sistema si el usuario con identificador idusuario existe en el Directorio Activo. Precondición: true Postcondición: Salida: Un valor booleano que será true si el usuario existe y false en otro caso. Nombre: mostrarservidores():listaservidoresexchange2007 Responsabilidad: Operación encargada de obtener el listado de servidores de correo para los buzones de los usuarios Exchange 2007. Precodición: true Postcondición: Salida: Listado con los servidores Exchange 2007 disponibles. Nombre: mostrarservidorescorreo(servidor):listabasesdatosservidorexch Responsabilidad: Operación encargada de obtener un listado de las bases de datos disponibles del servidor Exchange 2007 que se le pasa como parámetro. Precondición: Postcondición: Salida: Listado con las bases de datos disponibles en el servidor. Página 35

Nombre: crearbuzon(idusuario, servidor, basedatos) Responsabilidad: Operación encargada de dar de alta el buzón del usuario en el servidor y base de datos seleccionados. Precondición: El usuario existe y se ha seleccionado el servidor y la base de datos. Postcondición: Se crea el buzón del usuario con los requisitos establecidos por sistemas. Salida: Nombre: existebuzon(idusuario):existe Responsabilidad: Operación encargada de comprobar si el buzón del usuario con identificador idusuario existe. Precondición: El usuario existe en el Directorio Activo. Postcondición: Salida: Un valor booleano que indica con true que el buzón del usuario existe y con false que no existe. Página 36

Caso de uso: Eliminar Buzon Diagrama de Secuencia de Sistema: Contratos: Nombre: eliminarbuzon(idusuario) Responsabilidad: Operación encargada de eliminar del servidor de correo Exchange 2007 el buzón de un usuario con identificador idusuario. Precondición: El usuario existe en el Directorio Activo. Postcondición: Salida: Página 37

Caso de uso: Crear Redirección Buzón Diagrama de Secuencia de Sistema: Contratos: Nombre: crearredireccionbuzon(idusuario1,idusuario2) Responsabilidad: Operación encargada de redireccionar los correos entrantes del buzón del usuario idusuario1, al buzón del usuario idusuario2. Precondición: Los usuarios idusuario1 e idusuario2 existen en el Directorio Activo y ambos tienen buzones de correo. Postcondición: El buzón de idusuario1 está redireccionado a idusuario2. Salida: Nombre: existeredirecciónbuzon(idusuario):existe Responsabilidad: Operación encargada de comprobar la existencia de la redirección del buzón de correo del usuario idusuario. Precondición: El usuario existe en el Directorio Activo. Postcondición: Salida: Un valor booleano que indica con true que existe redirección y con false que no hay redirección. Página 38

Caso de uso: Eliminar Redirección Buzón Diagrama de Secuencia de Sistema: Contratos: Nombre: eliminarredirecciónbuzón(idusuario) Responsabilidad: Operación encargada de eliminar la redirección del buzón de correo que tiene el usuario idusuario. Precondición: El usuario al que se quiere quitar la redirección existe en el Directorio Activo y tiene su buzón de correo redireccionado a otro usuario. Postcondición: El buzón del usuario deja de estar redireccionado. Salida: Página 39

Caso de uso: Crear Dirección SMTP Diagrama de Secuencia de Sistema: Contratos: Nombre: creardireccionsmtp(idusuario, @SMTP) Responsabilidad: Operación encargada de almacenar una nueva dirección de correo en la lista de direcciones de correo del usuario idusuario. Precondición: El usuario existe en el Directorio Activo. Postcondición: La dirección forma parta de la lista de direcciones de correo del usuario. Salida: Nombre: obtenerdireccionessmtp(idusuario):lista@smtp Responsabilidad: Operación encargada de obtener todas las direcciones de correo del usuario. Precondición: El usuario existe en el Directorio Activo. Postcondición: Salida: Una lista con todas las direcciones de correo del usuario. Página 40

Caso de Uso: Eliminar Dirección SMTP Diagrama de Secuencia de Sistema Contratos: Nombre: eliminardirecciónsmtp(idusuario, @SMTP) Responsabilidad: Operación encargada de eliminar del listado de direcciones de correo del usuario idusuario la dirección que se envía como parámetro @SMTP. Precondición: El usuario existe en el Directorio Activo. Postcondición: La dirección de correo @SMTP es eliminada de la lista de direcciones de correo del usuario. Página 41

Caso de uso: Crear Contacto Diagrama de Secuencia de Sistema Contratos: Nombre: existecontacto(nombrevisible, @SMTP):existe Responsabilidad: Operación encargada de verificar si el contacto que se queire crear existe o no. Precondición: true Postcondición: Salida: Devuelve un valor boleano indicando si existe el contacto (true) o no existe (false). Nombre: crearcontacto(nombre, apellidos, nombrevisible, @SMTP, ubicación) Responsabilidad: Operación encargada de añadir al Directorio Activo un nuevo contacto. Precondición: El contacto no existe en el Directorio Activo. Postcondición: El contacto es añadido a la lista de contactos del Directorio Activo. Salida: Nombre: obtenercontactos():listacontactos Responsabilidad: Operación encargada de obtener todos los contactos del Directorio Activo. Precondición: Postcondición: Salida: Una lista con todos los contactos del Directorio Activo. Página 42

Caso de uso: Eliminar Contacto Diagrama de Secuencia de Sistema Contratos: Nombre: eliminarcontacto(contacto) Responsabilidad: Operación encargada de eliminar del Directorio Activo un contacto determinado. Precondición: El contacto existe en el Directorio Activo. Postcondición: El contacto seleccionado es eliminado de la lista de contactos. Salida: Página 43

Caso de uso: GestionarPropiedadesBuzón Diagrama de Secuencia de Sistema Contratos: Nombre: establecerprotocolosbuzón(listaprotocolos):boolean Responsabilidades: Operación encargada de realizar los cambios en los permisos de los protocolos del buzón de correo que el usuario puede utilizar. Precondición: El usuario existen en el Directorio Activo y tiene buzón de correo. Postcondición: Salida: Una variable booleana que indica si el proceso se ha llevado a cabo o no correctamente. Nombre:restriccionesMensajes(listaValores):boolean Responsabilidad: Operación encargada de llevar a cabo los cambios en la restricción del tamaño de los mensajes que se pueden enviar y recibir. Precondición: El usuario existe en el Directorio Activo y tiene buzón de correo. Postcondición: Salida: Una variable bolean que indica si el proceso se ha llevado a cabo o no correctamente. Nombre: límitealmacenamiento(listavalores):boolean Responsabilidad: Operación encargada de realizar los cambios en las cuotas de almacenamiento del Directorio Activo. Precondición: El usuario existe en el Directorio Activo y tiene buzón de correo. Página 44

Postcondición: Salida: una variable booleana que indica el estado final de la operación donde true indica que ha ido bien y false que ha ido mal. Nombre: ocultardireccionlistaexchange(valorbooleano):boolean Responsabilidad: Operación encargada de establecer la visibilidad de la dirección de correo del usuario en la lista de correo del servidor Exchange 2007. Precondición: El usuario existe y tiene un buzón de correo. Postcondición: Salida: Una variable booleana que indica si el proceso se ha llevado a cabo correctamente (true) o no (false). Página 45

Caso de uso: PermisosBuzón Diagrama de Secuencia de Sistema Contratos: Nombre: establecerpermisos(usuario1, usuario2, opción, estado) Responsabilidad: Operación encargada de modificar los permisos del usuario2 sobre el buzón de correo del usuario1. Precondición: Los dos usuarios existen y además, el usuario1 tiene un buzón de correo. Postcondición: Salida: Página 46

3.3 Arquitectura del sistema Antes de explicar cómo es la arquitectura de nuestro sistema vamos a explicar en detalle qué es el Directorio Activo y cuáles son sus componentes: El Directorio Activo o Active Directory (AD) es el término utilizado por Microsoft para referirse a su implementación de servicio de directorio en una red distribuida de computadores. Utiliza distintos protocolos (principalmente LDAP, DNS, DHCP, Kerberos...). Ilustración 4: Arquitectura del Directorio Activo Su estructura jerárquica permite mantener una serie de objetos relacionados con componentes de una red, como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso Ilustración 5 Su funcionamiento es similar a otras estructuras de LDAP (Lightweight Directory Access Protocol), ya que este protocolo viene implementado de forma similar a una base de datos, la cual almacena en forma centralizada toda la información relativa a un dominio de autenticación. La ventaja que Página 47

presenta esto es la sincronización presente entre los distintos servidores de autenticación de todo el dominio. Debido a esta centralización, se pueden crear varios objetos que afectarán a los recursos y los usuarios que acceden a la red. A su vez, cada uno de estos objetos tendrá atributos que permiten identificarlos en modo unívoco (por ejemplo, los usuarios tendrán campo «nombre», campo «email», etcétera, las impresoras de red tendrán campo «nombre», campo «fabricante», campo «modelo», campo "usuarios que pueden acceder", etc). Toda esta información queda almacenada en Active Directory replicándose de forma automática entre todos los servidores que controlan el acceso al dominio (Controladores de dominio o Domain Controlers). De esta forma, es posible crear recursos (como carpetas compartidas, impresoras de red, etc) y conceder acceso a estos recursos a usuarios, con la ventaja que estando todos estos objetos memorizados en Active Directory, y siendo esta lista de objetos replicada a todo el dominio de administración, los eventuales cambios serán visibles en todo el ámbito. Para decirlo en otras palabras, Active Directory es un repositorio centralizado que facilita el control, la administración y la consulta de todos los elementos lógicos de una red (como pueden ser usuarios, equipos y recursos). Como hemos dicho, toda la información almacenada en Active Directory es replicada a todos los controladores de dominio que son los que guardan el catálogo global (donde se almacena toda la información referente a los usuarios, grupos, puestos...). Para proveer alto rendimiento, disponibilidad y flexibilidad en ambientes distribuidos, el Directorio Activo utiliza un modelo de replicación Multi-Master. Este servicio permite a la organización crear múltiples copias del directorio conocidas como replicas, y colocarlas a lo ancho de la red. Los cambios hechos en cualquier lugar en la red se replicarán automáticamente a lo largo de la red, al contrario de los ambientes single-master, en la que los cambios solo se podían hacer en una réplica con autoridad de cambios en el directorio. Existen muchos casos en los que es interesante disponer de varios dominios de ordenadores Windows 2003 en la misma organización (distribución geográfica o departamental, distintas empresas, etc.). El Directorio Activo permite almacenar y organizar la información de directorio de varios dominios de forma que, aunque la administración de cada uno sea independiente, dicha información esté disponible para todos los dominios. Según los estándares de nombres DNS, los dominios de Active Directory se crean dentro de una estructura de árbol, con la raíz en la parte superior. Además, esta jerarquía de dominios de Windows 2003 se basa en relaciones de confianza, es decir, los dominios se vinculan por relaciones de confianza entre dominios. Cuando se instala el primer controlador de dominio en la organización se crea lo que se denomina el dominio raíz del bosque, el cual contiene la configuración y el esquema del bosque (compartido por todos los dominios de la organización). Más adelante, podemos agregar dominios como Página 48

subdominios de dicha raíz (árbol de dominios) o bien crear otros dominios "hermanos" de la raíz (bosque de dominios), debajo del cual podemos crear subdominios, y así sucesivamente. Árbol. Un árbol es un conjunto de uno o más dominios que comparten un espacio de nombres contiguo. Si exite más de un dominio, estos se disponen en estructuras de árbol jerárquicas. El primer dominio creado es el dominio raíz del primer árbol. Cuado se agrega un dominio a un árbol existente este pasa a ser un dominio secundario (o hijo). Un dominio inmediatamente por arriba de otro dominio en el mismo árbol de dominio es su padre. Todos los dominios quetengan un dominio raíz común se dice que forman un espacio de nombres contiguo. Los dominios secundarios (hijos) pueden representar entidades geográficas (Valencia, Madrid, Barcelona), entidades administradtivas dentro de la organización (departamenteo de ventas, departamento de desarrollo...), u otras delmiticaciones específicas de una organización, según sus necesidades. Los dominios que forman un árbol se enalazan mediante relaciones de confianza bidireccional y transitiva. La relación padre-hijo entre dominios de un árbol de dominio es símplemente una relación de confianza. Los administradores de un dominio padre no son automáticamente administradores del dominio hijo y el conjunto de políticas de un dominio padre no se aplican automáticamente a los dominios hijo. Bosque. Un bosque es un grupo de árboles que no comparten un espacio de nombers contiguo, conectados a través de relaciones de confianza bidireccionales y transitivas. Un dominio único constituye un árbol de un dominio, y un árbol único constituye un bosque de un árbol. Los árboles de un bosque aunque no forman un espacio de nombres común, es decir, están basados en diferentes nombres de dominio raiz de DNS, comparten una configuración, un esquema de directorio común y el denominado catálogo global. Es importante destacar que, aunque los diferentes árboles de un bosque no comparten el espacio de nombres, el bosque tiene un único dominio raíz, llamado el dominio raíz del bosque. Éste será el primer dominio creado en el bosque. Añadir nuevos dominios a unsque es fácil. Sin embargo, no se pueden mover dominios de Active Directory entre bosques. Solamente se podrán eliminar dominios de un bosque si éste no tiene dominios hijo. Además, después de haber establecido el dominio raíz de un árbol, no se pueden añadir dominios con un nombre de nivel superior al bosque. Tampoco se puede crear un dominio padre de un dominio existente. El implementar bosques y árboles de dominio permite mantener convenciones de nombres contiguos y discontiguos, lo cual puede ser útil en organizaciones con divisiones independientes que quieren mantener sus propios nombres DNS. Página 49

En resumen, cuando promocionamos un servidor Windows 2003 a controlador de dominio (mediante el asistente dcpromo, tenemos que decidir una de las siguientes opciones de instalación: DC adicional de un dominio existente o de un dominio nuevo (creación de un dominio) En el segundo caso, el dominio (nuevo) puede ser un dominio secundario de otro dominio existente (es decir, un subdominio de un árbol de dominios ya creado), o bien el dominio principal (raíz) de un nuevo árbol de dominios. En este caso, el dominio raíz puede ser de un bosque existente o de un nuevo bosque. 3.4 Relaciones de confianza Una relación de confianza es una relación establecida entre dos dominios de forma que permite a los usuarios de un dominio ser reconocidos por un controlador de dominio de otro dominio. Estas relaciones permiten a los usuarios acceder a los recursos de otro dominio y a los administradores definir los derechos de usuario para los usuarios del otro dominio. Todas las relaciones de confianza en un bosque basado en Windows 2003 son bidireccionales y transitivas: Bidireccionales: cuando se crea un nuevo dominio hijo, este automáticamente confía en el dominio padre y viceversa. Transitivas: si el dominio A y el dominio B (padre e hijo) confían el uno en el otro y además el dominio B y el dominio C (también padre e hijo) confían el uno en el otro, entonces el dominio A y el dominio C confían mutuamente el uno en el otro de forma implícita, aunque no exista una relación de confianza directa entre ellos. Hablando del bosque, podemos decir que una relación de confianza se crea automáticamente entre el dominio raíz del bosque y el dominio raíz de cada árbol de dominio añadido al bosque, lo que provoca que exista una confianza completa entre todos los dominios en un bosque de Active Directory. Desde un punto de vista práctico, un único proceso de inicio de sesión (logon) le permite al sistema autentificar a un usuario o máquina en cualquier dominio del bosque. Por tanto, este proceso permite potencialmente a las cuentas de usuario y máquina acceder a los recursos en cualquier dominio del bosque. Además de las confianzas transitivas y bidireccionales del bosque, que se generan automáticamente en el sistema operativo Windows 2003, se pueden crear explícitamente dos tipos diferentes de relaciones de confianza: Relación de confianza de acceso directo: una relación de confianza de acceso dirercto, también denominada relación de confianza de vínculo cruzado, es una relación de confianza Página 50

creada manualmente, que mejora la eficacia de los inicios de sesión remotos, acortando la ruta de confianza. Si los usuarios del dominio A necesitan frecuentemente tener acceso a los recursos del dominio C, se podría crear un vínculo directo mediante una relación de confianza de acceso directo, de forma que se omita el dominio B en la ruta de confianza. Una relación de confianza de acceso directo tiene las siguientes características. se puede establecer entre cualesquiera dos dominios del mismo bosque. debe establecerse manualmente en cada dirección. debe ser transitiva. Relación de confianza externa: una relación de confianza extgerna se crea manualmente entre dominios de Windows 2003 que pertenecen a bosques direferentes o entre un dominio de Windowss 2003 y un dominio cuyo controlador de dominio ejecuta Windows NT 4.0. Las relaciones de confianza extensas son unidireccionales e intransitivas, y deben establecerse manualmente en cada sentido para poder disponer de una relación de confianza externa bidireccional. 3.5 Unidades Organizativas Una Unidad Organizativa (Organizational Unit, OU) es un objeto del Directorio Activo que puede contener a otros objetos del directorio. Es decir, es un contenedor de otros objetos, de forma análoga a una carpeta o directorio en un sistema de archivos tradicional. En concreto, dentro de una unidad de este tipo pueden crearse cuentas de usuario, de grupo, de equipo, de recurso compartido, de impresora compartida, etc., además de otras unidades organizativas. Es decir, mediante unidades organizativas podemos crear una jerarquía de objetos en el directorio (lo cual se asemeja otra vez a un sistema de archivos típico de Windows). Los objetos ubicados dentro de una unidad organizativa pueden moverse más tarde a otra, si fuera necesario. Sin embargo, un objeto no puede copiarse: cada objeto es único en el directorio, y su existencia es independiente de la unidad organizativa a la que pertenece. Por tanto, el objetivo de las unidades organizativas es estructurar u organizar el conjunto de los objetos del directorio, agrupándolos de foma coherente. En el Directorio Activo, las unidades organizativas permiten: Conseguir una estructuración lógica de los objetos del directorio, de acuerdo con la organización de la empresa (por despartamentos o secciones, sedes, delegaciones geográficas, etc.). Entre otras ventajas, esta organización le permite al administrador del dominio una gestión más lógica de los usuarios, grupos, equipos, etc. Pero también le permite a cualquier usuario una búsqueda de los objetos más sencilla cuando explora el directorio buscando recursos (por ejemplo, se podría localizar fácilmente las impresoras compartidas del edificio central de la delegación de Alicante). Delegar la administración. Cada unidad organizativa puede administrarse de forma independiente. En concreto, se puede otorgar la administración total o parcial de una unidad Página 51

organizativa a un usuario o grupo de usuarios cualquiera. Esto permite delegar la administración de subconjuntos estancos del dominio a ciertos usuarios que posean el nivel de responsabilidad adecuada. Establecer de forma centralizada comportamientos distintos a usuarios y equipos. A cada unidad organizativa pueden vincularse políticas de grupo, que aplican comportamientos (generalmente en forma de restricciones) a los usuarios y equipos cuyas cuentas se ubican en dicha unidad. De esta forma, podemos aplicar restricciones distintas a subconjuntos de usuarios y equipos del dominio, en función exclusivamente de la unidad organizativa donde se ubican. Por ejemplo, podemos limitar a los usuarios del departamento de contabilidad para que sólo puedan usar ciertas aplicaciones, pero que esto no se aplique a los usuarios del departamento de informática. En muchos sentidos, el concepto de unidad organizativa se puede utilizar en Windows 2003 de la misma forma que se entendía el concepto de dominio en versiones anteriores de Windows NT, es decir, conjunto de usuarios, equipos y recursos administrados independientemente. En realidad, en Windows 2003 el concepto de dominio viene más bien asociado a la distribución de los sitios (topología de red) y a la implementación de DNS que exista (o quiera crearse) en la empresa. De este modo, en muchas organizaciones de pequeño o medio tamaño resulta más adecuado implementar un modelo de dominio único con múltiples unidades organizativas que un modelo de múltiples dominios. Si es necesario, cada unidad puede administrarse independientemente, con uno o varios administradores delegados y comportamientos (políticas) diferentes. 3.6 Estructura Física En Active Directory, la estructura lógica está separada de la estructura física. La estructura lógica se utiliza para organizar los recursos de red mientras que la estructura física se utiliza para configurar y administrar el tráfico de red. En concreto, la estructura física de Active Directory se compone de sitios y controladores de dominio. La estructura física de Active Directory define dónde y cuándo se producen el tráfico de replicación y de inicio de sesión. Una buena comprensión de los componentes físicos de Active Directory permite optimizar el tráfico de red y el proceso de inicio de sesión, así como solventar problemas de replicación. 3.7 Sitios Un sitio es una combinación de una o varias subredes IP que están conectadas por un vínculo de alta velocidad. Definir sitios permite configurar la topología de replicación y acceso a Active Directory de forma que Windows 2000 utilice los vínculos y programas más efectivos para el tráfico de inicio de sesión y replicación. Normalmente los sitios se crean por dos razones principalmente: Página 52

Para optimizar el tráfico de replicación. Para permitir que los usuarios se conecten a un controlador de dominio mediante una conexión confiable de alta velocidad. Es decir, los sitios definen la estructura física de la red, mientras que los dominios definen la estructura lógica de la organización. 3.8 Controladores de dominio Un controlador de dominio (Domain Controller, DC) es un equipo donde se ejecuta Windows 2003 Server y que almacena una replica del directorio. Los controladores de dominio ejecutan el servicio KDC, que es responsable de autenticar inicios de sesión de usuario. La información almacenada en cada controlador de dominio se divide en tres categorías (particiones): dominio, esquema y datos de configuración. Estas particiones del directorio son las unidades de replicación: Partición de directorio de dominio: contiene todos los objetos del directorio para este dominio. Los datos del dominio en cada dominio se replican a cada controlador de dominio en este dominio, pero no más allá del dominio. Partición del directorio de esquema: contiene todos los tipos de objetos y atributos que pueden ser creados en el Directorio Activo. Estos datos son comunes a todos los dominios del bosque. Por tanto, los datos del esquema se replican a todos los controladores del dominio del bosque. Partición de directorio de configuuración: contiene la topología de replicacióny los metadatos. Por ejemplo, aplicaciones compatibles con Active Directory almacenan información en esta partición del directorio. Estos datos son comunes a todos los dominios en el bosque, y se replican a todos los controlaores de dominio en el bosque. Además de estas tres particiones de directorio de escritura, existe una cuarta categoría de información almacenada en un controlador de dominio: el catálogo global. Un catálogo global es un controlador de dominio que almacena las particiones de directorio de escritura, así como copias parciales de sólo lectura de todas las demás particiones de directorio de dominio del bosque. 3.9 Funciones de los controladores de dominio Las versiones anteriores de Windows NT Server usaban múltiples controladores de dominio y sólo se permitía que uno de ellos actualizase la base de datos del directorio. Este esquema de maestro único exigía que todos los cambios se replicasen desde el controlador de dominio principal (Primary Domain Controller, PDC) a los controladores de dominio secundarios o de reserva (Backup Domain Controllers, BDCs). Página 53

En Windows 2000, todos los controladores de dominio admitían cambios, y estos cambios se replican a todos los controladores de dominio, lo mismo sucede ahora para Windows 2003. Las operaciones de administración de usuarios, grupos y equipos son operaciones típicas de múltiples maestros. Sin embargo no es práctico que algunos cambios se realicen en múltiples maestros debido al tráfico de replicación y a los posibles conflictos en las operaciones básicas. Por estas razones, las funciones especiales, como la de servidor de catálogo global y operaciones de maestro único, se asignan sólo a determinados controladores de dominio. A continuación veremos estas funciones. 3.10 Servidor de Catálogo Global El catálogo global es un depósito de información que contiene un subconjunto de atributos para todos los objetos de Active Directory (partición de directorio de dominio). Los atributos que se almacenan en el catálogo global son los que se utilizan con más frecuencia en las consultas. El catálogo global contiene la información necesaria para determinar la ubicación de cualquier objeto del directorio. Un servidor de catálogo global es un controlador de dominio que almacena una copia del catálogo y procesa las consultas al mismo. El primer controlador de dominio que se crea en Active Directory es un servidor de catálogo global. Se pueden configurar controladores de dominio adicionales para que sean servidores de catálogo global con el fin de equilibrar el tráfico de autenticación de inicios de sesión y la transferencia de consultas. El catálogo global cumple dos funciones importantes en el directorio: Permite que un usuario inicie una sesión en la red mediante el suministro de la información de pertenencia a grupos universales a un controlador de dominio cuando inicia un proceso de sesión. Permite que un usuario busque información de directorio en todo el bosque, independiente de la ubicación de los datos. Descritos todos los posibles componentes del directorio activo ya se puede entender un poco mejor el siguiente dibujo, que representa la estructura del directorio activo: Página 54

Ilustración 6 Después de esta explicación ya podemos explicar mejor la arquitectura de nuestro sistema: En la ilustración 7 se muestra cómo funciona la aplicación. La aplicación se ejecuta desde la máquina XP y es la aplicación la que se encarga de modificar los objetos del directorio activo que están en el catálogo global almacenado en el Controlador de dominio. Ilustración 7: Funcionamiento de la aplicación. Nos encontramos en un dominio único con Unidades Organizativas. Los servidores son Windows Server 2003 y los puestos son Windows XP. En la ilustración 8 se puede observar cómo está organizado nuestro dominio. Ilustración 8 Página 55

Página 56

4 Elección tecnológica Para realizar el desarrollo de AdminTool no hubo elección tecnológica, ésta vino impuesta por Ibermática. Como plataforma para desarrollar escogieron Microsoft Visual Basic 6.0 Enterprise Edition. Anticuada si tenemos en cuenta que desde hace ya unos años existe una plataforma más potente, Visual Studio.Net, cuya versión actual es Visual Studio 2010 con una mayor documentación a la hora de llevar a cabo ciertas partes de la aplicación. En cuanto al equipo a utilizar se trata de equipos con sistema operativo Windows XP o Server 2003. Para desarrollar la aplicación se utilizó un equipo con Windows Server 2003 mientras que el equipo de producción tiene instalado Windows XP. Página 57

Página 58

5 Diseño Caso de uso: Gestionar Buzón if opcion = Crear Buzon then show crearbuzon if opcion = Eliminar Buzon then show eliminarbuzon if opcion = Redireccionar Buzon then show crearredireccionbuzon if opcion = Eliminar Redireccion Buzon then show eliminarredireccionbuzon if opcion = Crear Direccion SMTP then show creardireccionsmtp if opcion = Eliminar Direccion SMTP then show eliminardireccionsmtp if opcion = Crear Contacto then show crearcontacto if opcion = Eliminar Contacto then show eliminarcontacto if opcion = Activar/Desactivar OWA then show OWA if opcion = Modificar Propiedades Buzon then show modificarpropiedadesbuzon Caso de uso: Crear Buzón If usuario existe = true then Crear Buzón para el usuario introducido Comprobar existencia del buzón else Indicar que el usuario no existe end if Página 59

Caso de uso: Eliminar Buzón If usuario existe = true then Eliminar buzón del usuario introducido Comprobar existencia del buzón else Indicar que el usuario no existe end if Caso de uso: Crear Redirección Buzón If usuario1 existe = true then if usuario2 existe = true then Crear redirección de buzón del usuario 1 al usuario 2 comprobar redirección del buzón else Indicar que el usuario2 no existe else Indicar que el usuario1 no existe end if Caso de uso: Eliminar Redirección Buzón If usuario existe = true then Eliminar redirección del buzón del usuario Comprobar redirección del buzón else Indicar que el usuario no existe end if Página 60

Caso de uso: Crear Dirección SMTP if usuario existe = true then Crear dirección smtp al usuario Obtener las direcciones smtp del usuario else Indicar que el usuario no existe end if Página 61

Caso de uso: Eliminar Dirección SMTP if usuario existe = true then Eliminar dirección smtp del usuario Obtener las direccioens smtp del usuario else Indicar que el usuario no existe end if Caso de uso: Crear Contacto if contacto existe = false then Crear el contacto con los datos introducidos Obtener los contactos else Indicar que el contacto ya existe end if Caso de uso: Eliminar Contacto if contacto existe = true then Eliminar el contacto seleccionado Obtener los contactos else Indicar que el contacto no existe end if Página 62

Caso de uso: Activar/Desactivar OWA if usuario existe = true then Comprobar estado OWA if OWA = Activado then Deshabilitar OWA else Habilitar OWA end if Comprobar estado OWA else Indicar que el usuario no existe end if Caso de uso: Modificar Propiedades del Buzón if usuario existe = true then Establecer protocolos buzón con los datos seleccionados Establecer restricciones de los mensajes con los datos introducidos Establecer límites de almacenamiento con los datos introducidos Establecer visibilidad del buzón del usuario en la lista de exchange según lo seleccionado else Indicar que el usuario no existe end if Página 63

6 Implementación Por motivos de privacidad de la empresa en la que he desarrollado este proyecto de fin de carrera no he podido adjuntar el código fuente completo de la aplicación. Es por ello que procederé a explicar puntos importantes de la implementación de Admintool, mostrando en algunos casos código fuente real para una mejor comprensión. La aplicación se ha implementado con Visual Basic y el entorno de desarrollo ha sido Visual Studio 6.0 profesional. 1. La interfaz de usuario: Con formularios de Visual Basic Ilustración 12: Interfaz de usuario de Admintool Página 65

2. La capa de negocio (que hace consultas contra la base de datos): Con módulos de código. Ilustración 13: Gestores de la capa de negocio. 6.1 Modelo de desarrollo Como base para llevar a cabo la implementación he usado el patrón Modelo Vista Controlador. Aunque al usar Visual Basic esas fronteras tan claras marcadas por dicha arquitectura de software son difusas al estar el controlador y la vista juntas. De esta manera obtenemos dos capas, por un lado la capa de presentación junto con la capa de negocio, y por otro lado la capa de datos. La principal ventaja de una arquitectura de software basado en capas es que en caso de tener que realizar cambios en la aplicación, estos sólo se deben realizar en la capa correspondiente a ese cambio. Aunque, como he dicho, en este caso se complica un poco más realizarlos al utilizar únicamente dos capas en vez de tres. A continuación explicaré brevemente en qué se basa el Modelo Vista Controlador y qué es eso de la programación por capas. Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El estilo de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página html y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Bases de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. Descripción del patrón Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las Página 66

presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista. Muchos sistemas informaticos utilizan un Sistema de Gestión de Bases de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí. Wikipedia: http://es.wikipedia.org/wiki/modelo_vista_controlador La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. Ilustración 14: Programación por capas La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraido del resto de niveles, de forma que basta con conocer la api que existe entre niveles. Página 67

Capas 1.- Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. 2.- Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. 3.- Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Wikipedia: http://es.wikipedia.org/wiki/programación_por_capas Tratándose ésta de una aplicación que hace uso del Directorio Activo necesitamos de un conector que nos permita comunicarnos. Microsoft desarrolló para ello WMI, cuyas siglas significan Windows Management Instrumental (Instrumentación de Administración de Windows). En otras palabras, se trata de una API para sistemas operativos Windows con el fin de controlar, monitorizar y administrar equipos de manera local o en red. Para una mayor definición de qué es se puede consultar la siguiente página web: http://msdn.microsoft.com/en-us/library/aa394582(vs.85).aspx Página 68

6.2 Gestión de Exchange 2007 (método y atributos) Para controlar el servidor Exchange 2007 en un principio pensé en Powershell para gestionarlo. Pues fue así como lo hicieron en su momento para poder gestionar los buzones de los usuarios en el Exchange 2003. Pero la utilización de Powershell implica una serie de peros. A continuación expondré algunas de estas pegas: Debido a que hay que ejecutarlo en una linea de comandos, cada vez que se ejecuta un script en powershell aparece la ventana negra de la terminal. Al ser ejecutado el script en una terminal no se puede acceder directamente a los resultados. Hay que utilizar para ello un fichero intermedio en el cuál se guardará la información de salida del script. Con el fin de poder tratar dicha información desde la aplicación y averiguar si el comando se ha llevado a cabo correctamente o no. Pero esto añade lentitud, ya que en algunos casos para verificar si se ha realizado la operación hay que esperar en torno a los 30 segundos. Un tiempo de espera demasiado elevado si tenemos en cuenta que la aplicación es utilizada por un centro de atención al usuario, donde prima la rapidez de actuación. Además, teniendo en cuenta que una misma aplicación puede ser utilizada por varios agentes del CAU, dicho fichero no puede tener el mismo nombre. Es por esto que al iniciar Admintool se genera un número aleatorio que se utilizará como nombre del fichero temporal. Cuando se cierre la aplicación el fichero será eliminado. Como ya he dicho, para averiguar si un script se ha ejecutado correctamente hay que esperar una cierta cantidad de tiempo que suele resultar aleatoria. No siempre tarda lo mismo la creación de un buzón de correo para un usuario o la redirección de un buzón a otro. Es decir, no siempre se puede garantizar la verificación de las operaciones que se han llevado a cabo. Por esta razón es posible que un verificación que da error, en el fondo sí se haya llevado a cabo, pero por el tiempo de espera utilizado no se le ha dado tiempo al servidor Exchange 2007 a enterarse de los cambios e incluso, a replicar su información con los controladores de dominio. Siendo este un problema muy común en varios entornos de producción, donde el tiempo de replicación entre diferentes sites está entre los 10 y los 15 minutos. Existe un peligro potencial de manipulación de los scripts de powershell. Ya que estos, al estar en texto plano pueden ser manipulados con gran facilidad para ejecutar órdenes que no estaban escritas inicialmente. Por ejemplo, supongamos el caso en el que un agente del CAU descontento con su situación laboral decide vengarse borrando todos los buzones de los usuarios de la entidad para la cuál actúa como agente. En este caso le bastaría coger un script -supongamos el de la creación del buzón de correo de un usuario- cambiar el contenido del script y guardarlo. Después iniciaría la aplicación Admintool e iría a la creación de buzones. En este caso le Página 69

bastaría seleccionar el servidor de correo y poner un usuario existente en el Directorio Activo. A continuación, se ejecutaría el script con permisos de administrador y se eliminarían todos los buzones de correo de dicha entidad. En otras palabras, los scripts en powershell son en potencia un fallo de seguridad grave y añaden lentitud a la aplicación. Justamente todo lo contrario de lo que se pretende obtener con el desarrollo de Admintool. Es por ello que investigué una forma alternativa y más segura de llevar a cabo la gestión del Exchange 2007. En un primer momento no encontré información para hacer esta gestión en las páginas propias de Microsoft, como son, technet.com, msdn.com, microsoft.com y más páginas propias de ellos. Google tampoco arrojó información útil al respecto. Decidí entonces averiguar qué atributos del Directorio Activo son los que se utilizan para las distintas operaciones y con qué valores. El método de trabajo es el siguiente. 1. Con la ayuda de los ADSITools genero un listado de todos los atributos que contienen valores en el Directorio Activo para un usuario X. 2. Utilizando la propia interfaz de gestión de Exchange 2007 creo al usuario X un buzón de correo. 3. Vuelvo a generar con los ADSITools el listado con los atributos del DA utilizados y sus valores. De esta manera y haciendo multiples pruebas pude encontrar los atributos que son utilizados para crear un buzón de correo, redireccionar el buzón de un usuario a otro, ocultar a un usuario de la lista de correos del servidor, gestionar las quotas del buzón, etc. Así pues, para gestionar las propiedades de los buzones de correo obtuve lo siguiente: Ilustración 15: Gestionar propiedades del buzón del usuario. Página 70

6.2.1 Crear buzón de correo Antes de nada, debemos crear el buzón del usuario. El cuál nos permitirá realizar las modificaciones pertinentes tanto en los protocolos de acceso por parte del usuario, como en los tamaños de los mensajes que puede enviar y recibir, así como en los límites de almacenamiento y si queremos que aparezca en la lista de correo del servidor. Para ello debemos utilizar los atributos indicados en al tabla XXX con sus respectivos valores. Aunque existe un problema al crear de esta manera el buzón de correo, no se genera el identificador único msexchmailboxguid. Lo cuál es un problema grave, ya que es el encargado de identificar el usuario con su buzón y con la base de datos de recuperación. Lo cuál nos deja únicamente una opción para crear el buzón, utilizar Powershell. No es tan elegante como hacerlo tratando directamente con los atributos del Directorio Activo, haciendo que la operación sea totalmente transparente. Pero hay casos en los que es inevitable, como lo es este. ATRIBUTO VALOR DESCRIPCIÓN mailnickname DavidSalinas Alias que se utiliza para el usuario (string). mdbusedefaults True Utilizar valores por defecto de la base de datos. homemdb homemta legacyexchangedn msexchhomeserverna me CN=DB1,CN=SG1,CN=InformationStore,CN= Exchange1,CN=Servers,CN=AG1,CN=Admini strative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC =contoso,dc=com CN=Microsoft MTA,CN=Exchange1,CN=Servers,CN=AG1,C N=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC =contoso,dc=com CN=Headquarters,CN=Administrative Groups,CN=Corp1,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC =corp,dc=mycompany,dc=com /o=organization/ou=ag1/cn=configuration /cn=servers/cn=exchange1 Esta propiedad especifica la ruta hacia el almacén del buzón. Provee compatibilidad hacia atrás con servidores Exchange antiguos. msexchmailboxguid Binario o Hexadecimal o Decimal Identificador único para cada buzón de Página 71

msexchrecipientdispla ytype MsExchRecipientTypeD etails MsExchUserAccountCo ntrol textencodedoraddress msexchversion 1073741824 1 0 c=us;a= ;p=cie;o=exchange;s=salinas;g=david; xxxxxx msexchpoliciesincluded {7A11B2E3-E30C-493D-AAFC- CE35D99E01F3},{26491CFC-9E50-4857- 861B-0CB8DF22B5D7} msexchpoliciesexclude d showinaddressbook {26491cfc-9e50-4857-861b-0cb8df22b5d7} CN=All Contacts,CN=All Address Lists,CN=Address Lists Container,CN=CIE,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC =cie,dc=lan CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=CIE,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC =cie,dc=lan correo que identifica el buzón con su usuario y con el sistema de recuperación. Para activar la política de las direcciones de correo. Para desactivar la politica de las direcciones de correo. Configuración de la aparición de la dirección de correo en la lista de correos. targetaddress SMTP:davidsalinas@gmail.com Dirección de correo que se utilizará como principal. proxyaddresses mapirecipient SMTP:davidsalinas@gmail.com smtp:pruebas-admintool@empresa.com X400:C=us;A= ;P=Empresa;O=Exchange;S=Salinas;G=David; False Contiene todas las direcciones de correo del usuario. Página 72

6.2.2 Protocolos del buzón de correo PROTOCOLO ATRIBUTO DA ACTIVAR DESACTIVAR 1. Outlook Web Acces 2. Exchange Active protocolsettings Eliminar HTTP 0 1 OWA 0 3. MAPI protocolsettings Eliminar MAPI 0 4. POP3 protocolsettings Eliminar POP3 0 1 4 ISO-8859-1 0 5. IMAP4 protocolsettings Eliminar IMAP4 0 1 4 ISO-8859-1 0 1 0 0 Añadir HTTP 0 1 OWA 0 Añadir MAPI 0 Añadir POP3 0 1 4 ISO-8859-1 0 Añadir IMAP4 0 1 4 ISO-8859-1 0 1 0 0 El atributo protocolsettings es un campo multi-valued string. Es decir, es un array de strings. Si el atributo no contiene valores Exchange 2007 entiende que todos los protocolos están activados con sus valores por defecto. De esta manera solamente añadiremos al atributo aquellos protocolos que queramos deshabilitar añadiendo como parte del array el valor indicado en la tabla. En el caso del protocolo Exchange Active no he logrado averiguar qué valor debe tener. 6.2.3 Restricciones del tamaño de los mensajes RESTRICCIONES TAMAÑO MENSAJES 6. Tamaño máximo mensajes (envío) 7. Tamaño máximo mensajes (recepción) ATRIBUTO DA ACTIVAR DESACTIVAR submissioncontlength Añadir al atributo un valor numérico que en KiloBytes indique el tamaño máximo del mensaje que se puede enviar. delivcontlength Añadir al atributo un valor numérico que en KiloBytes indique el tamaño máximo del mensaje que se puede enviar. Eliminar el valor numérico del atributo. Eliminar el valor numérico del atributo. Página 73

Para activar, tanto el límite del tamaño máximo del mensaje que se puede recibir, como el límite del tamaño máximo del mensaje que se puede enviar, basta con añadir al atributo correspondiente un valor numérico que indique en KiloBytes dicho límite. En el caso en el que estos atributos no contengan valor alguno (atributos no definidos <Not Set>), entonces Exchange 2007 entiende que estos límites están configurados por defecto. 6.2.4 Límites de almacenamiento del buzón (cuotas) LÍMITES ALMADENAMIENTO 7. Valores predeterminados del buzón de correo 9. Advertir al llegar a un límite 10. Prohibir envío al llegar al límite 11. Prohibir envío y recepción al llegar al límite ATRIBUTO DA ACTIVAR DESACTIVAR mdbusedefaults True False mdbstoragequota Añadir al atributo un valor numérico que en KiloBytes indique el tamaño máximo del mensaje que se puede enviar. mdboverquotalimit Añadir al atributo un valor numérico que en KiloBytes indique el tamaño máximo del mensaje que se puede enviar. mdboverhardquotalimit Añadir al atributo un valor numérico que en KiloBytes indique el tamaño máximo del mensaje que se puede enviar. Eliminar el valor numérico del atributo. Eliminar el valor numérico del atributo. Eliminar el valor numérico del atributo. Cuando el atributo mdbusedefaults (ver tabla XXX) está activado (valor True) predomina sobre el resto de atributos de la tabla XXX. Aun conteniendo valores el resto de atributos. En el caso en el que mdbusedefaults esté desactivado (False) Exchange 2007 hará uso de los otros atributos, que en el caso de no estar defnidos (<Not Set>) tomarán sus valores por defecto. Página 74

6.2.5 Ocultar usuario de la lista de correo del servidor OCULTAR CONTACTO ATRIBUTO DA ACTIVAR DESACTIVAR 12. No mostrar en la lista de direcciones msexchhidefromaddresslists True False Cuando se crea un buzón de correo por defecto se muestra el contacto en la lista de direcciones. Si no se quiere mostrar dicha dirección en la lista basta con añadir el valor True al atributo. Cuando queramos volver a mostrarlo en la lista de direcciones cambiaremos el valor True por False. 6.2.6 Añadir contacto Para la creación de un contacto hay que usar una serie de atributos comunes a la creación de un usuario en el Directorio Activo. A continuación expondré los atributos característicos de los contactos. Los valores mostrados son los valores que por defecto asignó Exchange 2007. ATRIBUTO VALOR DESCRIPCIÓN countrycode 0 InstanceType 4 internetencoding 1310720 legacyexchangedn msexchpoliciesincluded /o=cie/ou=first Administrative Group/cn=Recipients/cn=Pruebas-Admintool {7A11B2E3-E30C-493D-AAFC- CE35D99E01F3}, {26491CFC-9E50-4857-861B- 0CB8DF22B5D7} msexchpoliciesexcluded {26491cfc-9e50-4857-861b-0cb8df22b5d7} msexchrecipientdisplay Type showinaddressbook 6 CN=All Contacts,CN=All Address Lists,CN=Address Lists Container,CN=CIE,CN=Microsoft Exchange,CN=Services,CN=Configuration,D C=cie,DC=lan CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Actualiza las direcciones de correo según la política establecida. Desactiva la política para permitir cambiar las direcciones de correo. Permite gestionar el control de la visibilidad del contacto que creamos. Página 75

Container,CN=CIE,CN=Microsoft Exchange,CN=Services,CN=Configuration,D C=cie,DC=lan textencodedoraddress c=us;a= ;p=cie;o=exchange;s=salinas;g=david; targetaddress SMTP:davidsalinas@gmail.com Campo obligatorio. Establece como dirección de destino la establecida aquí. proxyaddresses mapirecipient SMTP:davidsalinas@gmail.com X400:C=us;A=;P=CIE;O=Exchange;S=Salin as;g=david; False Listado con todas las direcciones de correo pertenecientes al contacto. Al crear un contacto este no debe tener las direcciones de correo propias de la entidad. Es por ello que a la hora de crearlo hay que deshabilitar la política que controla que los contactos tengan estas direcciones. Para ello se añade al atributo msexchpoliciesexcluded el valor indicado en la tabla XXX. Una vez desactivada la política procedemos a añadir las direcciones de correo -la propia del contacto y la X400- al atributo proxyaddresses. Dicho atributo es multi-valued String. 6.2.7 Redireccionar buzón de correo A la hora de redireccionar un buzón de correo de un usuario a otro, hay que tener en cuenta que ambos usuarios deben existir en el Directorio Activo y que ambos deben tener buzón de correo. De no ser así, no se podrá realizar la redirección. Ilustración 16: Redireccionar buzón a otro usuario. Página 76

Para este caso los atributos a utilizar son los siguientes: ATRIBUTO VALOR DESCRIPCIÓN altrecipient UsuarioDestino.distinguishedName forwardingaddress usuariodestino.samaccountname Es la cuenta a la que se reenviará el correo. deliverandredirect True/False Determina si el correo debe de ser recibido por el buzón del usuario ausente y también enviado al buzón del usuario destino. Si se pone a False, únicamente se enviará el correo al buzón del usuario al que se ha redireccionado el buzón. msexchreciplimit Valor numérico Establece el número máximo de usuarios a los que reenviar el correo. Para dejarlo por defecto basta borrar el contenido del atributo. 6.2.8 Realizar consultas en el Directorio Activo Antes de proceder a explicar cómo manipular atributos del Directorio Activo es necesario que explique cómo obtener, por ejemplo, un usuario para después poder trabajar con él como si de un objeto se tratase. La siguiente función es utilizada para, dado un identificador de usuario, obtener dicho usuario en el Directorio Activo y devolver un objeto usuario con el que poder trabajar. Function GetUser(ByVal user) Dim objswbemlocator: Set objswbemlocator = CreateObject("WbemScripting.SWbemLocator") Dim objwmiservice: Set objwmiservice = objswbemlocator.connectserver(inicio.strcomputer, "root\directory\ldap", Inicio.USUARIO_AUTH, Inicio.PASSWORD_AUTH) Dim colitems: Set colitems = objwmiservice.execquery("select * FROM ds_user WHERE ds_samaccountname= '" & user & "'", "WQL", wbemflagreturnimmediately + wbemflagforwardonly) Dim objitem, user_adsipath For Each objitem In colitems user_adsipath = objitem.adsipath Next Dim objdso: Set objdso = GetObject("LDAP:") Página 77

Dim objuser: Set objuser = objdso.opendsobject(user_adsipath, Inicio.USUARIO_AUTH, Inicio.PASSWORD_AUTH, ADS_SECURE_AUTHENTICATION) Set GetUser = objuser End Function Primero debemos crear el objeto SwbemLocator que nos permitirá conectar con un controlador de dominio y acceder al LDAP (Lightweight Directory Access Protocol, Protocolo Ligero de Acceso a Directorios). El LDAP es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar información en él. A la hora de conectarnos al controlador de dominio y con el fin de tener permisos de administración a la función ConnectServer le pasamos como parámetros y en este orden los siguientes: El servidor que actúa como controlador de dominio. El servicio al que conectarnos. El usuario con privilegios de administrador. La contraseña del usuario que hemos introducido. Una vez establecida la conexión es el momento de ejecutar la consulta que queremos realizar. Es importante saber que aunque para la creación de usuarios y de contactos hemos utilizado las clases User y Contact respectivamente, a la hora de hacer las consultas debemos anteponer ds_ a esas clases. De manera que para hacer una consulta en la clase User la tabla pasará a llamarse ds_user y ds_contact para los contactos. Hay que decir también que en esta clase de consultas no se puede utilizar la cláusula ORDER BY. Únicamente admite consultas simples. 6.2.9 Trabajar con atributos del Directorio Activo Ahora que ya hemos visto algunos atributos y que sabemos cómo realizar consultas al Directorio Activo puedo proceder a explicar una de las maneras mediante la cuál podemos gestionar un usuario, un contacto, etc. Por ejemplo, en el caso de querer activar el protocolo POP3 del buzón de un usuario tendremos que eliminar dicho valor del atributo protocolsettings de la siguiente manera: Dim objuser : Set objuser = GetUser(pUsuario) objuser.putex ADS_PROPERTY_DELETE, "protocolsettings", Array("POP3 0 1 4 ISO-8859-1 0 ") En este caso, al tratarse el atributo protocolsettings de un multi-valued string, debemos utilizar el procedimiento PutEx tanto para añadir un nuevo valor al array, como para borrar un valor existente. En el caso en el que quisiéramos deshabilitar el protocolo POP3 tendríamos que añadir el string al atributo protocolsettings de la siguiente manera. Página 78

Dim objuser : Set objuser = GetUser(pUsuario) objuser.putex ADS_PROPERTY_APPEND, "protocolsettings", Array( POP3 0 1 4 ISO-8859-1 0 ) Si quisieramos añadir varios valores al array podríamos ponerlos todos seguidos separados por comas de la siguiente manera. Dim objuser : Set objuser = GetUser(pUsuario) objuser.putex ADS_PROPERTY_APPEND, "protocolsettings", Array( valor1, valor2, valor3 ) Para el caso en el que sea un valor numérico o un string (ninguno arrays) haremos la modificación del atributo de la siguiente manera. Para añadir al atributo department el departamento al que pertenece el usuario: objuser.put "department", Departamento de Ventas En el caso en el que queramos borrar el departamento al que pertenece deberemos introducir un string que contenga un espacio. objuser.put "department", Para todos los casos, una vez queramos almacenar los datos deberemos ejecutar el procedimiento SetInfo del objeto usuario. objuser.setinfo Para los atributos multi-valued además hay que tener en cuenta que es posible utilizar las siguientes opciones: ADS_PROPERTY_CLEAR = 1 ADS_PROPERTY_UPDATE = 2 ADS_PROPERTY_APPEND = 3 ADS_PROPERTY_DELETE = 4 Podemos declararlas como constantes al inicio del módulo, fuera de toda función y procedimiento y así utilizar el nombre de dicha constante en vez del número de la opción escogida para pasárselo como parámetro al procedimiento. 6.2.10 Ejemplos A continuación expongo a modo de ejemplo código utilizado por el Admintool para mostrar u ocultar un usuario de la lista de correo del Exchange 2007 y gestionar el límite de almacenamiento del buzón. Mostrar u ocultar un usuario de la list de correo de Exchange 2007: Página 79

Function ocultardireccionlistaexchange(byval pusuario, ByVal pckocultar) On Error GoTo tratarerror Inicio.LogEvent EVENT_INFORMATION, vbtab & "Estableciendo visibilidad de la dirección en la lista de direcciones del Exchange del buzón (" & pusuario & ")." Dim objuser : Set objuser = GetUser(pUsuario) If pckocultar = 1 Then objuser.put "msexchhidefromaddresslists", True Else objuser.put "msexchhidefromaddresslists", False End If objuser.setinfo ocultardireccionlistaexchange = True Exit Function tratarerror: Inicio.LogEvent EVENT_ERROR, vbtab & "ERROR: La actualización de no mostrar la dirección de correo en la lista de direcciones de Exchange ha fallado (" & pusuario & ")." ocultardireccionlistaexchange = False End Function Página 80

Establecer el límite de almacenamiento del buzón de un usuario: Function limitealmacenamiento(byval pusuario, ByVal pckquotadefault, ByVal pckquotaissue, ptbquotaissue, ByVal pckquotasend, ByVal ptbquotasend, ByVal pckquotasendreceive, ByVal ptbquotasendreceive) On Error GoTo tratarerror Inicio.LogEvent EVENT_INFORMATION, vbtab & "Estableciendo límites de las cuotas del buzón (" & pusuario & ")." Dim objuser : Set objuser = GetUser(pUsuario) If pckquotadefault = 1 Then objuser.put "mdbusedefaults", True objuser.setinfo Else objuser.put "mdbusedefaults", False objuser.setinfo If pckquotaissue = 1 Then objuser.put "mdbstoragequota", ptbquotaissue Else objuser.putex ADS_PROPERTY_CLEAR, "mdbstoragequota", 0 End If objuser.setinfo If pckquotasend = 1 Then objuser.put "mdboverquotalimit", ptbquotasend Else 'MsgBox "CKquotaSend = 0", 0, "pruebas" objuser.putex ADS_PROPERTY_CLEAR, "mdboverquotalimit", 0 End If objuser.setinfo If pckquotasendreceive = 1 Then objuser.put "mdboverhardquotalimit", ptbquotasendreceive Else objuser.putex ADS_PROPERTY_CLEAR, "mdboverhardquotalimit", 0 End If objuser.setinfo End If limitealmacenamiento = True Exit Function tratarerror: Inicio.LogEvent EVENT_ERROR, vbtab & "ERROR: La actualización de los límites de los de las cuotas ha fallado (" & pusuario & ")." limitealmacenamiento = False End Function Página 81

Página 82

7 Pruebas Una de las fases más importantes de todo proyecto es la fase de pruebas que se suele encontrar en último lugar en el ciclo de vida en cascada. Es una de las fases donde más tiempo se suele invertir, ya que es donde se verifica el correcto funcionamiento de la aplicación y de no ser así se pulen esos errores. Lo ideal sería realizar pruebas exhaustivas con toda la combinatoria posible de acciones. A la hora de la verdad resulta imposible hacer eso. Es por ello que se establecen una serie de pruebas de manera que si la aplicación es capaz de pasarlas se entiende que está preparada para pasar a producción. Aun así, lo más seguro es que vuelvan a aparecer nuevos errores. Es por ello que una vez se hayan hecho las pruebas por el propio desarrollador y corregido los errores obtenidos, se implantará en el sistema de producción donde un agente del CAU se encargará de llevar a cabo pruebas por su cuenta. El objetivo es que este agente utilice la aplicación como será usada en producción. 7.1.1 Pruebas unitarias Las pruebas unitarias tratan de probar el correcto funcionamiento de un módulo de código. De esta manera garantizamos que cada uno de los módulos es capaz de funcionar correctamente por separado. Se trata así pues de aisalar cada una de las partes de la aplicación y garantizar que cada una de ellas es correcta. A continuación se muestra la lista de pruebas unitarias que se han llevado a cabo para comprobar el correcto funcionamiento de los módulos de la aplicación. 1. Alta Buzón Dejar campos obligatorios en blanco. Crear buzón con identificador de usuario inexistente. 2. Eliminar Buzón Dejar campos obligatorios en blanco. Eliminar buzón con identificador de usuario inexistente. 3. Crear Redirección Buzón Dejar campos obligatorios en blanco. Crear redirección con identificador de usuario dueño de buzón inexistente. Crear redirección con identificador de usuario de buzón destinto inexistente. Crear redirección con ambos identificadores de usuario inexistentes. Crear redirección con alguno de los usuarios o ambos sin buzón de correo. Página 83

4. Eliminar Redirección Buzón Dejar en blanco el campo de identificador de usuario. 5. Obtener Direcciones SMTP Dejar en blanco el campo de identificador de usuario. 6. Crear Dirección SMTP Dejar en blanco alguno o todos los campos obligatorios. Introducir un usuario inexistente. 7. Eliminar Dirección SMTP Dejar el campo de identificador de usuario en blanco. Introducir un identificador de usuario inexistente. 8. Crear Contacto Dejar alguno o todos los campos obligatorios en blanco. Introducir los datos de un contacto ya existente. 9. Eliminar Contacto No seleccionar contacto alguno (dejar en blanco el contacto). Introducir contacto inexistente. Seleccionar contacto con símbolos extraños. 10. Gestionar Propiedades Buzón Seleccionar opciones por defecto. Restaurar opciones por defecto. Habilitar protocolos. Deshabilitar protocolos. Seleccionar opción por defecto de las restricciones del tamaño de los mensajes. Introducir valores en las opciones de las restricciones del tamaño de los mensajes. Por separado y todos juntos. Seleccionar opción por defecto de los límites de almacenamiento. Introducir valores en las opciones de los límites de almacenamiento. Por separado y todos juntos. Mostrar información relevante del buzón para el usuario. Habilitar no mostrar en la lista de direcciones de Exchange. Deshabilitar no mostrar en la lista de direcciones de Exchange. Introducir/cambiar el identificador de usuario por uno no existente. Borrar/dejar en blanco el identificador de usuario. Página 84

11. Modificar Permisos Buzón Introducir alguno o ambos identificadores de usuario inexistentes. Introducir alguno o ambos identificadores de usuario sin tener buzón de correo. Dejar en blanco alguno o ambos campos de identificadores de usuario. No seleccionar ninguna opción para asignar permisos. Seleccionar opción de asignación de permisos pero no seleccionar tipo (permitir revocar). Introducir todos los campos requeridos correctamente. 7.1.2 Pruebas de integración Aunque previamente hayamos demostrado que los módulos funcionan correctamente a través de las pruebas unitarias, no es descabellado pensar que al hacerlos trabajar conjuntamente puedan surgir nuevos fallos. Por esta razón realizamos este tipo de pruebas para asegurarnos que los módulos que estén relacionados funcionen correctamente. Un ejemplo de pruebas de integración que se ha realizado puede ser el módulo GestorBuzon que contiene los módulos crearbuzón, RedireccionarBuzón, etc. Para comprobar la correcta integración de GestorBuzon se han realizado pruebas de integración. 7.1.3 Pruebas de validación Se trata de pruebas que realiza el cliente. Son pruebas que se realizan sobre todo el sistema completo con el fin de determinar si se satisface los requisitos iniciales. De esta manera el cliente comprueba en su propio entorno de explotación si lo acepta como está o no. Para llevar a cabo estas pruebas, un agente del CAU se encargó de hacer las pruebas en el entorno de producción y realizar un informe sobre la adecuación o no de los requisitos iniciales con lo desarrollado. 7.1.4 Pruebas del sistema Como último paso se estableció un periodo de pruebas en real dentro del Centro de Atención a Usuarios, en paralelo al anterior sistema de gestión, para comprobar que el sistema era fiable y cumplía las expectativas. Página 85

7.2 Plan de Implantación Para la creación de un puesto exclusivo para la administración del CAU, principalmente hay que tener dos apartados en cuenta: Seguridad y Utilidad. 7.2.1 Seguridad En el apartado de seguridad, lo primero que hay que tener en cuenta es qué permisos va a tener el usuario que va a utilizar el CAU para la consola. Lógicamente será un usuario sin privilegios de administrador, creando un usuario que únicamente será usuario de dominio. Por otra parte, el CAU gestionará diferentes diferentes operaciones a nivel de Directorio Activo (altas, bajas,...), por lo que en ciertas ubicaciones habrá que asignarle permisos específicos. Para ello se creará un grupo para la asignación de dichos permisos con el fin de asignarlos una única vez. De esta manera evitamos asignar usuario por usuario los permisos, los aplicamos al grupo y añadimos los usuarios que vaya a utilziar el CAU al grupo. A continuación se exponen los permisos que debe tener el grupo para las distintas ubicaciones en el Directorio Activo. Permisos especiales en COMPUTERS: Este objeto y todos los secundarios. Ficha objeto: Crear equipo objetos. Eliminar equipos objetos. Ficha propiedades. Nada. Equipo objeto. Ficha objeto: Mostrar contenido. Leer todas las propiedades. Escribir todas las propiedades. Permisos de lectura. Todas las escrituras validas. Escritura valida en el host DNS. Escritura valida en el nombre principal del servicio. Ficha Propiedades. Todos. Permisos especiales en USUARIOS: Este objeto y todos los secundarios. Ficha objeto: Crear equipo objetos. Página 86

Eliminar equipos objetos. Ficha propiedades. Nada. Usuario objeto. Ficha objeto: Mostrar contenido. Leer todas las propiedades. Escribir todas las propiedades. Permisos de lectura. Modificar permisos. Ficha propiedades: Todos. Usuario objeto: Ficha objeto: Restablecer contraseña. Ficha propiedades: Nada. Permisos especiales en GRUPOS: Este objeto y todos los secundarios. Ficha objeto: Crear equipo objetos. Eliminar equipos objetos. Ficha propiedades: Nada. Equipo objeto. Ficha objeto: Mostrar contenido. Leer todas las propiedades. Escribir todas las propiedades. Permisos de lectura. Todas las escrituras validas. Agregarse o quitarse como miembro. Ficha propiedades. Todos. Una vez dado los permisos, para realizar ciertas tareas vamos a necesitar lanzar scripts que tienen que establecer una conexión WMI desde la consola del CAU a diferentes servidores, y para ello deberemos añadir al grupo como grupos permitidos para establecer dichas conexiones. Los permisos lo realizaremos de la siguiente manera: 1. MiPC Click derecho: Administrar 2. Aplicaciones y Servicios: Control WMI click derecho: En la pestaña de seguridad: propiedades: root-directory-ldap Página 87

Seleccionamos LDAP y pinchamos en seguridad. Aquí agregamos al usuario con permisos de: Enable account y Remote Account. Por último, hay que conceder permisos al grupo en los servidores de datos, que es donde se almacenan las carpetas personales de los usuarios. Para ello, y puesto que existen muchos recursos personales se ha ejecutado un script para la concesión de dichos permisos. 7.2.2 Utilidad En el apartado de utilidad, lo primero que hay que tener en cuenta es para qué va ha utilizar el CAU la consola. Hay que definir muy bien qué operaciones realiza, qué aplicaciones utiliza y de qué manera realizan las diferentes tareas de administración. Para ello, como primer paso hay que obtener informacióndirecta de los agentes del CAU (ya sea mediante una reunión,... ) para que expliquen con detalle todas las tareas que realizan. Se valorará qué aplicaciones requeire la consola del CAU para que realicen dichas tareas y se analizarán las diferentes posibilidades de instalación. Una vez tenga la lista de tareas que realiza el CAU se empezará a configurar el puesto. La consola puede ser un C o un servidor, no requiere de características especiales, cuanta más memoria, más velocidad de procesamiento, más espacio en disco, menos problemas habrá en el futuro. Una vez seleccionada la máquina física, instalaremos las diferentes aplicaciones. Sistemas operativo: Instalaremos Windows XP Professional con el Service Pack 3. Añadiremos el puesto o servidor al dominio. Crearemos un perfil para el usuario. Configuraremos una tarea de reinicio semanal. Herramientas administrativas: Instalaremos las herramientas adminsitrativas, puesto que la aplicación lo requiere para realizar diferentes tareas de administración del Directorio Activo. La aplicación propiamente dicha: Instaremos la aplicación básica para que los usuarios del CAU lo utilicen en caso de querer realiar operaciones relacionadas al Directorio Activo, tales como altas de usuario, bajas de usuario, etc. Winconnect Los usuarios del CAU trabajan en remoto mediante Terminal Server conectándose a la consola. Dicha consola al tener como sistema operativo Windows XP, únicamente puede acceder una persona, puesto que es una limitación del sistema operativo. Instalaremos la aplicación Winconnect para ampliar el acceso remoto a los usuarios del CAU que lo utilicen según la licencia que se compre. A día de hoy la licencia es para cuatro usuarios simultáneos. Una vez isntalada la aplicación, habrá que añadir al usuario al grupo Remote Desktop Users para que puedan acceder por Terminal Server. Por último se añadirá en las propiedades del usuario, en la pestaña de cuenta (Account), en el botón Log on Página 88

to... el nombre o la dirección ip que tiene en el Directorio Activo la consola del CAU. Página 89

8 Gestión del proyecto 8.1 Incidencias relevantes Durante la realización del proyecto me he encontrado con problemas, estos son algunos de ellos: El primer problema fue no disponer de documentación alguna para estudiar tanto el código fuente de la aplicación, como el qué tenía que hacer en cada caso el programa. Perdí bastante tiempo investigando su funcionamiento interno y en algunos momentos eché de menos algún comentario en el propio código que explicase para qué servía. El hecho de depender de equipos remotos sobre los que hacer el desarrollo hace que en algunos casos se pierda mucho tiempo por cuestiones de protocolo y seguridad, pudiendo llegar a estar hasta tres semanas con el proyecto detenido por no tener un equipo sobre el que desarrollar. Algunas entidades bancarias tienen un protocolo de seguridad tan fuerte, que incluso aunque reporten fallos detectados en sus versiones en temas de permisos de directorios (anteriores a mi llegada) no son capaces de decir qué permisos han de tener dichos directorios. Con lo que el fallo continua existiendo. Continuando con la política de seguridad, para trabajar con el directorio activo he necesitado conocer los campos de las tablas, en concreto la tabla de usuarios sobre la cual he tenido que realizar consultas para obtener datos. Para ello he utilizado los ADSItools, los cuales en una entidad me fue denegada su instalación por resultar peligroso al acceder al directorio activo. El departamento de sistemas está siempre tan atareado que en el momento en el que les hacía llegar alguna petición urgente para obtener información sobre el directorio activo, permisos y rutas imprescindible para la continuación de la aplicación, dicha respuesta podía llegar a tardar varios días, con la consecuente pérdida de tiempo. Tuve que invertir bastante tiempo en aprender powershell para poder realizar los scripts necesarios para controlar la creación, deshabilitación del buzón de los usuarios, así como, otras opciones relacionadas con el servidor de correo Exchange 2007. Imprimiendo varios manuales y libros propios de Microsoft legalmente sobre el tema para aprender a programar los scripts. Finalmente descubrí que se podía controlar ciertas partes de Exchange Server 2007 a través del Directorio Activo, aunque ya fue tarde para realizar el cambio. Página 90

8.2 Gantt planificado VS Gantt real Ilustración 16: Gantt planificado Ilustración 17: Gantt Real Página 91