Domanda

Ho un sito Web che funziona correttamente con IIS 6.0:Autentica gli utenti con le credenziali di Windows e quindi, quando comunica con il servizio che raggiunge il DB, passa le credenziali.

In IIS 7.0, le stesse impostazioni di configurazione non passano le credenziali e il DB viene colpito da NT AUTHORITY\ANONYMOUS.

C'è qualcosa che mi sfugge?Ho disattivato l'accesso ANONIMO nel mio sito Web IIS 7.0, ma non riesco a farlo funzionare.

Queste sono le impostazioni che sto utilizzando sia su IIS 6.0 che su 7.0:

<authentication mode="Windows">
<identity impersonate="true">

Cosa è cambiato da 6.0 a 7.0?

È stato utile?

Soluzione

Sono state apportate modifiche tra IIS7 e IIS6.0.Ho trovato per te un post sul blog che potrebbe effettivamente aiutarti (clicca qui per vederlo).

Stai eseguendo la tua applicazione in modalità integrata o in modalità classica?Da quello che ho visto, impostando l'attributo Impersonate su true dovresti visualizzare un errore 500 con il seguente messaggio di errore:

Errore interno del server.Questo è l'errore HTTP 500.19:Non è possibile accedere alla pagina richiesta perché i dati di configurazione correlati per la pagina non sono validi.

Ecco la soluzione alternativa proposta:

Soluzione alternativa:

1) Se l'applicazione non si basa sull'impersonamento dell'utente richiedente nelle fasi di BeginRequest e AuthenticaTeRequest (le uniche fasi in cui la rappresentazione non è possibile in modalità integrata), ignora questo errore aggiungendo quanto segue al Web.Config della tua applicazione:

<validation validateIntegratedModeConfiguration="false"

/>

2) Se l'applicazione fa affidamento sull'impersone in BeginRequest e AuthenticaTeRequest, oppure non sei sicuro, passa alla modalità classica.

Speravo che fosse utile per capire come funziona ora IIS 7.0.

Altri suggerimenti

Il tuo server IIS è configurato per essere considerato attendibile per la delega da parte di SQLServer?Mi sono già imbattuto in questo problema in precedenza con WebDAV in cui dovevamo avere il server che esegue IIS considerato affidabile dal file server per l'autenticazione per conto del file server.

Interessante...Io ho il problema opposto - Non essere capace per ottenere che l'autenticazione venga passata dal browser client, attraverso il server web e sul database all'interno di una grande rete aziendale tramite firewall.

Ritengo inoltre che l'autenticazione "end-to-end-user" nel database sia una cattiva idea e un potenziale rischio per la sicurezza.Non c'è nulla che impedisca all'utente finale di caricare query SQL e di connettersi direttamente al tuo database, quindi è meglio che il tuo schema sia bloccato!

@Esteban - Chiarito il mio non molto utile per aiutarti risposta.

In genere, se si esegue un'autenticazione double hop come questa, Kerberos è generalmente coinvolto a meno che la prima autenticazione non sia Basic.

Controllerei l'autenticazione sui server IIS 6 e mi assicurerei che sia la stessa su IIS 7.

Se la casella IIS 6 è impostata su Windows Integrato, è necessario verificare le impostazioni Kerberos: SPN, delega ecc.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top