Hi Trevor,

I have two domains, subdomain.domainA.com and subdomain.domainB.com that have a two way trust between them. TechNet article http://technet.microsoft.com/en-us/library/gg602068.aspx states:

Using People Picker with multiple forests or domains

By default, People Picker will only return users, groups, and claims from the domain on which SharePoint 2013 is installed. If you want People Picker to return query results from more than one forest or domain, you must either have a two-way trust between the forests or domains, or you must configure People Picker to use an encrypted account and password for a one-way trust between forests and domains.

However, when we upgraded from SP2010 to SP2013 the people picker is only picking up one of the domains, despite our two-way trust. 

Any ideas why this might be so?

Thanks,

Kathryn

Is this a Selective Trust?

Not sure, will check with domain admins. . .

Also validate that the new servers have appropriate port access to all of the Domain Controllers in the specified domain.

Hi Trevor,

The domain admin confirms that it is a full two-way trust that is not selective. I'm going to confirm that all the ports are open. I saw in a Bill Baer post from 2009 that said the following ports need to be open for People Picker. However, do the Kerberos ports have to be open in SharePoint 2013 with a default claims web application that is using NTLM authentication? Thanks, Kathryn

TCP/UDP 135, 137, 138, 139 (RPC) 
TCP/UDP 389 by default, customizable (LDAP) 
TCP 636 by default, customizable (LDAP SSL) 
TCP 3268 (LDAP GC) 
TCP 3269 (LDAP GC SSL) 
TCP/UDP 53 (DNS) 
TCP/UDP 88 (Kerberos) 
TCP/UDP 445 (Directory Services) 
TCP/UDP 749 (Kerberos-Adm) [Opt.] 
TCP port 750 (Kerberos-IV) [Opt.]

Kerberos can be used despite an IIS site not being configured to use Kerberos.  Remember this is Server to Server communication.

You can also try http://peoplepicker.codeplex.com from the SharePoint s

Hi Trevor,

I recreated the web application just in case there was anything wrong with it and ran the PeoplePicker Port Tester. It returned all of the records in the Domain B OU I specified and all ports connected except the following failed:

tcp/137

tcp/138

tcp/749

tcp/750

It also found 7 servers in the "DNS Test" column.

Next I checked to make sure the profiles from the Domain B were being returned. If I type in "kathryn birstein" in the "FInd Profiles" box in "Manage User Profiles", both the profile for the ID in Domain A, DomainA\kathryn.birstein, and the profile for the ID in Domain B, DomainB\kbirstein, come up. 

However when I search in People Picker I only get the DomainA ID. The SharePoint server FQDN name is spservername.subdomain.domainA.com and DomainB is in a different forest with the user names being in subdomain.DomainB.com but this should not make a difference if there is a Full Trust between them. Any other ideas of why People Picker refuses to find user in DomainB??  --Kathryn 

If there is a Forest Transitive Trust (this is where subdomains will trust subdomains from other forests by way of the forest trust), no there should not be an issue.  In addition, SharePoint needs the port access to DCs in that domain.

If you do a People Picker search for a user that only exists in subdomain.DomainB.com, can you watch the ULS trace from the WFE you're interacting with?  That may help lead to a possible solution as well.

Hi Trevor,

I've absolutely confirmed that this is a two-way Forest Transitive Trust and that all DCs can be accessed. If I try to add the exact DOMAIN\acctid into the SharePoint 2013 web application, it says "We can't find an exact match". In the ULS log it says:

"Unable to get domain DNS or forest DNS for domain domainname. ErrorCode=1355

Error in resolving user 'Domainname\kbirstein' : System.ArgumentException: Specified value is not supported for the domainName parameter.     at Microsoft.SharePoint.Utilities.SPUserUtility.GetDomainControllerToSearch(SPWebApplication webApp, String domainName)     at Microsoft.SharePoint.Utilities.SPActiveDirectoryPrincipalBySIDResolver.ResolvePrincipal(String input, Boolean inputIsEmailOnly, SPPrincipalType scopes, SPPrincipalSource sources, SPUserCollection usersContainer)     at Microsoft.SharePoint.Utilities.SPUtility.ResolveWindowsPrincipal(SPWeb web, SPWebApplication webApp, String input, SPPrincipalType scopes, Boolean inputIsEmailOnly)."

Any idea what these errors mean??

Thanks,

Kathryn

Looks like WINS is not enabled in the domain SharePoint is part of.  I ran into this issue, as well.

http://support.microsoft.com/kb/2874332

Hi Trevor,

We finally figured it out! Turns out that the forest we could not search had the subdomain as the ROOT domain, that is, domainB.com does not really exist, its subdomain.domainB.com.

So we did the stsadm command:

stsadm -o getproperty -pn peoplepicker-searchadforests -pv forest:subdomain.domainB.com;forest:domainA.com -url http://webappname

and it WORKED! Now I can add users from DomainB and DomainA and choose them in the People Picker. What's really WEIRD is that we do NOT have to give this command in SharePoint 2010 (on Windows Server 2008R2) to make it work. The SharePoint 2013 farm is on Windows Server 2012. Don't know if this made the difference.

Anyway, thanks for all your help!

Kathryn

Hi Trevor, 

Does Wins is required in SharePoint environment? as we have same issue with two-way domains

THanks