Migración de certificados SHA-1 a SHA-2

Los certificados electrónicos permiten asegurar y acreditar webs, aplicaciones y servicios informáticos. Gracias a ellos, muchas de las transacciones electrónicas que realizamos a diario son seguras . Para la creación de dicho, se emplea una fórmula matemática o hash que determina su huella electrónica. Es por ello, que es muy importante que este código sea robusto y resistente frente a ataques que puedan vulnerarlo y suplantarlo.

Desde 1995 el algoritmo más empleado para la generaciónde certificados era el SHA-1. Dicha firma se consideraba inquebrantable con la tecnología vigente, pero hace un tiempo se comprobó que no era tan inexpugnable . Esto, junto con la bajada de los precios en el cloud computing  (que permite emplear  grandes recursos computacionales para el cálculo de combinaciones) ha agilizado la obsolencia de esta firma; y, empresas como Microsoft y Google, han establecido una serie de plazos para realizar la migración a SHA-2. Así pues,  esta semana me gustaría explicar cómo poder migrar nuestro certificado SHA-1 a SHA-2.

Antes de realizar ninguna acción debemos comprobar que  la infraestructura, servicios o aplicaciones afectadas por este cambio sean compatibles con SHA-2.  Una  vez verificada esta premisa, podríamos generar el certificado. La mayoría de las entidades certificadoras (symantect, digicert, etc) nos van a permitir generar uno nuevo SHA-2 sin coste adicional.

Creación del certificado SHA-2

Para realizar la solicitud de dicho de manera sencilla utilizaremos la librería criptográfica OpenSSL.  Esta herramienta es propia de las distribuciones de Linux, si queremos emplearla desde Windows tendremos que usar algún software como por ejemplo Win32_SSL.

Generación del archivo CSR

Desde una consola de Windows nos ubicamos en el directorio donde se encuentre la instalación de OpenSSL y generamos la solicitud csr , creando una clave de 2048.

image

El fichero csr que se generará será  similar al de la imagen inferior, el cual copiaremos integramente e introduciremos en la página de la CA correspondiente a nuestro certificado.

image

Una vez realizada la solicitud, la entidad certificadora se encargará de generar el crt correspondiente.

Exportación de crt

Descargaremos el archivo crt  generado por la CA a nuestro equipo . Con la clave anteriormente generada (clave.key) y el fichero .crt podremos exportar nuestro certificado a  formato pfx, empleando también la consola de OpenSSL; e indicando a continuación una contraseña para el archivo. Así:

image

Una vez exportado ya podremos instalarlo en nuestros sistemas.

Como cuestiones a tener en cuenta: debemos identificar los sistemas dependientes de los certificados y prestar especial atención a la generación del fichero crt por parte de la CA, ya que una vez generado, el antiguo certificado SHA-1 quedará revocado, y, los sistemas en los que esté instalado podrían dejar de funcionar.  Y con este pequeño apunte me despido. ¡Hasta la próxima!

Webinar: Azure Websites on OpenSource

Actualización (9/9/2015): ¿Te perdiste el evento? ¡Puedes ver la grabación en el mismo enlace de inscripción! Tras rellenar el formulario podrás acceder a la grabación del evento.

La semana que viene estaremos Roberto González y servidor impartiendo un webinar de Microsoft sobre el OpenSource en Azure Websites (ahora Azure AppService). Os dejamos los datos del evento:

  • Título: Azure Websites on OpenSource
  • Idioma: Inglés
  • Abstract: Azure is the most open, broad and flexible cloud platform for every customers needs, regardless of the application, framework, data source or operating system their solution may require. Whether you’re interested in various Linux flavors, Docker, MongoDB, Hadoop or languages like Java, Python, PHP and Ruby, you will find first-class support for all. This is the second webinar of a series around OpenSource on Azure, and it will provide an insight of Azure Websites. Azure Websites is a fully managed Platform-as-a-Service (PaaS) that enables you to build, deploy and scale enterprise-grade web apps in seconds. Most importantly, it speaks your language – be it ASP.NET, Java, PHP, Node.js or Python. You can also run your favorite web apps and CMS solutions including, but not restricted to WordPress, Drupal and Joomla.
  • Fecha: martes 1 de septiembre de 2015
  • Hora: 10:00 a 11:30 CET
  • Ponentes:
    • Carlos Milán Figueredo – Enterprise Team Lead
    • Roberto González Gómez – Software Development Engineer

– REGISTRO GRATUITO –

¡Os esperamos!

Envio de correo desde FIM (Conector de WebServices)

Hola a todos, hoy vamos a tratar un tema radicalmente distinto a mi habitual post de PowerShell. En este caso, vamos a hablar del conector de Web Services para FIM, y cómo se puede añadir un flujo para que envíe correo. En primer lugar, y a grosso modo, hablemos de FIM:

 Brevísima introducción a FIM

Forefront Identity Manager, FIM para los amigos,  es un gestor de Identidad. Su última versión ha sido renombrada como Microsoft Identity Manager (MIM), que en el futuro recibirá nuevos artículos en este blog. La parte más importante del producto es el Synchronization Service (FIM Sync), aunque también dispone de una funcionalidad llamada FIM Portal (basado en Sharepoint) que ayuda a simplificar algunas tareas de gestión. Su función consiste en sincronizar la identidad de los usuarios a través de muy diversos entornos. Dicho así suena a que es algo muy fácil, pero en realidad, la gestión de identidad puede suponer un dolor de cabeza muy serio en cuanto tenemos más de una única fuente de datos en la que se encuentre la identidad de los usuarios.

Vamos por partes: Entendemos por identidad como la esencia que identifica de forma inequívoca a una persona. En el caso de Active Directory, la identidad de una persona coincide con su cuenta de usuario. Pero ¿Qué sucede si lo que se tiene de esa persona es una tabla en una base de datos de Recursos Humanos? En muchos casos, lo que se hace es enviar un correo electrónico con los datos de dicha persona (su identidad) al administrador de Active Directory, quien procede al alta de dicha persona. En ocasiones, se ha automatizado el proceso, de forma que dar de alta a una persona en la BBDD de Recursos Humanos automáticamente crea una cuenta en Active Directory.

Ahora bien, ¿Qué sucede si con el paso del tiempo, el usuario notifica al administrador de Active Directory que ha cambiado su domicilio, pero no lo notifica a Recursos Humanos? O bien el administrador se encarga de decirle al responsable de RRHH que hay que cambiar el domicilio, o bien… siempre cabe la posibilidad de que el domicilio se quede sin cambiar.
La situación se complica, si además hay que gestionar la identidad del usuario en más de uno o dos sistemas diferentes. Máxime si uno de los sistemas es además un sistema personalizado propio y exclusivo de la empresa.

Forefront Identity Manager entra para poner un poco de orden en todo este caos de identidad. FIM, como herramienta, posee una base de datos llamada “Metaverso”, en la que va a guardar metadatos de todas las fuentes de identidad configuradas, y se encarga de poner en orden todo ello, asignando los datos correctos a la identidad (única e irrepetible) de una persona. Pero no sólo actúa de repositorio y almacén central de datos, adquiridos mediante conectores de muy diversa naturaleza. Sino que además, actúa como sincronizador, y se encarga de distribuir los cambios que se realicen a la entidad “usuario” a todos los sistemas afectados, de forma que los datos de dicho usuario Siempre estén en sincronía.

Para poder hacer esto, FIM proporciona una serie muy amplia de conectores, llamados Management Agents, que se pueden conectar a infinidad de orígenes de identidad, como puede ser Active Directory, Microsoft SQL Server, tablas en una Base de Datos, líneas en un archivo CSV…. la variedad es inmensa. Pero pese a la gran variedad de conectores disponibles, siempre queda la posibilidad de que una empresa esté usando un sistema de gestión de identidad propio… que debe ser sincronizado con otros sistemas. Un ejemplo, puede ser una aplicación personalizada de gestión de recursos humanos.

Para este tipo de sistemas, FIM proporciona herramientas que permiten la creación/desarrollo de nuevos Management Agent, ya sea el conector ECMA 2.0, o el conector basado en WebServices.

De los dos, a priori, el que parece más sencillo de usar, pero al mismo tiempo aparenta ser el más limitado, es el conector de WebServices. Pero eso es sólo en la superficie. Ya que al profundizar en él, no es tan sencillo de utilizar ni tampoco es tan limitado como parece. Así pues, y tras esta larga introducción ¿qué mejor forma de mostrar su potencia, que mostrando un pequeño snippet que nos permite enviar un correo desde FIM?

 Prerrequisitos

Para poder replicar el contenido de este post, es necesario más trabajo del habitual. La versión de FIM sobre la que se ha trabajado es FIM 2010 R2. Como requisito base, se va a necesitar un Active Directory, así que es necesario tener un laboratorio de AD con al menos un DC. También es necesario tener un Microsoft SQL Server instalado y configurado (aunque puede estar funcionando en la misma máquina donde se despliegue FIM Sync). La buena noticia, es que en ambos casos, tanto SQL Server (2008/2012) como FIM 2010R2 tienen una trial de 180 días, así que es posible desplegarlos sin preocupaciones, que nos van a durar casi 6 meses. Finalmente, y dado que se usa el conector de web services, es buena idea tener una máquina adicional con IIS en la que se despliegue un web service. Y ya puestos a pedir, también viene bien tener un Visual Studio con el que desarrollar el web service (por simplicidad), aunque es perfectamente posible implementar un web Service SOAP que se pueda usar en Apache y PHP.

Pregunta del millón: Si se va a utilizar FIM y el conector de Web Services para enviar correo, ¿realmente es necesario montar un servidor con un webservice (por muy simple que sea) para que todo esto funcione? La respuesta es . FIM va a comprobar que el conector tiene definido un web service y un tipo de objeto que va a leer en sus operaciones. Así que si no existen ni el objeto ni el servidor del que lo va a leer… no se va a poder crear el conector en el cliente de FIM Sync.

EstructuraServidoresEn definitiva, se necesita tener al menos tres máquinas virtuales en un laboratorio de AD: Domain Controller, un Servidor Web, y la máquina de FIM (que simultáneamente hospeda SQL Server). Esta configuración FIM-SQL_Server no es la aconsejada para despliegues físicos, pero en cambio, ésta es la configuración recomendada si se va a desplegar un servicio de FIM Sync en Azure

Conector de WebServices

Este conector está basado en Windows Workflow Foundation (WWF). Bueno, en un subconjunto de WWF, para ser más precisos. Esto de entrada ya parece un limitante, pero con suficientes dosis de creatividad, es posible hacer casi de todo.

Para poder trabajar con este conector, se utiliza un editor llamado “Web Service Configuration Tool“, absolutamente minimalista, pero que cumple con su cometido a la perfección. De entrada, se puede ver que hay tres secciones bien diferenciadas: Discovery, Object Types y Test Connection.

interface

  • Discovery es la sección donde se puede editar y añadir nuevos Web Services, en este caso basados en SOAP, aunque instalando una actualización también es posible usar servicios REST.
  • Object Types es la sección donde se definen los objetos que se van a sincronizar con FIM. Cuando se configura, aparecen las opciones para añadir el código WWF que va a gestionar las operaciones de Full Import, Delta Import, y Export (delete-add-replace) relacionadas con ese objeto. Estos objetos, se proyectan directamente en el metaverso de FIM a la hora de crear el Management Agent, así que es seguro decir que hay total libertad a la hora de definir los Object Type.
  • Finalmente, la sección Test Connection es la que vamos a usar en este post.

Obviamente, las cosas no son tan sencillas como decir “vamos a hacer un test de envío de correo” y listo. En este caso, para poder hacer el test, FIM hace comprobaciones sobre los archivos de configuración creados con la herramienta. Se fija en detalles tan insignificantes como que la herramienta se va a conectar a un Web Service SOAP existente, o que los datos que devuelve el Web Service son compatibles con un Object Type detallado previamente, etc. Por eso es necesario contar con una máquina adicional que

Cómo crear un Web Service en Visual Studio, e instalarlo en un servidor IIS adicional para que FIM pueda leerlo, es un tema aparte que merece un mini-post para detallarlo. Simplemente decir, que para que todo esto pueda funcionar con el Web Service Configuration Tool en modo SOAP, es necesario tener un web service accesible, y que haya sido configurado en la herramienta, de forma que pueda pasar las validaciones de FIM Sync. Para ello, simplemente acudimos a la sección de Discovery, y añadimos un nuevo servicio, con tipo de tipo de credencial none y con modo de seguridad none. Al fin y al cabo, es un servicio de pruebas, y no es necesario complicarse aún más con modelos de autenticación.

nuevoServicioSOAP

A continuación añadimos un objeto, para que las validaciones de FIM no se quejen y nos digan que el conector no es válido. Sumamente sencillo y rápido, que lo importante no es crear el objeto en el configurador

objetoMetaverso

Ahora que ya está todo preparado (Active directory, despliegue de máquinas, servicio web…) vamos a lo importante: cómo enviar correo.

Envío de Correo: Uso de la sección Test Connection

Con todo ya preparado, ¡toca ponerse manos a la obra! Tenemos el Web Service Configuration Tool, así que toca empezar a mover componentes. Como estamos trabajando con Windows Workflow Foundation, todo va a ser bastante visual, y sobre todo, hay que tener en cuenta que el código se incrusta dentro de bloques denominados secuencias.

Lo primero: Definir las variables que necesitamos para desarrollar el proyecto.

vars

El editor de configuración, dispone de tres secciones interesantes en la parte inferior de la ventana de edición de código: Variables, Arguments, Imports. Para el uso que importa en este artículo, sólo se va a hacer uso de la sección “Variables”, en la que definimos las variables que se van a utilizar. Es importante señalar dos apartados de esta sección: Scope que indica el ámbito de la variable, dentro de una secuencia, y Variable Type, que es donde definimos el tipo de las variables. En Variable Type, se muestra una serie de tipos predefinidos aunque, y aquí entra la magia, es posible buscar cualquier clase presente en el .NET framework para utilizarla como tipo de variable.

advancedTypes_WSConnectorEstablecer que las variables estén en el scope “sequence” (el top-level) es el equivalente a definirlas como variables globales que estarán disponibles para todas las secuencias que se creen dentro de la secuencia padre.

A continuación, es necesario definir la estructura de lo que es necesario para enviar un correo. Los pasos básicos. Esto lo vemos en la siguiente captura de pantalla:

overView Tenemos una Secuencia, que es el cuerpo principal del programa en WWF que se va a “escribir” en la sección de “Test Connection”. En esta secuencia, se añade una nueva secuencia, y se la llama “SendMail”. Una secuencia equivale conceptualmente a una función. Es una agrupación de elementos, que se puede plegar y desplegar a voluntad para ocultar sus contenidos. En este caso, la secuencia SendMail tiene tres partes: Una que es el cuerpo del Mensaje, que se define asignando un valor a una variable, otra sección que es “configurar Servidor SMTP”, y una última sección que es “Enviar Mail”. Estas secciones se despliegan a continuación para mostrar sus contenidos.

configurarSMTP

En la secuencia de “Configurar Servidor SMTP”, lo que se hace es configurar el objeto del tipo SMTPClient que se definió al principio del proceso. Para mejorar la claridad de lo que se hace, hemos renombrado las acciones del tipo “assign” para que su descripción muestre la ruta completa de variables que se está asignando. Convenientemente, las credenciales para conectar al servidor SMTP quedan oscurecidas dentro del textbox en el que están escritas, pero para que lo tengamos claro, son un objeto del tipo Net.NetworkCredentials. Para simplificar aún más, indicamos que el cuerpo del mensaje no es HTML.

A continuación, desplegamos la segunda secuencia “Enviar Mail”

enviarMail

 

En este caso, se establece la dirección de envío (mailMessage.From = New System.Net.MailAddress(fromMailAddress)), y aquí viene lo potente: El componente de WWF “InvokeMethod”, que permite ejecutar un método de una clase que haya sido instanciada en un objeto. En este caso, se añade la dirección a la que se quiere enviar a la lista de destinatarios. Es necesario usarlo, ya que internamente es una lista, y los correos destino se deben añadir uno a uno. Se define el Subject del mensaje, se define el Body del mensaje, y se vuelve a usar un InvokeMethod para, esta vez sí, hacer que el objeto SMTPClient (instanciado como smtpService) se encargue de enviar el correo electrónico que hemos definido.

anadirDestinatario

Finalmente, si queremos que FIM se entere de que todo ha terminado con éxito, toca añadir al final de la secuencia la siguiente asignación:

resultTrue

Con esto, hemos definido la configuración del conector de Web Services. Pero todo esto, por sí solo, no hace absolutamente nada. Es necesario Crear un Management Agent del conector de Web Services en FIM Sync, e indicarle que use este archivo de configuración. Para ello, lo más importante es copiar el archivo de configuración a una carpeta muy concreta, de lo contrario, FIM Sync no será consciente de su existencia.

url

 

Finalmente, con el archivo de configuración copiado en la carpeta de Extensiones, se puede proceder a crear el Management Agent. Para ello, se abre el Synchronization Service Manager on FIM, y se acude a la sección “Management Agents”, seleccionamos “Create”, y nos encontramos con esto:

creandoMA

Se selecciona que el Management Agent que se desea crear es el de “Web Service (Microsoft)”, se le pone un nombre, y se pulsa “Next”, esto nos lleva a la pantalla de configuración de conexión del MA.

creandoMA.2

En esta sección, es importante elegir el proyecto del configurador del conector que hemos creado, y el Host y el puerto que hemos definido en el proyecto, así como la misma configuración en el modo de seguridad y el tipo de credencial de cliente. FIM va a validar todo esto, y en caso de que haya algún error no va a dejar que continuemos bajo ningún concepto.

Una vez  todo está validado, FIM pasa a la siguiente pantalla “Global Parameters”, en la que aparece un único checkbox disponible:

creandoMA.3¡¡¡¡ “Test Connection” !!!! Marcando este checkbox, FIM va a ejecutar el código que hemos creado anteriormente en el apartado “Test Connection”, que existe única y específicamente para ser ejecutado en este instante. Esto es muy útil para probar partes del código del conector de Web Services, ya que se pueden ejecutar sin ningún tipo de compromiso, y en caso de que todo haya funcionado bien, lo sabremos gracias a la sección “Result = true” que añadimos al final del código. Para pruebas más complejas, es muy útil no devolver ningún valor de Result (por defecto es false), o cambiarlo a False en caso de que algún tipo de validación no se haya ejecutado como se espera.

Es la hora de la verdad: En cuanto se pulse “Next”, teniendo el checkbox marcado, FIM va a compilar el conector de Web Service, y va a ejecutar la sección de “Test Connection”. En caso de que todo salga bien, se enviará un correo electrónico a la dirección deseada, y el cuadro de diálogo para crear un Management Agent pasará a la siguiente sección “Configure Partitions and Hierarchies”. Pero todo ello ya no pertenece al ámbito de este post.

En cambio, lo que sí pertenece, es la última captura de pantalla…

correoFIM

Finalmente, ¡los correos han llegado a su destino!

 

Conclusión

En este artículo se ha compartido un fragmento de código para el conector de Web Services, que es muy útil a la hora de diagnosticar problemas en casos de importaciones masivas. Por ejemplo, si hay que sincronizar medio millón de usuarios, eso es un proceso que puede tomar varios días de proceso para el conector. En caso de que hubiese algún tipo de problemas, un sistema de alertas por email que indique que algo está pasando es vital para ayudar a actuar de inmediato, corrigiendo la situación que esté dando problemas en el lado servidor antes de vernos forzados a interrumpir el proceso. Cualquier interrupción de una operación de full Import puede suponer días de espera, ya que es una operación que no puede ser reiniciada.

En definitiva, una herramienta útil para desarrollos más complejos utilizando el conector de Web Services.

¡Hasta la próxima!

¿Active Directory domain o Cloud domain?

Cuando hemos dado alguna charla sobre los servicios Cloud de Microsoft, nos gusta hacer una aproximación construyendo un mensaje basado en la Identidad. Si pensamos en cuál es el centro neurálgico de cualquier infraestructura On-premise, seguramente digamos Active Directory. En torno a él desplegamos una serie de servicios como pueden ser el correo electrónico, aplicaciones, bases de datos, etc.

Con la aparición de plataformas en la nube como Office 365, Azure o EMS, por ahorro de costes o funcionalidades añadidas que podemos dar a nuestros usuarios, llega el momento de mover esos servicios y “externalizarlos”. En este caso en la nube de Microsoft estamos cubiertos, ya que han seguido una aproximación muy parecida a los entornos On-premise, y tenemos como centro neurálgico a Azure Active Directory. Como hemos explicado en varias ocasiones, AAD es un Directorio como Servicio, proporcionando un almacén de credenciales y plataforma de autenticación única para cualquier producto Cloud de Microsoft. Además podemos desarrollar nuestras aplicaciones para que autentiquen arriba y disfrutar de una experiencia de Single Sign-On.

Capture17

 

Como podéis observar en la imagen, cada vez más servicios dependen de la nube, y nuestro Active Directory se queda algo desangelado ahí abajo. Pueden existir todavía escenarios donde dependemos de una autenticación tradicional, como puede ser el login en nuestros equipos de trabajo, aplicaciones legacy que no podemos cambiar, el RADIUS de la WiFi, etc. Pero la tendencia claramente es llegar a un punto donde no necesitemos mantener ninguna infraestructura local, ni siquiera nuestro directorio de usuarios.

Con esa idea en mente se ha desarrollado Windows 10, el primer sistema operativo de Microsoft que nos permite iniciar sesión en nuestro equipo autenticando directamente en Azure Active Directory.

Capture3

Una vez unido el equipo al dominio de AAD, se le aplicarán las políticas que hayamos definido. Lógicamente a día de hoy no tenemos ni de lejos las opciones con las que contamos en un entorno On-prem con las GPOs, tanto de Equipo como de Usuario, pero es un comienzo.

Además de este modo estamos registrando automáticamente el equipo como dispositivo del usuario, por lo que podremos manejarlo desde un MDM como Intune desde el minuto 1. También tendremos esa experiencia de SSO con cualquier aplicación que tengamos enlazada a nuestro AAD, pensar en Office 365…

Si lo tenemos habilitado, podremos unirnos a Azure AD incluso cuando tengamos la identidad federada:

Capture11

Capture13

 

Capture15

El detalle de cómo debemos configurar nuestro Azure Active Directory para poder unirnos de esta forma, lo podéis encontrar en este fantástico post de Sergio Calderón. Fijaros en el detalle de la notación con la que aparece un usuario unido a un dominio de AAD (AzureADUsuario):

Capture2

Pero entonces… si me he unido a un dominio de Azure Active Directory que tiene sus propias políticas, pero que tengo federado con un Active Directory donde configuro mis GPOs… ¿¿donde estoy?? ¿¿que me aplica??

Bueno, la respuesta es que aunque la autenticación se realice en última instancia en el AD local, ambos directorios son disjuntos.

Lo podemos ver en la información del sistema:

Capture4

 

O más claramente, si intentamos unirnos al Active Directory local:

Cloud domain

Por lo tanto nos toca elegir… ¿Active Directory domain o Cloud domain? ¿Vosotros qué preferís?

¡Hasta la próxima!