Archivo de la etiqueta: active directory

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!

Autenticación Office 365 en ADFS con múltiples dominios

¡Hola a todos! Hoy toca hablar de un proceso que puede que tengamos que afrontar tarde o temprano, e involucra Office 365, múltiples dominios validados, federación, e integración con Active Directory. Dicho así, parece más difícil de lo que en realidad es, así que… empecemos por plantear un posible escenario, y a continuación dar los pasos para resolverlo.

Imaginemos el siguiente escenario: Tenemos un tenant de Office 365 con varios dominios validados para gestionar nuestro correo electrónico y tenemos desplegado ADFS y DirSync para proporcionar servicios de sincronización y autenticación del Active Directory contra Office 365 con nuestro dominio principal. Y supongamos que nuestra empresa dispone de una gama de productos, cada uno de ellos con su propio dominio.

Y justo hoy, deciden añadir un nuevo producto a la lista… ¿Qué tenemos que hacer para preparar nuestro dominio y Office 365 para la nueva situación?

 

Primero: Agregar el nuevo dominio a Office 365 y validarlo, con el código de verificación que Office 365 nos proporciona y que hay que utilizar en el registro TXT de DNS.

addDomain

Segundo: Añadir el nuevo dominio a la lista de sufijos de UPN de nuestro AD. Para ello, debemos acudir a las herramientas administrativas, y abrir “Dominios y Confianzas de Active Directory” (Active Directory Domains and Trusts)

HerramientasAdministrativas

Una vez abierto, lo que deseamos es cambiar las propiedades de nuestro dominio, así que pulsamos con click derecho sobre el nodo raíz del árbol de dominios, y seleccionamos “Propiedades”

ADDomainsTrusts

En ese instante, podremos añadir los sufijos de UserPrincipalName que necesitemos para definir las cuentas de usuario. En este caso tenemos tres sufijos definidos: dos .com y un .net. Adicionalmente podemos añadir “nuevodominio.com”, o simplemente eliminar un sufijo que ya no sea necesario.

ADDomainsTrusts_newdomain

Podemos conformarnos con añadir “nuevodominio.com”, aunque podemos añadir todos los que deseemos. Cada dominio que añadamos aquí, pasa a formar parte de las confianzas de nuestro Active Directory, por lo que podemos utlizarlo como sufijo del UserPrincipalName para crear o modificar cuentas de usuario en nuestro AD a placer.

Tercero: Añadir el dominio elegido al servicio de federación ADFS. Para hacer esto, debemos conectarnos con office 365 mediante el cmdlet “connect-msolservice”. Una vez hemos conectado, nos encontramos ante dos casos habituales:

  • Hemos seguido las instrucciones hasta ahora y hemos agregado el dominio. Tan sólo nos falta asegurarnos de que está validado (por ejemplo con la ayuda de https://www.whatsmydns.net/ para comprobar el estado de propagación de los DNS), y una vez validado, simplemente tenemos que lanzar este cmdlet: Convert-MsolDomainToFederated -SupportMultipleDomain -DomainName nuevodominio.com
  • Si por el contrario, no hemos agregado el dominio, entonces tendremos que usar este otro cmdlet: New-MsolFederatedDomain -SupportMultipleDomain -DomainName nuevodominio.com

Además de los avisos que el proceso de conversión pueda generar, una forma de verificar si hemos tenido éxito es con el cmdlet “Get-MsolDomain”

getMSOLDomain

Una vez ejecutados los cmdlets, nos encontraremos con que la pantalla de inicio de sesión de Office365 nos redirige correctamente a nuestros servidores de ADFS para autenticar al usar un UPN con el nuevo dominio.

 

Cuarto: Ahora que ya tenemos la capacidad de definir UPNs con el nuevo dominio, hemos añadido el dominio a Office365, y ADFS está aceptando el nuevo dominio para autenticación de usuarios… la fase final es la más sencilla de todas: Agregar/modificar los usuarios que necesitemos que utilicen el nuevo UPN, y sincronizarlos con DirSync.

 

¡Y eso es todo! Como es habitual, prestad atención a la sección de Bonus, porque puede contener algunos trucos o situaciones que os podáis encontrar al realizar este proceso.

 

Bonus:

  • Si necesitamos convertir el dominio de Federado a Standard, se utiliza el cmdlet “Convert-MsolDomainToStandard -DomainName nuevodominio.com -PasswordFile pwd.txt -SkipUserConversion $false”. Este cmdlet, lo que hace es deshacer el proceso de federación, y generar un archivo de texto en el que se encuentran TODOS los usuarios que hay actualmente en Office365, proporcionando una nueva contaseña aleatoria para todos los afectados por el paso de dominio Federado a Standard.
  • Si estáis convirtiendo un usuario desde un UPN federado hacia otro UPN federado… DirSync puede dar problemas de sincronización. El motivo es que actualmente no está soportado.
  • Gracias a la magia de ADFS, podemos federar múltiples subdominios sin tener que volver a validarlos por DNS en Office 365. El motivo principal es que como ya está federado el dominio principal, es de confianza, y por tanto todo subdominio se valida y federa automáticamente. Para acelerar las cosas los podemos añadir con el cmdlet “New-MsolFederatedDomain”, desde la shell directamente.

AAD Sync

Con este título tan críptico, en este post queremos aprovechar y hablaros sobre la última versión de Azure Active Directory Sync, más conocido anteriormente como Dirsync.

La beta 3 que salió hace menos de un mes y que tenéis disponible a través de Connect, ya permite vislumbrar tanto la interfaz como las nuevas funcionalidades que traerá el sincronizador gratuito de Microsoft para Azure Active Directory.

AAD Sync

Entre las funcionalidades más destacables, nosotros queremos resaltar las siguientes:

1.   Sincronización desde multi-forest: de manera muy sencilla vamos a poder añadir bosques de AD en el propio asistente y definir qué atributos del usuario se encuentran en cada uno de ellos.

MultiForest

AttributeMapping

2.   Sincronización desde otros directorios (LDAP, SQL,…): aunque en la beta 3 no tenemos todavía disponible la opción, en la versión final se podrán sincronizar usuarios desde directorios que no sean AD como puede ser un LDAP en Linux, una base de datos SQL, etc. Desde luego esta será una de las características más apreciadas por multitud de clientes con entornos heterogéneos, como pueden ser las Universidades.

3.   Password write-back: dar la posibilidad a un usuario de que se cambie la contraseña de dominio cuando quiera, incluso fuera de la red corporativa, muchas veces puede resultar complicado. La necesidad de conectarse a la VPN, montar un portal web con ADFS, utilizar FIM, son algunas de las opciones más comunes. Con esta nueva versión de Dirsync, y apoyándonos en Azure Active Directory Premium, podremos utilizar el propio portal de Azure accesible por el usuario para resetearse la contraseña local. Podemos utilizarlo tanto con la sincronización de passwords que ya teníamos con Dirsync como en un entorno federado con ADFS.

Password write-back

Recordar que debéis tener habilitado Azure Active Directory Premium para el directorio en cuestión, sino recibiréis un error:

Error AAD Premium

4.   Filtrado de atributos por aplicación: permite sincronizar a Azure Active Directory únicamente los atributos del usuario que sean necesarios para poder trabajar con ciertas aplicaciones. De esta manera podemos limitar la información que nos llevamos arriba así como mantener más limpio el entorno.

AAD App filter

Una vez terminada la configuración ya podríamos arrancar la sincronización, siendo ésta por defecto la de todos los usuarios, grupos y contactos del forest especificado. Si queremos restringir la sincronización por ejemplo por OU (Unidad Organizativa), debemos seguir el procedimiento tradicional de arrancar la “UI Avanzada” ejecutando el msiiclient.exe y editar los contenedores que nos queremos llevar de nuestro AD local.

Container filter

Para terminar, arrancamos la sincronización desde la misma consola o ejecutando de nuevo el asistente de AAD Sync, y ya tendremos nuestros usuarios en la nube.

FI/FS

Espero que os hayan parecido interesantes todas las novedades que nos esperan con nuestro querido DirSync.

¡Hasta la próxima!

Problemas mezclando controladores de dominio de Windows Server 2003 con controladores de dominio de Windows Server 2012 R2

Actualización (2015/1/22): Ya hay disponible un hotfix en http://support.microsoft.com/kb/2989971

Estoy trabajando en un proyecto donde estamos haciendo una extensión de red en Microsoft Azure a través de tunel Site to Site y entre las primeras tareas a llevar a cabo es replicar un par de controladores de dominio en máquinas de Azure.

El dominio se encuentra en modo funcional de Windows Server 2003 y los servidores son, evidentemente, Windows Server 2003 (en efecto, ¡están fuera de soporte!). Más allá de lo poco recomendable que es a día de hoy mantener sistemas con Windows XP o Windows Server 2003, me he topado con este post del blog oficial del equipo de soporte de AD DS.

El problema consiste en un fallo en la autenticación por Kerberos que ocasiona que los usuarios no puedan iniciar sesión de forma aleatoria. El problema aparece si tenemos el siguiente cóctail:

  • Controladores de dominio con Windows Server 2003.
  • Controladores de dominio con Windows Server 2012 R2.
  • Ambos tipos de controladores sirviendo para el mismo dominio.

El problema se produce por el cifrado utilizado a la hora de generar los hashes de las contraseñas en la autenticación por Kerberos, debido a que:

  • Los DC con Windows Server 2003 no soportan usar AES para generar los hashes. Estos utilizan DES.
  • Los DC con Windows Server 2012 R2 no soportan usar DES para generar los hashes. Estos utilizan AES.

Algunas de las posibles soluciones son:

  • Utilizar Windows Server 2012 para nuestros controladores de dominio, que no está afectado por el problema.
  • Desactivar el cifrado por AES en el apartado de “Tipos de cifrado soportados” en las GPO. Esto hará que los controladores de dominio usen RC4-HMAC que está soportado tanto en 2003 como en 2012 y 2012 R2.
  • Otras opciones detalladas en el artículo original.

Mientras tanto, Microsoft ha confirmado oficialmente que están trabajando en un hotfix para el problema.

Enlace relacionado: It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers

Filtrado de atributos en Azure Active Directory, consideraciones a tener en cuenta

Cuando trabajamos con sincronización de Azure Active Directory (por ejemplo, para Office 365) podemos hacer el filtrado de objetos a sincronizar por unidad organizativa (OU) o bien por sus atributos.

En caso de que queramos hace el filtrado por atributo hay algunas cosas importantes que tener en cuenta:

  • El “filtrado” consiste en definir una regla para especificar qué objetos NO van a sincronizar. Todo lo que no cumpla esta regla sincronizará.
  • Sólo es válido para usuarios. Todos los grupos de distribución y seguridad del AD no se verán afectados por la regla, así como los contactos; por lo que sincronizarán independientemente de los que establezcamos. Esto se debe a que en el FIM subyacente a AAD Sync Tool estos objetos se encuentran ya filtrados mediante reglas de extensión que no son fácilmente modificables.
  • El filtrado en el FIM se establece de acuerdo a comparadores de cadenas, estando disponibles los siguientes:

    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
    Captura del FIM incorporado en AAD Sync Tool, mostrando propiedades de filtrado de atributos que podemos encontrar en el Management Agent de Active Directory
  • Se pueden combinar múltiples operadores con múltiples atributos, pero la regla lógica que sigue para aplicar el filtro es siempre AND. Por ejemplo: si extensionAttribute15 equivale a “estudiante” y extensionAttribute14 equivale a “nosync” entonces filtrar (no sincronizar) el objeto.

Happy syncing!