Buenas Prácticas para Securizar nuestros Domain Controllers (1 de 2)

Buenas,

Comenzamos hoy una serie de 2 artículos en los que me gustaría exponer una serie de buenas prácticas o recomendaciones para mejorar la seguridad en nuestros controladores de dominio, lo cual será un elemento fundamental para mejorar de manera sustancial la seguridad del dominio.

Estos articulo pretende dar una serie de recomendaciones pero no ir paso a paso al detalle de cómo implementar las mismas puesto que por el contrario los artículos serían demasiado largos y bastante complejos de leer y seguir.
Una vez hecha esta breve introducción y definido el ámbito de los articulos paso a detallar las buenas prácticas que yo considero fundamentales para mejorar la seguridad de nuestros controladores de dominio.

1– Parchear los controladores de dominio: Aunque pueda parecer muy básica no todo el mundo lo hace. Los parches de seguridad de Microsoft corrigen números vulnerabilidades en los controladores de dominio y es muy importante mantener los mismos actualizados.

2– Reducir el número de Domain Admins al mismo posible y usar las credenciales de Domain Admins solo cuando es necesario: Para proteger nuestros controladores de dominio y nuestro dominio en general debemos tener en el grupo Domain admins únicamente las cuentas de adm de los administradores del dominio y no ninguna otra persona de it de nuestra organización y por supuesto ningún usuario estándar. Igualmente es importante remarcar que los administradores de dominio también tendrán una cuenta estándar para su trabajo rutinario y que solo usarán la cuenta de domain admin para realizar tareas administrativas en el dominio.

3– Proteger las cuentas de servicio con permisos de Domain Admins: Si por algún motivo tenemos la necesidad de que una cuenta de dominio tenga permisos de Domain admins debemos proteger la misma. Intentando definir Manged service accounts siempre que sea posible o definir contraseñas complejas (más de 25 caracteres) y asegurar que el cambio de la misma sucede al menos 2 veces por año.

4– Implemente fine grained password para los Domain Admins: Los requisitos de complejidad y vigencia de la password de un Domain Admins no puede ser nunca los mismos que los de un usuario estándar, por lo tanto es muy recomendable define políticas de fine grained password policy con complejidad alta y vigencia de password corta para los Domain Admins

5– Configurar inactive log-off sesión para Domain Admins: en las cuentas de Domain Admins también será una muy buena práctica forzar el logoff de la sesión tras 10 minutos de inactividad con el objetivo de asegurar que no dejamos sesiones de administador inactivas las cuales podrían ser comprometidas.

En el siguiente artículo de la serie detallaré otras 5 buenas prácticas para mejorar la seguridad en nuestros domain contollers.

Espero que resulte de utilidad

Un saludo

Premium Assurance – Extensión de soporte para Windows Server y Sql 2008

Buenas,

Hoy me gustaría hacer eco de una noticia que publico Microsoft a finales del 2016 la cual tiene una gran relevancia de cara a la planificación de actualización o migración ya sea on-premises o al cloud de los sistemas actuales corriendo bajo Windows server y sql Server 2008. Está noticia la cual creo que es bastante relevante, creo que también es general desconocida para la mayoría de los administradores de la plataforma Wintel.

Como todos o la mayoría de nosotros sabemos, el soporte extendido de Sql server 2008 termina en julio del 2019 y el soporte extendido de Windows server 2008 R2 termina en Enero de 2020, lo que nos llevaba a la necesidad de comenzar a pensar y planificar en la actualización o el remplazo de los sistemas corriendo bajo estas versiones.

Sin embargo Microsoft a finales del pasado año anuncio Windows server Premium assurance y sql server Premium assurance, lo cual es un paquete que estará disponible para los clientes de software assurance el cual permitirá ampliar el soporte de Windows server 2008 y sql server 2008 hasta 6 años más como podéis ver en la imagen adjunta.

Igualmente debemos saber que Premium assurance evidentemente tendrá un coste el cual comenzará con 5% de la licencia y se irá incrementando de manera anual hasta un máximo de un 12% de licencia del producto habilitado con esta funcionalidad y que durante este periodo Microsoft proporcionara parches críticos y high y posibilidad de abrir casos de soporte.

Creo que con lo mencionado anteriormente quedaría bastante claro este tema, no obstante adjunto el enlace al anuncio oficial de Microsoft.

https://blogs.technet.microsoft.com/hybridcloud/2016/12/08/introducing-windows-server-premium-assurance-and-sql-server-premium-assurance/

Espero que resulte de utilidad

Un saludo

Funcionamiento del AdminsdHolder en Directorio Activo

Buenas,

A raíz de una consulta que he recibido esta semana por mail me gustaría aprovechar para comentar que es AdminsdHolder y como está relacionado el mismo con la consulta que he recibida esta semana.

En la consulta que recibí me preguntaban sobre la manera para delegar un grupo de directorio activo para que los miembros del mismo pudieran agregar y eliminar miembros del grupo account operators puesto que definían los permisos editando la seguridad del grupo account operators y al rato se deban cuenta de que las acls del mismo habían vuelto a tener los valores iniciales.

La explicación de todo esto se basa en el Adminsdholder, puesto que este es un mecanismo de seguridad que se ejecuta cada hora en los dcs el cual define los permisos de los grupos de protegidos con la misma definición de permisos definida el Adminsdholder con el objetivo de garantizar la seguridad de los grupos protegidos de directorio activo como pueden ser Enterprise admin, domain admins, schema admins, account operators y server operators.

Como normalmente las imágenes suelen ser más explicativas que las palabras pasamos a realizar una demostración.

1- En un entorno de demo he añadió la cuenta testsam con permisos de control total en la cuenta del Enterprise admin

2- Al volver a comprobar un poco más tarde podemos observar que la acl de seguridad de la cuenta del Enterprise admin se ha vuelto al valor inicial.

3- Si Abrimos la consola de usuarios y equipos de directorio activo y vamos system, adminsdholder y accedemos a sus propiedades para ver la opciones de seguridad observamos que son las misma que se han definido al usuario del Enterprise admin

Con esto quiero explicar que si por algún motivo queremos modificar los permisos de las grupos a las cuentas protegidas debemos de modificar los permisos del adminsdholder y siempre aplicarán a todas las cuentas y grupos protegidos, por lo que será muy recomendable dejar estos valores por defecto y definir la de otra manera sin usar cuentas y grupos protegidos.

Espero que resulte de utilidad.

Un saludo

Servicios de directorio activo gestionado en la nube: AWS Directory Service for Microsoft Active Directory & Azure Active Directory Domain Services

Buenas,

Hoy me gustaría hacer el último post de año hablando de AWS directory services for Microsoft active directory y Azure domain services.

Los servicios de directorio en la nube es algo que cualquier empresa mediana/grande en la actualidad debe considerar, sobre todo teniendo en cuenta la tendencia actual en la que la empresas actuales están consolidando cada vez más servicios en el public Cloud.
Si bien es cierto que tanto Amazon con Azure proveen una capa de servicios básicas de directorio en la nube la cual nos permite básicamente proveer de autenticación a nuestras aplicaciones modernas y servicios Cloud, hoy me gustaría ir un paso más adelante y hablar del servicio de directorio activo gestionado que proveen tanto Amazon como Azure bajo los nombres de AWS de Directory Services for Microsoft Active Directory & Azure Active Directory Domain Services. La diferencia principal entre el servicio de directorio básico y el servicio gestionado de directorio activo reside en que el servicio básico de directorio activo nos permite proveer de autenticación a aplicaciones modernas (cloud), sin embargo si queremos realmente disponer del servicio de directorio activo gestionado en la nube y autenticar en aplicaciones legacy con kerberos, ldap o NTLM y disponer de funcionalidades como domain join o gpos nuestra opción pasará por contratar y usar un servicio de directorio activo gestionado en la nube.

Una vez resumidas las diferencias entre un servicio de directorio básico en la nube y un servicio de directorio activo gestionado, me gustaría dar algo más de detalles acerca de la funcionalidades soportadas tanto por AWS Directory services for Microsof Active Directory como por Azure Active Directory domain services, ambos productos son muy similares por no decir iguales en cuanto a funcionalidades, soportando ambos las siguientes funcionalidades:

– Monitoring: Ambos proveedores de cloud proveen monitorización de la disponibilidad y del rendimiento del servicio.

– Alta disponibilidad: Ambos servicios gestionados despliegan dos controladores de dominio para proveer alta disponibilidad a la solución

– Backup: Se realizan backup periódicos del servicio gestionado y tenemos posibilidad de realizar una recuperación

– Domain Join: Nos permite conectar los servicios corriendo en la nube a los servicios de directorio activo gestionado

– Ldap, NTLM & keberos support: Quizas la funcionalidad que nos haga decantarnos por los servicios de directorio activo gestionado la cual posibilita el movimiento de aplicaciones legacy al public cloud.

– Creación de relaciones de confianza: Ambos soluciones nos permiten crear relaciones de confianza con nuestro dominio on-premises.

– Extensión de Esquema: Si tenemos aplicaciones que requieren de una extensión de esquema para funcionar podremos realizar dicha extensión de esquema a nuestro directorio activo gestionado en el cloud

– GPos y DNS: Ambos servicios de directorio nos permiten crear gpos e interactuar con el servicio de dns

– Uso de las herramientas de administración tradicionales:
La administración/gestión del servicio de directorio gestionado en la nube se realiza principalmente con las herramientas tradiciones de administración como son la consola de usuarios y grupos de directorio activo, la consola de dns y la de gpos.

Como podéis observar ambos servicios son iguales en lo referente a funcionalidades y desde mi punto de vista los factores determinantes a la hora de decantarnos por uno u otro serán el precio y el proveedor en el que se ejecuten nuestra vms corriendo en el cloud en un módulo de Infrastructure as a service.

Espero que resulte de utilidad.

Un saludo

Mejoras de DNS en Windows Server 2016

Buenas,

En este post me gustaría explicar las principales ventajas incluidas en el role de DNS incluidas en Windows Server 2016. Como todos sabemos DNS es un servicio clave en cualquier red empresarial el cual nos permite realizar la resolución de nombres en nuestro dominio, o lo que es lo mismo convertir nombres en ips e ips en nombre si tenemos la resolución reversa activada. Igualmente es importante recordar que los servicios de Directorio Activo se basan y tienen una dependencia total del servicio de DNS, por lo tanto de una manera o de otra las nuevas funcionalidades de DNS incluidas en Windows Server 2016 también tendrán un beneficio colateral para Directorio Activo.

Bien, una vez hecha esta breve introducción pasamos a detallar las mejoras principales que trae dns en Windows Server 2016.

– DNS policyes: O políticas de DNS, nos permiten controlar la forma en la que los registros DNS responden a las querys de DNS, permitiéndonos por ejemplo controlar el bloqueo para solicitudes DNS conocidas como maliciosas.

-Response Rate Limit: Como su propio nombre indica nos permitir configurar un ratio de respuestas a las querys DNS en nuestros servidores, el objetivo principal de esta funcionalidad es proteger el servidor DNS contra ataques de denegación de servicio permitiendo limitar el número de veces por segundo que un servidor DNS puede responder a las querys de un determinado cliente.

– IPAM: Aunque esta funcionalidad ya estaba disponible en Windows server 2012 ha sido mejorada de una manera muy notable en Windows Server 2016. Dentro de las funcionalidades incluidas en IPAM 2016 destacaremos las dos siguientes:
– Incluye gestión del servicio de DNS e inventario de los registros host
– Soporta Gestión de más de un forest de directorio activo con una sola plataforma de IPAM: Como requerimientos mencionaremos la necesidad de tener una relación de confianza entre los forests y desplegar un servidor de ipam dentro de la plataforma en cada forest.

Espero que resulte de utilidad.

Un saludo

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