2

We're using SharePoint 2013 as an intranet portal and want to customize what global navigation links users see based on their AD group membership and I'm having a hard time getting it to work.

I have a user named Joe Somebody and Joe is in an AD group named “DIV Test”. I also created a SharePoint group named “DIV Test” as well and it has the AD group “DIV Test” as a member. If I modify the Audience setting of a navigation link and only give access to the "DIV Test" group (whether I choose the AD group directly under Distribution/Security Groups or the SharePoint group), the user cannot see the link in the navigation bar. However, if I explicitly put Joe Somebody in the audience field or even put that user directly into the SharePoint "DIV Test" group, then it works and the user can see the link in the navigation bar.

But what I'm trying to avoid is managing these users in a SharePoint group. When we onboard employees, they are added to certain AD groups for their department and I want to use leverage those groups to target who can see what URLs. I've given both the SharePoint "DIV Test" group and the AD "DIV Test" group access to a test site my mine and when I check permissions for Joe Somebody, he is inheriting permissions from both of those groups. But this inheritance doesn't seem to be working for the navigation audience targeting. Any suggestions?

  • Have you created an audience in central administration to target the navigation link to this AD group? If not, create an audience with the rule that users must be a member of your AD group. Ensure that the audience is compiled, then use this audience to target the visibility of the navigation link. There's quite a good walkthrough at collaboris.com/blogs/collaboris-blog/chirag-mehta/2013/07/25/… – Andy Dawson Apr 26 '16 at 19:10
  • Thanks for the suggestion Andy. I actually had tried that too with no luck. I just went ahead and dove a little deeper into it and am seeing some odd behavior there as well. I created an audience and only have one rule which checks if the user is apart of a certain AD group and then I compiled the audience. It compiles successfully but only recognizes four users. There are actually 40 users in this particular group. Something interesting that caught my eye is that those four users are all new users that have been created recently. I tested this with another AD group and saw similar results. – Sina Motamedi Apr 26 '16 at 23:59
  • It's worth double-checking the user profile synchronisation output and logs (in miisclient) to see whether you're having issues importing these users. Does each user that's not a part of the audience when compiled have a profile in SharePoint? – Andy Dawson Apr 27 '16 at 14:50
  • So this is interesting. I checked the event logs and when our profile sync service runs, I have a bunch of FIMSynchronizationService errors (event ID 6801) and it says "The user does not exist or is not unique". There are 36 AD accounts that throw this error. The interesting thing is that when I compile audiences, these same accounts are the only ones that actually show up as members. So lets say I have accounts for Bob and Sally and both are in the same "TEST" AD group. Bob's account throws an error during profile sync but shows as a member in the TEST group under audience compilation. – Sina Motamedi Apr 28 '16 at 23:12
4

I ended up contacting Microsoft and was able to get this resolved. We made a few changes so I'm not 100% sure which step fixed it but I have an idea. For starters, it's worth mentioning we used to run 2010 and we upgraded to 2013.

This was the error in the event log (6801): "Exception while trying to migrate account 'CTO\JohnDoe' to 'CONTOSO\JohnDoe'. ---> Microsoft.SharePoint.SPException: The user does not exist or is not unique." CTO being our domain's NetBios name and CONTOSO being our actual domain name. If you recall, I saw this error daily when the profile sync would run and it would only error for 36 accounts. Oddly enough, those 36 accounts were the only ones where SharePoint actually recognized their AD group membership (seems like the reverse of what you'd expect).

So we ran the following commands in SharePoint Management Shell.

Get-SPServiceApplication
$UPA = Get-SPServiceApplication –Id <GUID of User Profile Service Application>
$UPA.NetBIOSDomainNamesEnabled=1
$UPA.Update()

See here for a reference article that goes into more detail on this topic (there's also a TechNet article on it). I think this is the step that actually fixed the problem.

However, we also checked out the sync connection in Central Administration > Application Management > Manage Service Applications > User Profile Service Application > Configure Synchronization Connections. We verified it was querying the correct containers and we made note of the service account that was talking to our Active Directory.

Then, they loaded a script on my machine (see below) which checks the permissions of the service account in your AD to see if it can replicate directory changes. The service account I was using didn't have the proper permissions. So we followed this TechNet article which explains how to delegate control. After doing that, we re-ran the script and it came back saying it had the proper permissions.

Once that was done, we deleted the Sync Connection and recreated it and ran a full sync. I verified that there were no errors in the event log and everything began working from there. I was now able to compile audiences and see the appropriate members. I was able to do audience targeting simply using a security group from AD and it recognized the correct users in each group. Hope this info helps anyone else that might be having similar issues.

Script Instructions: If you have the script at C:\Script.ps1 and you're watching to check permissions for your account named "CTO\Admin", you would run it like this:

PS C:\>.\Script.ps1 CTO\Admin

Failure output looks like this (in red font):

has no a 'Replicating Directory Changes' permission on 'DC=contoso,DC=com'

has no a 'Replicating Directory Changes' permission on 'CN=Configuration,DC=contoso,DC=com'

Successful output looks like this (in green font):

has a 'Replicating Directory Changes' permission on 'DC=contoso,DC=com'

has a 'Replicating Directory Changes' permission on 'CN=Configuration,DC=contoso,DC=com'

param( [string] $userName="")
function Check-ADUserPermission(
    [System.DirectoryServices.DirectoryEntry]$entry, 
    [string]$user, 
    [string]$permission)
{
    $dse = [ADSI]"LDAP://Rootdse"
    $ext = [ADSI]("LDAP://CN=Extended-Rights," + $dse.ConfigurationNamingContext)

$right = $ext.psbase.Children | 
    ? { $_.DisplayName -eq $permission }

if($right -ne $null)
{
    $perms = $entry.psbase.ObjectSecurity.Access |
        ? { $_.IdentityReference -eq $user } |
        ? { $_.ObjectType -eq [GUID]$right.RightsGuid.Value }

    return ($perms -ne $null)
}
else
{
    Write-Warning "Permission '$permission' not found."
    return $false
}
}

# Globals

$replicationPermissionName = "Replicating Directory Changes"

# Main()

$dse = [ADSI]"LDAP://Rootdse"

$entries = @(
[ADSI]("LDAP://" + $dse.defaultNamingContext),
[ADSI]("LDAP://" + $dse.configurationNamingContext));

Write-Host "User '$userName': "
foreach($entry in $entries)
{
$result = Check-ADUserPermission $entry $userName $replicationPermissionName

if($result)
{
    Write-Host "`thas a '$replicationPermissionName' permission on '$($entry.distinguishedName)'" `
        -ForegroundColor Green
}
else
{
    Write-Host "`thas no a '$replicationPermissionName' permission on '$($entry.distinguishedName)'" `
        -ForegroundColor Red
}
}

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.