Recibir un mensaje de inicio de sesión mediante la autenticación de Windows integrada

Tengo una aplicación .NET 3.5 que se ejecuta bajo IIS 7 en el servidor Windows 2003 y no puedo hacer que la autenticación integrada de Windows funcione correctamente mientras continúo recibiendo el mensaje para iniciar sesión. He configurado la Autenticación de Windows habilitada en IIS con todos los demás tipos de seguridad deshabilitados y mi aplicación de autenticación / autorización de archivo web.config está configurada como:

<system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
    <authenticationmode="Windows"/>
    <authorization>
    <deny users = "?" />
    </authorization>
</system.web>

Con esta configuración, espero la verificación detrás de escena del usuario de Windows para permitir el acceso y denegar a los usuarios anónimos. Sin embargo, lo que obtengo es una ventana emergente de inicio de sesión de Windows cuando intento acceder al sitio.

He estado solucionando este problema durante unos días y no puedo resolver el problema. Basándome en publicaciones con problemas similares, confirmé que mi URL no incluye ningún punto, verifiqué dos veces que mi configuración de IE esté configurada para Habilitar autenticación integrada de Windows y también agregué mi URL a mis sitios de intranet, pero aún aparece la ventana emergente.

Para solucionarlo aún más, habilité la Autenticación anónima en IIS y modifiqué mi archivo web.config al que me deja entrar y luego agregué Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name.toString () ) para intentar ver qué usuario se está utilizando en la autenticación. El resultado que obtengo es IIS APPPOOL \ myapp, que obviamente es el grupo de aplicaciones IIS para mi aplicación.

Realmente agradezco cualquier ayuda que alguien pueda proporcionar para que sigo usando solo la autenticación de Windows, pero no obtengo la ventana emergente y la autenticación de Windows se realiza contra el usuario real de Windows.

Gracias.

Nota adicional después de la resolución de problemas adicional:

Acabo de notar que cuando el inicio de sesión falla y el mensaje de inicio de sesión de Windows se muestra nuevamente, muestra el nombre de usuario que intentó iniciar sesión como "SERVERNAME" \ "USERNAME", lo que me llevó a creer que estaba tratando de validar al usuario contra el servidor frente al dominio. Para confirmar esto, creé una cuenta de usuario local directamente en el servidor de la aplicación con el mismo nombre de usuario y contraseña que el usuario del dominio de red e intenté iniciar sesión nuevamente. El resultado fue que recibí el mensaje de inicio de sesión nuevamente, pero cuando ingresé el nombre de usuario y la contraseña esta vez, pude iniciar sesión correctamente. El usuario de la red y el servidor de la aplicación están en el mismo dominio, por lo que no estoy seguro de por qué la autenticación IIS apunta a las cuentas del servidor de la aplicación local y no a las cuentas del dominio. Me doy cuenta de que esta es una pregunta de IIS en este momento, así que la publico en forums.iis.

Tengo un servidor Windows 2008 en el que estoy trabajando, por lo que mi respuesta no es completamente la misma que tiene el OP en un servidor Windows 2003.

Esto es lo que hice (grabar esto aquí para poder encontrarlo más tarde).

Estaba teniendo este mismo problema:

En mi archivo Web.config , tenía esta sección:

<system.web>
    <authentication mode="Windows" />
    <authorization>
        <allow users="*" />
        <deny users="?" />
    </authorization>
</system.web>

En IIS, todo esto parece resolverse con el icono de Autenticación .

1. Editar permisos: asegúrese de que su cuenta ASP.NET tenga permiso. El mío no se agregó originalmente.

Ahora ve a las características de Autenticación :

Habilite la autenticación anónima con IUSR:

Habilite la autenticación de Windows , luego haga clic derecho para configurar los proveedores .

¡NTLM debe ser PRIMERO!

A continuación, verifique que en Configuración avanzada ... la Protección extendida es Aceptar y Habilitar la autenticación en modo Kernel está VERIFICADA:

Una vez que hice esto, volví a mi aplicación web, hice clic en el enlace Examinar e inicié sesión sin tener que proporcionar mis credenciales nuevamente.

Espero que esto sea beneficioso para muchos de ustedes, y espero que también me sea útil más adelante.

Solo para beneficio de otras personas. Si el error es a 401.1 Unauthorizedy su código de error coincide 0xc000006d, entonces se está encontrando con una "función" de seguridad que bloquea las solicitudes de FQDN o encabezados de host personalizados que no coinciden con el nombre de su máquina local:

Siga este artículo de soporte para solucionar el problema:

https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (original, ahora desaparecido: http://support.microsoft.com/kb/896861 )

Del artículo de soporte, para asegurarse de que no se pierda:

La solución es un truco de registro que deshabilita esta política explícitamente.

Para realizar esta configuración, busque manualmente esta clave en el registro del servidor:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

y edite o agregue una nueva clave:

DisableLoopbackCheck (DWORD)

luego envió el valor a 1 para deshabilitar la verificación de bucle invertido (la autenticación local funciona), oa 0 (la autenticación local no está permitida).

O más fácilmente puede usar Powershell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

Parece que las compilaciones recientes de Windows 10 (1803 y posteriores) también requieren esta configuración para poder autenticarse localmente.

Este me tomó un tiempo porque los comentarios de todos los demás aquí no me ayudaron. ¡Encontré este artículo y lo arreglé!

Tuve un problema similar por el cual quería proteger solo una cierta parte de mi sitio web. Todo funcionó bien excepto en IE. Tengo habilitada la autenticación anónima y de Windows. Para Anónimo, la identidad se establece en la identidad del grupo de aplicaciones. El problema fue con la autenticación de Windows. Después de investigar un poco, encendí Fiddler y descubrí que estaba usando Kerberos como proveedor (en realidad, está configurado en Negociar de forma predeterminada). Lo cambié a NTLM y eso lo solucionó. HTH

Daudi

Agregue permiso [Usuarios de dominio] a su seguridad web.

• Haga clic derecho en su sitio en IIS en la carpeta Sitios
• Haga clic en Editar permisos ...
• Seleccione la pestaña Seguridad
• En la sección Grupos o nombres de usuario, haga clic en el botón Editar ...
• En la ventana emergente Permisos, en Nombres de grupos o usuarios, haga clic en Agregar ...
• Introduzca [Usuarios de dominio] en los nombres de los objetos para seleccionar el área de texto y haga clic en Aceptar para aplicar el cambio.
• Haga clic en Aceptar para cerrar la ventana emergente Permisos
• Haga clic en Aceptar para cerrar la ventana emergente Propiedades y aplicar su nueva configuración

No cree errores en su servidor cambiando todo. Si tiene un mensaje de Windows para iniciar sesión cuando usa la Autenticación de Windows en 2008 R2, simplemente vaya Providersy mueva hacia ARRIBA NTLMpara cada aplicación. Cuando Negotiatees el primero en la lista, la autenticación de Windows puede dejar de funcionar la propiedad para una aplicación específica en 2008 R2 y se le puede solicitar que ingrese el nombre de usuario y la contraseña que nunca funcionará. Eso sucede en algún momento cuando hiciste una actualización de tu aplicación. Solo asegúrese de que NTLMsea ​​el primero en la lista y nunca volverá a ver este problema.

Si su URL tiene puntos en el nombre de dominio, IE la tratará como si fuera una dirección de Internet y no como local. Tienes al menos dos opciones:

1. Obtenga un alias para usar en la URL para reemplazar servidor.dominio. Por ejemplo, myapp.
2. Siga los pasos a continuación en su computadora.

Vaya al sitio y cancele el diálogo de inicio de sesión. Deja que esto suceda:

En la configuración de IE:

WindowsIdentity.GetCurrentes correcto: debe obtener el usuario APPPOOL. Esto se debe a que el proceso ASP.NET, que está ejecutando su código, es la identidad actual. Si desea que devuelva el usuario que ingresa a la identidad del sitio, deberá agregar la siguiente línea en su web.config:

<identity impersonate="true" />

Esto hace que el proceso asuma la identidad del usuario que solicita la página. Todas las acciones se realizarán en su nombre, por lo que cualquier intento de leer carpetas en la red o acceder a los recursos de la base de datos y similares significará que el usuario actual necesitará permisos para esas cosas. Puede leer más sobre la suplantación de identidad aquí . Tenga en cuenta que, dependiendo de cómo esté configurada la topología de su servidor web / base de datos, es posible que tenga problemas de delegación con la suplantación activada.

Pero su problema original es que parece que no se puede determinar la identidad y aparece una ventana emergente de inicio de sesión. Notaré que no necesita el <deny>bloqueo si ha deshabilitado la autenticación anónima en IIS. Nunca lo incluimos (excepto en especial<location> bloques y similares), así que diría que podría intentar eliminarlo y volver a intentarlo. Sin embargo, todo lo demás suena bien.

No especificó qué usuario está ejecutando el grupo de aplicaciones en IIS. ¿Es una cuenta personalizada o es la predeterminada? Si es personalizado, ¿es una cuenta de dominio o una cuenta local en el servidor web? Las cuentas personalizadas a veces pueden requerir algunos pasos más, como registrar un SPN. Además, puede ser un problema que la cuenta personalizada no tenga permiso en AD para resolver la cuenta del usuario entrante.

También puede consultar los registros de IIS para ver qué respuesta se devuelve. Lo más probable es que sea un 401, pero debería tener un subnúmero después, como 401.2 o algo así. Ese subnúmero a veces puede ayudar a determinar la raíz del problema. Este artículo de KB enumera cinco.

Esto me lo arregló.

Mi servidor y mi PC cliente son Windows 7 y están en el mismo dominio

1. en iis7.5, habilite la autenticación de Windows para su Intranet (deshabilite todas las demás autenticaciones ... tampoco es necesario mencionar la autenticación de Windows en el archivo web.config

2. luego vaya a la PC cliente .. IE8 o 9- Herramientas-Opciones de Internet-Seguridad-Intranet local-Sitios-avanzado-Agregue su sitio (quite el ticketmark "require server verfi ..." .. no es necesario

3. IE8 o 9- Herramientas-Opciones de Internet-Seguridad-Intranet local-Nivel personalizado-Autenticación de usuario-Inicio de sesión-Seleccionar inicio de sesión automático con nombre de usuario y contraseña actuales

4. guardar esta configuración ... ya está ... No más solicitudes de nombre de usuario y contraseña.

5. Asegúrese de que, dado que su PC cliente es parte del dominio, debe tener un GPO para esta configuración, .. o de lo contrario, esta configuración se revertirá cuando el usuario inicie sesión en Windows la próxima vez

Puede estar relacionado con el navegador. Si está utilizando IE, puede ir a Configuración avanzada y marcar la casilla de verificación "Habilitar autenticación integrada de Windows".

En mi caso, la configuración de autorización no se configuró correctamente.

Tuve que

1. abra las Reglas de autorización de .NET en el Administrador de IIS

   

2. y eliminar la regla de negación

   

En nuestra Intranet, el problema se resolvió en el lado del cliente ajustando la configuración de seguridad como se muestra aquí. Cualquiera de las casillas de verificación de la derecha nos funcionó.

Acabo de resolver un problema similar con una aplicación ASP.Net.

Síntomas: pude iniciar sesión en mi aplicación utilizando un usuario local, pero no un usuario de dominio, incluso si la máquina se unió correctamente al dominio (como dice en su Nota adicional). En el visor de eventos de seguridad, hubo un evento con ID = 4625 "Domain sid inconsistent".

Solución: encontré la solución aquí . El problema era que mis máquinas de prueba eran máquinas virtuales clonadas (Windows Server 2008 R2; un controlador de dominio y un servidor web). Ambos tenían el mismo SID de máquina, lo que aparentemente causó problemas. Aquí esta lo que hice:

1. Elimina el servidor web del dominio.
2. Ejecute c: \ Windows \ System32 \ Sysprep \ Sysprep.exe en la VM.
3. Reinicie la VM.
4. Une el servidor web al dominio.

Pierde algunas configuraciones en el proceso (preferencias de usuario, IP estática, recrear el certificado autofirmado), pero ahora que las he recreado, todo funciona correctamente.

También tuve el mismo problema. Probé la mayoría de las cosas que se encuentran en este y otros foros.

Finalmente tuvo éxito después de hacer un pequeño RnD propio.

Entré en Configuración de IIS y luego en las opciones de permisos de mi sitio web agregué mi Grupo de usuarios de dominio de organizaciones.

Ahora, como todos los usuarios de mi dominio han tenido acceso a ese sitio web, no encontré ese problema.

Espero que esto ayude

¿Ha intentado iniciar sesión con su prefijo de dominio, por ejemplo, DOMINIO \ Nombre de usuario? IIS 6 utiliza de forma predeterminada el equipo host como dominio predeterminado, por lo que especificar el dominio al iniciar sesión puede resolver el problema.

Probé los trucos de configuración de IIS anteriores y el truco del registro de bucle invertido, y revisé y recreé los permisos del grupo de aplicaciones y una docena de otras cosas y todavía no pude deshacerme del bucle de autenticación que se ejecuta en mi estación de trabajo de desarrollo con IIS Express o IIS 7.5, desde una sesión de navegación local o remota. Recibí cuatro respuestas de estado 401.2 y una página en blanco. El mismo sitio exacto implementado en mi servidor de ensayo IIS 8.5 funciona sin problemas.

Finalmente noté que el marcado en el Cuerpo de respuesta que el navegador dejó en blanco contenía la página predeterminada para un inicio de sesión exitoso. Determiné que el manejo de errores personalizados para ASP.NET y HTTP para el error 401 estaba impidiendo / interfiriendo con la autenticación de Windows en mi estación de trabajo pero no el servidor intermedio. Pasé varias horas jugando con esto, pero tan pronto como eliminé el manejo personalizado solo para el error 401, la estación de trabajo volvió a la normalidad. Presento esto como una forma más de disparar tu propio pie.

La autenticación de Windows en IIS7.0 o IIS7.5 no funciona con kerberos (proveedor = Negociar) cuando la identidad del grupo de aplicaciones es ApplicationPoolIdentity. Uno tiene que usar el Servicio de red u otra cuenta integrada. Otra posibilidad es usar NTLM para que funcione la Autenticación de Windows (en Autenticación de Windows, Proveedores, coloque NTLM en la parte superior o elimine la negociación)

chris van de vijver

Tuve el mismo problema porque el usuario (Identidad) que usé en el grupo de aplicaciones no estaba debajo del grupo IIS_IUSRS. Agregó el usuario al grupo y todo funciona

En mi caso, la solución fue (además de los ajustes sugeridos anteriormente) reiniciar la computadora de desarrollo local / IIS (servidor de alojamiento) de mi / users. Mi usuario acaba de ser agregado al grupo de seguridad de AD recién creado, y la política no se aplicó a la cuenta de AD del usuario hasta que cerré la sesión / reinicié mi computadora.

Espero que esto ayude a alguien.

Encontré el mismo problema de solicitud de credenciales e hice una búsqueda rápida y nada en Internet lo solucionó. Me tomó algún tiempo encontrar el problema, uno tonto.

En IIS -> Configuración avanzada -> Credencial de ruta física (está vacío)

Tan pronto como agregué una ID de máquina (dominio / usuario) que tiene acceso a la VM / servidor, la solicitud de contraseña se detendría.

Espero que esto ayude

Tenía este problema en .net core 2 y después de pasar por la mayoría de las sugerencias desde aquí, parece que nos perdimos una configuración en web.config

<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

La configuración correcta era forwardWindowsAuthToken = "true" que parece obvio ahora, pero cuando hay tantas situaciones para el mismo problema, es más difícil de identificar

Editar: también encontré útil el siguiente artículo de Msdn que explica cómo solucionar el problema.

Tuve el mismo problema y se resolvió cambiando la identidad del grupo de aplicaciones del grupo de aplicaciones bajo el cual se ejecuta la aplicación web a NetworkService