Hace varios meses, Microsoft añadió una característica al roadmap de Microsoft 365 que generó mucho interés. La función se llama Disable Basic Authentication in Exchange Online using Authentication Policies (Deshabilitar la autenticación básica en Exchange Online mediante Políticas de autenticación) y, como se indicó en los elementos del roadmap, permite a un administrador la posibilidad de definir protocolos que deberían permitir la autenticación básica.

¿Por qué fue tan interesante? Como probablemente sabrás, la autenticación básica en Exchange Online acepta un nombre de usuario y una contraseña para las solicitudes de acceso de clientes, y el bloqueo de la autenticación básica puede ayudar a protegernos de ataques de fuerza bruta en Exchange Online. Últimamente ha habido un aumento en la ocurrencia de este tipo de ataques, por lo que Microsoft aceleró su lanzamiento de esta función, ya que ayuda a prevenirlos.

Si una organización no tiene clientes de correo electrónico heredados o no desea permitir clientes de correo electrónico heredados, puede usar estas nuevas políticas de autenticación en Exchange Online para deshabilitar las solicitudes de autenticación básica. Esto obliga a todas las solicitudes de acceso de clientes a utilizar la autenticación moderna, lo que evitará que estos ataques afecten a su organización.

Todavía se está trabajando en algunos aspectos de esta función, pero en respuesta al aumento de ataques que estamos viendo, Microsoft ha querido que las políticas de autenticación ya estén disponibles para sus usuarios, y por lo tanto ya se está implementando esto en todo el mundo.

Ya hay un artículo excelente que describe cómo funciona esta función y recomendamos que se lea, comprenda y se siga el artículo antes de habilitar esta función.

Hay tres advertencias importantes a esta característica:

• Existe una falta de telemetría para los administradores de los tenants que nos informe sobre qué usuarios están utilizando Autenticación básica (y con qué protocolo), y una vez que se habilita un bloqueo, saber si realmente el tráfico fue bloqueado. En otras palabras, realmente no podemos saber si una restricción está funcionando correctamente.
• Un cambio de política puede tardar hasta 24 horas en hacerse efectiva, a menos que el administrador llame a un cmdlet (como Set-User) para cada usuario. Por lo tanto, es posible que el bloqueo no se inicie de inmediato y requerirá nuestra acción si deseamos que se aplique al instante.
• Si la identidad de un usuario no se ha replicado en Azure AD/Exchange Online, no se bloqueará, y por lo tanto, cualquier solicitud recibida por Exchange Online se enrutará a Security Token Service (STS) autorizado, donde es probable que falle. Este mismo comportamiento también significa que cualquier solicitud de autenticación para usuarios desconocidos en un tenant (como podría ocurrir durante un ataque de rociado de contraseña) también se reenviará al STS autorizado para el dominio.

El equipo de Exchange se había estado absteniendo de pasar de la preview privada a la pública, principalmente debido a los dos primeros puntos mencionados antes: Un administrador de un tentant podría configurar mal algo y no darse cuenta hasta que sea demasiado tarde, debido a la falta de informes y al efecto retardado del cambio de política.

Sin embargo, dada la frecuencia cada vez mayor de estos tipos de ataques, prefirieron dar acceso públicamente a la capacidad, sabiendo que todos leerán cuidadosamente la documentación antes de configurar. Se sigue trabajando para mejorar el conjunto de funciones, pero al menos ya no es necesario esperar más.

Es importante tener en cuenta que para los grandes clientes, aplicar el cmdlet a todos los usuarios que usan Exchange Online es un desafío, pero nuevamente creemos que el beneficio supera los aspectos negativos en esta etapa.

Es de nuestro interés prevenir que estos tipos de ataques pongan en peligro nuestros datos y usuarios, y esperamos que estas herramientas sean útiles y útiles. ¡Úsalos sabiamente!