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

Windows Server 2016 TP5 Ya esta aqui

Buenas,

Volvemos a la carga después de algún tiempo en el que no he podido escribir con la frecuencia con la que lo venía haciendo principalmente por temas de tiempo.

Hoy me gustaría hablaros de la TP5 (Technical Preview 5) de Windows server 2016 la cual fue liberada para descarga el pasado 27/04/2016. Es importante mencionar que muy probablemente esta sea la última techinical preview de Windows server 2016 puesto que se espera tener versión final o RTM más o menos para septiembre, muy probablemente coincidiendo con el evento Microsoft Ignite, igualmente comentar que la versión TP5 se considera “Feture ready” o lo que es lo mismo, esta versión ya incluye todas las funcionalidades que tendrá la versión final aunque algunas de ellas aún pueden tener bugs y serán corregidas de cara a la RTM.

Una vez realizada esta pequeña introducción de la TP5 de Windows server 2016 lo primero que me gustaría hacer es dejar el link de descarga de la misma.

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Seguidamente me gustaría mencionar algunas de la funcionalidades más significativas que han cambiado/mejorado desde la versión anterior (Windows server 2016 TP4)

– Nuevas funcionalidades en Storage Space Direct: Cabe destacar entre todas ellas la suportabilidad para crear storage space direct solo con 3 servidores al igual que ocurre actualmente con Vmware VSAN, por otro lado también se incorporan mejoras en la gestión de los mismo mediante un wizard de configuración automática y la gestión de los mismos mediante virtual machine manager.

– Nuevas funcionalidades en Nano server: Por primera vez se incluye la opción de realizar un despliegue de Nano server tanto en la versión standard como en la versión datacenter. Igualmente se han incorporado mejoras en la Emergency console (EC) de nano con la cual se pueden configurar todos los parámetros tct/ip, configurar el firewall de Windows y habilitar y deshabilitar WinRM

– Incorpora nuevos ADMX files: Estos ficheros admx los cuales se puede incorporar a la gpmc (Group Policies Management Console) nos permitirán configurar y administrar políticas de configuraciones basadas en claves de registro.

– Actualización de WSA: WSA (Windows server App) es una tecnología para crear instaladores de Windows la cual apareció por primera vez en la versión TP4 la cual incluye bastante mejoras en relación con los instaladores msi, igualmente es importante mencionar que WSA es el único tipo de instalador soportado en Nano. De cara a la versión TP5 WSA ha sido mejorado soportando la creación de paquetes de instalación y actualización de aplicaciones.

Espero que os resulte de utilidad y que os animéis a descargar y probar Windows server 2016 TP5.

Un saludo

Aumentar/Reducir la capacidad de máquinas virtuales en Azure de manera programada

Buenas
Hoy me gustaría explicar el procedimiento para aumentar o disminuir la capacidad de nuestras máquinas virtuales en azure cambiando el tipo de las mismas.

Es bien sabido por todo que Microsoft factura las máquinas virtuales de Azure al igual que el resto de hosters dependiendo del tamaño de las mismas. Por lo tanto la cantidad de memoria y de cpu asignada a una máquina virtual será directamente proporcional al precio que pagaremos por tener la misma en ejecución. Igualmente es importante mencionar que Azure calcula el precio de facturación de las máquinas virtuales por minuto, por lo tanto nos beneficiaremos de una precio mas ventajoso solamente un minuto después de reducir la capacidad y tendremos que pagar un precio más elevado justo un minuto después.

Teniendo en cuenta los puntos mencionados podemos imaginar que el propósito principal detrás de aumentar o la reducir la capacidad es tener un ahorro costes el cual podemos conseguir reduciendo la capacidad cuando nuestros servidores son menos demandados y aumentando la capacidad en las horas de actividad pico.

Una vez tenemos claro en que momentos podemos reducir la capacidad de nuestros servidores (en la mayoría de los casos por las noches y fines de semana) seremos capaces de manera programada cambiar el tipo de máquina virtual por una de menor o mayor capacidad según convenga. Igualmente me gustaría remarcar que el cambio de tipo de máquina virtual requiere un reinicio de la misma, es más en nuestro ejemplo primero apagaremos la misma para posteriormente cambiar el tipo y volverla a ejecutar.

Una vez hecha breve introducción pasamos a ver de manera práctica como cambiar el tipo de máquina virtual en azure de manera programada.

1- Lo Primero que debemos hacer es crear una cuenta de automatización en Windows Azure y definir los credenciales que usaremos para ejecutar Runbooks en la misma. El procedimiento para realizar estas tareas podéis encontrarlo en este post
(pasos del 1 al 7)

2- Creamos un runbook

3- Accedemos a la parte de editado del workflow e introducimos el siguiente código

Ademas dejaros el pantallazo del mismo os lo dejo en texto plano para facilitar el realizar copy y paste del mismo.

workflow reduce_capacity
{

$cred = Get-AutomationPSCredential -Name “PShell_Credentials”
Add-AzureAccount -Credential $cred
Stop-AzureVm -ServiceName tstsamw2k12r2 -Name tstsamw2k12r2
InlineScript{$azureVM = Get-AzureVM -ServiceName ‘tstsamw2k12r2’ -Name ‘tstsamw2k12r2’
Set-AzureVMSize -VM $azureVM -InstanceSize ‘Basic_A3’ | Update-AzureVM}
Start-AzureVm -ServiceName tstsamw2k12r2 -Name tstsamw2k12r2

}

Evidentemente en vuestros script deberéis de editar los valores para los credenciales guardados así como el nombre de de la máquina y el tipo de la mismas ‘Basic_A3’ en mi caso.

4- Por último definiremos un programación asociada al runbook

Espero que resulte de utilidad.

Un saludo