Come scrivere codice che chiama un servizio WCF e se necessario torna da Kerberos a NTLM?

Question

Devo chiamare un servizio WCF a livello di programmazione. Il servizio può essere ospitato con l'autenticazione o NTLM o Kerberos e deve funzionare in entrambi. Cioè, se la connessione al servizio via Kerberos fallisce, allora dovrebbe tornare a NTLM.

Ecco il codice che sto utilizzando per Kerberos autenticazione (se del caso, il servizio è ospitato in SharePoint 2010 e viene chiamato da una parte web):

public static SiteMembershipSvc.SiteMembershipServiceClient InitialiseSiteMembershipService(string url) 
{ 
    var binding = new BasicHttpBinding(); 
    binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; 
    binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows; 
    url = url.EndsWith("/") ? url + SiteMembershipAddress : url + "/" + SiteMembershipAddress; 
    var endpoint = new EndpointAddress(url); 
    var proxy = new SiteMembershipSvc.SiteMembershipServiceClient(binding, endpoint); 
    proxy.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation; 
    return proxy; 
} 

Chiamare un metodo sul proxy quando corsa in un ambiente NTLM dà l'errore:

The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'NTLM'.

Nota: l'URL può essere in un'altra applicazione web su un altro server. Non riesco a verificare quale autenticazione esegue l'app web della web part e ritengo che sia la stessa di dove è ospitato il servizio WCF.

Come è possibile (automaticamente o manualmente) garantire che l'autenticazione ricada indietro da Kerberos a NTLM in caso di errore?

Aggiornamento:

Come detto, l'errore di autenticazione si verifica quando un metodo Web viene chiamato. Tuttavia, non voglio aspettare così a lungo che ci sono diversi metodi web nel servizio chiamato da più posti. Mi piacerebbe testare l'autenticazione nel punto in cui è configurato il proxy (nello snippet di codice sopra).

Ho provato a utilizzare proxy.Open() ma ciò non sembra causare l'errore.

Answer 1

non sono stato in grado di trovare un modo per farlo automaticamente. Invece ho aggiunto l'interfaccia utente all'applicazione in cui deve essere scelto il tipo di autenticazione.

Answer 2

Questo è un po 'fuori curva, ma perché ricade su NTLM. Ho avuto grosse difficoltà con la sicurezza nella directory attiva e WCF tutte correlate ai nomi principali dei servizi (SPN).

Kerberos avrà esito negativo se si sta eseguendo il servizio come servizio diverso da Servizio di rete a meno che non sia stato dichiarato un SPN nel dominio per il servizio. Per impostare l'SPN è necessario il kit di amministrazione del server Windows, che ha il comando setspn.

setspn -A HTTP\machinename domain\service_account 

Ciò consentirà quindi a Kerberos di condividere le credenziali del client per il servizio all'interno del dominio.

Si prega di fare qualche lettura, in quanto si potrebbe rompere kerberos per tutti gli altri servizi in esecuzione sulla stessa scatola a seconda della configurazione.

Answer 3

Ho avuto lo stesso msg di errore che ho postato su here e risolto con la creazione di un endpoint dinamico in questo modo:

public static SiteMembershipSvc.SiteMembershipServiceClient InitialiseSiteMembershipService(string url) 
{ 
    //create endpoint 
    EndpointAddress ep = new EndpointAddress(new Uri(string), EndpointIdentity.CreateUpnIdentity("MyDomain\WCFRunAsUser")); 
    //create proxy with new endpoint 
    SiteMembershipSvc.SiteMembershipServiceClient service = new SiteMembershipSvc.SiteMembershipServiceClient("wsHttp", ep); 
    //allow client to impersonate user 
    service.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation; 
    //return our shiny new service 
    return service; 
} 

stavo correndo il servizio WCF come un utente di Active Directory specifico piuttosto che il NETWORK_SERVICE predefinita .

Answer 4

impostazione Prova:

proxy.ClientCredentials.Windows.AllowNTLM = true;

Secondo this, AllowNTLM è ormai obsoleto - io non sono sicuro di quello che l'alternativa corretta è.

Answer 5

Suppongo che si stia utilizzando il nome DNS completo del server come indirizzo del servizio. Prova a utilizzare il nome NETBIOS o l'indirizzo IP. Questo dovrebbe costringerlo a usare NTLM.

Se si conosce il protocollo utilizzato dal server, è possibile configurare l'app in modo che utilizzi il nome completo o l'ip.

Spero che funzioni per voi.

Answer 6

Se il tuo Kerberos fallisce, verrà automaticamente impostato su NTLM, non devi fare nulla di speciale.

http://www.windowsecurity.com/articles/Troubleshooting-Kerberos-SharePoint-environment-Part1.html

http://www.windowsecurity.com/articles/Troubleshooting-Kerberos-SharePoint-environment-Part2.html

http://www.windowsecurity.com/articles/Troubleshooting-Kerberos-SharePoint-environment-Part3.html

Answer 7

(riconosco il post originale è molto vecchio.)

è possibile utilizzare qualcosa di diverso BasicHttpBinding (come WsHttpBinding)? Secondo l'articolo this, BasicHttpBinding è l'unica eccezione agli oggetti vincolanti, in quanto non negozia automaticamente. Questo è il motivo per cui allowNTLM non ha alcun effetto.