locked
Unable to select AD security groups from peoplepicker RRS feed

  • Question

  • Dear all,

    We've been banging our heads against the wall for quite some time now because of the following problem that we have:

    We are using MOSS 2007 with one frontend and one application server which both make use of a SQL cluster. In addition we have a single server test environment which makes use of the same SQL cluster. Both versions of SharePoint are the same (SP2).

    What we try to accomplish is that we can select AD security groups within several SharePoint sites. For this we have set up a custom import connection with the following settings:

    • Specify a domain controller (selected one from the list);
    • Port: 389
    • Time out: 120
    • Checked - Enable Server Side Incremental  
    • Search base: DC=domain,DC=com
    • User filter: (&(objectCategory=person)(objectClass=user)( !(userAccountControl:1.2.840.113556.1.4.803:=2))(|(!sAMAccountName=acc*)(sAMAccountName=accPerson1)(sAMAccountName=accPerson2))) 
    • Scope: subtree
    • Page size: 10
    • Page time out: 120 
    • Use Default Account

    Afterwards we did a full import with a resultset of 2,974 profiles and 0 errors.

    When I go to a SharePoint site on the test environment and I will look up a security group using the peoplepicker it will show me the correct group. But when I do the same on the production environment it doesn't show anything. Both environments are configured identical.

    Could someone please help us out.

    Kind Regards,

    Kevin 

    Tuesday, June 7, 2011 7:30 AM

Answers

  •  

    Hi,

     

    Did you run the full import in the production environment? If not, please run the full import in the production environment, then check the effect.

     

    What is the exact error? How many domains do you have? If you have more than one, do they have trust relationships between them?

     

    Can you add individual user?

     

    When you  go add a user /Group & say Check name or Browse, the following steps will be done.

     

    1.       Site administrator or other users submit a query to the people-picker web control.

    2.       The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service. Make sure the WFE can find the GC.

    3.       Once located it tries to connect to it . This first connection, which is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE” .  Make sure the WFE can connect to the GC.

    4.       If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service or a specified domain user . Check the application pool account has enough permission on the AD.

    5.       The WFE sends an LDAP Global Catalog Search Request to the DC.

     

    You can use Wireshark to capture the network trace to narrow down this issue.

     

    For more information about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ), please look into the following two articles:

     

    All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-1

    http://blogs.msdn.com/rajank/archive/2009/09/01/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-1.aspx

     

    All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2

    http://blogs.msdn.com/rajank/archive/2009/09/20/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-2.aspx

     

    Thanks,

    Rock Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

     


    Regards, Rock Wang Microsoft Online Community Support
    Wednesday, June 8, 2011 7:16 AM
  • Conceptually the port requirements become clear, 1) we know we are executing an LDAP query against a directory source impersonating an account with access to that source, binding to the users container and a SearchResultCollection object to hold a collection of SearchResults returned by the FindAll method (see example later in this article) and 2) we require name resolution to resolve a directory server at the destination. Specifically when you enter a name or partial name in the user interface the Windows API will return a SID for that account, once the SID has been acquired, the People Picker attempts to retrieve additional information about that user from the Active Directory. Quite clearly under these conditions we will require either port 389 LDAP or port 636 sLDAP, or where a Domain Controller is granted the Global Catalog role, 3268 and 3269, and in both cases 53 DNS, 445 Directory Services in addition to authentication protocols, Kerberos, Kerberos-Adm, and Kerberos-IV. A complete list of ports and protocols required to successfully instantiate and execute a People Picker request are as follows :

    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.]

     

    Tuesday, June 14, 2011 7:11 AM

All replies

  •  

    Hi,

     

    Did you run the full import in the production environment? If not, please run the full import in the production environment, then check the effect.

     

    What is the exact error? How many domains do you have? If you have more than one, do they have trust relationships between them?

     

    Can you add individual user?

     

    When you  go add a user /Group & say Check name or Browse, the following steps will be done.

     

    1.       Site administrator or other users submit a query to the people-picker web control.

    2.       The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service. Make sure the WFE can find the GC.

    3.       Once located it tries to connect to it . This first connection, which is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE” .  Make sure the WFE can connect to the GC.

    4.       If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service or a specified domain user . Check the application pool account has enough permission on the AD.

    5.       The WFE sends an LDAP Global Catalog Search Request to the DC.

     

    You can use Wireshark to capture the network trace to narrow down this issue.

     

    For more information about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ), please look into the following two articles:

     

    All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-1

    http://blogs.msdn.com/rajank/archive/2009/09/01/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-1.aspx

     

    All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2

    http://blogs.msdn.com/rajank/archive/2009/09/20/all-you-want-to-know-about-people-picker-in-sharepoint-functionality-configuration-troubleshooting-part-2.aspx

     

    Thanks,

    Rock Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

     


    Regards, Rock Wang Microsoft Online Community Support
    Wednesday, June 8, 2011 7:16 AM
  • Hi,

     

    I just want to say hi to know if our suggestion is helpful to you, if you have any questions, feel free to reply to the forum.

     

    Thanks,

    Rock Wang

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    Regards, Rock Wang Microsoft Online Community Support
    Tuesday, June 14, 2011 3:21 AM
  • Hi Rock Wang,

    I'm sorry that I've have not yet replied to your answer. Thanks for answering so quick btw.

    We did run the full import on the production environment and there is a total import difference of 1 profile.

    We have three domains in total and there is a trust between them. I am able to add an individual user from one of these domains.

    I didn't try out wireshark yet, but do you know which ports on the firewall have to be configured in order to make use of the peoplepicker? Because we think it is a firewall issue as our test environment is able to crawl the AD groups.

    Thanks,

    Kevin.

    Tuesday, June 14, 2011 5:40 AM
  • Conceptually the port requirements become clear, 1) we know we are executing an LDAP query against a directory source impersonating an account with access to that source, binding to the users container and a SearchResultCollection object to hold a collection of SearchResults returned by the FindAll method (see example later in this article) and 2) we require name resolution to resolve a directory server at the destination. Specifically when you enter a name or partial name in the user interface the Windows API will return a SID for that account, once the SID has been acquired, the People Picker attempts to retrieve additional information about that user from the Active Directory. Quite clearly under these conditions we will require either port 389 LDAP or port 636 sLDAP, or where a Domain Controller is granted the Global Catalog role, 3268 and 3269, and in both cases 53 DNS, 445 Directory Services in addition to authentication protocols, Kerberos, Kerberos-Adm, and Kerberos-IV. A complete list of ports and protocols required to successfully instantiate and execute a People Picker request are as follows :

    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.]

     

    Tuesday, June 14, 2011 7:11 AM