Share via


用于在 SharePoint 2010 中更改帐户身份的 SPMigrateUsers 工具

原文发布于 2012 年 6 月 3 日(星期日)

有时,您会想要或需要在 SharePoint 中更改帐户标识。最好的示例与 SAML 声明有关。事实上,在我的示例中,我将电子邮件地址用作用户的标识声明。我这样做是因为 a) 大多数人都有电子邮件地址;b) 电子邮件地址是大多数用户都了解的。然而,有时我会收到退回的电子邮件,因为人们有时会更改电子邮件地址。当您更改电子邮件地址时,很明显您拥有的所有权限都将终止。说实话,我并不认为这是常见的情况,或者我不会使用电子邮件地址入手。不过,我承认偶尔确实会发生此类情况,因此当您的 SharePoint 都由电子邮件地址保护时您该怎么办?

我之前发布的有关 IMigrateUserCallback 接口的博客文章中描述了控制这种情况的关键所在:https://blogs.msdn.com/b/sharepoint_chs/archive/2011/03/08/windows-saml.aspx。在这篇文章中,我介绍了如何使用此接口进行身份迁移,并举例说明如何将 Windows 声明标识转换为 SAML 声明标识。我决定仅编写一个小型的 Windows 应用程序,该应用程序将允许您输入要更改的凭据,并替您修改。它在实际运用中的目标是用作简单的一次性工具来进行这些更改,但您可以轻松地获取源代码(随本文提供)并对其进行修改以实现更具创意的操作,如从文件或数据库中读取用户列表并自己进行比较。

此工具的另一个优点是它实际可用于多种情景。因此,您不仅可以使用它将一个电子邮件地址转换为另一个地址,还可以将一个组名称转换为另一个组名称。另一种情况就是,有的操作人员告诉我:“嘿,你应该为组名称使用 SID(即 SAML 中的角色声明),因为在重命名组时,SID 仍然保持不变”。虽然这也是真的,但同样 a) 我并没有看到太多这样的情况发生;b) 你们有多少人想要开始键入组 SID 名称并将其添加到 SharePoint 组(如果回答是的话,请立即寻求解决方法);c) 一旦您移到基于云的服务(如 Azure、Google、Yahoo、Facebook 等),SID 在本地 Active Directory 外就毫无意义。您的 SID 将毫无用处,就像[在此填写您自己的“就像……一样没用”笑话]一样。

有关此工具的另一优势在于,它不会限制您只能在单一类型的提供程序内进行更改。希望将 Windows 组更改为 SAML 角色声明?您完全可以那么做。希望将 SAML 标识声明更改为 FBA 成员资格用户?您也可以那么做。希望将 FBA 角色更改为 AD 组?同样没有问题。一切由您决定 – 我只尝试了不同提供程序之间的不同“用户”和“组”的各种组合,到目前为止均能成功来回转换。

令人高兴的是,工具本身非常容易使用;这里有一张图片:

在应用程序首次启动时,它会加载所有 Web 应用程序的列表。对于各 Web 应用程序,它使用在该 Web 应用程序上所用的所有提供程序的列表填充它下面的两个组合框。如果您具有多个 SAML 提供程序或多个 FBA 提供程序,则将在下拉列表中列出各提供程序。您只需选择从中迁移的提供程序以及迁移到的提供程序。在“声明值”(Claim Value) 部分,键入您希望迁移的值,以及将该值迁移到的提供程序。只需在“纯文本值”(Plain Text Value) 编辑字段中键入该值,并单击标识声明按钮(左侧)或组声明按钮(右侧)。文本描述对此提供了完整的说明,并且这些按钮上的文本会根据您所用的身份提供程序发生更改,以显示有意义的信息。

例如,假定您仅使用了 SAML 身份验证并且希望将电子邮件地址“steve@contoso.com”迁移到“stevep@contoso.com”。您应挑选您的 Web 应用程序,并且各下拉列表中已默认选择 SAML 身份验证提供程序。然后在“值前”(Before Values) 部分,您应该在“纯文本值”(Plain Text Value) 编辑框中键入“steve@contoso.com”,并且单击“ID 声明”(ID Claim) 按钮;该按钮将正确的编码声明值放入“编码值”(Encoded Value) 编辑框中。下一步您应在“值后”(After Values) 的“纯文本值”(Plain Text Value) 编辑框中键入“stevep@contoso.com”。再次单击“ID 声明”(ID Claim) 按钮,将正确的值放入“编码值”(Encoded Value) 编辑框中。(注意:在上面的图片中,“值后”(After Values) 部分中的按钮显示“用户”(User),而不是“ID 声明”(ID Claim),这是因为在该示例中,它是从 SAML 声明迁移到 Windows 声明。)在提供了所有值后,只需单击“迁移”(Migrate) 按钮来完成该过程;当迁移完成时将出现消息框通知您。

在通过多种不同的 Web 应用程序和多种不同的身份验证类型测试此工具的过程中,我确实遇到了几个问题,我想在此提出以防您也遇到这几个问题。其中一个问题是当我尝试为一个特定 Web 应用程序迁移用户时,出现了“拒绝访问”错误消息。我一直没有找到出现这种问题的原因,所以我只能说在该 Web 应用程序中某些东西不稳定,但我并不确定那个东西具体是什么,因为我在服务器场中尝试的四五个其他 Web 应用程序上它都运行良好。

其次就是这种情况:迁移已成功完成,但我却无法作为迁移的用户登录。经过更深层地挖掘,我发现从中迁移的帐户不是经过 IMigrateUserCallback 函数推送的(即,出现的是 SharePoint 问题,而不是此应用程序存在编码问题)。如果您遇到这种情况,建议您使用源代码和 Visual Studio 逐步通过调试程序,以确保您从中迁移的帐户得到调用。不幸的是,我有一个 FBA 成员用户陷入这种困境。

最后,需要注意的是 – 如果您将帐户从一个值迁移到另一个,然后作为新用户登录并在页面右上角的欢迎控件中看到旧帐户名称等信息,请不要大惊小怪。迁移功能仅更改帐户名称。如果有其他用户信息发生更改,那么只要您更新用户配置文件,正确的信息就会在下一次与配置文件系统同步时下推到所有网站集。

就是这些了 – 立即使用它并希望它对您有所帮助。正如我在上面所述,我包含了完整的源代码,以便您可以自己进行尝试,并根据您的情况进行修改。

这是一篇本地化的博客文章。请访问 The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010 以查看原文