2015-05-12 16 views
5

Ho due siti, A e B. A utilizza un'API che espone B e B richiede l'autenticazione di Windows. Entrambi i siti vivono nel dominio D.autenticazione di Windows da locale a server, ma non da server a server

L'API viene consumata tramite HttpClient e quando il sito A viene eseguito localmente, sotto il mio account di dominio (che si trova nel dominio P), l'accesso è concesso. In questo caso, HttpClient è istanziato in questo modo:

using(var client = new HttpClient(new HttpClientHandler { UseDefaultCredentials: true })) 

Quando A viene distribuito a un server di prova, i risultati di cui sopra in una risposta 401 Unauthorized. Il pool di applicazioni sul server di test è in esecuzione con un account di servizio nel dominio D.

Quando esplicitamente utilizzando tale account di servizio come questo:

var credential = new NetworkCredential("service-account", "password", "D"); 
var cache = new CredentialCache 
{ 
    { 
    new Uri(apiServerUri), "NTLM", credential 
    } 
}; 
var handler = new HttpClientHandler 
{ 
    Credentials = cache 
}; 

using(var client = new HttpClient(handler)) 
... 

E ancora in esecuzione sito A a livello locale, l'accesso è ancora concesso. L'accesso è garantito anche quando si accede all'API direttamente tramite browser e si specificano le credenziali dell'account di servizio. I registri indicano che è sicuramente l'account di servizio utilizzato per accedere all'API.

La distribuzione di questo retro al server di test produce ancora 401 Unauthorized.

Il deployment del sito A in un'istanza locale di IIS, inoltre, utilizza correttamente l'API di B.

Il sito in esecuzione B localmente e quindi l'accesso tramite il sito A localmente, restituisce 401 Unauthorized.

L'accesso all'API tramite un browser sul server di prova in cui è distribuito lo A e che specifica le credenziali dell'account del servizio fornisce anche uno 401 Unauthorized.

Non sono sicuro di dove andare da qui - mi manca qualcosa nel codice per farlo funzionare? O è probabile che sia un problema di IIS o AD?

+0

Emana come il problema Kerberos, prova questo: http://blog.jimmychandra.com/post/service-principal-name-headache –

+0

Non sto tentando di eseguire l'autenticazione double-hop o passthrough, quindi non lo sono sicuro come sarebbe un problema di delega? Dovrebbe semplicemente usare l'identità del pool di app. Ma continueremo a farlo subito –

+0

Quindi Web 1 è sullo stesso server di Web2? Potrebbe essere una semplice reazione da quando vedevo Server To Server. Supponendo client -> server 1 -> server 2 (come in letterale box server/istanza server e non solo livello applicazione Web) ... –

risposta

4

Mentre sono ancora da determinare esattamente il motivo per cui questo lavoro intorno funziona, o se c'è un modo migliore di farlo (perché questo si sente goffo), il seguente ha permesso A per la connessione a B, quando entrambi sono seduti sullo stesso server.

Il sito B ha avuto un'ulteriore impostazione di binding dell'host in IIS, per l'ascolto su localhost:12345. Il sito A è stato configurato per la connessione a tale endpoint, anziché il nome di dominio per il sito B. L'autenticazione ora funziona correttamente.

Sarei interessato se qualcuno può spiegare perché questo è il caso - non mi piacciono le correzioni "magiche".

modificare sembrerebbe che this kb article è una causa probabile per questo comportamento.In particolare:

Quando si utilizza il nome di dominio completo (FQDN) o un'intestazione host personalizzato per navigare un sito Web locale che è ospitato su un computer che è esegue Microsoft Internet Information Services (IIS) 5.1 o una versione successiva , potrebbe essere visualizzato un messaggio di errore analogo al seguente: HTTP 401.1 - non autorizzata: accesso non riuscito Questo problema si verifica quando il sito Web utilizza l'autenticazione integrata ed ha un nome che è mappato all'indirizzo di loopback locale

e

Pertanto, l'autenticazione non riesce se il nome di dominio completo o l'intestazione dell'host personalizzato che si utilizza non corrisponde al nome del computer locale.

Le modifiche del Registro di sistema non sono realmente un'opzione su questi server, quindi sembra che il lavoro attorno a ciò che verrà utilizzato.

Problemi correlati