Como vimos en la entrada anterior, integracion-de-correo-microsoft-365-en-sap-correo-saliente, es posible configurar el correo saliente de SAP con Microsoft 365. En esta entrada trataremos el caso opuesto, configurando la integración de correo entrante Microsoft 365 en SAP.

Ésta casuística puede ser más complicada ya que pueden darse múltiples configuraciones, casi tantas posibilidades como entornos existan. Muchas de estas peculiaridades pueden suponer un reto a la hora de realizar una implementación sencilla.

Para ilustrar este post, vamos a basarnos en un caso con las siguientes premisas:

• Correo corporativo en Microsoft 365
• Un único dominio
• Un entorno grande consolidado que busca el mínimo de cambios sobre la estructura actual
• Conservación de todos los correos en las cuentas entrantes
• Necesidad de reforzar la seguridad.

Visión general

Para la integración de correo entrante Microsoft 365 en SAP con este caso práctico, dado que Office recepcionará los correos entrantes y deben permanecer en las cuentas originales, deberemos indicarle cual y cómo es el destino al cual debe reenviar una copia de dichos correos.

Para ello generaremos una o más reglas y uno o más conectores según sean las necesidades. Habremos de tener en cuenta dos particularidades del entorno de correo:

• Microsoft 365 solo enviará información al puerto 25 del destino del conector que definamos. En entornos unix no es recomendable utilizar puertos por debajo del 1024, por lo que utilizaremos el firewall para redirigir el tráfico, evitando así tener que enlazar puertos del sistema.
• Microsoft 365 utiliza internamente el protocolo propietario TNEF (Transport Neutral Encapsulation Format), por lo que todos los correos enviados hacia uno de los dominios propios utilizará dicho protocolo salvo que se modifique. Puede desactivarse de forma global, pero dado que se va a intentar maximizar la compatibilidad y minimizar los cambios en la infraestructura ya existente, se llevará a cabo una alternativa.

Éstos puntos serán importantes en la solución que se va a proporcionar.

Entorno de Red

Como en la entrada anterior, el primer punto es configurar las conexiones, esta vez en sentido inverso. Debe permitirse el tráfico entrante que llegue desde Microsoft a nuestro entorno, denegando las que lleguen de cualquier otra dirección. Deberemos además redireccionar el tráfico entrante en el puerto 25 a nuestro sistema y puerto adecuado que definiremos más adelante (en este caso el puerto 25000).

Podemos ver las direcciones e ips de Microsoft aquí.

Perfiles, servicio SMTP y SAPConnect [incoming]

Deberemos configurar el parámetro para levantar un servicio SMTP con el arranque de SAP similar al siguiente:

icm/server_port_X, donde X es un número correlativo para los servicios del ICM que hayamos definido.

En este parámetro estaremos indicando que se haga uso de un servicio smtp por el puerto 25000 con autenticación TLS/SSL.

El valor TLS especifica los posibles valores para el cifrado TLS usando STARTTLS. Los valores para este parámetro son:

• 0: indica que no debe utilizarse
• 1: se ofrece pero es opcional
• 2: que su uso es obligatorio.

Tal y como indica Microsoft, esta última es la opción correcta.

Hay otros valores que podría ser interesante añadir como TIMEOUT y PROCTIMEOUT para limitar el  intervalo antes del timeout y tiempo de procesamiento respectivamente, que típicamente suelen ser valores entre 60 y 120 segundos. En caso de no indicarlos se tomará el valor por defecto del kernel que suele ser de 60.

Es necesario utilizar un puerto que no interfiera con otros ya activos, como los reservados para el sistema operativo. En entornos linux, si fuera necesario, podríamos utilizar la opción EXTBIND=1 para autorizar el uso de puertos dentro del rango <1024 (más info: 421359 – ICM: Binding ports < 1024 on UNIX), siempre y cuando no exista ya un servicio smtp activo en dicho puerto.

Para que estos parámetros tomen efecto deberemos reiniciar el ICM o directamente la instancia. Podremos ver los valores aplicados en la transacción SMICM → Pasar a → Servicios:

Una vez el parámetro está definido hay algunos campos que podemos modificar dinámicamente:

Podemos comprobar que el servicio se ha creado y responde con un telnet:

Para poder recepcionar los correos desde SAP es necesario activar el servicio SAPConnect en la transacción SICF:

Una vez llegados hasta este punto el entorno SAP está listo para recibir emails, aunque aún deberemos hacérselos llegar.

Conectores y reenvíos Office 365

En este apartado las combinaciones son numerosas, podríamos reenviar a SAP todos los correos que lleguen a un buzón o solo aquellos con determinado asunto, etc.

Para una de estas posibilidades podemos crear un conector similar al siguiente en el centro de administración de Exchange → Flujo de correo → Conectores:

En la siguiente imagen podríamos, en caso de tener dos dominios, utilizar uno en exclusiva para el reenvío de correos a SAP, aunque en este caso dejaremos la elección del envío en manos de otras reglas:

Indicaremos la(s) IP(s) a la que se intentará realizar el envío, detrás de la cual tendremos el servicio SAP:

Con preferencia, y tal como hemos definido en el parámetro del servicio smtp, utilizaremos siempre la capa de seguridad TLS

Será preciso completar un test aunque sea incorrecto para poder avanzar y guardar el conector. Para ello pulsamos validar:

Y finalmente pulsamos en crear conector:

Podremos utilizar este conector para reenviar correos a través de él mediante reglas con mayor o menor complejidad. Por ejemplo, podemos crear una regla para que todos los correos enviados a una cuenta en concreto, se canalicen hasta SAP a través del conector:

Es importante tener en cuenta que con dicha configuración estándar el correo no llegará al buzón, sino que será redirigido exclusivamente a SAP salvo error en el conector.

En caso de que quisiéramos que se mantuviera en el buzón, podemos crear una regla para que se envíe una copia dentro del propio buzón marcando la opción de conservar:

Transacción SOIN

Podemos verificar los correos entrantes en la transacción SOIN.

Es probable que durante las pruebas iniciales queramos realizar traces a todos los correos entrantes para poder determinar su correcto enrutamiento. Podemos gestionar el uso del trace mediante la opción SOIN →Utilidades → Parametrizaciones de trace:

Es importante desactivarlo o activarlo sólo cuando recibamos errores para evitar más traces de los necesarios.

Podremos ver los traces en la transacción SOIN → Utilidades → Selección de trace.

Con ésto habremos terminado la integración de correo entrante Microsoft 365 en SAP. Opcionalmente conviene tener en cuenta el siguiente punto acerca de el formato TNEF.

Formato TNEF [opcional]

Por defecto Outlook, Ms Exchange y por extensión Office 365 utilizan el formato propietario TNEF (https://es.wikipedia.org/wiki/TNEF) siempre y cuando sea posible. Es posible Es probable que por ello nos encontremos con el inconveniente de que lleguen correos a SAP con adjuntos de tipo winmail.dat que nos será imposible tratar dentro del sistema. Dentro de este adjunto encontraríamos la información codificada en dicho formato pero no podremos hacer uso de ella.

Más info: https://support.microsoft.com/en-us/topic/how-email-message-formats-affect-internet-email-messages-in-outlook-3b2c0536-c1c0-1d68-19f0-8cae13c26722

Para abordar este problema Microsoft propone dos soluciones:

1. Cambiar el formato para los contactos externos
2. Cambiar el formato para los contactos de un dominio específico.

Más info: https://support.microsoft.com/es-es/topic/c%C3%B3mo-especificar-el-formato-del-mensaje-de-correo-electr%C3%B3nico-que-se-usa-para-los-destinatarios-externos-para-evitar-los-datos-adjuntos-de-winmail-dat-4a379475-1557-9554-ab72-91c5867afc11

Para poder aplicar cualquiera de las dos soluciones deberemos conectarnos a la PowerShell de nuestro Exchange Online:

https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?redirectedfrom=MSDN&view=exchange-ps

Instalamos el proveedor de paquetes a instalar

Install-PackageProvider -Name NuGet -Force Install-Module -Name PowerShellGet -Force 

Instalamos el módulo EXOV2, ExchangeOnlineManagement, que contiene un pequeño conjunto de cmdlets nuevos y optimizados para escenarios de recuperación de datos en masa (miles y miles de objetos).

Install-Module -Name ExchangeOnlineManagement

Modificamos la política para hacerla menos restrictiva:

Set-ExecutionPolicy RemoteSigned

Importamos los modulos:

Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement

Import-Module ExchangeOnlineManagement

Nos conectamos para poder operar:

 Connect-ExchangeOnline -UserPrincipalName <UPN> [-ShowBanner:$false] [-ExchangeEnvironmentName <Value>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions] Connect-ExchangeOnline -UserPrincipalName correo_usuario_admin@...onmicrosoft.com

Esto nos abre una ventana de login y nos conectamos.

Finalmente configuramos nuestro exchange como mejor nos convenga.

¿Te ayudamos a configurarlo?

Microsoft 365, antes Microsoft Office 365, es un conjunto de herramientas que nos permite crear, acceder y compartir a documentos tanto en un entorno local como en la nube, gestión de correo electrónico, etc. entre muchas otras posibilidades.

La integración del correo Microsoft 365 en SAP es una de las formas en las que ambas suites interactúan.

En la siguiente nota (722513 – Desktop Office Integration: Maintenance information) podréis encontrar más información al respecto.

La integración del correo saliente Microsoft 365 en SAP no es un proceso complicado y con Microsoft 365 no difiere mucho de otras alternativas. En esta entrada trataremos el correo saliente y dejamos para una futuro el correo entrante. La configuración del correo saliente es notablemente más sencilla que la del entrante:

Configuración de red / conectividad

El primer paso es asegurarnos de que tenemos acceso desde SAP al servidor smtp.office365.com.

Desde el propio servidor SAP podemos realizar ping y telnet a dicha dirección y puerto 587, y con ello comprobaremos si accedemos correctamente. En caso de no tener éxito habrá que revisar los diferentes elementos de red que intervienen en esta comunicación.

Nodo de salida a Office 365

Para definir un nodo de salida deberemos ir a la transacción SCOT y definir un nodo de tipo SMTP que enviará los e-mails a través del host smtp.office365.com en el puerto 587.

Como se muestra en la imagen de arriba es necesario indicar en el apartado SMTP Connection → Security la opción más restrictiva: TLS obligatorio. El resto de opciones no funcionarán o podrían presentar problemas, por lo que no es aconsejable su uso.

Dentro de las opciones (SMTP Connection → Settings) del nodo recién creado recomendamos activar las siguientes dos opciones:

• Check Host Name
• Check Server Certificate

De esta forma se comprobarán el nombre del servidor de correo y el certificado con el que se autentique. El hecho de utilizar esta última opción nos ofrecerá permitirá indicar el contenedor PSE en el que albergaremos el certificado que debemos aceptar de Microsoft. Indicaremos el contenedor SSL Client por defecto en el campo Client Identity, donde posteriormente importaremos dicho certificado.

Por último, deberemos indicar un usuario y contraseña de una cuenta válida dentro del servicio Microsoft 365.

Es importante destacar que la cuenta de usuario que hayamos definido en la imagen anterior será la emisor de los correos. Si queremos cambiar el emisor de los mails por otra cuenta diferente, por ejemplo la de un usuario final, la primera cuenta deberá tener permisos para enviar correos en nombre de la segunda dentro de Microsoft 365.

Certificados de seguridad

Una vez definido que debe aceptarse el certificado del servidor, debemos incluir dicho certificado o el de las entidades que lo generen en la transacción STRUST dentro del contenedor pse que hemos definido. De lo contrario veremos en los traces del ICM aparecer errores de certificado cada vez que tratemos de enviar un correo y dichos correos no llegarán al destinatario.

Podemos obtener el certificado del servicio SMTP de Microsoft 365 ejecutando el siguiente comando:

openssl s_client -starttls smtp -showcerts -connect smtp.office365.com:587 -servername smtp.office365.com | openssl x509 > o365.cer

Tras ello abriremos el contenedor definido en el punto anterior, cargaremos el certificado y lo incluiremos en la lista de certificados admitidos, guardaremos y distribuiremos. En función de la versión es posible que sea necesario reiniciar el ICM.

Cuentas de correo

En la transacción SU01 podemos añadir/modificar la cuenta de correo de cada usuario. Si la cuenta coincide con la del servidor Microsoft 365 no habrá problema.

No obstante es muy habitual que cada usuario tenga su propia cuenta. En ese caso podemos encontrarnos con errores como el siguiente en la SOST:

o en los traces del ICM:

Este problema se debe a que la cuenta de correo definida para el usuario SAP, en la transacción SU01, no tiene permiso para enviar correos en nombre de la que hayamos definido en la transacción SCOT. Debemos entonces asignar estas autorizaciones desde el centro de administración de Microsoft 365. Puede hacerse de forma global mediante comandos PowerShell o manualmente para cada usuario/buzón compartido. Hay que tener en cuenta que no es válido para grupos de Microsoft 365. Para ello seleccionamos un usuario y editamos sus opciones:

Y añadimos la cuenta definida más arriba en el apartado de autenticación de la TX SCOT:

Con ésto ya estaría el sistema listo para enviar correos desde SAP haciendo uso del servicio Microsoft 365.

Resumen

En apenas unos pocos pasos hemos configurado la integración del correo saliente Microsoft 365 en SAP con seguridad TLS y comprobación del certificado.

Próximamente configuraremos el correo saliente.