ActiveDirectoryMembershipProvider "El dominio o servidor especificado no pudo ser contactado".

Question

Tengo una aplicación que está utilizando ActiveDirectoryMembershipProvider para otorgar acceso a los usuarios. La aplicación está alojada en un equipo que no es de dominio, con un servidor de seguridad entre el servidor de aplicaciones y el controlador de dominio.

Hemos abierto el puerto LDAP al DC en la red interna; sin embargo, no importa lo que intentemos, terminamos con un error que dice "No se pudo contactar con el servidor o el dominio especificado".

¿Alguien tiene alguna sugerencia sobre cómo puedo resolver esto? Hemos intentado todo lo que podemos pensar y simplemente no estamos llegando a ningún lado.

Mi cadena de conexión es:

<add name="ADConnectionString" 
    connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/> 

Y el profesional es:

<add name="ActiveDirectoryMembershipProvider" 
    type="System.Web.Security.ActiveDirectoryMembershipProvider" 
    connectionStringName="ADConnectionString" 
    attributeMapUsername="SAMAccountName" 
    connectionProtection="None" 
    connectionUsername="LdapUser" 
    connectionPassword="LdapPassword" /> 

Answer 1

¿Ha probado con una herramienta de navegación LDAP, desde el cuadro de mando a distancia para ver si se puede conectar con los criterios siendo utilizado aquí? Es decir. ¿Es un problema de conectividad o algo más?

Answer 2

Parece que la solución es abrir el puerto 445.

Read this thread

No se nos permite abrir, así que supongo que estoy atascado.

Answer 3

Se puede utilizar esta dos artículos, se pueden resolver su problema

www.ddj.com/windows/184406424

forums.asp.net/t/1408268.aspx

y verificación sus firewalls

Answer 4

The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.

Dado que podría consultar directamente con una herramienta LDAP, eso sugiere que el firewall está abierto correctamente. Sin embargo, tenga en cuenta que el ActiveDirectoryMembershipProvider no usa LDAP simple antiguo, sino que usa tecnologías de Microsoft. Por ejemplo, si configura connectionProtection="Secure", ADMP intentará usar SSL y el puerto 636; si eso falla, utilizará la firma IPSec incorporada de Microsoft (consulte this article para obtener más detalles).

De todos modos, esto hace que me pregunte acerca de un par de cosas:

1. ¿El dominio de AD haber un IPSec "necesaria" la política que se niega conexiones desde equipos que no es de dominio no configurado /? (Probablemente no, ya que se conectó con LDAP simple, pero vale la pena investigarlo)
2. ¿Ha agregado el nombre de NetBIOS del controlador de dominio a su archivo lmhosts y su nombre DNS a su archivo de hosts? (Muchos protocolos comprueban que el nombre informado de su destino coincide con el nombre con el que intentó conectarse).
3. Mucha gente ha notado problemas al usar ADMP entre diferentes dominios, y la solución requería que se creara una confianza unidireccional. Como parece que su computadora cliente no está en un dominio, no puede tener esa confianza, a menos que (a) sea miembro de un dominio diferente con una confianza unidireccional o (b) sea miembro de el mismo dominio y, por lo tanto, la confianza cliente-servidor es implícita.

Answer 5

tuve este error, y logró solucionarlo. Hay varias razones que pueden conducir a esto, aquí hay una lista de tareas para identificar un problema exect:

1. crear una aplicación de micro, con un único método Membership.GetAllUsers(), ejecuta en la máquina fuera de Active Directory (AD), con una contraseña incorrecta en la cadena de conexión, verifica si obtienes una contraseña incorrecta. Si no lo obtiene, no puede conectarse a su servidor de AD, verifique el firewall, si obtiene una excepción de contraseña no válida, vaya al siguiente paso.

2. Si puede, intente ejecutar la misma aplicación, localy en el servidor AD, primero con la contraseña incorrecta, que con la aplicación correcta, ejecutando localmente proporciona una excepción más detallada ¿qué está mal (para mí esta excepción me lleva a solucionar el problema) . En mi caso, me dijo que el servicio del servidor no se inició, que el servicio de la estación de trabajo no se inició.

Reflexiones sobre el hecho de que requiere los servicios del servidor y estaciones de trabajo de estar trabajando en el servidor: servicio de servidor que yo sepa se utiliza para el intercambio de archivos de Windows (NetBIOS sobre TCP), y está usando 445 del puerto, por lo que Mey sea que este puerto debe abrirse además del puerto LDAP. Mi segunda observación fue que si el puerto 445 se abría (netstat -an) aún no funcionaba, winows dejaría todos los paquetes en este puerto si las casillas de verificación Windows Client y Compartir archivos e impresoras no están marcadas en el adaptador de interfaz de red que rcived this packages . Verifique "telnet External_IP 445". Esa es toda la información que reuní mientras luchaba con este problema.

Answer 6

En caso de que alguien se topa con esto y quiere aplastar la cabeza en una pared ... Recientemente intentado hacer todo esto por un servidor de anuncios que mi compañía tenía en un dominio diferente que el contexto actual. Estaba usando el IP proporcionado y obteniendo fallas como se indica aquí. Incluso usó una herramienta como Softerra LDAP Admin y funcionó bien; sin embargo, Falló la administración de cuentas.

Tuvimos una URL expuesta públicamente enganchado a esa dirección IP (todavía sólo permite cierta de IP para realizar llamadas). Una vez que reemplacé el IP con la URL proporcionada, funcionó como un amuleto.

Hope esto ahorra alguien las horas de rompiendo la cabeza acabo de poner a mí mismo a través.