SharePoint Migrations with User Mapping to Claim-Based Authentication
Check out Best Alternative to InfoPath -> Try Now
Migrating from MOSS 2007 or WSS 3.0 to SharePoint 2010 is easy, provided that the source and destination servers both use the same trusted providers (e.g. NTLM or Classic Provider authentication on the source and claim-based authentication on the destination). Compatible trusted providers on source and destination allow users to be mapped easily from source to destination. However, when the source and destination’s trusted providers or authentication mechanisms differ, user mapping can become more challenging. This article elaborates on some of the complexities that can arise during these kinds of SharePoint migration scenarios.
While SharePoint applies security permissions to user accounts that grants or denies them access to specific content and features, it does not include an authentication mechanism. That’s why the SharePoint 2010 authentication model must be configured before performing migrations of this kind. Depending on governance and internal security policies, there might be multiple permutations that an organization can opt for. For example, claim-based authentication can be configured with Active Directory Federation Services (ADFS), Windows Live authentication, Form-Based Authentication (FBA) or Kerberos as a trusted provider.
In some complex scenarios, organizations previously using mixed-mode authentication in MOSS 2007 where, say, the default zone using NTLM authentication (where users stored in AD) is extended with another zone that uses form-based authentication (where users and groups are stored in SQL). Mapping users and permissions to a SharePoint 2010 destination server that uses form-based authentication and Windows Live providers with claims-based authentication can involve some risks, such as:
Will all users and groups stored in SQL or Active Directory be migrated, and will their respective records be automatically populated in the userinfo table? Will the user information on the source site be migrated as it is?
Will the migrated users have a claims-based authentication prefix prepended to the usernames and groups in the destination userinfo table?
Will these prepended authentication prefixes be technically correct for users and groups in AD as well as for FBA users and groups?
If you’re migrating from MOSS 2007 or WSS 3.0 to SharePoint 2010 with different providers configured on either side, then user mapping can be an area of concern. If you are planning to migrate manually, then besides the risks mentioned above, you might have to write a lot of code to cover the many permutations that could exist in this type of scenario.
You may like following SharePoint migration tutorials:
- Out of box workflows not appearing SharePoint 2013 after migrating from MOSS 2007
- SharePoint 2013 Document library checkboxes missing after migration from Moss 2007 to SharePoint 2013
- Workflow Migration with dSHIFT SharePoint Migrator
- SharePoint Migrations with Column Mapping
- Office 365 SharePoint Easy Migration Part 1
- Office 365 SharePoint Easy Migration Part 2
- SharePoint 2010 to 2013 migration Custom New Folder in Ribbon Disabled
- Site permissions not working after migrating from moss 2007 to SharePoint 2013
- How to work with content type column in a calculated field in SharePoint 2013 after migrating from Moss 2007?
Alternatively, you can opt for a migration tool like the dSHIFT Migrator, which seamlessly migrates all of your out-of-the-box content, users, and groups while retaining security permissions from a different authentication provider, be it mixed-mode, dual authentication trusted providers or claims-based authentication in SharePoint 2010.
SharePoint Online FREE Training
JOIN a FREE SharePoint Video Course (3 Part Video Series)