No, no es exacto decir que necesita Kerberos, un SPN, para confiar en el servidor para la delegación, y que esta es la ÚNICA manera de hacerlo. Sí, esta es una forma de hacerlo (y lo necesita todo para que sea posible a través de Kerberos), pero no es la ÚNICA manera, ni siquiera la más segura ni la más fácil. ¿Realmente desea tener que hacer configuraciones adicionales y crear un inicio de sesión para cada usuario de la web a su base de datos en SQL? ¿Qué pasa si cualquiera de esas cuentas está en peligro? Más cuentas, más vulnerabilidades.
No, cree una cuenta de servicio de dominio, y deje que acceda a SQL. Si sus chicos de seguridad cierran las cosas, dele a este usuario estos derechos: inicie sesión como un servicio, inicie sesión como un trabajo por lotes y permita el inicio de sesión localmente. O bien, si esto es solo para desarrollar y probar la teoría, o si no le importa o no puede encontrar la configuración o si aún recibe errores más adelante, y esto podría no obtener una gran cantidad de seguidores, pero dele la administración local (a veces tengo que hacer lo que tienes que hacer - algunos profesionales de seguridad cierran las cosas más de lo que me gustaría escribir - siempre puede solucionar problemas de seguridad más tarde para volver a cerrarla). Luego configure esa cuenta como la cuenta personalizada en el grupo de aplicaciones y otorgue a esa cuenta un inicio de sesión en SQL. Dale dbo en solo esa base de datos.
En el sitio web de IIS, configure el tipo de autenticación como Windows. Los he visto decir "Básico" en otros blogs para que Kerberos funcione, pero NTLM utiliza la autenticación de Windows. En IIS 7, es posible que también desee habilitar ASP.Suplantación NET. Personalmente, solo he probado esto en IIS 6, pero el principal es el mismo.
En el web.config, agregue esto bajo <configuration>, que es un "par" a <system.web>:
<connectionStrings>
<add
name="NorthwindConnectionString"
connectionString="Data Source=serverName;Initial
Catalog=Northwind;Integrated Security=SSPI;User
ID=userName;Password=password"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
Y en <system.web>:
<authentication mode="Windows"/>
<identity impersonate="true"
userName="domain\user"
password="password" />
Luego leer la cadena en su aplicación como esto:
using System.Configuration;
string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString;
if (connString != null) // do DB connection stuff here
Console.WriteLine("Northwind connection string = \"{0}\"",
connString.ConnectionString);
else
Console.WriteLine("No Northwind connection string");
}
Ver http://msdn.microsoft.com/en-us/library/ms178411.aspx.
Si no se conecta con la cuenta de servicio después de completar esa cuenta en el archivo web.config para la etiqueta impersonate y la conexión SQL, puede usar los métodos de suplantación utilizando WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Específicamente, quiere wic.Impersonate() y wic.Undo() después de obtener su token. Puede leer en el dominio, nombre y contraseña de la cuenta de servicio desde web.config, en la forma de AppKeys.
En resumen, hay formas de solucionar los problemas. Incluso puede cifrar la contraseña en el archivo web.config, tanto en ConnectionString como si desea almacenarlo en un AppKey en lugar de directamente en la etiqueta "impersonate", si no desea las contraseñas de texto sin formato (que Recomendaría en contra), por lo que puede tenerlo para la creación de un token de Inicio de sesión, si necesita utilizar los métodos de Suplantación (como yo lo hice).
"el SQL Server niega el acceso al usuario anónimo", ¿tiene acceso el 'usuario anónimo' a la base de datos? –
El usuario anónimo no tiene acceso a la base de datos. No quiero que el usuario anónimo acceda a la base de datos, quiero el usuario actual del sitio web. La delegación debe significar que el usuario actual es el que accede a la base de datos, en lugar del usuario anónimo. –