http authentication coldfusion active-directory ntlm

http - ¿Cómo uso la autenticación NTLM con Active Directory?



authentication coldfusion (7)

La fuente ModNTLM para Apache puede proporcionarle los punteros correctos.

Si es posible, debería considerar usar Kerberos en su lugar. Le permite autenticar Apache contra AD, y es un espacio de proyecto más activo que NTLM.

Estoy tratando de implementar la autenticación NTLM en uno de nuestros sitios internos y todo está funcionando. La única pieza del rompecabezas que no tengo es cómo tomar la información de NTLM y autenticarme con Active Directory.

Hay una buena descripción de NTLM y el cifrado utilizado para las contraseñas , que utilicé para implementar esto, pero no estoy seguro de cómo verificar si la contraseña del usuario es válida.

Estoy usando ColdFusion, pero una solución a este problema puede ser en cualquier idioma (Java, Python, PHP, etc.).

Editar:

Estoy usando ColdFusion en Redhat Enterprise Linux. Desafortunadamente no podemos usar IIS para administrar esto y en su lugar tenemos que escribir o usar una herramienta de terceros para esto.

Actualización - Lo tengo funcionando y aquí está lo que hice

Fui con la biblioteca JCIFS de samba.org.

Tenga en cuenta que el siguiente método solo funcionará con NTLMv1 y NO funciona con NTLMv2. Si no puede usar NTLMv1 puede probar Jespa , que admite NTLMv2 pero no es de código abierto, o puede usar Kerberos / SPNEGO.

Aquí está mi web.xml:

<web-app> <display-name>Ntlm</display-name> <filter> <filter-name>NtlmHttpFilter</filter-name> <filter-class>jcifs.http.NtlmHttpFilter</filter-class> <init-param> <param-name>jcifs.http.domainController</param-name> <param-value>dc01.corp.example.com</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.domain</param-name> <param-value>CORP.EXAMPLE.COM</param-value> </init-param> </filter> <filter-mapping> <filter-name>NtlmHttpFilter</filter-name> <url-pattern>/admin/*</url-pattern> </filter-mapping> </web-app>

Ahora todas las URL que coincidan /admin/* requerirán autenticación NTLM.


Lo que realmente está preguntando es: ¿hay alguna manera de validar los tokens "WWW-Authenticate: NTLM" enviados por IE y otros clientes HTTP cuando se realiza el inicio de sesión único (SSO)? SSO es cuando el usuario ingresa su contraseña una "sola" vez cuando lo hacen Ctrl-Alt-Del y la estación de trabajo lo recuerda y lo usa según sea necesario para acceder de manera transparente a otros recursos sin solicitar al usuario una contraseña nuevamente.

Tenga en cuenta que Kerberos, como NTLM, también se puede usar para implementar la autenticación SSO. Cuando se le presente un encabezado "WWW-Authenticate: Negotiate", IE y otros navegadores enviarán tokens Kerberos y / o NTLM envueltos en SPNEGO. Más sobre esto más adelante, pero primero responderé la pregunta como se me pidió.

La única forma de validar una "respuesta" de contraseña NTLMSSP (como las codificadas en los encabezados "WWW-Authenticate: NTLM" enviados por IE y otros navegadores) es mediante una llamada DCERPC de NetrLogonSamLogon (Ex) con el servicio NETLOGON de un dominio de Active Directory controlador que es una autoridad para, o tiene una "confianza" con una autoridad para la cuenta objetivo. Además, para asegurar adecuadamente la comunicación NETLOGON, se debe utilizar el cifrado de Secure Channel y se requiere a partir de Windows Server 2008.

Huelga decir que hay muy pocos paquetes que implementen las llamadas al servicio NETLOGON necesarias. Los únicos que conozco son:

  1. Windows (por supuesto)

  2. Samba - Samba es un conjunto de programas de software para UNIX que implementa una serie de protocolos de Windows que incluyen las llamadas de servicio NETLOGON necesarias. De hecho, Samba 3 tiene un daemon especial para este llamado "winbind" que otros programas como PAM y módulos de Apache pueden (y hacen) interactuar. En un sistema de Red Hat puedes hacer un yum install samba-winbind y yum install mod_auth_ntlm_winbind . Pero esa es la parte fácil: configurar estas cosas es otra historia.

  3. Jespa - Jespa ( http://www.ioplex.com/jespa.html ) es una biblioteca 100% Java que implementa todas las llamadas al servicio NETLOGON necesarias. También proporciona implementaciones de interfaces Java estándar para autenticar clientes de varias maneras, como con un filtro de servlet HTTP, un servidor SASL, un LoginModule de JAAS, etc.

Tenga en cuenta que hay una serie de aceptadores de autenticación NTLM que no implementan las llamadas de servicio NETLOGON necesarias, sino que hacen algo más que finalmente conduce a la falla en un escenario u otro. Por ejemplo, durante años, la forma de hacer esto en Java fue con el filtro de servlet de autenticación HTTP NTLM de un proyecto llamado JCIFS. Pero ese filtro utiliza una técnica de hombre en el medio que ha sido responsable de un "error de hipo" de larga data y, más importante aún, no es compatible con NTLMv2. Por estos y otros motivos, está programado para ser eliminado de JCIFS. Hay varios proyectos que han sido involuntariamente inspirados por ese paquete que ahora también están igualmente condenados. También hay una gran cantidad de fragmentos de código publicados en los foros de Java que decodifican el token de encabezado y arrancan el dominio y el nombre de usuario, pero no hacen absolutamente nada para validar realmente las respuestas de contraseña. Baste decir que si usa uno de esos fragmentos de código, puede caminar con los pantalones bajados.

Como he eludido anteriormente, NTLM es solo uno de los varios proveedores de soporte de seguridad de Windows (SSP). También hay un Digest SSP, Kerberos SSP, etc. Pero el Negociado SSP, que también se conoce como SPNEGO, suele ser el proveedor que MS usa en sus propios clientes de protocolo. El SSP Negociar en realidad solo negocia el NTP de NTLM o el SSP de Kerberos. Tenga en cuenta que Kerberos solo se puede usar si tanto el servidor como el cliente tienen cuentas en el dominio de destino y el cliente puede comunicarse con el controlador de dominio lo suficiente para adquirir un vale de Kerberos. Si no se cumplen estas condiciones, el NTP de NTLM se usa directamente. Entonces NTLM no está de ninguna manera obsoleto.

Finalmente, algunas personas han mencionado el uso de un "enlace simple" de LDAP como un servicio de validación de contraseñas make-shift. LDAP no está realmente diseñado como un servicio de autenticación y por esta razón no es eficiente. Tampoco es posible implementar SSO usando LDAP. SSO requiere NTLM o SPNEGO. Si puede encontrar un aceptador NETLOGON o SPNEGO, debe usarlo en su lugar.

Micro


Como yo lo entiendo
NTLM es uno de los métodos de autenticación integrados de IIS. Si el Host está registrado en el dominio de dicho directorio activo, debe ser automático. Una cosa a tener en cuenta es que el nombre de usuario debe estar en uno de dos formatos.

Si intenta ir contra un directorio activo diferente, debe usar una autenticación de estilo de formularios y algún código LDAP.

Si está intentando hacer lo de Intranet No Zero Login con autenticación integrada de IIS

  • el dominio debe aparecer como un sitio de confianza en el navegador IEx
  • o use una url usa el nombre de netbios en lugar del nombre DNS.
  • para que funcione en firefox lea aquí

Hm, no estoy seguro de lo que estás tratando de lograr.

Por lo general, la implementación de NTLM en un sitio interno es tan simple como desmarcar "Habilitar el acceso anónimo" en "Autenticación y control de acceso" en la pestaña "Seguridad de directorio" de las propiedades del sitio web en IIS. Si eso se borra, los usuarios de su aplicación web verán un diálogo emergente NTLM.

No es necesario que escriba ningún código que interactúe con Active Directory. IIS se encarga de la autenticación por usted.

¿Puedes ser más específico sobre lo que intentas hacer?



Echa un vistazo a Waffle . Implementa SSO para servidores Java que usan Win32 API. Hay servlet, válvula tomcat, seguridad de primavera y otros filtros.


Puede resolver la ventana emergente de autenticación de Firefox realizando los siguientes pasos en Firefox:

  1. Abra Mozilla Firefox
  2. Escriba about: config en la barra de direcciones
  3. Ingrese network.automatic-ntlm-auth.trusted-uris en la búsqueda texfield
  4. Haga doble clic en el nombre de preferencia y la clave en el nombre de su servidor como valor de cadena
  5. Cierra la pestaña
  6. Reinicia Firefox.