Showing posts with label Protocol. Show all posts
Showing posts with label Protocol. Show all posts

Friday, September 23, 2011

SharePoint People Picker and Active Directory

Introduction:
SharePoint People Picker enables end users to enter either username or part of the username/display name and have the input resolved against a source that is holding user information (mostly active directory, but we can also use other directory sources).
Following is the screenshot of how a people picker page looks in SharePoint 2010.


Note: The following part of the article considers that SharePoint Picker People is using classic (Windows Integrated Authentication). When SharePoint People Picker uses classic authentication method, we can use stsadm setproperty commands. If the web application is using Claims based authentication, then stsadm setproperty commands would not cause any effect on the configuration.

How people picker works:
Following is the sequence of activities that occur when you try to search for a user in people picker
  • User submits a query in people picker
  • The query is sent to one of the Web Front End (WFE) servers. The server which is handling the request performs a lookup in DNS for the domain controller server holding the Global Catalog Service.
  • DNS returns the I.P. address of the domain controller holding GC. SharePoint will use any random port on it’s server and connect to the Domain controller server on port 3268. Port 3268 is the LDAP over TCP port used by Global Catalog service.
  • SharePoint will initially ask for some information from DC which will let SharePoint know the authentication mechanism that is supported, LDAP capabilities, end points, etc.
  • If the Active Directory requests for authentication, SharePoint will use the web application’s application pool account to send a LDAP query.
  • SharePoint will now send a LDAP query (for the username which the user requested) to the DC server. The query is created using “System.DirectoryServices” namespace. If the server is a standalone installation and the application pool is running under Local system or Network Service, then DOMAIN\MACHINE_NAME will be used for authentication. Once username is found in the directory, Windows APIs will return the SID of the user. Using the SID, further information about the user is retrieved from the Active Directory.
  • DC sends the response back to the SharePoint server.  System.DirectoryServices uses “DirectorySearcher” object to formulate the search response. A “SearchResultContainer” object is sent containing “SearchResults” which were returned by the “FindAll” method.
    Refer: http://msdn.microsoft.com/en-us/library/ms180881(VS.90).aspx
  • The information is parsed and displayed in People Picker.

We know now that SharePoint initially queries DNS and then communicates with the Domain Controller holding GC to get the details of the user. For the communication to happen successfully, we need to ensure that the following ports are open between SharePoint and Domain controller (holding GC).

On SharePoint Server:
  • TCP/UDP 135, 137, 138, 139 (RPC)
  • TCP/UDP 389 (LDAP default port)
  • TCP 636 (LDAP SSL default port)
  • TCP/UDP 53 (DNS) 
  • TCP/UDP 88 (Kerberos)
  • UDP 464 (Kerberos Change Password)

On Domain Controller:
  • TCP/UDP 135 (RPC)
  • TCP/UDP 389  (LDAP default port)
  • TCP 636 (LDAP SSL default port)
  • TCP 3268 (LDAP Global Catalog)
  • TCP 3269 (LDAP SSL Global Catalog)
  • TCP/UDP 88 (Kerberos)
  • TCP/UDP 53 (DNS)
  • TCP/UDP 445 (Directory Services)

Following ports are optional
  • TCP/UDP 749 (Kerberos-Adm)
  • TCP port 750 (Kerberos-IV)

If people picker is pulling up users from another domain, then to support the communication between domains inside the corporate network requires at least a one-way trust relationship in which the perimeter network trusts the corporate network.
On the other domain controller (or if the communication occurs through ISA), the following ports are required to be kept open for inbound connections in the DC/ISA server.
  • TCP/UDP 135 (RPC)
  • TCP/UDP 389 (LDAP default port)
  • TCP 636 (LDAP SSL default port)
  • TCP 3268 (LDAP Global Catalog)
  • TCP 3269 (LDAP SSL Global Catalog)
  • TCP/UDP 53 (DNS)
  • TCP/UDP 88 (Kerberos)
  • TCP/UDP 445 (Directory Services)

    Optional Ports:
  • TCP/UDP 749 (Kerberos-Adm)
  • TCP port 750 (Kerberos-IV)
In case of any queries, please feel free to drop a comment and I will respond back.


Friday, September 16, 2011

Visio Graphic Service Protocol

Visio Graphic Service Protocol is used to retrieve information about a Web Drawing (which is usually stored in a .vdw format) in a SharePoint document library. SharePoint as an application uses this protocol to retrieve data and display the graphic on the site. When we open a Visio diagram in SharePoint site, the Visio protocol client calls the server for information. The information is either returned in raster or vector format. Raster file data is returned as .png (portal network graphic) format while a vector data is returned as XAML.

Visio Graphic Services uses SOAP (Simple Object Access Protocol) for formatting request and response received from the server. The information is transmitted using TCP IP protocol (either through HTTP or HTTPS, depending on the way you have configured Visio Service Application). Following Diagram shows the messaging and transport stack used by the service.



Following are the pre-requisites for the service protocol to work properly:
  • Service endpoint. 
  • Appropriate permissions to call the method from VisioGraphicService.svc 
  • Token based security mechanism
SharePoint acts as the client requesting the information. Visio Service is hosted in a website known as “SharePoint Web Services”. The sub directory name is usually a GUID. Search through the contents of the site and you will find that VisioGraphicService.svc is hosted in one of the directories of the web application.


Open IIS Manager and check the Content view of the “SharePoint Web Services” web application. You should see a similar picture as above. The GUID might differ though.

VisioGraphicService.svc acts a a service endpoint and is needed to communicate and transfer data across. SharePoint Web Services web application uses TCP port 32843 (HTTP) and TCP port 32844 (HTTPS) for communication. Usually a default configuration of SharePoint uses HTTP port for communication unless you specific any other setting from Central Administration site.

Ensure we have these port(s) open. In case firewall is blocking the ports or you are facing any network issue, Visio diagrams may fail to refresh or may not render at all. Just in case, I am documenting some sample error messages I received because TCP 32843 port was blocked.

w3wp.exe Visio Graphics Service Web Access 8046 Critical Failed to get Vector Diagram for visio file (null) page (null) Exception : Could not connect to http://servername:32843/virtualDirectoryID/VisioGraphicsService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it :32843.
w3wp.exe Visio Graphics Service Web Access High BeginGetVectorDiagram failed: System.OperationCanceledException: The server failed to process the request. ---> System.ServiceModel.EndpointNotFoundException: Could not connect to http://servername:32843/virtualDirectoryID/VisioGraphicsService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it :32843. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it :32843


See Microsoft Technet Article for details about ports that need to be open for communication: http://technet.microsoft.com/en-us/library/cc262849.aspx#ServiceApp

You might find these articles useful