calendar - servidor - ultima version de mac os

¿Autenticación de servidor a servidor de Exchange Web Services sin contraseña de texto? (2)

Estoy construyendo una aplicación de servidor que ejecuta procesos automatizados que deben ser compatibles con los servidores de Exchange en la versión 2007. Actualmente uso OAuth a través de Azure AD para la conexión de Office 365, pero aún estoy tratando de encontrar una solución para las instalaciones. Intercambio pre-2013.

He estado leyendo acerca de la autenticación de Exchange (básica, NTLM, etc.) y parece que no puedo encontrar ninguna referencia a un sistema de token a largo plazo que me permita configurar la autenticación con una contraseña de uso único. Preferiría no almacenar las contraseñas de los usuarios en una base de datos central, cifrada o no, ya que es una gran responsabilidad de seguridad y podría tener una ingeniería inversa.

¿Se me escapa algo?

¿Hay alguna manera de autenticarse en Exchange sin una contraseña cada vez?

Me temo que no. Las conexiones requerirán una contraseña para los servidores en las instalaciones.

Respondiendo a mi propia pregunta como un seguimiento, ya que no estaba satisfecho con algunas de las respuestas y / o lo que pude encontrar a través de una extensa búsqueda.

Después de una gran cantidad de investigaciones investigando los servidores de Exchange, cómo se autentican y los protocolos soportados y utilizados, encontré lo que considero una mejor opción: NTLM .

Ahora, déjame explicarte.

El objetivo que estaba tratando de lograr fue el siguiente:

Ser capaz de autenticarse en un servidor Exchange 2007+
Haga que la autenticación sea una "configuración única" a través de un proceso inicial
Nunca almacene contraseñas de texto sin formato (particularmente en una plataforma / datastore central de servicio)

Con esos puntos en mente:

No pude usar la autenticación "Básica" ya que requeriría almacenar la contraseña del usuario en texto plano en un almacén de datos central
OAuth no funciona, ya que solo es compatible con Exchange 2013+

Con eso, realmente solo me quedé con NTLM. Desafortunadamente, he sabido que NTLM tiene una historia difícil con fallas de seguridad sobre su legado de muchos años, pero me metí en ello más para ver si de alguna manera era capaz de cumplir con mis requisitos.

Desafortunadamente, NTLM se ha mantenido durante un tiempo un tanto "secreto" en términos de sus especificaciones. Es una especificación patentada, por lo que la información con respecto a su funcionamiento interno es desafortunadamente bastante poco común. Durante mucho tiempo, la única fuente real de información de especificación con respecto a NTLM era en realidad información que se sometió a ingeniería inversa (¡gracias Eric Glass!) . Afortunadamente, sin embargo, Microsoft finalmente comenzó a publicar documentación sobre NTLM en su sitio de MSDN más recientemente .

Después de examinar bastante el protocolo, y después de ejecutar algunas pruebas en un servidor de prueba de Exchange en muchas permutaciones de configuraciones diferentes, me di cuenta de que NTLM realmente se ajustaría a todos mis requisitos. ¿Cómo? Bueno, gracias a la forma en que funciona el protocolo, una vez que una credencial ha sido hash (en una de las 3 formas posibles en la especificación [LM, NTv1, NTv2]) no es necesario volver a codificarla para el mismo objetivo Esto significa que, de forma similar a la contraseña de hash de un usuario para un mecanismo de registro típico, puede simplemente solicitar las credenciales de Exchange / NTLM por adelantado y luego actualizar las credenciales una vez.

¡¡¡NOTA!!! ¡Hay una trampa!

Tenga en cuenta que si puede copiar la credencial una vez y usarla varias veces, significa que el hash es una especie de "contraseña equivalente". Lo que quiero decir con eso, es que el hash se puede usar como una contraseña una vez que se lo conoce, ya que es una de las únicas piezas de información necesarias para autenticarse en el futuro. (Esto se conoce coloquialmente como "pasar el hash" ).

Sin embargo, considerando la alternativa de almacenar una contraseña en texto plano, esto es mucho mejor. ¿Por qué? Porque al menos no está almacenando una credencial sin procesar que podría usarse en cualquier otro esquema de autenticación o filtrando una contraseña que puede compartirse en otros entornos (sí, la gente lamentablemente sí lo hace).

Teniendo en cuenta ese conocimiento, aún se debe tener mucho cuidado al almacenar estas credenciales hash. Finalmente, si se puede usar otro esquema de autenticación más fuerte, úselo.

Entonces, gracias a la forma en que funciona el protocolo NTLM, cumple con los requisitos:

Ser capaz de autenticarse en un servidor Exchange 2007+
- NTLM está disponible en todos los servidores de Exchange 2007+
Haga que la autenticación sea una "configuración única" a través de un proceso inicial
- Las credenciales y el objetivo solo deben ingresarse una vez, ya que una vez que se realiza un saludo inicial con el servidor sabrá que el esquema de autenticación funciona. (Esto, por supuesto, no considera que la configuración de un servidor de Exchange remoto pueda cambiarse en cualquier momento. Por lo tanto, el manejo correcto de los errores debería implementarse)
Nunca almacene contraseñas de texto sin formato (particularmente en una plataforma / datastore central de servicio)
- La credencial hash se almacena en su lugar. Sin embargo, se debe tener mucho cuidado, con una técnica de encriptación dual potencialmente empleada, debido a la "captura" explicada en la nota anterior.

De todos modos, espero que alguien más encuentre esto en algún momento para que no tengan que hacer tantas lecturas de especificación y experimentación como debí.

Además, por lo que vale la pena, como noté que las implementaciones de código abierto de NTLM no son solo raras sino también más comúnmente solo medio completas, mi equipo ha abierto nuestra implementación de NTLM en PHP. Está disponible en GitHub .