En este “PR4” vamos a abordar las siguientes consultas (entre paréntesis las iniciales de quien envió la pregunta):
- (XF) Tengo un problema con mail spoofing, hay alguna buena práctica para configurar Exchange?
- (RB) Cómo puedo bloquear una sesión telnet hacia mi servidor de correo?, no bloqueando el puerto sino la aplicación.
- (AP) Para renovar un certificado de seguridad emitido por una CA instalada en servidores físicos dentro del mismo dominio, el proceso es diferente que con una CA locamente en el servidor con Exchange? Existe un método diferente a crear el certificado que no sea por el servicio web?
- (RLL) En ocasiones, en el día a día muchos usuarios se quejan de que tienen problemas para sincronizar su correo en el teléfono. En la mayoría de los casos se trata de problemas de comunicaciones (red wifi, problema de datos, etc.) Quisiera saber que posibilidades hay de verificar de forma concreta la sincronización de un usuario en su dispositivo móvil.
Si te perdiste los artículos anteriores hace clic aquí.
1. (XF) Tengo un problema con mail spoofing, hay alguna buena práctica para configurar Exchange?
Para evitar el spoofing de correos podemos utilizar registros SPF y el filtro antispam de “Sender ID”.
El Sender ID nos habilita a chequear si existe un registro SPF y en base a esto que acción tomar. Por ejemplo rechazar el correo, eliminarlo o estampar el resultado.
De esta manera al recibir correo se chequea el registro SPF y se verifica si la IP de origen se encuentra incluida.
Si nos están enviando mail usando nuestro propio dominio de correo, Exchange al recibir el correo consultaría al DNS y si la IP del servidor que envió no coincide con lo configurado en el registro SPF toma una acción según como se encuentre configurado el filtro.
Para esto primero debemos configurar un registro SPF para nuestra organización. Hay varias formas de generar este registro, a continuación dejo link a un asistente web:
Por más información sobre SPF ver el siguiente artículo:
https://aprendiendoexchange.com/introduccion-a-dns-para-exchange
2. (RB) Cómo puedo bloquear una sesión telnet hacia mi servidor de correo?, no bloqueando el puerto sino la aplicación.
No podemos hacer esto a través de Exchange. Lo que podemos hacer es limitar desde que direcciones IP se pueden conectar al servicio.
De forma predeterminada al instalar Exchange cualquier equipo de la red se podría conectar al puerto 25 (SMTP) y por ejemplo enviar correos internos (no externos, a no ser que el relay este abierto).
Los únicos equipos que necesitan conectarse a través de SMTP son los que envíen correo usando este protocolo. En el caso de clientes, solo los que utilicen POP o IMAP requieren acceso a SMTP para enviar correo. De cualquier modo en este caso deberían utilizar el conector dedicado a clientes en el puerto 587.
3. (AP) Para renovar un certificado de seguridad emitido por una CA instalada en servidores físicos dentro del mismo dominio, el proceso es diferente que con una CA locamente en el servidor con Exchange? Existe un método diferente a crear el certificado que no sea por el servicio web?
El proceso de renovación de un certificado es exactamente el mismo independientemente de donde se encuentre configurada la CA. Por fuera de esto, no sería recomendado instalar la CA en Exchange.
En adición, tener en cuenta que si se instala una CA para emitir certificados a Exchange, cuando se conecten equipos externos van a recibir errores relacionados a confianza del certificado. La recomendación (salvo casos excepcionales) es utilizar un certificado público.
Respecto al método para crear la solicitud de certificado, tenemos varias formas, las recomendadas para Exchange son mediante el EAC (Exchange 2013/2016), EMC (Exchange 2010) o el shell (Exchange 2010/2013/2016).
4. (RLL) En ocasiones, en el día a día muchos usuarios se quejan de que tienen problemas para sincronizar su correo en el teléfono. En la mayoría de los casos se trata de problemas de comunicaciones (red wifi, problema de datos, etc.) Quisiera saber que posibilidades hay de verificar de forma concreta la sincronización de un usuario en su dispositivo móvil.
Existen varios motivos por los cuales los usuarios podrían tener problemas al sincronizar el correo con activesync, más allá del tema de comunicaciones, muchas veces se trata del software específico a nivel de dispositivo (a veces desactualizado o con una versión problemática), errores de certificados o de autodiscover entre otros.
Uno de los cmdlets que tenemos en Exchange es el “Test-ActiveSyncConnectivity”.
Por ejemplo, para chequear que este funcionando bien a nivel de servidor:
Otro ejemplo, en este caso chequeando el acceso para un usuario especifico:
Test-ActiveSyncConnectivity -TrustAnySSLCertificate -MailboxCredential (get-credential usuario@dominio.com) –UseAutodiscoverForClientAccessServer
En este caso particular se estaría utilizando autodiscover y usamos entre paréntesis “get-credential” para que nos solicite en una ventana las credenciales del usuario.
Por fuera de este cmdlet, la forma más sencilla de chequear el acceso externo sin lugar a dudas es mediante el sitio de Microsoft dedicado para este fin:
Microsoft Remote Connectivity Analyzer
Este sitio nos permite chequear el acceso a cualquier servicio y no solo Activesync. En la primer ventana nos da a elegir que servicio queremos chequear y luego nos pide los datos de acceso incluyendo si queremos validar el acceso con configuración manual o mediante autodiscover.
Dentro de los errores más comunes a nivel de acceso de clientes en Exchange, se encuentran:
- Configuración de los directorios virtuales
- Autodiscover externo
- Registros faltantes en DNS
- Certificados
Por este motivo en el curso de administración hacemos especial foco en estos aspectos.
En casos muy particulares podemos complementar habilitando el logging a nivel del buzón:
Set-CASMailbox usuario -ActiveSyncDebugLogging:$true
En esta instancia reproducimos el error y luego obtenemos el log:
Get-ActiveSyncDeviceStatistics -Mailbox usuario -GetMailboxLog:$true -NotificationEmailAddress admin@dominio
En definitiva, en principio podemos utilizar el sitio de Microsoft o el cmdlet Test-ActiveSyncConnectivity, luego en base a la información obtenida tendremos más herramientas para avanzar en el proceso de troubleshooting de conexiones. En caso de querer tener un detalle completo de lo que intenta hacer el dispositivo al sincronizar el correo habilitar el debug logging, reproducir el problema y revisar el log.
Así que dejamos este artículo por acá, deja tus comentarios más abajo si te quedan dudas.
Deja una respuesta