2013-02-14 10 views
11

Quando provo e accedere al mio appena distribuito (a lcoal IIS 7.5) MVC4 app, ottengo l'errore:Perché la mia app MVC tenta di accedere al mio DB come macchina e non come identità del pool di applicazioni?

Login failed for user 'DOMAIN\MACHINE-NAME$'

in cui viene aggiunto il '$' e non fa parte del nome della macchina.

La stringa di connessione nel web.config si presenta così:

<add name="ComairRIEntities" 
    connectionString="metadata=res://*/Data.ComairRI.csdl|res://*/Data.ComairRI.ssdl|res://*/Data.ComairRI.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=(local);initial catalog=MyDB;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" 
    providerName="System.Data.EntityClient" /> 

risposta

8

Questo è quello che sta succedendo:

nella stringa di connessione si ha la seguente impostazione: sicurezza integrata = True Ciò significa che la connessione SQL Server verrà autenticato con le credenziali del processo che avvia la connessione. Poiché si esegue IIS e IIS utilizzano i pool di applicazioni, la connessione verrà autenticata con l'utente Windows che esegue il pool di applicazioni. Per impostazione predefinita si tratta di un utente con quasi nessuna autorizzazione denominata NetworkService. NetworkService (o forse in IIS7.5 è diverso) non avrà mai diritti di accesso al tuo database. Le sfumature del tuo scenario particolare potrebbero essere un po 'diverse perché ci sono un sacco di diverse eredità di sicurezza in IIS e un sacco di utenti diversi il processo potrebbe finire, tuttavia, il problema di base è che hai sicurezza integrata = True e l'utente con cui è in esecuzione il processo IIS è un utente standard con quasi nessun diritto.

Per risolvere avete alcune opzioni:

  1. Change protezione integrata = True per l'autenticazione nome utente \ password. Questo lo risolverà al 100%, ma potresti non voler memorizzare la password in chiaro nel file web.config.
  2. Nelle impostazioni della directory virtuale IIS, configurare l'utente anonimo come significativo con i diritti di accesso al db. Questo alla fine aiuterà, ma dovrai giocare con impostazioni diverse per farlo bene.

Se avete bisogno di più aiuto con 2 #, è necessario fornire le seguenti informazioni:

  1. L'identità del AppPool
  2. L'identità della directory virtuale e tutte le impostazioni di autenticazione del directory virtuale.
1

Sei sicuro che questo bit deve avere il & quot?

provider connection string=&quot 

Non dovrebbe essere solo un segno di citazione come nel resto della stringa?

C'è anche uno alla fine della stringa.

+0

la stringa di connessione viene generata da EF e rimane la stessa per tutte le distribuzioni. Quando funziona in tutto tranne uno, dubito che una citazione sanguinante sia il problema. – ProfK

+0

@ProfK ok era solo l'unica cosa che potevo vedere sbagliato con esso –

+2

Questo non è sbagliato. Ho citato l'intera stringa di connessione EF dal file web.config. Utilizza '"' in modo che un "effettivo" venga memorizzato come parte della stringa di connessione e non lo risolva – ProfK

1

Questo è l'account utente locale che l'identità del pool di app si manifesta come quando ci si connette a SQL Server. Prova a cambiare il pool di app per utilizzare il servizio di rete e concedere l'autorizzazione al servizio di rete al tuo database, o dare l'autorizzazione IUSR_YOUR-MACHINE al database. Poiché stai lavorando localmente, potrebbe essere più semplice creare db_owner del servizio di rete del tuo database locale. Ovviamente ci sono problemi di sicurezza nel fare questo in produzione!

3

Ci sono molte buone informazioni in questa domanda: Login failed for user 'DOMAIN\MACHINENAME$'.

If you see a failure like Login failed for user 'DOMAIN\MACHINENAME$' it means that a process running as NETWORK SERVICE or as LocalSystem has accessed a remote resource, has authenticated itself as the machine account and was denied authorization.

Ciò che sembra strano è che si sta ancora cercando di accedere ad un database locale, ma un nome utente di DOMAIN\MACHINENAME$ implica che accede a un database non-locale.

Sei sicuro che la stringa di connessione che hai postato sia effettivamente quella che viene utilizzata?

L'altra cosa che si potrebbe fare è creare un account utente specifico per il pool di applicazioni in cui è in esecuzione il proprio sito - molto probabilmente avrà bisogno di autorizzazioni di lettura e scrittura.

Il tipo di account utente dipenderà dal proprio ambiente: se si sta eseguendo all'interno di un dominio, è possibile creare un utente di dominio e continuare a utilizzare integrated security=True nella stringa di connessione o, in caso contrario, è possibile indagare utilizzando l'autenticazione SQL.

Edit:

Ho avuto questo errore esatto una volta, facendo quasi esattamente la stessa cosa. Nel mio caso il database era su un server separato (cioè, non la stessa macchina di quanto sembra essere nel tuo caso), ma la soluzione era questa:

  1. Creare un account di dominio.
  2. Aggiungilo a Sicurezza \ Accesso e sicurezza \ Utenti in SQL Management Studio.
  3. Fornirlo con l'appartenenza al ruolo db_datareader e db_datawriter in SQL Management Studio.
  4. Sul server Web, eseguire aspnet_regiis -ga domain\account_name
  5. Impostare questo account su quello utilizzato per l'accesso anonimo.
  6. Creare un nuovo pool di applicazioni per questa applicazione Web.
  7. Impostare l'identità del pool di applicazioni su questo account.

Si noti che questo era per IIS 6, quindi se siete in IIS 7 + potrebbe non essere necessario punti 4, 5 e 6.

1

Verificare l'identità che l'AppPool per la vostra applicazione è in esecuzione in Gestore IIS. Probabilmente sarà AppPoolIdentity. Quindi verificare di aver creato un accesso in SQL Server per tale identità, che sia mappato al proprio database e che disponga dell'appartenenza/delle autorizzazioni necessarie per il ruolo richieste dall'applicazione. Il nome dell'identità sarà "IIS AppPool \ [AppPoolName]". (Vedi http://www.iis.net/learn/manage/configuring-security/application-pool-identities per ulteriori informazioni).

Se ciò non funziona, spiegare il modo in cui è configurata la connessione del database dell'applicazione, incluso se la rappresentazione è abilitata o meno.

2

Una cosa da notare è che DOMAIN\MACHINE-NAME$ è la sintassi utilizzata per rappresentare le credenziali della macchina nel dominio. Analogamente a come si dispone di un account utente, esiste anche un account computer quasi identico (tranne che le autorizzazioni sono significativamente diverse).

Poiché si ottiene DOMAIN\MACHINE-NAME$ non si dispone di un problema di rappresentazione. La prima cosa da fare è guardare il pool di applicazioni per vedere quale identità è in esecuzione come.

È possibile eseguire questa operazione aprendo Gestione IIS e selezionando Pool di applicazioni. Quindi selezionare il pool di applicazioni e fare clic su "Visualizza applicazioni" a destra, questo consente di verificare che tutto sia impostato correttamente.

Se è configurato correttamente poi cliccare su "Impostazioni avanzate ...", sotto il "Modello di processo" header c'è un campo di "Identità", dovrebbe essere uno dei seguenti:

  • ApplicationPoolIdentity
  • LocalService
  • LocalSystem
  • NetworkService
  • DOMINIO \ account

Se ApplicationPoolIdentity è impostato come previsto, se non è uno personalizzato altrimenti, è probabile che si ottenga DOMAIN\MACHINE-NAME$ come si verifica. È dubbio un account personalizzato dal momento che si presenterebbe come tale account.

Se è ApplicationPoolIdentity e la macchina SQL non si trova sulla stessa macchina (o potenzialmente se si utilizza un nome host o un indirizzo IP), è possibile ottenere DOMAIN\MACHINE-NAME$ poiché si tratta delle credenziali di rete di ApplicationPoolIdentity. ApplicationPoolIdentity utilizza IIS AppPool\ApplicationPool per l'accesso locale, ma DOMAIN\MACHINE-NAME$ per l'accesso remoto, poiché il primo è disponibile solo localmente.

Verificare inoltre che si stia effettivamente utilizzando quella stringa di connessione esatta, per i motivi sopra riportati in merito al metodo di accesso che è importante.

Se questo non lo risolve, sarebbe di aiuto se si dettagliasse quale Identità è stata impostata e se la rappresentazione di ASP.Net è abilitata.

1

Esaminerò quanto segue.

Invece di "origine dati = (locale)" utilizzare il nome computer in cui risiede il database. Controlla la risoluzione DNS per assicurarti che il nome sia corretto.

Assicurarsi che l'utente in cui è in esecuzione il pool di applicazioni abbia il permesso di connettersi al server del database.

1

È necessario aggiungere l'identità del pool di applicazioni al server SQL come accesso. leggere questo: http://www.iis.net/learn/manage/configuring-security/application-pool-identities-and-sql-server-express

+0

Il pool di app e l'identità della macchina non sono la stessa cosa: sta tentando di accedere a SQL come identità * machine * – ProfK

+0

@ProfK Anche se i nostri registri mostravano l'identità della macchina negli errori di accesso, quando abbiamo aggiunto l'identità del pool in realtà ha funzionato. – julealgon