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|userA@domain.com

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|userA@domain.com -- Full Control

  

--------------------------------------

Any ideas would help,

Thanks a lot!

• Edited by Vincent 2013 Friday, August 24, 2012 6:59 AM change some line

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:

1. Create a new test user (no sense in messing up a real user)
2. Log test user in to the site with NTLM
3. Log out test user
4. Log test user in to the site with ADFS
5. Log out test user
6. 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). 
7. Move-SPUser (details below)
8. Verify there is now one user for the test user
9. Log test user on to the site with NTLM
10. Log out test user
11. Log test user on to the site with SAML
12. Log out
13. 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|testuser@domain.com" -IgnoreSID

Dear Jason:

Thanks for your great help!, I 'll try this and give the feedback, thanks

Dear Jason:

I have tried your solution, it works.

After executed the Move-SPUser command, the following happens:

 

1. All of the existing permission assignments of <i:05.t|saml provider|userA@domain.com> will lost.

2. The permission assignments of <Domain\UserA> will transfer to <i:05.t|saml provider|userA@domain.com>.

Eg:

Before:  Domain\UserA -- Full Control

After: i:05.t|saml provider|userA@domain.com -- Full Control

3. The attributes of <Domain\UserA>'s user profile will override the attributes of <i:05.t|saml provider|userA@domain.com>'s user profile.

 

I haven't tried other parts yet, any supplements would appreciate, thanks!

  

Thanks for your great help!

Awesome! Thanks for testing that out, now I know the answer too! :D

Thanks Guys, a very insightful manoeuvre indeed.  That's going straight into the kit bag forever!

anyone had experience with migrating groups?

I am migrating from Windows claim to SAML claims (ADFS) and I am unsure what claim type to use for group

I have used i:05.t| for user (which is the email claim) but I have no idea what to use for groups

My understanding is that you use the group ID with Move-spuser

- eg this DOMAIN USERS on Windows Claims c:0+.w|s-1-5-21-4141157335-984627893-128140258-513

What suffix to use for migrating the groups?