SharePoint: Shared Mailboxes, disabled accounts, and People Picker

Posted On March 26, 2021

Important: This is not something that is supposed to work. You’ll see that we can get it to work in certain scenarios, but it is not an intended design of SharePoint. At any time, a code change could be made that breaks our workarounds and leaves little recourse other than enabling the accounts in Active Directory.

Now that we got that out of the way, consider the following scenario:

  • You have a SharePoint 2016 or 2019 site.
  • You have Shared Mailboxes created in Exchange.
  • The backing Active Directory accounts for these Shared Mailboxes are disabled in Active Directory.
  • You try to use People Picker to find these Shared Mailbox accounts and add them to a list column, but People Picker will not find the account.
  • If you enter the account name in domain\userName format and click OK without first resolving the account, it will appear to add it.
  • If you try to add the account to a SharePoint group, or at the site permissions level, People Picker may find it, but will fail to add it with the following error:

“The user does not exist or is not unique”

Cause:

The problem here is that the Shared Mailbox is implemented as a user account in Active Directory, and that account is disabled.

By default, and for obvious reasons, People Picker will not resolve disabled accounts.

The only reason it ‘sort of’ works is due to an unintended side effect of the PeoplePickerSearchInMultipleForests property, which I detailed in an blog post a while back. – Basically, because these Shared Mailbox accounts have a value populated for msExchMasterAccountSid, SharePoint will find them, even though they are disabled. By default, these Shared Mailboxes have msExchMasterAccountSid set to S-1-5-10 (which resolves as “NT Authority\self”) – That’s why People Picker finds them, but also why it tries to add them to the site as a group claim and fails with the above error.

Solution:

Enable these Shared Mailbox accounts in Active Directory.

— I understand that this may result in additional costs in a hosted Exchange scenario, or there may be other valid reasons for not wanting to enable the accounts, which leads us to our “workarounds”…

Workarounds

Option 1:

  • We can change PeoplePickerSearchReplicatedMasterSIDPropertyName from msexchmasteraccountsid to objectsid.
    • In that case, the account is resolved by ObjectSID, which properly resolves the account as a user object.
    • The problem with this is that People Picker will now find and resolve any and every disabled account in Active Directory, not just these Shared Mailbox accounts.
    • To work around that problem, you can try to limit the scope of people picker to avoid the “regular” disabled accounts. For example, if all of your “regular” disabled user accounts (the ones we do not want People Picker to find) are stored in a certain Active Directory container (OU), you could deny access to that OU. This is also a bit of a “hack” and not entirely recommended, but here it is:
      • In Active Directory Users and Computers, find the OU that contains the “regular” disabled users, choose properties, and select the Security tab.
      • Add the service account that is running the application pool for the SharePoint web application.
      • In the Permissions box, choose Deny on the Full Control permission, and click ok.
      • That’s it.  You should still be able to find the Shared Mailbox accounts, but not any of the “regular” disabled user accounts within the denied OU. — Please keep in mind that this solution only really works well in the case where all of your “regular” disabled user accounts are in specific OUs.  If there are also enabled user accounts in those same OUs, People Picker will not be able to find them.

You can make this change by running PowerShell like this on any SharePoint server in the farm:

$wa = Get-SPWebApplication https://yourWebAppHere
$ws = $wa.WebService
if($ws.PeoplePickerSearchInMultipleForests)
{Write-host -ForegroundColor Red "Your People Picker settings are in 2010 mode.  For this to work properly, PeoplePickerSearchInMultipleForests should be False"}
else {Write-host "Changing to ObjectSid..."
$ws.PeoplePickerSearchReplicatedMasterSIDPropertyName = "objectsid"
$ws.update() }

To revert to the default configuration, you can use this PowerShell:

$wa = Get-SPWebApplication https://yourWebAppHere
$ws = $wa.WebService
$ws.PeoplePickerSearchReplicatedMasterSIDPropertyName = "msexchmasteraccountsid"
$ws.update()

Option 2:

  • You could leave PeoplePickerSearchReplicatedMasterSIDPropertyName set to MSExchMasterAccountSID, but then update the MSExchMasterAccountSID value in Active Directory for only the Shared Mailbox accounts to match their value for ObjectSid.
    • The main problem with this approach is I have no idea if Exchange needs the MSExchMasterAccountSID value to be S-1-5-10 (nt authority\self) on Shared Mailbox accounts for some reason, so I couldn’t tell you what (if any) impact this may have on Exchange and mail flow to the mailbox – you’d have to test that.
    • And it’s a manual change to each account, which could be done easily enough in-bulk with a PowerShell script, but would also have to be done manually for any new Shared Mailbox account that is created.

At any rate, here’s the PowerShell to do it:

$username = "theAccountNameHere"
$user = Get-ADUser $username -properties msexchmasteraccountsid, objectsid
$sid = $user.objectsid
Set-ADUser $user -replace @{msExchMasterAccountSid = $sid.value}

Option 3:

  • This last one I didn’t actually test, but in theory, another option would be to point PeoplePickerSearchReplicatedMasterSIDPropertyName at a different AD attribute entirely so as to not resolve all disabled accounts and also not interfere with Exchange.  — I believe pretty much any attribute in the AD schema with a Syntax of “SID” could work as long as:
    • The attribute is set to be indexed and replicated to the Global Catalog.
    • The attribute is not being used for anything else.
    • Note: You’d still need to manually update each Shared Mailbox account by copying the ObjectSid value for that account into the new AD attribute you choose.

Related Tips:

If you are getting inconsistent People Picker results, please keep in mind that previous entries that were resolved successfully are stored within browser cache, and you may need to clear that out.

Add a Comment