none
People Picker in Two-Way Trust

    Question

  • 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


    Kathryn Birstein, Senior SharePoint Architect

    Sunday, October 06, 2013 7:34 PM

Answers

  • 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


    Kathryn Birstein, Senior SharePoint Architect

    Tuesday, October 15, 2013 1:38 AM

All replies

  • Is this a Selective Trust?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, October 06, 2013 7:53 PM
    Moderator
  • Not sure, will check with domain admins. . .

    Kathryn Birstein, Senior SharePoint Architect

    Sunday, October 06, 2013 8:41 PM
  • Also validate that the new servers have appropriate port access to all of the Domain Controllers in the specified domain.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, October 06, 2013 10:24 PM
    Moderator
  • 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.]


    Kathryn Birstein, Senior SharePoint Architect

    Monday, October 07, 2013 6:40 PM
  • 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 server.


    Trevor Seward, MCC

      

    Follow or contact me at...


    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.


    Monday, October 07, 2013 6:41 PM
    Moderator
  • 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 


    Kathryn Birstein, Senior SharePoint Architect

    Wednesday, October 09, 2013 1:53 AM
  • 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.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, October 09, 2013 4:09 AM
    Moderator
  • 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


    Kathryn Birstein, Senior SharePoint Architect

    Monday, October 14, 2013 10:04 PM
  • 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


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, October 14, 2013 11:02 PM
    Moderator
  • 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


    Kathryn Birstein, Senior SharePoint Architect

    Tuesday, October 15, 2013 1:38 AM