Microsoft ha anunciado la retirada de la autenticación Basic para SMTP AUTH en Exchange Online, y los dispositivos que fallarán primero son aquellos que nadie recuerda haber configurado: escáneres, impresoras multifunción y viejos servidores de aplicaciones con la contraseña de un buzón escrita en un formulario web. El calendario de retirada se ha actualizado, así que consulte el último anuncio de Microsoft para conocer los hitos vigentes en lugar de fiarse de una fecha publicada en un blog, incluido este. El trabajo de inventario es el mismo sea cual sea la fecha.
Por qué este sigue abierto
La autenticación Basic ya se desactivó en Exchange Online para Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover y los clientes de Outlook. SMTP AUTH se dejó como estaba en los entornos donde se utilizaba y se deshabilitó en los tenants donde no.
Más del 97 % de los ataques de credential stuffing y más del 99 % de los ataques de password spray utilizan autenticación heredada, según el análisis de Microsoft recogido en su guía para bloquear la autenticación heredada.
SMTP AUTH lo utilizan los clientes POP3 e IMAP4 que necesitan enviar correo y las aplicaciones, servidores de informes y dispositivos multifunción que generan mensajes.
Encuentre lo que sigue usándolo
Puede que no encuentre nada. Si los valores predeterminados de seguridad (security defaults) están activados, SMTP AUTH ya está deshabilitado en Exchange Online, y también lo está en las organizaciones creadas después de enero de 2020, salvo que alguien lo haya habilitado por buzón.
En caso contrario, empiece por los registros de inicio de sesión. En el Microsoft Entra admin center, vaya a Entra ID > Monitoring & health > Sign-in logs, añada la columna Client App y filtre por los protocolos de autenticación heredada. Repita la operación en la pestaña User sign-ins (non-interactive), porque los dispositivos rara vez inician sesión de forma interactiva. El workbook Sign-ins using legacy authentication ayuda en el triaje.
Después, revise los buzones. La configuración por buzón prevalece sobre la de toda la organización, así que liste aquellos donde SMTP AUTH está habilitado de forma explícita:
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}Un valor en blanco significa que el buzón sigue la configuración de la organización, que puede comprobar con Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. A continuación, revise la página de "escanear a correo" de la impresora, la configuración de notificaciones del ERP, las herramientas de monitorización y copia de seguridad, y cualquier script programado que envíe un informe.
Asocie cada hallazgo a un responsable y anote la dirección de envío, el puerto, si el emisor está alojado por un tercero y si los destinatarios son internos o externos. Necesitará estos datos para elegir el sustituto.
A qué debe migrar cada uno
El destino adecuado depende de lo que el emisor sea capaz de hacer, de dónde se ejecute y a quién envíe correo.
| Emisor | Migrar a | ¿Alojado por un tercero? | Notas |
|---|---|---|---|
| Aplicación compatible con OAuth | Client SMTP submission con OAuth | Compatible | Puerto 587, TLS 1.2 o 1.3, buzón con licencia |
| Solo notificaciones internas | High Volume Email | Compatible | Puerto 587, cuenta HVE |
| Destinatarios internos, sin posibilidad de autenticación | Direct Send | Compatible | Puerto 25, actualizar SPF |
| Destinatarios internos y externos | Azure Communication Services Email | No incluido en la comparativa de Microsoft | Recomendación de Microsoft para este caso |
| Dispositivo sin OAuth, en su red | Relé SMTP mediante un conector | No compatible | Puerto 25, certificado o IP estática |
| Script a medida o código propio | OAuth 2.0 o la Graph API | Su propio código | Cambiar el código |
Microsoft recomienda OAuth para el client SMTP submission, y apunta a HVE para el correo exclusivamente interno y a Azure Communication Services Email para el correo interno y externo. Si dispone de un servidor de correo local, también puede hacer el relé a través de él, usando autenticación Basic contra ese servidor o un relé anónimo (no un relé abierto).
Compruebe antes el volumen. El envío con OAuth está limitado a 10 000 destinatarios al día y 30 mensajes por minuto. El relé SMTP no está sujeto a esos límites, aunque tiene sus propios límites razonables, y HVE no tiene límites de destinatarios ni de tasa de mensajes para el correo interno.
Impresoras y escáneres
Revise primero el firmware, ya que una actualización del fabricante puede añadir OAuth. Si no, la solución habitual es el relé SMTP basado en conector. No requiere un buzón con licencia, se autentica mediante certificado TLS (lo recomendado) o una IP pública estática que no comparta con otra organización, y usa el puerto 25 contra su endpoint MX.
El relé no guarda los mensajes en Elementos enviados y no omite el antispam, por lo que el correo sospechoso puede ser filtrado. Microsoft recomienda añadir una entrada al registro SPF, y puede revisar el registro con nuestro verificador de DMARC y SPF. Un dispositivo que utilice por defecto el puerto 465 no admite las versiones de TLS que exige el client SMTP submission, y uno sin TLS 1.2 no puede usarlo en absoluto.
Sistemas ERP y otras aplicaciones
Las aplicaciones de línea de negocio, como un ERP, son las más difíciles, porque el código de correo pertenece al proveedor. Pregunte si el producto admite OAuth 2.0 para SMTP o la Graph API. Si no, el relé mediante conector es la alternativa, siempre que la aplicación se ejecute en su propia red.
Si la aplicación la aloja el proveedor, el relé queda descartado: la tabla de Microsoft indica que el relé SMTP es el único método que no admite emisores alojados por terceros. El proveedor puede usar client SMTP submission con OAuth, HVE si el correo va solo a destinatarios internos, o Azure Communication Services Email. Direct Send también funciona con emisores alojados, pero no está autenticado, así que actualice su registro SPF para permitir que el proveedor envíe en nombre de su dominio.
Si la aplicación envía con una dirección distinta del buzón que inicia sesión, conceda el permiso Enviar como (Send As). Sin él, los mensajes rebotan con 5.7.60 SMTP; Client doesn't have permissions to send as this sender.
Scripts
Para los scripts que usted controla, Microsoft cita la Graph API como alternativa para el correo autenticado, o bien puede implementar OAuth 2.0 contra los endpoints IMAP, POP o SMTP.
Por dónde empezar
- Extraiga los inicios de sesión heredados de los registros de Entra, interactivos y no interactivos, y liste los buzones donde
SmtpClientAuthenticationDisabledsea$false. - Asigne un responsable a cada emisor y registre sus destinatarios (internos o externos), el puerto, la compatibilidad con TLS y si lo aloja un tercero.
- Elija un destino de la tabla anterior, pruebe un dispositivo de cada tipo y migre cada uno solo después de un mensaje de prueba satisfactorio.
- Tras la migración, ejecute
Set-TransportConfig -SmtpClientAuthenticationDisabled $true. Un buzón que siga en$falseprevalece sobre esa configuración, así que establezca cada uno en$null(sigue a la organización) o en$trueconSet-CASMailbox. Vuelva a ejecutar el filtro-eq $falsepara comprobar que no queda ninguno y confirme el valor de la organización conGet-TransportConfig. - Cree una política de Conditional Access que bloquee la autenticación heredada, configurada primero en modo Report-only, con al menos una cuenta de emergencia excluida.
Si el inventario revela más de lo que puede migrar a tiempo, nuestro equipo de consultoría puede ayudarle con la evaluación y el plan de migración.
