SharePoint Navigation Audience Targeting Not Working With AD Group

Question

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?

Answer 1

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
}
}