Palabras prohibidas en contraseñas en entornos híbridos Azure AD y WSAD

 

Hola, 

A pesar de que está a la vista y es fácil de implementar, pocas o ninguna vez he encontrado la hibridación de la configuración avanzada de política de contraseñas entre Azure AD y Windows Server Active Directory.

En la ruta; Azure AD - Seguridad - Seguridad - Métodos de autenticación - Protección con contraseña, encontramos las opciones donde podemos bloquear al usuario tras 10 intentos, por defecto, fallidos durante en un principio 60 segundos. 

En este lugar, podemos también configurar una lista personalizada de palabras prohibidas en la contraseña, lo cual es realmente útil. Lo que nos permite además, si contamos con un entorno Windows Server Active Directory, descargar el software   que tras ser instalado en el DC o bien en un servidor que "vea" al DC y por otro lado, tenga acceso limitado a internet (Implementación de la protección con contraseña de Azure AD local - Microsoft Entra | Microsoft Learn) nos hace llegar la lista de palabras prohibidas personalizada a los cambios de contraseñas que se produzcan en el ámbito On premises.

AzureADPasswordProtectionProxySetup.exe

Realmente, el procedimiento de validación de contraseñas con palabras prohibidas, no funciona como todos creemos pensar, a continuación lo explicaré y realmente es algo más importante aún, conocer que previamente a la comprobación de nuestra lista predeterminada, Azure AD, comprueba la existencia de palabras prohibidas en una lista global que mantiene el fabricante.

De hecho, La comprobación de una contraseña para su aceptación en un entorno híbrido o solo cloud pasa por las siguientes comprobaciones: 

 

• Toda contraseña introducida se comprueba, antes de su aceptación, en una lista de contraseñas globales prohibidas, añadiré algo extraño y es que de contener una palabra de la lista. a la contraseña se le otorga un punto.
• Tras esto, se comprueba si la contraseña contiene una palabra prohibida de nuestra lista personalizada y de existir, se otorgará un punto.
• La contraseña pasa por un proceso de normalización, se convierten mayúsculas por minúsculas, se asociada cada letra a similares como a = @  o = 0 y se componen todas las variaciones posibles.
• Se crean variaciones para evitar contraseñas aproximadas
• Si la contraseña anterior era por ejemplo Alicante01 se comprueba si se trata Alicante10 o ej. abcdeg o abcdefg de existir esto se otorgaría un punto.
• Se comprueba si esa misma contraseña ha sido utilizada por el usuario anteriormente y de ser así se prohíbe.
• Se comprueba si la contraseña coincide con su nombre,  apellido o similitudes de información personal:  Miguel  o Miguel123 o aaaHern@ndez por ejemplo y de ser así, se otorga un punto.

Proceso de puntuación de contraseñas:

 

• Proceso de puntuación para aceptaciones o denegaciones.
• Por ejemplo una contraseña larga que contenga palabras prohibidas podría aceptarse
• Una contraseña que contenga su nombre tiene un punto
• Una contraseña que contenga una contraseña previamente utilizada un punto
• Cada palabra prohibida encontrada en una cadena  tiene un punto
• Cada carácter no prohibido encontrado tiene un punto
• La contraseña ha de tener 5 puntos o más.

Ejemplo:

 Prohibimos Alicante en la lista de palabras prohibidas y tratamos de utilizar  Al1c@nt3AN

                Al1c@nt3= 1 punto

                A = 1 punto

                N = 1 punto

                Total 3 puntos, la contraseña no se admite.

 

En cambio Al1c@nt3Aaaa

             Al1c@nt3 = 1 punto

Aaaa = 4 puntos (4 caracteres)

Total  5 puntos Al1c@nt3Aaaa se admite a pesar de estar Alicante prohibida.

Como apunte avanzado, revisa la documentación si dispone de varios bosques de WSAD on premises.

https://learn.microsoft.com/es-es/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy#read-only-domain-controller-considerations

Evitar "MFA Fatigue attack" en Azure AD

 

Hola, 

Estamos asistiendo a un aumento de ataques MFA Fatigue, el cual como ya sabréis, se basa en ingeniería social, mandando al usuario una gran cantidad de validaciones MFA hasta que este, aceptar por error una de ellas. 

Evidentemente para poder realizar este ataque, hay que conseguir la contraseña del usuario y para evitar esto, lo mejor es activar Passwordless en todos los accesos que solicitan validación al usuario. Sobre esto hablaré en otro post.

Respecto a la parte más directa de este ataque, he recopilado una serie de opciones que existen en Azure AD y que evitarán el ataque a usuarios en nuestro tenant. Las opciones que indico a continuación, existen en practicamente todos los directors cloud, como puede ser Ping Identity, Okta, Gsuite, etc. y por tanto son igualmente aplicables.

Bastionado de tenant resistente a MFA Fatigue

Protección ante inicios de sesión en riesgo

La primera opción y para mí fundamental es configurar la proteeción ante riesgos en el login. Para esto es necesario Azure AD P1, pero creo que a día de hoy, vale la pena contar con esta licencia.

Protección del inicio de sesión de usuario basada en el riesgo en Azure Active Directory - Microsoft Entra | Microsoft Learn

Bloqueo de cuenta tras X intentos 

Por otra parte, lo esencial en cualquier tenant, sería configurar el bloqueo de cuenta tras un número de denegaciones por parte del usuario y situar este umbral bastante bajo. no más de 3-5 solicitudes denegadas del usuario. Cabe destacar que viene sin configurar, lo cual me parece un fallo por parte de Microsoft.

Esto lo tenéis en Azure Active Directory -> Seguridad -> Autenticación multifactor -> Bloqueo de cuenta.

Alertas de fraude

Otra opción efectiva es la de ofrecer en el aviso a los usuarios la posibilidad de denunciar un fraude y posterior bloqueo de la cuenta durante unos minutos.

MFA coincidencia de números

Una de las opciones más efectiva, es la coincidencia de números e información de localización que está actualmente en Preview para MFA, pero que en el caso de la primera, llevamos disfrutando desde hace mucho tiempo lo usuarios con paswordless.

Estas opciones de push avanzado de MFA están soportadas tanto en escenario cloud, como en escenario híbrido con complemento NPS y validación ADFS.

Para activar estas opciones, tenemos que ir a Azure Active Directory -> Seguridad -> Métodos de autenticación -> Microsoft authenticator -> Configurar -> Requerir coincidencia de números y Mostrar la ubicación geográfica en notificaciones Push.

Esto propiciará que en el MFA aparezca la siguiente información. Obligando al usuario a introducir un número aparecido en pantalla a quien propicie la llamada al MFA.

Evidentemente, como digo siempre, todo esto hay que combinarlo con control de acceso mediante equipos corporativos y delimitación de la posibilidad de realizar login en nuestras aplicaciones asociadas a Azure AD, desde localizaciones y/o países válidos para nuestra empresa.

También es importante no tener asignados roles y hacer uso de PIM.

Saludos.

Tratando de evitar ataques AITM (Adversary in the middle) a identidades cloud.

 

Dado que está resultando realmente exitoso para los atacantes. Empresas como Zscaler y el mismo Microsoft, han publicado diversos estudios y análisis sobre los ataques que se están llevando a cabo mediante AITM. Este formato consiste en situarse entre el usuario y el portal de validación para recoger una cookie de inicio de sesión que prevalece válida mientras dura la sesión del usuario validado.

Links de los estudios:

AITM Attack Targeting Microsoft Email Users | Zscaler

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog

Una vez he repasados estos estudios, destaco lo siguiente. 

Los ataques se están produciendo con aplicaciones tales como: Evilginx2 -utilizado en mi video- Muraena y Modlishka. Todos ellos funcionan siendo un proxy entre la víctima y el servicio de destino, pudiendo ser desde Spotify hasta O365, pasando por Paypal, Instagram, Twitter, etc.

Buscando soluciones a este ataque, primeramente veo que como casi todo phising, suele llegar vía correo electrónico indicando al usuario que ha de validarse en una url. Por lo que aconsejo la puesta en marcha de Safe Links en Advanced Threath Management que forma parte de la protección avanzada de Microsoft Defender.

La diferencia entre Defender y Defender en versión avanzada, es que el segundo, protege al hacer click en urls peligrosas a día del mismo click en correos pero que pasaron a la bandeja de entrada del usuario, siendo validadas por un Defender más básico y no declarar estas peligrosas, por no estar localizadas en ese momento.

También observé en el piloto que construí, que Google Chrome marcó bastante antes mi URL maliciosa -yo registré el dominio Outloook.tk- mientras que Edge tardó algo más de 24 horas en avisarme.

A día de hoy, se mantiene activa una list de dominios utilizados como urls proxy que se puede consultar aquí: https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.

Dado que en los análisis hechos por Zscaler existen inicios de sesión tras 8 minutos después de robar al  usuario su información y no existen registro de acciones realizadas, como pueden ser enviar mails u otras y viendo también en mi piloto, que el software proxy me devolví la contraseña del usuario en texto plano. Me inclino a pensar que el atacante, registra un nuevo segundo factor en la configuración del usuario, para garantizarse futuros accesos con su usuario y contraseña + doble factor registrado.

Protección en Azure AD ante este ataque

Una vez el correo ha llegado al usuario y mientras nuestro sistema de detección de URLs no indique que la dirección es peligrosa, Estamos expuestos a que el usuario haga click y se valide en la ventana de login, por lo que cabe entender el funcionamiento de Azure AD en cuanto a la sesión del usuario, para protegernos ante la adquisición de la cookie.

PIM

Por supuesto, ya que nos podemos caer en la trampa y nos pueden secuestrar una credencial. Lo que es muy aconsejable es que ninguna de ellas, tenga roles privilegiados asociados. Esto lo conseguimos utilizando y activando PIM, tal y como expliqué en este Webinar.

De forma general podemos tener en cuenta lo siguiente:

Situación de riesgo	Herramienta para la remediación
El mail llegó al buzón del usuario y días después, habiendo sido marcado el dominio como peligroso, aun pudo hacer click visitando la web del atacante.	Activación de Advanced Threath Management para garantizar control de urls actualizado en el día del acceso.
La propia realización de inicio de sesión. Acceso por parte del atacante al existir una regla de permisividad del Login, excesivamente abierta. Permitiendo acceso desde su localización, lugar y dispositivo.	Este login se ha podido realizar al cumplir reglas, las cuales por defecto son, “cualquier parte del mundo”, “cualquier lugar”, cualquier dispositivo”. [1]   Se aconseja la creación reglas de acceso condicionar para delimitar países, lugares específicos como la oficina y dispositivos, distinguiendo entre logins desde equipos corporativos, sincronizados con AdConnect y considerados híbridos, y los no corporativos, considerados Register en Azure AD.
Posibilidad del inicio de sesión del atacante durante el periodo de validez de la cookie.   La cookie es válida mientras la sesión no se revoque.	Requerir re autenticación cada cierto tiempo si se realiza en equipos no corporativos.   https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency-and-multifactor-authentication
Uso de sistema multifactor que genera cookie atacable	Usar sistemas multi factor que no generen cookie:  Fido2 Security Keys Windows Hello for Business Certificado  El resto, sms, llamada y mobile app, generan cookie utilizable.

[1]Reglas condicionales efectivas

Método	Protección
Requerir dispositivo como “compliant”	Protege
Requerir dispositivo híbrido o unido a Azure AD	Protege
Regla condicional de control de sesión	Protege solo durante una ventana de tiempo
Regla condicional en la que permitir login solo desde sitios de confianza	Protege

Saludos

Asignar licencia de M365 por pertenencia a grupo en Azure AD

Hola, 

A continuación os detallo los pasos para asignar licencias de forma automática por pertenencia a grupos de Azure AD o AD sincronizados.

Licencias M365 Apps por device

El funcionamiento de asignación de licencias O365 apps por dispositivo, es el mismo que se describe a continuación, pero deberemos incluir equipos en el grupo correspondiente, en vez de usuarios. Tras eso, ya podremos desplegar Office 365 apps (anteriormente proplus) y este software será activado por dispositivo.

Para la poder inlcuir equipos en grupo de auto asignación de licencias, deberías habilitar la sincronización de dispositivos en Ad-Connect.

Licencias M365 por Usuario

Necesitas contar con licencia P1 o E5 pero con tener una se habilita la opción...

1. Ir a la opción "Licenses" en Azure AD.

2. Dentro de la opción elegida, hacer click "All groups" y luego en el tipo de licencias que queréis asociar al grupo.

3. Tras esto has de elegir "Users and Groups" y en el menú de la derecha elegir el grupo que queréis asociar.

4. Después de elegir el grupo, tenéis que hacer click en "Assignment options" y elegir las opciones de la licencia que queréis aplicar.

Con esto ya estaría. Una licencia se asignará a cada usuario perteneciente al grupo.

Debéis tener en cuenta que toda licencia asignada a un usuario mediante grupo, no podrá ser retirada de un usuario directamente, para eliminar la licencia asignada habrá que retirar al usuario del grupo.

Saludos.

Doble Factor (Azure AD) en Servicio Remote Desktop Gateway

Hola,

En el siguiente post, quiero detallaros como añadir doble factor de validación a la hora de conectar a vuestra granda Remote Desktop Services desde el exterior, haciendo uso del rol Remote Desktop Gateway.

Con este post quiero enriquecer comentando algunos aspectos que al seguir la información oficial, pueden pasar desapercibidos e incluso pueden provocar que os atasquéis. Esta información oficial la tenéis aquí: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-rdg

A continuación os detallo los elementos necesarios.

Infraestructura Onpremise:

1. Directorio activo sincronizado con Azure Ad mediante Ad-Connect u otros software de sincronziación.
2. Servidor RDG con rol Remote Desktop Gateway
• Rol Remote Desktop Gateway (RDG) en un servidor publicado a internet a través del puerto 443.
• Servicio Network Policy Server (NPS) Local del servidor Remote Destkop Gateway- (Importante conocer que este servicio existe y se activa automáticamente al añadir el rol RDG)
3. Servidor NPS donde habilitar el rol Network Policy Server, que conectaremos con Azure AD
• Descargar e instalar el software NPS Extension: https://www.microsoft.com/en-us/download/details.aspx?id=54688

Azure AD:

1. Activar MFA en usuarios sincronizados.
2. Obtener el Azure AD ID -  Azure Active Directory - Propiedades.

A continuación podéis ver los pasos de configuración.

Configuración: 

Servidor NPS:

• Abrir Powershell como administrado
• Ir a la ruta c:\program files\microsoft\azureMfa\config
• lanzar el script: AzureMfaNpsExtnconfigSetup.ps1

Errores conocidos: 

•  Si tienes Ws 2016 puedes econtrar problemas en la descarga del paquete: https://undercpd.blogspot.com/2020/04/install-package-failed-to-download.html
•  Si tienes Windows Server en un lenguaje que no sea inglés, puedes encontrar un error. El script trata de dar privilegios de acceso a la clave privada del certificado generado a  la cuenta "Network Service" cuando en español la cuenta es "Servicio de red", por lo que una vez el script te devuelve el error, puedes hacer este paso a mano. Por ejemplo podéis seguir este procedimiento https://docs.secureauth.com/display/KBA/Grant+Permission+to+Use+Signing+Certificate+Private+Key Tened en cuenta que el grupo no es Authenticated users como muestra esa guía.

Servidor RDG:

•  Ir a Inicio - Herramientas administrativas - Remote Desktop Services - Administrador de puerta de enlace de Escritorio Remoto
•  Click en Propiedades sobre botón derecho sobre el nombre del servidor 
•  Solapa Almacén de Cap de RD

•  Añadir nombre de servidor NPS - Agregar Frase secreta compleja y de vuestra invención.
• En el servidor RDG (no configundir con servidor NPS) abrir consola NPS. Inicio - Herramientas administrativas - Servidor de directivas de red. 
• Ir a Clientes y Servidores RADIUS - Grupos de servidores remotos RADIUS
• A la derecha ha de aparecer TS GATEWAY SERVER GROUP . Si no apareciese por favor actualizar ya de requiere unos minutos.
• Doble click sobre dicho grupo
• Comprobar que aparece el servidor NPS - Hacer click sobre él y click en Editar
• click en la solapa Equilibrio de carga
• Aumentar los segundos de solicitud e identificación a 60.
• 
• Aceptar todas las ventanas abiertas
• Cerrar consola NPS

Servidor NPS:

• Abrir Consola NPS - Inicio - herramientas administrativas - Servidor de directivas de redes
• Botón derecho sobre NPS (Local) y hacer click en Registrar servidor en Active Directory
• Dobre Click en Clientes y Servidores Radius
• Botón derecho sobre Clientes RADIUS - click en Nuevo
•  Dirección IP : Nombre de servidor RDG
• Introducir mismo secreto compartido que se introdujo en el servidor RDG
• Doble click en Directivas y directivas de red
• Botón derecho sobre la directiva "Connections to other access Servers
• Click en duplicar directiva
• Botón derecho - Propiedades sobre la directiva duplicada aparecida
• Modificar nombre
• Click en Directiva Habilitada
• Click en Conceder acceso
• Click en solapa Restricciones
• Métodos de autenticación
• marca la casilla Permitir a los clientes conectarse sin negociar un método...
• Click en la solapa Condiciones
• Agregar  condición incorporando a un grupo de usuarios de directorio activo, como grupo permitido para la conexión.
• Aceptar las ventanas aparecidas.

Tras esto, ya podréis probar la configuración de la conexión a través de RDG a un equipo en la red.

Saludos. 

Atributo de Exchange en Active Directory con O365

Hola,

Es muy probable que tengáis un escenario con O365 sincronizado con un AD clásico vía ADConnect en el que no haya estado nunca instalado Exchange.

En este escenario descrito, no encontraréis en los usuarios y grupos locales, ciertos atributos que si están en el objeto de Azure AD, pero que allí arriba, no podéis variar, dado que el objeto está sincronizado desde el AD Clásico.  Además, cambiar el valor de estos atributos, es necesarios para poder conseguir ciertas funcionalidades, como evitar que al usuario o grupo le llegue correo externo, desaparezca de la libreta global de direcciones, etc.

Solución

Pues bien, para poder tener a vuestro en vuestro AD local los atributos que estáis viendo desactivados en O365, tenéis que ampliar el esquema utilizando la instalación de Exchange Server 2016. Yo de hecho pienso que cabría hacerlo por defecto en toda instalación nueva de ADConnect.

1. Para realizar esto, tenéis que conseguir el DVD de instalación de Exchange. El cual anteriormente era público pero ahora, para disponer de él, tendréis que recurrir a una suscripción MSDN o similar.

2. Iniciar sesión con un administrador del dominio. Mi consejo es que si no tenéis a mano el administrador original del dominio, copieis este creando uno nuevo. Los usuarios que han sido itnroducidos en grupo Admin del dominio, Administador de esquema, etc. no suelen funcionar.

3. Una vez descomprimido su contenido en el disco del DC que es Administrador de esquema (netdom query fsmo es el comando que tenéis que lanzar para saber qué DC es el administrador de Esquema) y con el CMD como administrador abierto. tenéis que lanzar el siguiente comando:

- .\Setup.exe /PrepareSchema /IAcceptExchangeServerLicencesTerms

4. Actualizar el Schema en ADConnect

y con esto, tendremos los atributos necesarios en los usuarios: