0

I have a user that I want to grant access to a site in a given site collection.

When I search for that person in the people picker I can find her in the address book and then click to add her to the permissions dialog but when the permissions dialog populates it shows somebody with a different Account Name.

The Account Names are similar and are just different by the number at the end of their account name. In Active Directory these accounts are two distinct people.

I have noticed that if I try to grant the same person access to a site in a different site collection then everything works out fine and the name does not get switched when granting access.

I have confirmed that this Site Collection is not set for read only. Also I found the user in one of our content databases and the IsActive flag was set to true for her account.

Our User Profile sync is set to run incrementally every night and then fully once a week. This persons account has been around long enough that it should have already been through both of those sync jobs.

What could be the cause of this problem?

Improve this question

2 Answers 2

Reset to default
0

Try running:

$user = Get-SPUser -Identity "i:0#.w|domain\username" -Web http://webUrl
Move-SPUser -Identity $user -NewAlias "domain\username" -IgnoreSid

Make sure the -Web parameter specifies a location where this user resides (e.g. a working Site Collection). Also make sure you're using the same "domain\username" for both the Get and Move-SPUser. Lastly, make sure to run this as a Farm Admin account or an account with explicit rights on the UPSA.

What this will do is make sure that user's SID matches what is expected from Active Directory.

Improve this answer
5
  • I ran these commands but it did not resolve my issue. Can you tell me what these commands should do in a little more detail. Now when I try to run Get-SPUser on the identity I get an error stating that I must specify a valid user object. Is that script correct? This user account no longer shows up in the site collection which I called out in the Get-SPUser command which it did before. I still have other Site Collections where this user account is available.
    – BrianWaMc
    Commented Nov 9, 2015 at 16:37
  • What that effectively does is migrate the user from one user to another. But you can also 'migrate' from the same user to the same user. This will update the user's SID from Active Directory in both the UPA as well as all Site Collections across the farm. You did specify the same user account in the -NewAlias switch, correct?
    – user6024
    Commented Nov 10, 2015 at 16:30
  • Yes I did. I guess I can restate what you wrote so that you can make sure I understand the steps you spelled out.... the domain and username text in both places above should be replaced with the user I am trying to get to work's domain and user name. And in your command webUrl should be replaced with the full url to the site collection where I can add this user through the people picker. I used the ssl url which would be the only modification that I introduced.
    – BrianWaMc
    Commented Nov 10, 2015 at 18:42
  • So when I remove the piped part before the user name then my record comes up fine in all site collections. With the piped part it is failing on even my name. When I search for my broken user, say johndoe1, in Site Collections that they get replaced in the people picker with johndoe2 then johndoe2 comes back from Get-SPUser. When I search for the person with the broken account, johndoe1, without the piped part in a Site Collection that the people picker seems to work with I get the error stating ' You must specify a valid user object or user identity.' from Get-SPUser.
    – BrianWaMc
    Commented Nov 10, 2015 at 19:23
  • My SharePoint Web Application is SP 2010 and using Classic Authentication instead of Claims Based Authentication. I think this explains why adding "i:0#.w|" to the beginning of my Identity parameter was failing for Get-SPUser. So I guess I left that part out of your script when I ran it without error. Sorry for the confusion.
    – BrianWaMc
    Commented Nov 12, 2015 at 18:29
0

This problem was resolved by editing the users SharePoint record in the FIM Client on my backend server where the FIM Synchronization Service was running.

So in specific, we opened up the Metaverse Search in the FIM Client to search for the User Profile that was broken. I then went to the Connectors tab for this person's record. The CN for this person was pointing to somebody else in the SharePoint version of the connection in their record. This did not match up with the CN in the AD version of the connection.

I disconnected the SharePoint Version in the Connectors tab and re-synced the account in the FIM Client which came back as the correct CN record.

It took some time for this change to propagate to the Site Collections but now in all of the Site Collections I am able to select this user who previously had a broken record.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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