3

I have the exact same users in AD and ADFS - when I attempt to import the user profiles from these sources I end up with duplicate users, i want to essentially 'merge' the AD and ADFS users for SP user profiles.

I did try to use mapping via. the email attribute, but it seems as if it did not notice that the email addresses are the same for an AD user and ADFS user and created 2 user profiles in SharePoint.

Is there a way to get the mapping to create just 1 user profile for each user?

  • You have two authentication method in you farm, one with ntlm and other is ADFS, right? – Waqas Sarwar MVP Nov 25 '16 at 14:23
1

I'm not sure I understand this correctly, but from your description I'm guessing you probably implemented ADFS in an existing farm, where users already exist. While doing so you ended up with duplicate users, which is understandable. Claims authentication is different from SAML authentication, and naturally you end up with duplicate users.

Now, and here's the tricky part, when you switch AD from oldAD.local to newAD.local, you typically use Move-SPUser cmdlet. It states "The Move-SPUser cmdlet migrates user access from one domain user account to another. If an entry for the new login name already exists, the entry is marked for deletion to make way for the migration.". So if you have a new SAML-user already present, she will be deleted and replaced by the old AD signature. It means that the new user will hold the present records of the old user.

And using the switch -IgnoreSID makes the so called merge work even if the old AD can't be queried: "Indicates (if present) that Active Directory will not be queried for the SID history attribute to ensure that the new login name is correspondent to the old login name.".

Now, this is between different Active Directories, and not SAML users. So this has to be tested before implemented in production. I havn't tried this case before, and I'm not sure it would work. On the other hand, with the Move-SPUser cmdlet, the new authentication method would be connected to the old users records, which is what we want, and I see no reason it shouldn't work.

So preceed with the following great test case by Jason Warren:

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.