c# - clientcredentialtype - wcf message security certificate
La solicitud HTTP no está autorizada con el esquema de autenticación de cliente ''Negociar''. El encabezado de autenticación recibido del servidor era ''NTLM'' (5)
Hace algunos días tuve un gran dolor de cabeza con problemas de autenticación al usar la autenticación de Windows entre el cliente y el servicio web wcf . El error que estaba obteniendo era "La solicitud HTTP no está autorizada con el esquema de autenticación del cliente ''Negociar''. El encabezado de autenticación recibido del servidor era" NTLM ". Ninguna de las soluciones en la pila funcionaba porque la mayoría de ellas estaban relacionadas con métodos antiguos.
Actualicé mi versión anterior de WCF a WCF 4 con los cambios a continuación, espero que también pueda hacer los cambios similares.
1. Web.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Demo_BasicHttp">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="InheritedFromHost"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="DemoServices.CalculatorService.ServiceImplementation.CalculatorService" behaviorConfiguration="Demo_ServiceBehavior">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="Demo_BasicHttp" contract="DemoServices.CalculatorService.ServiceContracts.ICalculatorServiceContract">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Demo_ServiceBehavior">
<!-- To avoid disclosing metadata information, set the values below to false before deployment -->
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<protocolMapping>
<add scheme="http" binding="basicHttpBinding" bindingConfiguration="Demo_BasicHttp"/>
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
</system.serviceModel>
2. App.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ICalculatorServiceContract" maxBufferSize="2147483647" maxBufferPoolSize="33554432" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="4096" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:24357/CalculatorService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICalculatorServiceContract" contract="ICalculatorServiceContract" name="Demo_BasicHttp" />
</client>
</system.serviceModel>
La solución para mí fue configurar la AppPool para que utilizara el AppPoolIdentity para la identidad de NetworkService.
No es este el problema exacto, pero este es el resultado principal cuando se busca casi el mismo error :
Si ve este problema llamando a un servicio WCF alojado en el mismo equipo, es posible que deba rellenar la clave de registro BackConnectionHostNames
- En regedit, busque y haga clic en la siguiente subclave de registro:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa/MSV1_0 - Haga clic con el botón derecho en
MSV1_0, seleccione Nuevo y luego haga clicMulti-String Value. - En la columna Nombre, escriba
BackConnectionHostNames, y luego presione ENTER. - Haga clic con el botón
BackConnectionHostNamesenBackConnectionHostNamesy luego haga clic en Modificar. En el cuadro Información del valor, escriba CNAME o el alias DNS que se utiliza para los recursos compartidos locales en la computadora y luego haga clic en Aceptar.- Escriba cada nombre de host en una línea separada.
Consulte Llamando al servicio WCF alojado en IIS en la misma máquina que el cliente arroja un error de autenticación para más detalles.
Para mí, la solución fue además de usar "Ntlm" como tipo de credencial:
XxxSoapClient xxxClient = new XxxSoapClient();
ApplyCredentials(userName, password, xxxClient.ClientCredentials);
private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
{
clientCredentials.UserName.UserName = userName;
clientCredentials.UserName.Password = password;
clientCredentials.Windows.ClientCredential.UserName = userName;
clientCredentials.Windows.ClientCredential.Password = password;
clientCredentials.Windows.AllowNtlm = true;
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
}
LA RESPUESTA: El problema era que todas las publicaciones para tal problema estaban relacionadas con problemas más antiguos de kerberos e IIS donde las credenciales de proxy o las propiedades de AllowNTLM estaban ayudando. Mi caso fue diferente. Lo que descubrí después de horas de recoger gusanos del suelo fue que, en cierta medida, la instalación de IIS no incluía el proveedor Negotiate en la lista de proveedores de autenticación de Windows de IIS. Así que tuve que agregarlo y moverme hacia arriba. Mi servicio WCF comenzó a autenticarse como se esperaba. Aquí está la captura de pantalla de cómo debería verse si está utilizando la autenticación de Windows con la autenticación anónima OFF .
Debe hacer clic con el botón derecho en la autenticación de Windows y elegir el elemento del menú de proveedores.
Espero que esto ayude a ahorrar algo de tiempo.