No mapping for SAML authentication found

I just assisted a customer that was getting the following error in their ULS logs when trying to crawl a Duet BCS content source:

Error while crawling LOB contents. ( CX_WS_SECURITY_FAULT:An exception occurred: No mapping for SAML authentication found (Issuer SharePoint) )

We logged on to SharePoint as the service account being used to do the crawl and tried to display a list based on the Duet External Content Type and the same basic error was displayed:

CX_WS_SECURITY_FAULT:An exception occurred: No mapping for SAML authentication found (Issuer SharePoint)

When logged on to SharePoint as a different user the list displayed correctly, so our problem seemed to be user-specific. Based on my experience this typically means that there is a problem with the user mapping table (VUSREXTID) in SAP.

To troubleshoot this we started by turning on a Payload Trace on the SAP Duet server so we could see the requests coming in from SharePoint and could see the SAML Issuer and NameIdentifier being used.  This information is in the first entry (Request Step:1) in the payload data.  You can click the Original XML button to see it as XML.  Here is an example of what this should look like:

 

Next we looked at the entries in the VUSREXTID table in SAP to verify that we had a mapping for this user. To do this you can run transaction SM30 and enter VUSREXTID as the Table/View name.  In the External ID type dialog that appears enter SA  (for SAML NameIdentifier) and press enter.

We could see the correct entry in our list but we noticed that the case did not match. The VUSERXTID table is case sensitive, so we created the correct entry by using Copy As… to create a copy of the original and change the case to match the value seen in the SAML data in the payload trace. NOTE:  Creating New Entries directly in the VUSREXTID table is not supported because it bypasses some SAP logic that needs to be applied to the entries.  But you can use Copy As… to create entries based off of a working entry. 

With the case fixed, we re-tested but got the same error.

We realized that what had happened was that someone had added the entry to the VUSREXTID table directly without using Copy As… (which is not supported). The current entry and the copy we made from it were both invalid.  So, we removed them and used Copy As… to create a new entry based on an entry that we knew worked. We also could have used the implementation guide (transaction SIMGH) to execute the proper role mapping steps.   The problem was resolved and the account could now be successfully mapped to the SAP user.