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

Power Shell Desired State configuration (DSC) – Configuración del Pull Server

Buenas,

En esta última entrada de la serie veremos el procedimiento que debemos seguir para configurar un pull Server de DSC con el objetivo de aplicar las configuraciones mediante pull a nuestros clientes de DSC de manera automática en lugar de aplicar las mismas de manera manual haciendo un push de las configuraciones.

Primero que todo, me gustaría recomendaros la lectura del resto de entradas de la serie sobre DSC. Los mismos os ayudaran muchísimo para entender esta funcionalidad.

Power Shell Desired State configuration (DSC) – Introducción Teórica
Power Shell Desired State configuration (DSC) – Recuros y Generación del fichero MOF
Power Shell Desired State configuration (DSC) – Aplicando las configuraciones

Antes de comenzar con la parte práctica me gustaría mencionar que el Pull Server de DSC se puede configurar para distribuir las configuraciones tanto por SMB como por https y aunque cada una tiene sus Pro & Cons como norma general yo recomendaría configurarlo por https puesto que normalmente tendremos menos problemas de firewalls que puedan bloquear la comunicación con los clientes de DSC.

Una vez hecha esta breve introducción teórica pasamos a detallar los pasos para configurar el pull Server:

1- Nos aseguramos de tener los modulos de DSC descargados y descomprimidos en %programfiles%/WindowsPowerShell/Modules
(Esta procedimiento está perfectamente detallado en la segunda entrada de la serie “Recuros y Generación del fichero MOF”

2- Instalamos la funcionalidad de DSC en el pull server ejecutando el siguiente comando
Install-WindowsFeature DSC-Service –IncludeManagementTools

3– Habilitamos el servicio de Winrm ejecutando el siguiente comando
Winrmquickconfig

4- Ejecutamos el script de configuración del DSC Pull el cual podemos decargar desde la siguiente url de github
https://github.com/adbertram/Random-PowerShell-Work/blob/master/DSC/SetupDscPullServer.ps1

5- Copiamos los ficheros MoF los cuales queremos publicar a nuestros clientes de dsc y que ya explicamos como configurar de manera detallada en entradas posteriores de la serie en el siguiente directorio
C:\Program Files\WindowsPowerShell\DscService\Configuration

De una manera muy simplificada estos serían los pasos a realizar, aunque me gustaría recomendaros la lectura del siguiente artículo si quereis profundizar un poco más en los mismos.

http://blog.pluralsight.com/powershell-dsc-pull-server

Espero que resulte de utilidad

Un saludo

Power Shell Desired State configuration (DSC) – Aplicando las configuraciones

Buenas,

En este post de la serie me gustaría hablaros sobre el procedimiento para aplicar las configuraciones definidas mediante DSC. Aunque es perfectamente posible aplicar las configuraciones usando un Pull server el cual se encargará de aplicar las configuraciones definidas mediante DSC en los nodos destino, en este caso veremos cómo aplicar las configuraciones de manera manual en nuestros nodos destinos partiendo del fichero MOF y haciendo un push.

Antes de meterme en harina con este post me gustaría recomendaros la lectura de las dos primeras entradas de la serie:
Power Shell Desired State configuration (DSC) – Introducción Teórica
Power Shell Desired State configuration (DSC) – Recuros y Generación del fichero MOF

Primero que todo me gustaría mencionar que existen dos métodos de aplicar las configuraciones definidas mediante DSC. El primero de ellos sería mediante Pull y en la cual necesitaríamos apoyarnos en pull server el cual es consultado por los nodos de DSC para recibir dichas configuraciones, es cierto que este método añade un modo de automatización adicional a la hora de aplicar las configuraciones de dsc y suele ser la mejor opción en la mayoría de los escenarios. La segundo de los métodos sería mediante Push, con este método aplicar las configuración definidas mediante dsc de manera manual en nuestros nodos destinos, si bien esta opción requiere ejecutar un par de comandos de powershell en los los nodos donde queremos aplicar la configuración, será la mejor opción cuando queremos testear una configuración definida mediante DSC o cuando queremos aplicar una configuración la cual por algún motivo solo se debe aplicar una vez.

Como ya adelante al principio de este post, en este ocasión me centrare en el procedimiento para aplicar de manera manual mediante push las configuraciones definidas en el fichero mof y será en la siguientes entradas de la serie en las que veremos configurar un servidor de DSC el cual se encargará de hacer un pull de las configuraciones

Una vez hecha esta breve introducción teórica paso a detallar los dos requerimientos que deben tener los nodos donde queremos aplicar las configuraciones definidas mediante.

1- Tener en el nodo destino los recursos de DSC necesarios para recibir la configuración: En el segundo post de la serie podéis encontrar información detallada sobre los recursos de DSC. Como regla general podemos decir que si usamos recursos que vienen por defectos estos probablemente estén incluidos en nuestro nodo corriendo bajo Windows server. Sin embargo, si hemos descargado algún recurso personalizado este deberá ser copiado en el nodo destino antes de aplicar las configuraciones de DSC

2- PowerShell remoting habilitado: Para saber si PowerShell remoting está habilitado podemos usar la función de PowerShell detallada en el siguiente link

Llegados a este punto pasamos a ver los pasos que debemos seguir para hacer un push de la configuración de DSC en nuestro nodo destino, los cuales serían los siguientes:

1- Copiamos el ficheros mof al nodo donde queremos aplicar las configuraciones

2- Aplicamos la configuración ejecutando el siguiente comando:
Start-DSCConfiguration -Path ‘C:\TestDSC’ -Wait –Verbose

Espero que resulte de utilidad, en la siguiente entrada de la serie veremos cómo configurar el pull server.

Un saludo

Los Jueves Tecnológicos de Itpro.es – Serie de Webcast

Buenos días

Desde la comunidad Itpro.es estamos organizando una serie de webcast que dará comienzo el próximo jueves 28/01 con el primero de los webcast de la serie y que se extenderá durante 8 semanas todos los jueves de 19:00 a 20:00.

Todos los ponentes de estos webcast somos Microsoft MVP o empleados de Microsoft y la temática de los mismo es bastante diversa pero siempre tratando temas candentes en el mundo de los ITpros

En el siguiente link podéis encontrar información acerca de las temática, ponentes y fechas de los distintos webcast para registraros en los que os parezcan más interesantes.

Link webcasts – Jueves tecnológicos de Itpro.es

Espero que os resulten interesantes.

Un saludo

Power Shell Desired State configuration (DSC) – Recuros y Generación del fichero MOF

Buenas,

En esta segunda entrada de la serie veremos como usar los recursos de DSC los cuales nos permitirán generar ficheros MOF, estos ficheros serán los que tendrán las configuraciones que posteriormente aplicaremos mediante DSC en nuestro entorno.

Antes de iniciar este post me gustaría recomendaros la lectura de la primera entrada de la serie en la cual introducía DSC de manera un poco más teórica con el objetivo de aclarar los conceptos principales de esta tecnología. Este artículo podéis encontrarlo en el siguiente link

Para entender de manera correcta como debemos proceder para crear un fichero MOF es necesario primeramente entender el papel que juegan los recursos en el mismo. Un recurso funciona de una manera similar a un cmdlet de PowerShell y define las funcionalidades que se podrán aplicar en un fichero MOF. Por defecto DSC incorpora una serie de recursos los cuales nos permiten definir configuraciones en los elementos listados a continuación:

– Procesos de Windows
– Funcionalidades de Windows
– Gestión de usuarios locales
– Servicios
– Script
– Registro
– Gestión de paquetes (MSI & EXE)
– Log
– Gestión de grupos locales
– Variables de entorno
– Carpetas y ficheros

Por supuesto existe la posibilidad de descargar recursos adicionales a los incorporados por defecto teniendo en cuenta que los ficheros MOF se basan en un standard definido por la industria.

Una vez hecha esta breve introducción sobre los recursos de DSC, veremos donde podemos descargar dichos recursos así como el procedimiento de instalación de los mismos.

Aunque los recursos se pueden encontrar en diversos sitios de internet y basta con hacer una búsqueda en nuestro buscador preferido para encontrarlos, me gustaría dejaros un par de links a dos sitios que considero interesantes y los cuales suelo usar para buscar recursos.

– Technet gallery recursos para IT profesional
https://gallery.technet.microsoft.com/site/search?f%5B0%5D.Type=Tag&f%5B0%5D.Value=DSC%20Resource%20Kit&f%5B0%5D.Text=DSC%20Resource%20Kit
– Apartado de DSC en Github
https://github.com/PowerShellOrg/DSC

Una vez tenemos descargado el recurso de DSC que queremos instalar, el procedimiento de instalación es super sencillo. Tan solo debemos descomprimir los archivos descargados y copiarlos en el directorio C:\Program Files\WindowsPowershell\Modules de la máquina que usaremos para crear los archivos MOF

Llegados a este punto ya debemos de tener la máquina de desarrollo que usaremos para crear los ficheros MOF lista para realizar a esta tarea, por lo tanto abrimos Power Shell ISE donde procederemos a crear el fichero MOF.

Como ya mencione anteriormente los ficheros MOF esta basados en un standard definido por la industria pero se pueden crear y editar perfectamente usando PowerShell y el tener conocimiento de PowerShell nos facilitará muchísimo su creación. Para explicar la estructura de estos ficheros usare el siguiente fichero de ejemplo el cual tiene como objetivo forzar la instalación del cliente telnet mediante DSC.

Como podéis observar el fichero tiene tres partes claramente diferenciadas. Una primera parte que empieza en el comienzo del script y acaba en el final del mismo define donde comienza y acaba la configuración. La segunda parte que define los Nodos sobre los que se aplicará la configuración y la tercera indica las configuraciones que realizaran (en nuestro caso forzará a que el cliente telnet se encuentre presente)

Por último, una vez tenemos definida la estructura del fichero de configuración, guardamos el mismo con extensión .ps1 y lo ejecutamos para generar el fichero MOF.

Estos serían todos los pasos que debemos realizar para crear un fichero MOF de DSC, en la siguiente entrada de la serie veremos cómo aplicarlos en un máquina.

Espero que resulte de utilidad.

Un saludo