ejemplo - wcf service c# example

La solicitud HTTP no está autorizada con el esquema de autenticación de cliente ''Ntlm''. El encabezado de autenticación recibido del servidor fue ''Negociar, NTLM''

Question

He revisado un montón de artículos SO, e incluso otros sitios, pero parece que este servicio no funciona. Tengo un servicio SOAP al que intento llegar y está configurado de esta forma:

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
        <binding name="PROVIDERSSoapBinding">
            <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
            </security>
        </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://xxx.xx.xx.xxx:9011/provider/services/PROVIDERS"
            binding="basicHttpBinding" bindingConfiguration="PROVIDERSSoapBinding"
            contract="ServiceReference1.ProviderRemote" name="PROVIDERS" />
    </client>
</system.serviceModel>

Sin embargo, recibo el siguiente error al golpearlo desde la aplicación de mi consola:

La solicitud HTTP no está autorizada con el esquema de autenticación de cliente ''Ntlm''. El encabezado de autenticación recibido del servidor fue ''Negociar, NTLM''.

alguien me puede ayudar?

Answer 1

Debe configurar los NTAuthenticationProviders en NTLM

Artículo de MSDN: https://msdn.microsoft.com/en-us/library/ee248703(VS.90).aspx

Línea de comandos de IIS ( http://msdn.microsoft.com/en-us/library/ms525006(v=vs.90).aspx ):

 cscript adsutil.vbs set w3svc/WebSiteValueData/root/NTAuthenticationProviders "NTLM"

Answer 2

Intente configurar ''clientCredentialType'' en ''Windows'' en lugar de ''Ntlm''.

Creo que esto es lo que espera el servidor, es decir, cuando dice que el servidor espera "Negociar, NTLM", que en realidad significa Autenticación de Windows, donde intentará usar Kerberos si está disponible, o si no, volverá a NTLM (de ahí que ''negociar'')

Estoy basando esto en algo de lectura entre las líneas de: Seleccionar un tipo de credencial

Answer 3

Nos encontramos con este problema y descubrimos que el error se estaba generando al usar (IE en nuestro caso) el navegador que inició sesión como la cuenta de proceso, y luego cambiar el inicio de sesión de sesión a través de la aplicación (SharePoint). Creo que este escenario pasa dos esquemas de autenticación:

1. Negociar
2. NTLM

La aplicación albergaba un servicio web * .asmx, al que se llamaba en un servidor con equilibrio de carga, iniciando una llamada de servicio web a sí mismo utilizando un enlace .NET3.5 similar a WCF.

Código que se utilizó para llamar al servicio web:

public class WebServiceClient<T> : IDisposable
{
    private readonly T _channel;
    private readonly IClientChannel _clientChannel;

    public WebServiceClient(string url)
        : this(url, null)
    {
    }
    /// <summary>
    /// Use action to change some of the connection properties before creating the channel
    /// </summary>
    public WebServiceClient(string url,
         Action<CustomBinding, HttpTransportBindingElement, EndpointAddress, ChannelFactory> init)
    {
        var binding = new CustomBinding();
        binding.Elements.Add(
            new TextMessageEncodingBindingElement(MessageVersion.Soap12, Encoding.UTF8));
        var transport = url.StartsWith("https", StringComparison.InvariantCultureIgnoreCase)
                            ? new HttpsTransportBindingElement()
                            : new HttpTransportBindingElement();
        transport.AuthenticationScheme = System.Net.AuthenticationSchemes.Ntlm;
        binding.Elements.Add(transport);

        var address = new EndpointAddress(url);

        var factory = new ChannelFactory<T>(binding, address);
        factory.Credentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;

        if (init != null)
        {
            init(binding, transport, address, factory);
        }

        this._clientChannel = (IClientChannel)factory.CreateChannel();
        this._channel = (T)this._clientChannel;
    }

    /// <summary>
    /// Use this property to call service methods
    /// </summary>
    public T Channel
    {
        get { return this._channel; }
    }
    /// <summary>
    /// Use this porperty when working with
    /// Session or Cookies
    /// </summary>
    public IClientChannel ClientChannel
    {
        get { return this._clientChannel; }
    }

    public void Dispose()
    {
        this._clientChannel.Dispose();
    }
}

Descubrimos que si la credencial de la sesión era la misma que la cuenta de proceso del navegador, solo se usaba NTLM y la llamada fue exitosa. De lo contrario resultaría en esta excepción capturada:

La solicitud HTTP no está autorizada con el esquema de autenticación de cliente ''Ntlm''. El encabezado de autenticación recibido del servidor fue ''Negociar, NTLM''.

Al final, estoy bastante seguro de que uno de los esquemas de autenticación pasaría la autenticación mientras que el otro no, porque no se le otorgó el acceso adecuado.

Answer 4

Puede eliminar al cliente del problema usando wftech , esta es una herramienta antigua, pero me ha resultado útil para diagnosticar problemas de autenticación. wfetch le permite especificar NTLM, Negociar y kerberos, esto puede ayudarlo a comprender mejor su problema. Como está intentando llamar a un servicio y wfetch no sabe nada acerca de WCF, sugeriría aplicar su enlace de punto final (PROVIDERSSoapBinding) al serviceMetadata entonces puede hacer un GET HTTP del WSDL para el servicio con la misma configuración de seguridad.

Otra opción, que puede estar disponible para usted es forzar al servidor a usar NTLM, puede hacer esto editando la metabase (IIS 6) y eliminando la configuración Negociar, más detalles en http://support.microsoft.com/kb/215383 .

Si está utilizando IIS 7.x, entonces el enfoque es ligeramente diferente, los detalles sobre cómo configurar los proveedores de autenticación están aquí http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication .

Observo que ha bloqueado la dirección del servidor con xxx.xx.xx.xxx, así que supongo que se trata de una dirección IP en lugar de un nombre de servidor, esto puede causar problemas con la autenticación, así que si es posible intente apuntar a la máquina nombre.

Lamento no haberte dado la respuesta, sino más bien sugerencias para acercarte al problema, pero espero que te sirva de ayuda.

Terminaré diciendo que he experimentado este mismo problema y que mi único recurso fue utilizar Kerberos en lugar de NTLM, no olvide que deberá registrar un SPN para el servicio si sigue esta ruta.

Answer 5

Sé que esta pregunta es antigua, pero la solución para mi aplicación fue diferente a las respuestas ya sugeridas. Si alguien más como yo todavía tiene este problema, y ​​ninguna de las respuestas anteriores funciona, este podría ser el problema:

Utilicé un objeto de Credenciales de red para analizar un nombre de usuario y contraseña de Windows a un servicio web SOAP de terceros. Había establecido el nombre de usuario = "nombre de dominio / nombre de usuario", contraseña = "contraseña" y dominio = "nombre de dominio". Ahora este juego me da ese extraño error Ntlm y no NTLM. Para resolver los problemas, asegúrese de no usar el parámetro de dominio en el objeto NetworkCredentials si el nombre de dominio está incluido en el nombre de usuario con la barra invertida. Entonces, elimine el nombre de dominio del nombre de usuario y analice en el parámetro de dominio, o deje de lado el parámetro de dominio. Esto solucionó mi problema.

Answer 6

Si tanto su cliente como su servicio están instalados en la misma máquina , y está enfrentando este problema con las configuraciones correctas de cliente y servicio (lea: probado y probado en otra parte) , entonces vale la pena comprobarlo.

Compruebe las entradas del host en su archivo de host

% windir% / system32 / drivers / etc / hosts

Compruebe si está accediendo a su servicio web con un nombre de host, y ese mismo nombre de host se ha asociado con una dirección IP en el archivo de hosts mencionado anteriormente. En caso afirmativo, las credenciales NTLM / Windows NO se pasarán del cliente al servicio, ya que cualquier solicitud para ese nombre de host se enrutará nuevamente a nivel de la máquina.

Pruebe cualquiera de los siguientes

• Elimine la entrada de host de ese nombre de host del archivo hosts
O
• Si no es posible eliminar la entrada del host, intente acceder a su servicio con otro nombre de host. También puede intentar con la dirección IP en lugar del nombre de host

Edición: De alguna manera, la situación anterior es relevante en un escenario de carga equilibrada. Sin embargo, si no es posible eliminar las entradas del host, la desactivación de la comprobación de bucle en la máquina ayudará. Consulte el método 2 en el artículo https://support.microsoft.com/en-us/kb/896861