|Autenticación de proxy integrada: cuentas de servicio y suplantación

“Usar mis credenciales de Windows” necesita un sujeto. En un programa de escritorio puede ser la persona que lo ejecuta. En un servicio puede ser la cuenta del servicio. En una aplicación web, el inicio de sesión correcto de un visitante no sustituye automáticamente el contexto de seguridad de la solicitud saliente.

Esto explica por qué un navegador y el código del lado del servidor en la misma máquina pueden recibir resultados distintos de un proxy con autenticación integrada. Puede que estén presentando identidades diferentes.

Nombre las identidades antes de cambiar el código

• La persona que ha iniciado sesión en el navegador de escritorio.
• La cuenta que aloja el proceso de la aplicación.
• Cualquier identidad suplantada activa para la operación saliente.
• La cuenta que el proxy aceptó o rechazó realmente.

En las rutas de autenticación integrada compatibles con .NET, DefaultCredentials se refiere al contexto de seguridad actual. No es un alias global para cualquiera que haya abierto una página en otra máquina.

Si el producto actúa deliberadamente como usuario, la suplantación y cualquier requisito de delegación de red necesitan su propio diseño compatible. Activar un interruptor genérico de uso de credenciales predeterminadas no establece ese diseño. A la inversa, una tarea en segundo plano pensada para ejecutarse como identidad de servicio no debería depender de que alguien abra primero un navegador.

Compare el arranque interactivo y el desplegado sin secretos: contexto de cuenta, extremo del proxy, método anunciado e identidad rechazada. Evite copiar una contraseña de escritorio en la aplicación solo porque hizo que una solicitud puntual tuviera éxito. Configure la cuenta que la aplicación debe usar y luego mantenga esa titularidad visible en el registro de despliegue.