No, non è esatto dire che è necessario Kerberos, un SPN, per fidarsi del server per la delega e che questo è l'UNICO modo per farlo. Sì, questo è un modo per farlo (e hai bisogno di tutto per farlo accadere tramite Kerberos), ma non è l'UNICO modo, o anche tecnicamente il modo più sicuro o il modo più semplice. Vuoi veramente fare configurazioni extra e creare un login per ogni utente web sul tuo DB in SQL? Cosa succede se uno di questi account è compromesso? Più account, più vulnerabilità.
No, creare invece un account di servizio Dominio e consentire l'accesso a SQL. Se i tipi di sicurezza bloccano le cose, concedi a quell'utente questi diritti: Accesso come servizio, Accesso come lavoro batch e Consenti accesso in locale. Oppure, se questo è solo per sviluppare e testare la teoria o se non ti interessa o non riesci a trovare le impostazioni o continuerai a ricevere errori in seguito, e questo potrebbe non ottenere un ampio seguito, ma dargli un amministratore locale (a volte tu devi fare quello che devi fare - alcuni professionisti della sicurezza bloccano le cose più da vicino di quanto mi piacerebbe scrivere - possono sempre risolvere i problemi di sicurezza in seguito per bloccarli indietro). Quindi imposta quell'account come account personalizzato nel pool di app e assegna a quell'account un accesso in SQL. Dategli un dbo solo su QUESTO database.
Sul sito Web in IIS, impostare il tipo di autenticazione come Windows. Li ho visti dire "Basic" in altri blog, quindi Kerberos funzionerà, ma NTLM utilizza l'autenticazione di Windows. In IIS 7, è possibile anche abilitare ASP.Rappresentazione NET. Personalmente, ho provato solo su IIS 6, ma il principale è lo stesso.
nel web.config, aggiungere questo sotto <configuration>, che è un "pari" 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>
E in <system.web>:
<authentication mode="Windows"/>
<identity impersonate="true"
userName="domain\user"
password="password" />
quindi leggere la stringa nella vostra app come this:
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");
}
Vedere http://msdn.microsoft.com/en-us/library/ms178411.aspx.
Se non si connette all'account di servizio dopo aver inserito quell'account in web.config per il tag impersonato e la connessione SQL, è possibile utilizzare i metodi di rappresentazione utilizzando WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Nello specifico, vuoi wic.Impersonate() e wic.Undo() dopo aver ottenuto il loro token. Puoi leggere il dominio, il nome e la password dell'account di servizio da web.config, sotto forma di AppKeys.
In breve, ci sono modi per risolvere i problemi. È anche possibile crittografare la password nel web.config - sia in ConnectionString, sia se si desidera archiviarla in un AppKey anziché direttamente nel tag "impersonate", se non si desidera che le password in testo semplice siano presenti (Mi raccomando contro), e quindi puoi averlo per la creazione di un token di accesso, se hai bisogno di usare i metodi di rappresentazione (come ho fatto io).
"SQL Server sta negando l'accesso all'utente anonimo", il tuo utente anonimo ha accesso al database? –
L'utente anonimo non ha accesso al database. Non voglio che l'utente anonimo acceda al database, voglio l'utente corrente del sito. La delega dovrebbe significare che l'utente corrente è quello che accede al database, piuttosto che l'utente anonimo. –