.Net 3.5 SP1 breaks WCF clients and enforces server-side internal artifact on client - by Sytelus

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 364077 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 8/27/2008 4:36:27 PM
Access Restriction Public


Deployment of .Net 3.5 SP1 will cause clients of WCF services to fail with authentication error if WCF service is using Windows Auth over https (among other conditions). This is frequent enterprise scenario and not an edge case.

.Net 3.5 SP1 now adds a requirement for WCF clients to include UPN or SPN (see SP1 Readme file section This can be done by adding <Identity> element in endpoint in client's App.Config file although it will require new release of client. Also it may not be as simple if client is using ClickOnce and if there are different environments (such as Dev, Test, UAT etc).

This requirement has following additional defects:

1. The server-side service account name is now exposed to client. The client's config file must stay up to date if service account on server changes.

2. Even after adding this <Identity> element client still may fail to authenticate because of the behaviour of System.ServiceModel.ClientBase<T> constructor that accepts remoteAddress as parameter.

Many WCF services in enterprise tends to use Windows Auth and sometimes with Kerberos Constrained Delegation to realise SOA architecture. As the enterprise applications have various phases (Dev, Test, UAT, Production) the address of WCF service is almost never hardcoded in client's config file but instead if retrieved at run time. This leads client code to use the constructors of System.ServiceModel.ClientBase<T> which accepts remoteAddress as string parameter. However whenever this construcor is used, all child elements of <endpoint> in client's config file ignored (including <Idenity> element which is now required by 3.5 SP1). This causes client code to fail with following errors even after they have included <Identity> element with UPN.

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


The remote server returned an error: (401) Unauthorized


The target principle name is incorrect

You might also see error code KRB_AP_ERR_MODIFIED in event viewer when you enable kerberos logging via registry.

Sign in to post a comment.