NTLM and ADFS claim treated as different user

Question

Dear All:
Currently our SharePoint is using mix authentication mode (claim mode with two authentcation providers)：
Windows-NTLM & ADFS2.0
The ADFS'a identity store is same as SharePoint's domain, it means we have only a single AD, NTLM authentication provider is used for users who are in office, ADFS authentication provider is used when they are at home. (The same credential)
When users opens SharePoint, it prompts a page to let user to select which authentication provider they want to use (NTLM or ADFS).
The question is when the same user login by using NTLM or ADFS, the user will be treated as a different user
For example:
UserA login by using NTLM, his identity claim looks like: Domain\UserA
UserA login by using ADFS, his identity claim looks like:  i:05.t|saml provider|[email protected]
The profile and permissions of this user will be different
Is there a way to treat the user as the same user no matter login by ADFS or NTLM ?
I know if we remove the NTLM authentication provider, only use ADFS can solve this problem, but the client don't want to do this, because：
 The SharePoint is upgraded from 2007 (Classic mode) and it has a huge number of existing users, resources, permissions.
After upgraded to the claim mode, SharePoint automatically used the NTLM authentication provider.
If we removed the NTLM authentication provider, the client has to reset all permissions in SharePoint again, for example:
A ListItem's Permission:
1. In SharePoint 2007 Classic Mode:
Domain\UserA -- Full Control
2. After upgraded to SharePoint 2010 and upgraded to Claim Mode, the client didn't need to reset the permission：
Domain\UserA -- Full Control
3. If we remove the NTLM authentication provider, the client have to reset the permission：
i:05.t|saml provider|[email protected] -- Full Control
Any ideas would help,
Thanks a lot!

Answer 1

SharePoint sees the Windows and Claims identities as different, even though they are the are the same user in the same directory store.
I'm troubled by the SAML token though, if it was a claims windows token (i:0.w) I would say you could use Move-SPUser to consolidate them. I've done this
before when during configuration of a farm a user can appear with duplicate entries in the site, one for windows auth (DOMAIN\user) and one for claims (i:0.w#domain\user).
Move-SPUser can merge the SPUser objects together (this was one of the purposes of it's predecesor, the migrateuser stsadm operation). If it was a windows token it works, but because of the ADFS provider it could be strange.
Here's how I would test it out:
Create a new test user (no sense in messing up a real user)
Log test user in to the site with NTLM
Log out test user
Log test user in to the site with ADFS
Log out test user
With an admin account, verify using the method you previously used to determine duplicates that there are indeed two users for this test account (one windows, one SAML). 
Move-SPUser (details below)
Verify there is now one user for the test user
Log test user on to the site with NTLM
Log out test user
Log test user on to the site with SAML
Log out
With an admin account, verify again to make sure there is still only one account
For Move-SPUser and windows claims I would usually recommend merging the windows account into the claims. Without knowing what will happen I'd say let's try the same here (merge the windows account into the SAML claim):
$testUser = Get-SPUser -Web "http://sitecollection/or/site" -Identity "DOMAIN\testuser"
Move-SPUser -Identity $testUser -NewAlias "i:05.t|saml provider|[email protected]" -IgnoreSID
Jason Warren
Infrastructure Architect
Habanero Consulting Group
habaneroconsulting.com/blog