Publishing Microsoft Office SharePoint Server

This article is an excerpt from Microsoft Forefront Threat Management Gateway (TMG) Administrator's Companion by Jim Harrison, Yuri Diogenes, and Mohit Saxena from the Microsoft Forefront TMG Team with Dr. Tom Shinder, from O'Reilly (ISBN 0-7356-2638-3, copyright Microsoft Press 2010, all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

This chapter discusses how to plan and configure a Microsoft Office SharePoint Services deployment. With Office SharePoint Services, organizations can take file sharing and collaboration to a new level by helping to improve process efficiency and information worker productivity, increase business agility, and reduce operating costs. When you publish Office SharePoint Services to the Internet, TMG can help make these sites available to external users without compromising the security of your organization's network. This chapter explains what you need to consider while planning SharePoint and how to configure a Web Publishing rule in TMG to publish SharePoint services to the Internet. We'll conclude the chapter with a discussion of some common issues related to publishing SharePoint services and how to troubleshoot them.

Contents

• Planning to Publish SharePoint 
   
• Configuring SharePoint Publishing 
   
• Troubleshooting 
   
• Summary 
   
• Additional Resources 
   

Planning to Publish SharePoint

To have a stable and successful setup, it is essential to plan every deployment. Before publishing SharePoint, you need to take into account various aspects of the deployment. In this section we will discuss the security aspects, authentication, and Alternate Access Mapping (AAM) considerations before we publish SharePoint. One of the key aspects of every deployment is the security considerations that need to be in place before you publish any Web services. Some of the security considerations also depend on the type of authentication being used to either pre-authenticate the request at TMG or when delegating credentials to the published SharePoint using authentication delegation in TMG. You must consider your authentication requirements carefully because any authentication mismatch will cause failure in users' ability to access the published server.

Security Considerations

Administrators prefer to allow only the most restrictive access to their published servers to reduce the chance that the security of the network can be compromised. Some of the key areas that need to be planned around security are:

• Access based on source networks
   
• Access for only encrypted traffic (HTTPS) or for both encrypted and unencrypted traffic
   
• Allowing caching
   
• Access based on time
   
• Access based on user groups
   

Even though most of these considerations are very generic, they are important. Each area affects how the rule is configured.

Access Based on Source Networks

The whole idea of publishing a Web service is to allow external users to access the server for the published service. The most common deployment is to allow access to users on the Internet. When you create a SharePoint Web publishing rule, the default option is to allow access from the Anywhere computer set to the listener that is listening for the requests. An administrator can, however, set up address ranges or specific IP addresses to allow access only from that address range or IP address.

Access for Encrypted or Unencrypted Traffic

One of the most important security considerations when publishing any Web service to the Internet or to a non-trusted network is the encryption of traffic. Most administrators encrypt all incoming traffic from the Internet using certificates. You can set up a listener with a certificate to restrict access to only HTTPS traffic. TMG can then forward the traffic using HTTP to the published SharePoint server or over HTTPS depending on how the SharePoint is configured locally. SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications such as SharePoint, after receiving the client's request, TMG decrypts the request, inspects it, and terminates the SSL connection with the client computer. The Web publishing rules determine how TMG communicates the request for the object to the published SharePoint server. If the secure Web publishing rule is configured to forward the request using SSL (HTTPS), TMG initiates a new SSL connection with the published server. Because TMG is now an SSL client, it requires that the published Web server respond with a server-side certificate.

Remember that when you choose a certificate, that certificate needs to have a private key and its Common Name (CN) or one of its Subject Alternate Names (SANs) needs to be the same as the public URL. The certificate should be trusted up to the Root Certification Authority.

Tip:
For more information about certificate requirements please read http://technet.microsoft.com/en-ca/library/dd547090.aspx.

 

Allowing Caching

Content caching allows TMG to cache Web content and to respond to user requests from the cache, rather than contacting the Web server. This increases the performance of requests that are being serviced for the clients over the Internet. Caching also helps reduce the traffic from TMG to the published SharePoint server because the requests that are found in TMG's cache will be delivered to the client from TMG itself and will save the round trip to the published server.

Allowing Access Based on Time

Some administrators like to restrict access based on time. This helps prevent wasting bandwidth by allowing access only during business hours and restricting access during off hours. This can be done using either the built-in schedules or creating a custom schedule and allowing and denying access in the SharePoint publishing rule based on that schedule.

Allowing Access Based on User Groups

TMG can pre-authenticate a request before even forwarding it to the SharePoint server. This prevents any unauthenticated requests from even getting to the SharePoint server. You can configure TMG to allow all authenticated requests for any user in Active Directory or restrict access based on a select user group so that only the users belonging to that specific user group are allowed access to the published SharePoint server.

Authentication

TMG provides a variety of authentication mechanisms that can be used to pre-authenticate a request at TMG. Then the client is either allowed to authenticate against the SharePoint server directly or use the credentials collected in the pre-authentication process and delegate them to the SharePoint server, providing a seamless, single sign-on experience to the client. The different types of client authentication methods on TMG are:

• No Authentication
   
• Forms-Based Authentication
   
• HTTP Authentication (received in HTTP header)
   
• Client Certificate Authentication
   

TMG can validate the client credentials passed on one of these formats using the following providers and protocols:

• No Authentication (allows the internal published server to handle authentication)
   
• Windows Active Directory
   
• Active Directory over LDAP protocol
   
• RADIUS
   
• RADIUS one-time password
   
• SecurID
   

The most commonly used authentication at TMG is Forms-Based Authentication (FBA). When configured with FBA, TMG presents an HTML Form in which the user enters a user name and password, which TMG can then authenticate against Active Directory (in case TMG is a domain member) or Active Directory over LDAP protocol (in case TMG is a non-domain member). Once authenticated, TMG can provide the credentials to the SharePoint Server so that the user is not prompted again for a user name and password.

Remember that when you choose what type of authentication to use for external users, if TMG is set to delegate the user's credentials to the published SharePoint server, the authentication delegation method must be the same as the authentication type set on SharePoint. The delegation method can vary depending on the client authentication method set on TMG and in certain cases only certain combinations can be used. Hence it is important to plan what the client authentication method should be on TMG so that a matching delegation method to the authentication type of SharePoint is available.

Tip:
For different authentication methods available in TMG and what their valid authentication delegation combinations are, please read http://technet.microsoft.com/en-us/library/bb794722.aspx.

 

Alternate Access Mapping

Office SharePoint Services relies on absolute hyperlinks. A URL correction approach, such as TMG's link translation, does not provide a complete solution. This is where Alternate Access Mapping (AAM) comes into play. The main purpose of AAM is to create dynamic links for requests forwarded by the reverse proxy to serve to the end user while maintaining a proper mapping of what link should be returned to an internal user versus an external user.

Administrators often make the mistake of confusing link translation with AAM and don't deem AAM to be important. Link translation and AAM must never be used together in TMG. While configuring the SharePoint publishing rule (discussed in the next section), the TMG administrator is prompted to choose whether AAM is configured on the SharePoint server. If the administrator chooses to not configure AAM, TMG sets up link translation mappings for that rule. If the administrator decides that AAM is set up correctly, no link translation mapping is applied to that rule. SharePoint embeds its URLs in many places and in a variety of encodings that cannot be fixed by the reverse proxy server's link translation feature. SharePoint also has features that use or send URLs that do not go through reverse proxy Web publishing rules. E-mail alerts are a good example of this. Only AAM can ensure that the links in the e-mail alerts contain the correct URL, which can then be accessed publicly. Hence it is important to configure AAM on the Office SharePoint server before you publish it.

Tip:
To learn more about configuring AAM, read http://technet.microsoft.com/en-us/library/cc261814.aspx.

 

Configuring SharePoint Publishing

As explained in the section on planning, publishing a SharePoint site to the Web is similar to publishing any other Web application, with the notable exception that you must use the SharePoint Web Publishing Wizard if you want TMG to process the requests properly. This section will guide you through the process of publishing single-server and Web-farm publishing scenarios.

Regardless of which type of publishing scenario you intend to use, you always begin in the same place. Figure 23-1 illustrates the scenario from which we will derive our publishing configuration.

Figure 23-1 SharePoint publishing scenario

In this scenario, the SharePoint site administrators have already configured AAM and are using unencrypted connections between TMG and the SharePoint server by directing the Contoso network security team to support their third-party IDS system. The SharePoint administrators want TMG to use Kerberos constrained Delegation (KCD).

The following instructions only provide steps for asymmetric SSL bridging; that is, HTTPS between the client and Forefront TMG and HTTP between Forefront TMG and the SharePoint server.

Note:
The procedures that follow are condensed into four subsections: Common Starting Point (the point from which the remaining steps flow), Single Server (publishing a single computer), Multi-Server (publishing multiple sites in a single action), and Server Farm (publishing a SharePoint Web farm).

 

Common Starting Point

1. In the Forefront TMG management console, right-click Firewall Policy, select New, and then select SharePoint Site Publishing Rule, as shown in Figure 23-2.
   
   
   
   Figure 23-2 Creating a new SharePoint publishing rule
   
   
2. On the Welcome To The SharePoint Publishing Rule Wizard page, type in the name of the publishing rule, such as toronto.contoso.com, as shown in Figure 23-3. Click Next.
   
   
   
   Figure 23-3 Publishing Wizard Welcome page
   
   
3. On the Publishing Type page, select the type of publishing scenario you wish to use, as shown in Figure 23-4. Click Next to proceed to the desired publishing scenario, which is illustrated in the following procedure.
   
   
   
   Figure 23-4 Single-site publishing selection
   
   

Single-Server

The following steps continue from the Common Starting point and will guide you through the process for publishing a single SharePoint server.

1. On the Server Connection Security page, select the connection type for the SharePoint site as shown in Figure 23-5 and click Next.
   
   
   
   Figure 23-5 Server Connection Security page
   
   
2. On the Internal Publishing Details page, type in the fully qualified name of the SharePoint site as configured by the SharePoint administrator, shown in Figure 23-6. Select Use A Computer Name Or IP Address and enter the fully qualified host name or IP address in the Computer Name Or IP Address field. Click Next.
   
   
   
   Figure 23-6 Internal Publishing Details page
   
   
3. On the Public Name Details page, select This Domain Name (Type Below) and enter the FQDN as used by clients in the network where the Web listener will operate. For our scenario, external clients will use toronto.contoso.com as shown in Figure 23-7. Click Next.
   
   
   
   Figure 23-7 Public Name Details page
   
   
4. On the Select Web Listener Page, select the Web listener that is to accept connections for this publishing rule as shown in Figure 23-8. Click Next.
   
   
   
   Figure 23-8 Web Listener selection page
   
   
5. On the Authentication Delegation page, select the authentication method used at the SharePoint site. In this case, we have selected Kerberos Constrained Delegation (KCD). Note that the value provided in the Service Principal Name (SPN) is determined from the value we provided in the Internal site name as shown in Figure 23-9. Click Next.
   
   
   
   Figure 23-9 Authentication Delegation page
   
   

   Tip:
   Selecting the correct Kerberos Constrained Delegation configuration is a critical point for proper authentication from TMG to the published server. The considerations related to service accounts and multiple SPN are discussed in http://blogs.technet.com/isablog/archive/2009/02/05/another-blog-about-kcd-tips-and-tricks-on-kerberos-and-delegation-isa2006.aspx.

    

6. On the Alternate Access Mappings Configuration page shown in Figure 23-10, select the choice that best describes your current SharePoint configuration. Because we know that the Contoso SharePoint site has AAM configured, select SharePoint AAM Is Already Configured On The SharePoint Server. Click Next.
   
   
   
   Figure 23-10 Alternate Access Mappings Configuration page
   
   
7. On the User Sets page, leave the default selection in place as shown in Figure 23-11 and click Next.
   
   
   
   Figure 23-11 User Sets page
   
   
8. On the Completing The New SharePoint Publishing Rule Wizard page, verify the summary data as shown in Figure 23-12 and click Finish.
   
   
   
   Figure 23-12 Completing The New SharePoint Publishing Wizard page
   
   

   Note:
   Because we selected KCD, the publishing wizard produces the warning shown in Figure 23-13 to remind you that you should verify the necessary domain and server configuration for KCD to operate properly.

    

   
   
   Figure 23-13 KCD informational warning
   
    
   
   Figure 23-14 New SharePoint single-server publishing rule summary
   
    This completes the process required to meet the Contoso SharePoint administrator's requirements for publishing the Contoso SharePoint portal. The remaining steps are included to illustrate the differences in the Web publishing wizards.
    

Multi-Server

The following steps illustrate the process involved in publishing multiple, individual SharePoint sites as shown in Figure 23-15. You must begin this process with the Common Starting Point Steps. The servers that you are publishing are Sydney and Denver.

Figure 23-15 Multiple Web site selection

1. On the Specify Web Sites To Publish page, shown in Figure 23-16, click Add to add the Sydney server.
   
   
   
   Figure 23-16 Specify Web Sites To Publish page
   
   
2. In the Internal Site Details dialog box, type sydney in the Internal Site Name field as shown in Figure 23-17. Click OK to close the Internal Site Details dialog box.
   
   
   
   Figure 23-17 Adding the Sydney server to the list
   
   
3. On the Specify Web Sites To Publish page, click Add to add the Denver server.
    
4. In the Internal Site Details dialog box, type denverin the Internal Site Name field as shown in Figure 23-18. Click OK to close the Internal Site Details dialog box.
   
   
   
   Figure 23-18 Adding the Denver server
   
   
5. Verify that the Specify Web Sites To Publish page appears as shown in Figure 23-19 and click Next.
   
   
   
   Figure 23-19 Completed server additions
   
   
6. On the Published Web Sites Public Names page, type in the common domain suffix used by these publishing rules—in this case, contoso.com as shown in Figure 23-20. Click Next.
   
   
   
   Figure 23-20 Published Web Sites Public Names page
   
   
7. On the Select Web Listener Page, select the Web listener that is to accept connections for this publishing rule, as shown in Figure 23-21. Click Next.
   
   
   
   Figure 23-21 Multi-server Web listener selection
   
   
8. On the Authentication Delegation page, select the authentication method used at the SharePoint site. In this case, we have selected Kerberos Constrained Delegation (KCD) as shown in Figure 23-22. Click Next.
   
   
   
   Figure 23-22 Authentication Delegation page
   
   

   Note:
   Notice that the value provided in the Service Principal Name (SPN) field is empty. This is because we are publishing multiple servers with different names. You will have to edit each of the new rules to provide the appropriate SPN for each SharePoint server.

    

9. On the Alternate Access Mappings Configuration page, select the choice that best describes your current SharePoint configuration. We know that the Contoso SharePoint site has AAM configured, so select SharePoint AAM Is Already Configured On The SharePoint server, as shown in Figure 23-23. Click Next.
   
   
   
   Figure 23-23 Alternate Access Mappings Configuration page
   
   
10. On the User Sets page, leave the default selection in place as shown in Figure 23-24 and click Next.
    
    
    
    Figure 23-24 User Sets page
    
    
11. On the Completing The New SharePoint Publishing Rule Wizard page, verify the summary data as shown in Figure 23-25 and click Finish.
    
    
    
    Figure 23-25 Multi-server publishing summary page
    
    

    Note:
    You must now edit each new rule individually to specify the SPN for each server being published or the rules will not work.

     

    Figure 23-26 illustrates the rule summaries for the multi-server publishing rules.
    
    
    
    Figure 23-26 Multi-server rules list
    
    

Server Farm

The following steps illustrate the differences between publishing a single SharePoint site and publishing a server farm of SharePoint sites, as shown in Figure 23-27. You must begin this process with the steps from Common Starting Point. The servers that you are publishing are Sydney and Denver.

Figure 23-27 Server farm publishing selection

1. On the Server Connection Security page, select the connection type expected by the SharePoint site as shown in Figure 23-28 and click Next.
   
   
   
   Figure 23-28 Server Connection Security page
   
   
2. On the Internal Publishing Details page, type in the fully qualified name of the SharePoint site as configured by the SharePoint administrator, shown in Figure 23-29. Click Next.
   
   
   
   Figure 23-29 Server farm Internal Publishing Details page
   
   

   Note:
   Because all servers in the farm are publishing the same sites, they must all share a common name, preferably different from the actual server names.

    

3. On the Specify Server Farm page, click New as shown in Figure 23-30.
   
   
   
   Figure 23-30 Specify Server Farm page
   
   
4. On the Welcome To The New Server Farm Wizard page, type SP Farm in the Server Farm Name field as shown in Figure 23-31 and click Next.
   
   
   
   Figure 23-31 Welcome To The New Server Farm Wizard page
   
   
5. On the Servers page, click Add as shown in Figure 23-32.
   
   
   
   Figure 23-32 New Server Farm Definition Wizard Servers page
   
   
6. In the Server Details dialog box, type sydney as shown in Figure 23-33. Click OK to close the Server Details dialog box.
   
   
   
   Figure 23-33 Server details for the Sydney server
   
   

   Note:
   You may enter simple or qualified names or IP addresses in this field.

    

7. On the Servers page, click Add.
    
8. In the Server Details dialog box, type denver as shown in Figure 23-34. Click OK to close the Server Details dialog box.
   
   
   
   Figure 23-34 Server details for the Denver server
   
   
9. Verify that the Servers page list appears as shown in Figure 23-35. Click Next.
   
   
   
   Figure 23-35 Completed Server Farm Servers list
   
   
10. On the Server Farm Connectivity Monitoring page, leave the defaults as shown in Figure 23-36. Click Next.
    
    
    
    Figure 23-36 Server Farm Connectivity Monitoring page
    
    
11. On the Completing The New Server Farm Wizard page, verify that the summary appears as shown in Figure 23-37. Click Finish to close the wizard.
    
    
    
    Figure 23-37 Completing The New Server Farm Wizard page
    
    
12. On the Specify Server Farm page, select the new server farm as shown in Figure 23-38. Click Next.
    
    
    
    Figure 23-38 Completed Server Farm selection
    
    
13. On the Public Name Details page, select This Domain Name (Type Below) and type in the FQDN as used by clients in the network where the Web listener will operate. For our scenario, external clients will use toronto.contoso.com as shown in Figure 23-39. Click Next.
    
    
    
    Figure 23-39 Public Name Details page
    
    
14. On the Select Web Listener Page, select the Web listener that is to accept connections for this publishing rule as shown in Figure 23-40. Click Next.
    
    
    
    Figure 23-40 Web Listener selection page
    
    
15. On the Authentication Delegation page, select the authentication method used at the SharePoint site. In this case, we have selected Kerberos Constrained Delegation (KCD) as shown in Figure 23-41.Click Next.
    
    
    
    Figure 23-41 Server Farm Authentication Delegation page
    
    

    Note:
    Because the IIS process on all SharePoint servers run under the Local System account by default, you must use http/* as the SPN. This allows TMG to use the server name for the destination host when issuing the S4U2Proxy request. For more information on S4U2Proxy requests, please see http://msdn.microsoft.com/en-us/magazine/cc188757.aspx.

     

16. On the Alternate Access Mappings Configuration page, select the choice that best describes your current SharePoint configuration. We know that the Contoso SharePoint site has AAM configured, so select SharePoint AAM Is Already Configured On The SharePoint Server, as shown in Figure 23-42. Click Next.
    
    
    
    Figure 23-42 Alternate Access Mappings Configuration page
    
    
17. On the User Sets page, leave the default selection in place as shown in Figure 23-43 and click Next.
    
    
    
    Figure 23-43 User Sets page
    
    
18. On the Completing The New SharePoint Publishing Rule Wizard page, verify the summary data as shown in Figure 23-44 and click Finish.
    
    
    
    Figure 23-44 Completing the Server Farm Publishing Wizard
    
     Figure 23-45 illustrates the summary information for the server farm rule created.
    
    
    
    Figure 23-45 Server farm rules summary
    
    

Troubleshooting

The troubleshooting approach discussed in Chapter 22, "Publishing Servers," is valid for any Web publishing rule and SharePoint publishing rule is no exception. One setting that is very specific to a successful SharePoint publishing rule is the correct configuration of AAM. This is a SharePoint configuration that enables Microsoft Office SharePoint Servers to provide a URL appropriate to the client connection context.

Tip:
To understand how AAM can affect a publishing rule access read the following ISA/TMG Team Blog posting:http://blogs.technet.com/isablog/archive/2008/10/02/unable-to-check-out-a-document-in-moss-2007-published-through-isa-server-2006.aspx.

 

Review Your Publishing Rule First

Always use the SharePoint Publishing Rule Wizard when you publish SharePoint or MOSS services through TMG. This wizard configures some critical properties that allow the SharePoint publishing rule to work properly, and some areas shouldn't be changed unless you are guided by a Microsoft Support Engineer to do so (such as paths and link translation). For example, you might think that you should change the default paths created by SharePoint Publishing Wizard. Those paths are automatically added by the wizard and should provide proper functionality for your SharePoint site. The default set of paths are shown in Figure 23-46.

Figure 23-46 Default paths created by the SharePoint Publishing Wizard

Another scenario in which you should review a SharePoint publishing rule before collecting data for troubleshooting is if you did not create that rule. As a system administrator, you sometimes inherit a deployment that was already configured by someone else and now you are responsible for maintaining that infrastructure. Reviewing each element of the publishing rule can save you time before you begin your troubleshooting efforts.

Another important element of the SharePoint publishing rule is the TCP port used by the SharePoint site. This is very important because when SharePoint is installed in a Windows Server 2003 it requires Internet Information Services (IIS), which by default uses HTTP on the default port (TCP Port 80) for the default Web site. Because SharePoint Server is installed on top of IIS and the default ports usually are already in use, SharePoint will use a random port.

Note:
It is important to note that SharePoint Server will use a random port only in a scenario that the default port is already in use, such as the preceding example. Make sure to review your IIS configuration to identify which ports are in use.

 

When you finish installing SharePoint on your internal server you will notice, for example, that the Central Administration already uses a custom port randomly chosen during the installation process, as shown Figure 23-47.To make sure that this configuration is working properly review the port that SharePoint site is using and make sure it matches the Bridging tab.

Figure 23-47 Central Administration using a custom HTTP port

Another publishing rule configuration that can cause problems is if you have a mismatch between the authentication delegation of the rule and the authentication configuration of the published site. Review the authentication method used by SharePoint site that you are publishing through TMG and make sure to configure the publishing rule authentication delegation option to match this setting. Figure 23-48 shows an example of the authentication provider for the Central Administration site on a SharePoint Server:

Figure 23-48 The authentication specified on the SharePoint site

In this particular example the authentication method used by the SharePoint site is NTLM. Therefore, the authentication delegation method must be NTLM or Direct And The Client May Authenticate Directly.

Useful Tools

One extremely useful tool provided by TMG is the logging query mechanism. The Logging feature allows you to see near real-time access and results, which can point out a possible root cause for the problem. Combining this feature with a network monitor trace obtained during a reproduction of the issue can guide you to faster resolution of the problem.

To allow a better understanding of how those tools combine during the troubleshooting, we will examine a scenario where the external user is unable to access the Contoso SharePoint Web site (moss.contoso.com). In this scenario the external user complains that after entering his credentials in the authentication page, he receives Error Code 403 Forbidden, similar to Figure 23-49.

Figure 23-49 Error message received from external user

To prepare TMG to gather the traffic information at the right moment, follow these steps:

1. On the TMG Server computer (or using remote management console), open the Forefront TMG Management Console.
    
2. Click Forefront TMG (Array Name) in the left pane.
    
3. Click the Logs & Reports node in the left pane and click Edit Filter in the task pane, as shown in Figure 23-50.
   
   
   
   Figure 23-50 The Configuring Logging feature
   
   
4. In the Filter By drop-down list, select Client IP.
    
5. In the Condition drop-down list, select Equals.
    
6. In the Value field, type in the IP address of your external client. 
    
7. Click Add To List and then click Start Query.
    

Note:
This is not a mandatory procedure, but it will help you to focus your logging only from traffic originating from that particular IP and also will reduce the amount of information that appears on the Logging screen.

 

In addition those steps you will need to install Network Monitor on TMG and start a capture from the internal network interface card, which has connectivity with the published server selected for capturing traffic.

Tip:
For more information on how to use Network Monitor, see Chapter 33, "Using Network Monitor 3 to Troubleshoot TMG."

 

After you gather the traffic while the external user reproduces the issue, you can analyze it. In this particular case, Figure 23-51 indicates the moment where TMG shows the access denied response for that publishing rule.

Figure 23-51 TMG denying the access to the published server

In this case, the Logging feature indicated that TMG was denying the request, but the question of why TMG made that decision remains. This is where Network Monitor can assist you in understanding the underlying cause of a TMG action. Let's follow the traffic between Forefront TMG and SharePoint Server during a request:

1. We observe a successful TCP three-way handshake between TMG and the SharePoint Server:
   
   
    

    

   10.10.10.50   10.10.10.88  TCP   TCP:Flags=......S., SrcPort=11839, DstPort=19049
   10.10.10.88   10.10.10.50  TCP   TCP:Flags=...A..S., SrcPort=19049, DstPort=11839
   10.10.10.50   10.10.10.88  TCP   TCP:Flags=...A...., SrcPort=11839, DstPort=19049
   

2. The client issues the request to TMG, which then forwards it to the SharePoint server, including the credentials supplied by the user. Notice that the request is sending the HTTP GET Request using Basic Authentication:
   
   
    

    

   10.10.10.50 10.10.10.88  HTTP  HTTP:Request, GET / , Using Basic Authorization
   - Http: Request, GET / , Using Basic Authorization
        Command: GET
        + URI: /
        ProtocolVersion: HTTP/1.1
        Connection: Keep-Alive
        Reverse-Via: TMGB2
        Cookie: MSOWebPartPage_AnonymousAccessCookie=19049;
        Referer:  https://moss.contoso.com/CookieAuth.dll?GetLogon?curl=Z2F&reason=0&formdir=3
        UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64;    SLCC1; 
             .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.30618)
        Host:  mossrv:19049
        Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/
             x-ms-application, application/vnd.ms-xpsdocument, application/
             xaml+xml, application/x-ms-xbap, */*
        Accept-Language: en-us
        UA-CPU: x86
        Cache-Control: no-cache
        Front-End-Https: On
        X-Experience: Premium
        X-LogonType: Public
        - Authorization: Basic Y29udG9zb1xhZG1pbmlzdHJhdG9yOlBhc3N3b3JkNQ==
        - BasicAuthorization:
        Scheme: Basic
        - Realm: contoso\Bob:qwer!@#$
        + Realm: contoso\Bob:qwer!@#$
        HeaderEnd: CRLF
        HeaderEnd: CRLF
   

3. SharePoint Server sends the following packet with HTTP 401 and it specifies NTLM as the authentication method:
   
   
    

    

   10.10.10.88  10.10.10.50  HTTP  HTTP:Response, HTTP/1.1, Status Code = 401, URL: 
   / , Using NTLM X-Powered-By: Authentication
   - Http: Response, HTTP/1.1, Status Code = 401, URL: / , Using NTLM
        X-Powered-By: Authentication
        ProtocolVersion: HTTP/1.1
        StatusCode: 401, Unauthorized
        Reason: Unauthorized
        ContentLength: 1656
        + ContentType: text/html
        Server: Microsoft-IIS/6.0
        + WWWAuthenticate: Negotiate
        WWW-Authenticate:
        + WWWAuthenticate: NTLM
        X-Powered-By:
        XPoweredBy: ASP.NET
        MicrosoftSharePointTeamServices: 12.0.0.6219
        Date: Sat, 25 Apr 2009 18:58:55 GMT
        HeaderEnd: CRLF
        + payload: HttpContentType = text/html
   

As you could see through the packet capture, TMG was configured to delegate Basic authentication while the published server was configured to use NTLM. This is a classical example of authentication delegation mismatch between TMG and the published server.

Summary

In this chapter we discussed how to properly plan a SharePoint server publishing with various security and authentication considerations. We also saw the various options available while publishing a SharePoint server and in the end we saw some troubleshooting techniques in case SharePoint publishing fails. In the next chapter we will discuss Exchange publishing.