ADFS调用WCF服务遇Negotiate认证未授权问题求助

Let’s break down this tricky issue step by step—since you’re dealing with ADFS 2012 R2’s Windows Service-based host and a net.tcp WCF endpoint, the usual IIS-focused fixes won’t cut it. Here are targeted troubleshooting steps to try:

1. Resolve the HTTP vs Net.TCP Contradiction in the Error #

Your error mentions an HTTP request failure, but the WCF endpoint is net.tcp://<url>:8002/service/endpoint—this mismatch is a red flag.

• Verify your ADFS attribute store configuration with PowerShell:

  Get-AdfsAttributeStore
  

  Double-check that the EndpointUri matches the exact net.tcp address (no typos, missing net.tcp prefix, or incorrect port). A stray HTTP URI in the config could be causing this odd error message.

2. Validate ADFS Service Account Permissions #

ADFS runs under a dedicated service account (default: ADFS Service), and net.tcp uses Windows Negotiate auth—this account needs explicit access to the WCF service:

• Test connectivity as the ADFS service account:

  runas /user:<DOMAIN>\<ADFS-Service-Account> cmd.exe
  

  From this elevated command prompt, run:

  telnet <target-url> 8002
  

  If the connection fails, the account lacks network access rights (likely blocked by domain policies or local server permissions).
• Ensure the ADFS service account is added to the local Administrators group on the WCF server (or at least has permissions to access the net.tcp endpoint).
• Check the WCF service’s security config: Confirm it uses Security.Mode = Transport or TransportWithMessageCredential with ClientCredentialType = Windows—mismatched auth settings here will trigger Negotiate failures.

3. Verify Net.TCP Port Sharing and WCF Service Configuration #

Even if netstat shows port 8002 is listening, hidden WCF config issues could block connections:

• Check if the Net.TCP Port Sharing Service is running on the WCF server:

  Get-Service NetTcpPortSharing
  

  If your WCF binding has portSharingEnabled="true", this service must be running to allow shared net.tcp port access.
• Cross-reference the WCF service’s endpoint address with what ADFS is calling—even minor differences (like trailing slashes or case sensitivity) can break the connection.

4. Rule Out Network Layer Blocking (Beyond Windows Firewall) #

Disabling Windows Firewall isn’t enough—corporate network tools could still intercept net.tcp traffic:

• Test basic TCP connectivity from the ADFS server:

  Test-NetConnection <target-url> -Port 8002
  

  If this fails, run a packet capture (using Wireshark) on both the ADFS and WCF servers to see if TCP handshakes complete, or if RST packets are being sent to block the connection.
• Check local security policies on the ADFS server: Look for policies under Local Policy > Security Options that restrict outbound TCP connections or service account network access.

5. Enable Detailed Logging for Root Cause Analysis #

Turn up logging on both ADFS and WCF to get granular error details:

• Enable ADFS Debug Logs:

  Set-AdfsProperties -EnableDebugLog $true
  

  Reproduce the error, then check the ADFS > Debug log in Event Viewer for specific auth or connection failures.
• Enable WCF Trace Logs: Add this config to your WCF service’s app.config/web.config to capture incoming requests and errors:

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
        <listeners>
          <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Logs\WcfTrace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
  

  If the log shows no incoming requests from ADFS, the issue is definitely on the ADFS outbound/network side. If requests do arrive, check the service-side auth errors.

6. Re-Register the ADFS Attribute Store #

Corrupted attribute store config can cause silent failures:

• Unregister and re-register the store with PowerShell:

  Unregister-AdfsAttributeStore -Name "<Your-Attribute-Store-Name>"
  Register-AdfsAttributeStore -Name "<Your-Attribute-Store-Name>" -Type "<Full-Type-Name>" -Configuration @{ Endpoint = "net.tcp://<url>:8002/service/endpoint" }
  

  Ensure the Type parameter matches the correct assembly and class name for your custom attribute store.

内容的提问来源于stack exchange，提问作者MattDuFeu