SharePoint People Picker Ports
Some of the documentation that I have relied on for years discussing network ports required for SharePoint People Picker has been archived due to age. However, because the underlying functionality of People Picker hasn’t really changed much, the port requirements haven’t either. Here’s the list that applies to all versions of SharePoint Server:
Protocol |
Ports |
Description |
TCP & UDP |
135, 137, 138, 139 |
RPC |
TCP & UDP |
389 |
LDAP |
TCP |
636 |
LDAP SSL |
TCP |
3268 |
LDAP Global Catalog |
TCP |
3269 |
LDAP Global Catalog SSL |
TCP & UDP |
53 |
DNS |
TCP & UDP |
88 |
Kerberos |
TCP & UDP |
445 |
Directory Services |
Tips:
- Where it says “TCP and UDP”, it means ports for both protocols must be available.
- These requirements apply to every domain or forest you have configured the web application to search.
- Depending on how you have configured Active Directory Sites and Subnets and your DNS, you may have to open these ports between your SharePoint servers and all of your domain controllers.
- All of your SharePoint servers need to be able to access the domain controllers, not just your web-front-ends. Application servers do user lookups too.
- You can test TCP port connectivity with PowerShell. More on that below.
Test Port Availability:
You can use the PortQry or PortQryUI tools, or even a PowerShell script to test port availability. For TCP ports you can do it with a simple one-liner:
new-object system.net.sockets.tcpclient(“server.domain.com”, portnumber)
Example: new-object system.net.sockets.tcpclient(“DC.contoso.local”, 389)
Open port 389:
Closed Port 1989:
Behind People Picker setting misconfiguration, port availability / firewall configuration is one of the leading causes of a “slow” people picker and the dreaded “Sorry, we’re having trouble reaching the server” error message. See my Troubleshooting People Picker Performance post for more info.
And here’s a related post about RPC port problems when resolving users from trusted forests.