Azure Active Directory Group Self-service Request

Buenas,

Hoy me gustaría hablar de Azure Active Directory Self-Service request, esta funcionalidad dentro del portal de Azure nos permitirá que nuestros usuarios de Azure active directory pueden solicitar acceso a las aplicaciones de Azure configuradas de esta manera. Evidentemente igual podremos configurar que los administradores de la aplicación sean los encargados de aprobar o denegar dicho acceso.

De manera teórica creo que esta funcionalidad no requiere mucha más explicación, por lo tanto procedemos a explicar de manera práctica como configurarla.

1– Primero que todo nos logamos en el portal de azure y accedemos al directorio que usamos para publicar nuestras aplicaciones

2– Seguidamente pinchamos en configure.

3– Dentro del apartado de configure accedemos al apartado de group management y habilitamos “delegated group management” y en nuestro caso configuraremos en “some” users who can use self-service for security groups

4– Posteriormente accedemos a aplicaciones y concretamente a la aplicación donde queremos configurar el self service en nuestro ejemplo será para twitter el cual tenemos renombrado como corp_twitter y lo configuramos según aparece en el pantallazo

5– Seguidamente y al igual dentro de la aplicación pinchamos en en assign account para definir las cuentas que pobran acceder a la aplicación

6– En este caso en particular definiremos el grupo de selfservice definido en el paso anterior

Una vez llegados a este punto ya tendríamos la configuración lista, por lo tanto procederemos ahora a testear la funcionalidad y ver la experiencia de usuario, para ellos realizaremos los siguientes pasos.

1– Accedemos a https://myapps.microsoft.com y en mi caso me logaré con un usuario de prueba que creado el cual se tstselfserviceuser

2– Como podemos ver el usuario no tiene aplicaciones asignadas y pincharemos en obtener aplicaciones

3– Posteriormente buscamos la aplicación sobre la queremos tener acceso, en nuestro caso corp_twitter y hacemos click sobre la misma

4– Posteriormente pinchamos en agregar

5– Una vez realizado este paso se nos notifica que la aplicación está pendiente de aprobación

6– El administrador aprobara el acceso a la aplicación en el portal de azure

7– Por ultimo comprobamos que la aplicación nos aparece en myapps y que podemos acceder a la misma

Espero que os resulte de utilidad

Un saludo

Azure Active Directory Password Rollover

Buenas,

Hoy me gustaría hablar de la funcionalidad Azure Active Directory Password Rollover la cual está aún en preview. Esta funcionalidad nos permite no solo almacenar las password de las cuentas de uso compartido que toda organización usa como Facebook, twitter y linkedin sino que también incorpora la funcionalidad de cambiar las password de estas redes sociales en nuestro ejemplo de una manera automática usando una periodicidad definida por nosotros. Evidentemente estos cambios de password realizados de manera automática hace que el acceso a las redes sociales de la empresa sea más seguro y 100% gestionado por Azure.

Una vez realizada esta breve introducción de la funcionalidad pasamos a ver de manera práctica cómo funciona la misma.

1- Accedemos al portal de azure y al directorio donde queremos habilitar esta funcionalidad

2- En este caso en particular voy a créate un nuevo usuario en el directorio para mostrar el proceso completo, para ello pinchamos en “Add user” y seguimos las tres pantallas detalladas a continuación del wizard de creación de usuario

3- Posteriormente vamos a la pestaña de “applications” y pinchamos en add para añadir una nueva aplicación

4- En este caso añadiremos una aplicación desde la galería

5- Buscamos y selecciones twitter en este ejemplo como aplicación para añadir definiendo el nombre que queremos mostrar a los usuarios en el campo Display Name

6- Pinchamos en configure single sign on

7- Posteriormente pinchamos en Assign Accounts

8- Seleccionamos la cuenta que hemos creado y seleccionamos en Assign

9- En este pantalla será en la que habilitaremos password rollover, seleccionando primero que queremos que azure sea quien introduzca las credenciales de la aplicación en lugar de los usuarios y posteriormente habilitando password rollover

10- Por último definimos con que periodicidad cambiará Azure la password de la aplicación definida en la política de password rollover

Espero que resulte de utilidad

Un saludo

Mejoras en ADFS 2016

Buenas tardes,

En esta semana he estado jugando bastante y probando ADFS 2016, la verdad es que la versión 2016 incorpora bastantes funcionalidades las cuales me han sorprendido bastante y por ello me gustaría compartir con todos vosotros las más reseñables.

Autentiación desde directorios LDAP V3: Esta es quizás la más reseñable, ADFS 2016 no se integra solo con directorio activo como proveedor de credenciales sino que también tiene la posibilidad de hacerlo con cualquier LDAP corriendo en versión 3 como puede ser por ejemplo un Open LDAP.

Branding por cada IDP: En la versión 2016 también podemos personalizar de una manera bastante sencilla el branding por cada proveedor de identidad, de tal manera que los usuarios podrán autenticarse en una página totalmente distinta dependiendo del servicio de internet que vayan a consumir.

Conditional Access mejorado: Ahora es posible configurar políticas de acceso condicionales que requieren distintos parámetros de seguridad dependiendo donde se encuentren nuestros usuarios. Con esta funcionalidad podemos por ejemplo definir la autenticación de dos factores cuando los usuarios están fuera de la red corporativa y no requerida cuando están en la misma.

Azure Multifactor Authentication: En efecto, haciendo una integración entre ADFS 2016 y Azure AD es posible proveer multifactor authentication a las aplicaciones federadas, donde el primer factor de autenticación será normalmente la password y el segundo estará integrada con el dispositivo móvil donde podemos jugar con códigos sms, huella dactilar ….

Administración Delegada: Dentro de ADFS ahora es posible delegar la administración por IDP sin necesidad de delegar la administración del servidor ADFS por completo

Actualización sencilla desde ADFS 2012 R2: De una manera muy similar al role de Hyper-V existe la posibilidad de tener granjas de servidores ADFS con servidores en versión 2012 R2 y servidores en versión 2016, esto nos permite actualizar servidores de una manera cómoda y transparente para los usuarios donde actualizaremos el nivel funcional de la granja una vez actualizados todos los servidores.

Espero que resulte de utilidad

Un saludo

Microsoft Summit 2016

Buenas,

El pasado jueves 6/10/2016 tuve el placer de participar como Speaker junto con mi colega Juanjo Díaz en el evento Microsoft Summit 2016 el cual fue el evento de presentación oficial de Windows Server 2016.

En dicho evento nos encargamos de realizar una presentación de Nano, Hyper-V y contenedores en Windows server 2016 en la que nos centramos principalmente en la novedades de la versión 2016.

Como ya sois varios los que me habéis solicitado la presentación por mail y algunos los que me habéis preguntado si hay posibilidad de ver la grabación del evento, me gustaría facilitaros el acceso a los mismos en este post.

Referente a la presentación realizada, podéis encontrarla en el siguiente Link

La grabación del evento está disponible en la página oficial del evento la cual podéis ver a continuación.
https://www.microsoft.com/es-es/microsoftsummit

Espero que está información os resulte de utilidad y muchas gracias a todos los que seguisteis el evento de manera presencial o mediante el streaming.

Un saludo

Escalado de Hyper-V 2016

Buenas,

Escribo hoy este post tan cortito para compartir con vosotros lo datos de escalado de Hyper-V 2016 recientemente publicados de manera oficial por Microsoft.

Como podéis en la siguiente tabla, el incremento de la escalabilidad de Hyper-V 2016 es bastante notable con respecto a Hyper-V Server 2012 R2, multiplicando por 6 la Ram soportada a nivel de host y por 12 a nivel de guest.

Adjunto el enlace al post del blog oficial de Microsoft donde se pública esta noticia.

Espero que 24 tb de ram por host y 12 tb de ram por VM sean suficiente en vuestro entorno 🙂

Un saludo

Azure Active Directory Domain services

Buenas,

Hoy me gustaría escribir y contaros como funciona Azure Active Directory Domain Services. Aunque está funcionalidad está aún en modo preview yo ya he estado jugando con ella y la verdad es que tiene bastante buena pinta.

Azure Active Directory Domain Services básicamente nos permite montar un directorio activo en Azure o extender nuestro active directory on-premises a Azure pero sin necesidad de preocuparnos por desplegar domain controllers en azure, gestionar las operaciones de los mismos ni de tener una vpn entre azure y nuestro AD on-premises para realizar la replicación en el caso de que queramos tener en Azure Active Directory los mismos usuarios y grupos que tenemos on-premise.

Igualmente me gustaría puntualizar que cuando que nos permite montar un directorio activo en Azure me refiere a que el servicio de Azure Active directory domain services pone a la dispoisición de las máquinas virtuales corriendo en azure los principales services de directorio activo como pueden ser, conexiones de máquinas al dominio, gestión de gpos, dns, NTLM, kerberos o LDAP.

Antes de explicar los pasos para habilitar esta funcionalidad en modo preview me gustaría dar un par de pinceladas más sobre su funcionamiento. Básicamente existen dos posibles escenarios de despliegue. El primero escenario de despliegue sería válido para clientes que solo tienen infraestructura en Azure, los cuales únicamente deben habilitar la funcionalidad y empezar a usar los servicios. El segundo tipo escenario de despliegue sería válido para clientes los cuales quieres habilitar la funcionalidad y replicar usuarios y grupos definidos en el directorio activo on-premises, los cuales deberán habilitar la funcionalidad y usar la herramienta Azure Ad connects para gestionar la sincronización de usuarios y grupos con Azure como se viene haciendo desde hace tiempo para proveer SSO en las aplicaciones SAAS como Office 365.

Una vez hecha la introducción de la funcionalidad, pasaremos a explicar cómo habilitar la misma. Por favor no olvidéis que en este momento está en modo preview y no es recomendable habilitarlo en producción

1– Nos Logamos en el Portal de Azure

2– Accedemos al apartado de Active Directory en el Menú

3– Creamos un nuevo directorio donde habilitaremos la funcionalidad o lo habilitamos en uno existente. Yo en mi caso en creo un nuevo.

4– Seleccionamos el directorio y pinchamos en Configure

5– Nos desplazamos un poco hacia abajo en el pestaña de configuración y pulamos en On para activar domain services, igualmente definiremos el nombre del dominio el cual podría ser exactamente el mismo que tenemos on-premises y virtual network de azure sobre la que presentaremos estos servicios. Una vez seguidos estos pasos pulsamos en save, Azure tardará más o menos 30 minutos en configurar la funcionalidad.

6– Una vez realizados estos cambios observaremos que nos aparece la ip del controlador de dominio generados por Azure aunque no tengamos acceso a el como tal y no debamos preocuparnos de operarle. Lo que si sería una muy buena idea es definir la ip del controlador de dominio como servidor dns para la virtual network de azure.

Espero que resulte de utilidad el post

Un saludo

SAML, OpenID o OAuth en la Federación de Identidades

Buenas,

Últimamente he estado trabajando en informando bastante en la parte de Federación de identidades la cual tiene como objetivo principal proveer Single Sign On (SSO) en nuestras aplicaciones. Igualmente me gustaría comentar que los principales beneficios del SSO y la federación de identidades es tanto la mejora de la experiencia de usuario evitando que el mismo necesite recordar las claves de acceso a la aplicación y aportándole un acceso directo y transparente a las mismas como evitar la necesidad de mantener y gestionar una base de datos de usuarios, roles y credenciales por cada aplicación.

Antes de empezar hablar sobre los tres principales protocolos de gestión de identidades (SAML, OpenID y OAuth) me gustaría explicar de una manera bastante resumida que es la federación de identidades para aquellos que seáis nuevos en este tema. La Federación de identidades nos permite desacoplar las capas de autorización y autenticación puesto que me permite a las aplicaciones federadas usar un identity management system para obtener la credenciales del usuario y autenticarles en la aplicación. Los identity management system más conocidos en el marcado son Microsoft ADFS y ping identity, sin embargo no quiero orientar este post a las aplicaciones que nos permiten configurar la federación y si a los tres protocolos mencionados en el asunto.

Una vez realizada esta breve introducción pasaremos a explicar un poco más al detalle los tres protocolos disponibles para configurar la federación.

-OpenID: Es un standard de federación abierto esponsorizado entre otros por Microsoft, Google, Facebook y paypal y permite que los usuarios puedan elegir e implementar su proveedor de OpenID preferido para autenticar en las aplicaciones que soportan este protocolo. Un ejemplo del proceso de autenticación y autorización con OpenID en la aplicación servicewnow sería el siguiente:

-SAML: Con mucha diferencia el más usado para autenticar en aplicaciones SAAS por clientes enterpise, está basado en xml y permite la autorización en la aplicación federada con saml mediante el uso de un token generado por el identiy provider. Un ejemplo del proceso de autenticación y autorización con SAML en la aplicación Salesforce sería el siguiente.

-OAuth: Se basa también en un standard abierto y se diferencia de los dos anteriores en que se usa únicamente para autorización y no para autenticación puesto que en este caso el proveedor de autorización es un tercero como puede ser el sistema de autenticación de twitter o facebook. Este protocolo se usa de manera muy frecuente para proveer SSO a aplicaciones móviles donde los dos anteriores tienen más carencias. Un ejemplo del proceso de autenticación con OAuth sería el siguiente:

Espero que resulte de utilidad

Un saludo

¿Qué funcionalidades o beneficios nos aporta Azure AD?

Buenas

Tras escribir el siguiente post hace un par de semana en el que daba algunos consejos que nos pueden ser de bastante utilidad para identificar si tiene sentido desplegar Azure AD en nuestro en entorno, he recibido un par de mails preguntándome dudas adicionales sobre el tema, concretamente consultándome acerca de las funcionalidades o beneficios adicionales que nos puede aportar tener Azure AD en nuestro entorno.

Tras recibir estas dos consultas he decidido publicar este post en el que explicaré que funcionales adicionales a sincronización de usuarios & passwords y single sign on en aplicaciones cloud nos aporta Azure AD.

Dichas funcionalidades serían las siguientes:

– MFA (Multi-factor Authentication ): El cual nos da una capa de seguridad adicional a la autenticación basado únicamente en usuario y password pudiendo usar como segundo factor de autenticación códigos generados en aplicaciones móviles, mensajes de texto, llamadas telefónicas, Smart card o sistemas de autenticación basados en biometría

– Conditional Access: Es una de las funcionalidades que más me gusta, la cuales nos permite definir distintas políticas de acceso dependiendo de donde nos conectemos. Con esta funcionalidad podrías por ejemplo definir como requerido el uso de MFA cuando conectamos fuera de la oficina y no requerido cuando conectamos en la misma

– Password Write Back: Esta funcionalidad nos permite cambiar la password en nuestro directorio activo on-premises iniciando el cambio de password desde una aplicación publicada en el cloud.

– Users account Provisioning: Esta funcionalidad la cual está disponible solo para alguna aplicaciones, nos permite automatizar el aprovisionamiento de cuentas de usuario en nuestro aplicaciones cloud partiendo de la creación de usuarios on-premises en directorio activo.

– Acceso a aplicaciones On-premises autenticando con Azure AD: Esta funcionalidad, la cual se integra con Azure AD app proxy nos permite como su propio nombre idéntica, autenticar con Azure AD en aplicaciones on-premises y por lo tanto dar un punto de seguridad adicional en la autenticación de estas aplicaciones usando funcionalidades como MFA.

– Azure B2B and B2C: Estas dos funcionalidades bien merecen un post dedicado solo a las mismas, pero por dar un resumen diremos que la primera nos provee un sistema de autenticación para dar acceso a nuestras aplicaciones a nuestros partners y la segunda a nuestros clientes.

Espero que resulte de utilidad.

Un saludo

Identificar si necesitas tener Azure AD en tu entorno y como replicar usuarios y passwords

Buenas

Como ya son varios los amigos dentro del mundillo del IT que me han preguntado cuando resulta interesante disponer de Azure AD y cómo podemos posibilitar que nuestros usuarios usen las mimas credenciales en la nube que usan en el directorio activo local, me he decido y he escrito este post el cual espero que se útil también para otras personas.

Primero que todo intentaré explicar que debemos de tener en cuenta para determinar si debemos desplegar el servicio de Azure AD en nuestra organización y esto lo sabremos dando respuesta a dos simples preguntas.

¿Estamos usando en nuestra organización alguna aplicación cloud que sea integrable con Azure Ad como puede ser office 365, google Apps, workday, salesforce ….?

¿Tenemos las necesidad de que los usuarios de estas aplicaciones pueden autenticarse con las mismas credenciales que tienen on-premises y que solo tengan que teclear el usuario y la password una vez?

Si la respuesta a las dos preguntas anteriores es afirmativa entonces podemos decir que SI necesitamos usar Azure AD.

Una vez que tenemos este punto 100% claro, el siguiente punto que me gustaría explicar es la manear que existe para sincronizar los usuarios entre nuestro directorio activo on-premises y Azure AD.

Para ellos existe una herramienta que se llama Azure AD Connect que trabaja como un bróker entre nuestro controlador de dominio on-premises y el servicicio de Azure AD replicando en Azure AD tanto usuarios como passwords.
Igualmente me gustaría mencionar que esta herramienta permite configurar varias acciones dentro del wizard de configuración de la cuales quizás las más reseñables en este nivel sea la posibilidad de editar los atributos que queremos replicar y la funcionalidad de password writeback la cual está disponible solo en la versión Premium y no permite cambiar la password en nuestro directorio on-premises aun cuando iniciamos el cambio de password en Azure.

Por último para terminar este post, me gustaría dejaros un par de imágenes que creo que son bastante representativas de como funciona la solución.

Prometo profundizar en artículos adicionales sobre este tema.

Un saludo

Membresía de grupos temporal en Windows server 2016

Buenas

Hoy me gustaría hablar de una nueva funcionalidad de Windows Server 2016 la cual nos permite definir membresía de grupos de manera temporal. Esta funcionalidad se enmarca dentro del Marco de JTA (just on time Access) que tanto persiguen los departamentos de seguridad y es especialmente útil a la hora de definir permisos a trabajadores que necesitan ser miembros de ciertos grupos de manera temporal para realizar un trabajo Puntual.

Igualmente me gustaría remarcar que esta funcionalidad también es aplicable a los grupos de administración o cualquier otro grupo de Directorio Activo y por lo tanto ideal para proporcionar permisos de administración para auditorias y similares.

Una vez hecha breve introducción teórica me gustaría me gustaría continuar detallando los requisitos para implementar la misma que son:
– Windows Server 2016 tp4 o superior
– Nivel funcional de forest window server 2016 (en este momento en technical preview y no recomendable en Producción hasta la liberación de la versión final

Seguidamente una vez identificados los requisitos me gustaría explicar de manera práctica como activar y usar esta funcionalidad.

1– Habilitamos la funcionalidad “Privileged Access Management Feature” mediante Powershell. De una manera similar a la papelera de reciclaje de Directorio Activo esta funcionalidad debe ser activada para poder ser usada, para ello ejecutre el siguiente comando.
Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Scope ForestOrConfigurationSet -Target test.int

2– Una vez habilitada la funcionalidad mediante powershell podemos definer membresía de manera temporal. En el comando del ejemplo estoy añadiendo la cuenta de usuario secoperator durante dos días al grupo domain admins.
Add-ADGroupMember -Identity ‘Domain Admins’ -Members ‘secoperator’ -MemberTimeToLive (New-TimeSpan -Days 2)

3– Por ultimo comentar que podemos ejecutar el siguiente comando para comprobar los usuarios con membresía temporal en un grupo
Get-ADGroup ‘Domain Admins’ -Property member –ShowMemberTimeToLive

Espero que resulte de utilidad

Un saludo