更多关于 SharePoint 2013 上的高信任应用程序的故障排除提示

  • Article

原文发布于 2012 年 11 月 2 日（星期五）

嘿，我是一个应用程序开发者，我喜欢开发，但说实话，如果我的新 SharePoint 应用程序再出现“令牌的颁发者不是一个受信任的颁发者”问题，而我又不得不跟踪的话，我可能会朝计算机大声怒吼。为了尽量帮助您保持理智，我将列出一个当我遇到这种问题时需要查找的东西的列表。当我找到新的令人兴奋的产生和解决此错误的方法时，我将更新本文并在下面放一个“更新！”的提示。

请务必记住我说“高信任应用程序”的时候，这意味着您没有使用 ACS 作为 SharePoint 应用程序的信任代理，而是在创建 OAuth 令牌并用您自己的证书进行签署。我知道我们在某篇文章中记录了整个过程，所以我不会在这里再次说明。我假设您已阅读过该文章，尝试过该过程，但现在您打算对显示器竖中指。话说回来，以下是我见过的一些发生此错误的方式：

  1. 添加到 SPTrustedRootAuthority 列表 - 当您使用证书签署 OAuth 令牌时，您需要创建 New-SPTrustedRootAuthority。就像 SharePoint 2010 中的 New-SPTrustedIdentityTokenIssuer，您需要将签署了证书的令牌和链中的每个证书添加到 SharePoint 的受信任颁发机构列表中。您可以按照我在以下文章中介绍的过程执行相同的操作：https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx（该链接可能指向英文页面）。只需忽略从 ADFS 中导出证书的相关内容。我假设您已经通过一些其他方式（GoDaddy、VeriSign 等公共根 CA、自签名证书或域颁发的证书）为高信任应用程序创建了证书。
  2. 客户端 ID 全部使用大写字符 - 如我在另一篇文章中所述，如果您正在构建自承载的解决方案，当您在应用程序的 AppManifest.xml 文件或 Web 应用程序的 web.config 中插入客户端 ID 时，请确保不要使用大写字母。有关详细信息，请参阅：https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx（该链接可能指向英文页面）。
  3. 令牌颁发者未配置为信任代理 - 我在另一篇文章里也描述了这个问题：https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx（该链接可能指向英文页面）。文章主旨是确保在创建 New-SPTrustedSecurityTokenIssuer 时包含 -IsTrustBroker 标记。
  4. 更新！： web.config 中缺少 IssuerId 密钥 - 为了在 SharePoint 2013 中使用应用程序的信任代理功能，应用程序在创建要发送到 SharePoint 的 JWT 令牌时必须知道信任代理的 IssuerId。方法是在 web.config 中查找名为 IssuerId 的应用程序属性。该属性在应用程序的 web.config 中与 ClientId、ClientSecret 等在相同位置，就像这样：<add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>。
  5. 更新！： 在 Visual Studio 中使用 Office 工具 RTM Preview - RTM Preview 中实际有一个小错误，该错误在 Preview 2 中已修复。用于将授权令牌发送到 SharePoint 的代码不会在 web.config 中查找 IssuerId 元素，而是发送不同的值。发送的内容以及为什么发送其实并不重要，重要的是，使用该版本工具时解决此问题的方法是始终使用 web.config 中 ClientId 密钥的 SPTrustedSecurityTokenIssuer 的 IssuerId 值。当您获得 Preview 2 后，请立即安装，并将 ClientId 更改为您创建和注册（使用下面介绍的 Register-SPAppPrincipal）的唯一 GUID。不要让所有应用程序都使用同一个 ClientId，因为它标识了签署 OAuth 令牌的应用程序，并且在整个 SharePoint UI 范围中使用。当需要对其进行故障排除或审核时，如果所有应用程序都使用同一个值，这将产生问题。

现在，还有一个相关问题值得注意：假设您“认为”您已经跨过此错误，但尝试在自承载应用程序中从 SharePoint 网站检索内容时，又遇到拒绝访问错误。这可能意味着：

  1. SharePoint 应用程序的 AppManifest.xml 文件中的 ClientId 值与自承载应用程序的 web.config 中的 ClientId 值不匹配。我们正在对 Visual Studio 工具进行改进，未来应该会减少此问题的发生。

现在一个差不多同样好的问题是发生这种情况时如何跟踪相关内容？如果这很简单，我就不会朝着显示器怒吼和竖中指了。以下是我截至到目前找到的发生这种问题时最适合的数据源。同样，如果我找到新内容，我会添加到列表中：

  1. ULS 日志 - 一直以来的最爱，尤其是在假日聚会上，我喜欢打开 ULS 日志欣赏海量的数据。好吧，这是讽刺。但是您确实可以进入管理中心、监视、配置诊断记录。扩展 SharePoint Foundation 类别并选择以下项目：App Auth、应用程序身份验证、身份验证授权和声明身份验证。将记录和跟踪级别设置为“详细”并保存更改，然后尝试再次启动应用程序。获取众多 ULS 日志查看工具之一以查看收到和正在处理的请求。这是收集有关应用程序身份验证问题的提示的好方法。
  2. Fiddler - 也是一个最爱。Fiddler 对于这些情况也非常有用。您最常看到的是 401 未授权错误（就像随时出现的基础问题“令牌的颁发者不是一个受信任的颁发者”）。如果您查看请求中的上一帧，并单击响应帧中的“标题”选项卡，您将看到类似如下的 WWW-Authenticate cookie： Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" 。您能从中得到什么？我看出来我的 ClientId 值应该是 e9134021-0180-4b05-9e7e-0a9e5a524965，我的领域应该是 8a96481b-6c65-4e78-b2ef-a446adb79b59。检查 ClientId 值足够容易，可以查看 AppManifest.xml 文件和自承载应用程序的 web.config。领域错误的可能性微乎其微，但您始终可以运行以下 PowerShell 进行验证：

$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm

这会将您的领域输出到屏幕上。最后，还可以执行一项操作来进行验证：确保为要使用的 ClientId 创建 appPrincipal。下面又列出一些可用于对此进行检查的 PowerShell ，其中使用了上面的 WWW-Authenticate 标题信息：

Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo

如果遇到错误或没有结果，则说明您没有有效的 SPAppPrincipal，您需要使用 PowerShell 创建一个。为完整性起见，以下是一个实现该操作的示例：

$clientId = "some guid you create"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "My Cool App"

好了，今天的高信任应用程序故障排除提示列表到此结束。如果有更多消息，我将更新本文。

 

 

 

 

这是一篇本地化的博客文章。请访问 More TroubleShooting Tips for High Trust Apps on SharePoint 2013 以查看原文