¿Cómo escribir código que llame a un servicio WCF y que retroceda desde Kerberos a NTLM si es necesario?

Question

Necesito llamar a un servicio de WCF programmatically. El servicio puede hospedarse con ya sea autenticación NTLM o Kerberos y debe funcionar bajo cualquiera de ellos. Es decir, si falla la conexión al servicio a través de Kerberos, debe recurrir a NTLM.

Aquí está el código que estoy usando para Kerberos de autenticación (si es relevante, el servicio está alojado en SharePoint 2010 y se está llamando desde una pieza de la tela):

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; 
} 

llamar a un método en el proxy cuando es ejecutado en un entorno NTLM da el error:

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

Nota: la dirección URL puede estar en otra aplicación web en otro servidor. No puedo verificar en qué autenticación se ejecuta la aplicación web de la parte web y asumir que es igual a donde se aloja el servicio WCF.

¿Cómo puedo (automática o manualmente) garantizar que la autenticación vuelva desde Kerberos a NTLM cuando falla?

Actualización:

Como se mencionó, el error de autenticación se produce cuando se llama a un método web. Sin embargo, no quiero esperar tanto, ya que hay varios métodos web en el servicio llamados desde varios lugares. Me gustaría probar la autenticación en el punto donde está configurado el proxy (en el fragmento de código anterior).

He intentado usar proxy.Open() pero eso no parece causar la falla.

Answer 1

no he sido capaz de encontrar una manera de hacer esto de forma automática. En su lugar, agregué UI a la aplicación donde se debe elegir el tipo de autenticación.

Answer 2

Esto es un poco fuera de balance, pero ¿por qué está retrocediendo a NTLM. He tenido dificultades significativas con la seguridad en Active Directory y WCF, todos relacionados con los nombres principales del servicio (SPN).

Kerberos fallará si está ejecutando el servicio como algo más que el Servicio de red a menos que tenga un SPN declarado en el dominio para su servicio. Para configurar el SPN necesita el kit administrativo del servidor de Windows, que tiene el comando setspn.

setspn -A HTTP\machinename domain\service_account 

Esto permitirá que Kerberos comparta las credenciales del cliente a su servicio dentro del dominio.

Lea atentamente, ya que podría romper kerberos para cualquier otro servicio que se ejecute en la misma caja, dependiendo de su configuración.

Answer 3

que tenían el mismo error msg, que he publicado sobre here y lo resolvió mediante la creación de un extremo dinámico de este 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; 
} 

estaba corriendo el servicio WCF como un usuario de Active Directory específico en lugar del NETWORK_SERVICE por defecto .

Answer 4

entorno Probar:

proxy.ClientCredentials.Windows.AllowNTLM = true;

Según this, AllowNTLM está obsoleta - no estoy seguro de cuál es la alternativa correcta es.

Answer 5

Supongo que está utilizando el nombre completo dns del servidor como la dirección del servicio. Intente usar el nombre NETBIOS o la dirección IP. Eso debería obligarlo a usar NTLM.

Si sabe qué protocolo está usando el servidor, puede configurar su aplicación para usar el nombre completo o la ip.

la esperanza de que funcione para usted.

Answer 6

Si falla su Kerberos, se establecerá automáticamente de forma predeterminada a NTLM, no tiene que hacer nada especial.

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

(I reconocen el post original es muy antigua.)

¿Se puede usar algo distinto BasicHttpBinding (como wsHttpBinding)? De acuerdo con el artículo this, BasicHttpBinding es la única excepción a los objetos vinculantes, ya que no negocia automáticamente. Esta es la razón por la cual allowNTLM no tiene ningún efecto.