다음을 통해 공유

AD FS 2.0: The Admin Event Log Shows Error 111 with System.ArgumentException: ID4216

  • 아티클

Symptoms

When a user browses to a relying party (RP) application in which the IP-STS or RP-STS is AD FS 2.0, the user provides credentials to the STS and subsequently fails before the STS response is posted either to the RP or the RP-STS (depending on your deployment scenario).

Event Viewer shows Error Event 111 in the AD FS 2.0/Admin log with the following detail:

 

The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue

Additional Data
Exception details:
System.ArgumentException: ID4216: The ClaimType '<some-value>' must be of format 'namespace'/'name'.
Parameter name: claimType
   at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)

 

If you test this scenario using IDP-initiated sign-on, you may find that access to the RP works with no error.

The URL to test IDP-initiated sign-on to AD FS 2.0 is: https://<sts-DNS-name>/adfs/ls/idpinitiatedsignon.aspx

Cause

In short, the STS has a Claim Description with a Claim Type (URI) which does not meet the format requirements for the SAML token requested.

SAML tokens have URI (ClaimType) rules that will differ based on the version of the SAML token you intend to issue. AD FS 2.0 supports WS-Federation, WS-Trust, and SAML 2.0 protocols. WS-Federation protocol only supports SAML 1.1 tokens. WS-Trust protocol can work with multiple token types. SAML 2.0 protocol only supports SAML 2.0 tokens.

SAML 1.1 tokens have strict URI rules which state that the format must be  'namespace'/'name'. These can be constructed many ways, and here are a few common examples:

  • myOrganization/myClaimType
  • urn:myOrganization:claims/myClaimType
  • http://myOrganization/claims/myClaimType

SAML 2.0 tokens do not have the same URI requirements, and simple names can be used. Examples:

  • emailAddress
  • costCenter

When you are browsing to the RP application first, you are performing RP-initiated sign-on which could result in a request on any of the supported protocols. If your RP is protected by WIF, then your request will be WS-Federation which means a SAML 1.1 token. A Fiddler trace will clue you in to which protocol you are using. If you are doing IDP-initiated sign-on, then you are utilizing SAML 2.0 protocol, which means you get a SAML 2.0 token. This explains why the IDP-initiated sign-on scenario may be working for you.

Resolution

The easiest solution is to change your Claim Descriptions to only include Claim Types which are compliant with SAML 1.1 token rules. That way, it doesn't matter which protocol or token type you are using, and the Claim Description will be versatile for any protocol scenario (consider protocol transition).

If there is some reason the claim type cannot be changed, then you need to ensure that your RP-initiated request utilizes a request for a SAML 2.0 token, or you could move toward a IDP-initiated solution which would guarantee the use of a SAML 2.0 token.