Inside SharePoint
Securing External SharePoint Communications
Pav Cherny
Contents
Encrypting SharePoint traffic in Internet-accessible scenarios by using Transport Layer Security (TLS)/Secure Sockets Layer (SSL) is a familiar approach for securing communication.
Ever since 1995 when Netscape introduced SSL as a means of securing data through cryptography implemented on top of the HTTP protocol, Web-based client/server communication has relied heavily on SSL certificates.
SharePoint technologies take advantage of TLS through IIS with .NET, which provide the underlying TLS-capable Web server platform.
However, enabling TLS for SharePoint sites is only one aspect of securing external communication.
You must also consider other facets such as host-based and network firewalls, design topology, and the underlying Active Directory and physical network dependencies.
In the July 2009 column, I covered options for securing server communication in the internal environment by enforcing health policies through Network Access Protection (NAP) with IPSec and by following general SharePoint security best practices.
One of the key premises of securing internal communication is knowing the identity of internal users and computers and, based on this, creating policies to grant and restrict access.
This premise is effective in an authenticated environment such as one that uses Active Directory and Kerberos or NT Lan Manager (NTLM), but it's incomplete in environments where at least some of the users are anonymous or where a class of users, such as vendors or partners, need different policies applied.
Security in the context of Internet-facing sites requires a similar approach of using multiple layers.
One of the underlying principles of securing external communication is blocking unwanted access as early as possible, while having the ability to perform security audits and logging for unauthenticated and authenticated users.
The typical approach to satisfying this need is to use, at minimum, a firewall at the network edge for user authentication and stateful inspection of HTTP traffic.
However, TLS poses a challenge to stateful packet inspection, because the firewall must be able to decrypt packets, inspect them, re-encrypt them, and pass them to a front-end server for processing.
Moreover, the firewall (and any load-balancing solution) must preserve HTTPS sessions.
Internet Security and Acceleration (ISA) Server 2006 and Intelligent Application Gateway (IAG) Server 2007 provide a firewall solution that works together with IIS and SharePoint to deliver a TLS-compatible means of securing communication.
Understanding TLS communication in SharePoint requires an understanding of how the hosting architecture and topology affect the way IIS and any firewalls handle SSL certificates.
Accordingly, there are a number of considerations for designing and deploying SharePoint solutions that are accessible from the Internet.
The SharePoint architecture includes some challenging configuration aspects in addition to IIS, SSL and firewall considerations, such as alternate access mappings (AAM), authentication, and SharePoint zones.
Topology Design Considerations
Developing multiple layers of security for SharePoint sites begins with defining physical network topology.
If you can reduce or eliminate unwanted traffic before it hits front-end and back-end servers, you not only lessen server load but also mitigate the risks of viruses, spam, and malware that come with malicious traffic.
The network topology that accommodates TLS for SharePoint depends on the usage scenario required for your organization.
Figure 1 shows a decision tree with some considerations and relevant topology decisions.
You can simplify the decisions further by separating the various topology options into three areas:
-
Traffic before it hits the firewall.
-
Traffic between the firewall and the internal network.
-
Traffic inside the internal network.
.gif)
Figure 1 Decision considerations for Internet-accessible topologies.
In terms of configuring TLS, making this distinction is vital because you must configure routing and firewall rules to bridge HTTPS connections between Internet requests and IIS front-end servers, configure IIS to serve SharePoint applications, and ensure that internal resources are protected.
Depending on the topology, TLS traffic may need to be able to traverse all three of these areas through multiple routers and firewalls.
Let's take a look at three topology options for Internet-accessible sites and consider how the topologies affect TLS traffic.
Figure 2 shows a basic "edge" topology with one firewall securing internal servers.
.gif)
Figure 2 Basic edge topology with a single firewall.
In edge topology, a single network firewall stands between external users and internal SharePoint sites.
It has the advantage of using a single Active Directory environment for internal and external users, which simplifies maintenance and administration.
To secure traffic via TLS, you configure the firewall to also act as a reverse proxy.
The concept of an integrated reverse proxy such as ISA Server is vital for securing Internet-facing sites, because the reverse proxy intercepts incoming requests, can authenticate external users, decrypts TLS traffic, inspects it according to firewall rules, and forwards requests to front-end servers.
Public URLs may differ from internal URLs, so the reverse proxy must have a means to perform link translation to convert external URLs into internal URLs.
IAG Server provides additional security capabilities, such as end-point, health-based authorization through an access policy based on user identity and client computer health, and the ability to translate links for internal SharePoint URLs when using Outlook Web Access.
To add an additional layer to the topology and exercise more granular control over communication between servers, you can create a perimeter network that hosts SharePoint servers.
In a perimeter network, the SharePoint servers are isolated from the Internet by a firewall and from the internal network by a firewall.
This is a back-to-back topology, as shown in Figure 3.
.gif)
Figure 3 A “back-to-back” topology with two firewalls.
Of course, you are not limited to just two firewalls in a back-to-back topology.
You can implement additional layers separated by firewalls or routers to further separate the SharePoint roles.
For example, you could use a three-layer approach, putting each layer in a DMZ, where front-end servers are first, followed by application, database and search/index server, and concluded by Active Directory/DNS servers.
You can also customize a back-to-back topology to include an internal staging environment in a separate farm and publish it to the farm in the perimeter network.
Another option is to split the SharePoint farm between the perimeter network and the internal network to create a split back-to-back topology, as shown in Figure 4.
In keeping with the approach of using security layers in the topology, front-end servers reside in the perimeter network and the back-end servers running SQL Server reside in the internal network.
The remaining roles, such as index, search, and central administration, can be in either network.
.gif)
Figure 4 In a “split” back-to-back topology, server roles can be set up in either
the DMZ or the internal network.
Place the search server in the internal network for optimal search and crawling performance.
You can dedicate the search server to crawling.
Keep in mind that the split back-to-back topology requires a one-way trust between the perimeter and internal and AD environments to support communication.
Authentication
Determining the appropriate authentication configuration for securing external communication can quickly become overwhelming, due to the available options and the topology levels at which authentication and authorization take place.
For example, your environment may support RSA SecureID, incorporate Network Policy Server (NPS), or use a custom Lightweight Directory Access Protocol (LDAP)-based directory.
In the end,the relevant authentication aspects of securing external SharePoint communication include authentication of external and internal users, and IIS authentication for SharePoint sites.
Let's simplify these aspects even more by tracing the communication path of requests from external users to SharePoint sites to see how authentication and authorization happen.
-
An external user makes a request that is routed to the firewall.
If the firewall is an ISA Server configured to use forms-based authentication (FBA), the user is presented with a logon form and authenticated.
The request is then sent to a front-end server.
-
IIS on the front-end server accepts the request; determines the site associated with the URL; checks the authentication configuration for the site; authenticates the traffic; and passes it to SharePoint for authorization.
-
SharePoint performs authorization.
SharePoint site permissions and authorization are outside of the scope of this article, because TLS is configured for each site at the IIS level.
For more information about SharePoint authorization and authentication, see Plan authentication methods (Office SharePoint Server).
Site Configuration to Support TLS
SharePoint relies heavily on IIS and the underlying topology and authentication configuration to provide the necessary functionality to support TLS.
By the time traffic is routed to SharePoint, it has already passed through the firewall and been handled by IIS.
Configuring SharePoint sites to support TLS is more a task of informing SharePoint of the underlying environment for each site than directly specifying SSL certificates, creating service account, and so on.
Still, it's important to consider two SharePoint-specific details when deploying TLS: zones and Alternate Access Mapping (AAM).
Both are configured in the Central Administration site under Application Management.
When creating or extending a Web application, you can specify zones and enter details about the environment that SharePoint uses to create an initial set of AAMs (see Figure 5).
The key considerations from a security perspective are the authentication provider and whether the ISA Server uses TLS to communicate with the front-end server, or terminates the HTTPS requests from external users at the firewall and communicates via HTTP.
.gif)
Figure 5 SSL and other confi guration options for a SharePoint site.
Although using TLS for communication from ISA Server to front-end servers creates additional processing overhead, it provides an end-to-end encrypted solution and is my preferred method.
Terminating TLS at the ISA Server may also break some usage scenarios, such as when using custom Web Parts that store URLs in a SQL Server database.
The process is similar for enabeing an existing site for TLS.
You must check the Use Secure Sockets Layer (SSL) radio button, configure the other options, and then navigate to the AAM settings and verify that they are configured properly.
Zone and AAM configuration is interrelated.
SharePoint uses the idea of zones to allow logical distinctions between parts of your topology, such as Internet, extranet, and intranet and the URLs available to those parts.
AAM definitions specify how the URL header should look to users of various zones when the URL is different from the internal URL.
If your internal URL is the same as a public URL that uses a fully qualified domain name (FQDN), you do not need to configure AAM ; SharePoint does that automatically.
For other scenarios, configure AAMs for your SharePoint sites.
Troy Starr posted a comprehensive overview of AAMs for Sharepoint on the SharePoint Team blog, which you can find at What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3).
It is well worth a look; AAM misconfiguration is one of the most prevalent causes of extranet scenario issues.
IIS Configuration for SSL Certificates
As mentioned, enabling SSL for a SharePoint site is done at the IIS level.
In IIS7, SSL certificates are configured via Server Certificates.
They are located under the Properties page of IIS Server.
Microsoft has already published instructions, considerations and usage scenarios to keep in mind when enabling IIS sites to use SSL; remember that certificate authority and IP address/port binding are especially relevant for securing Internet-accessible sites.
There are several options for generating an SSL certificate.
You can use selfssl.exe, deploy a PKI with a trusted Windows Certification Authority (CA), or use a commercial provider.
For lab environments and development purposes, a self-signed certificate works well, but you may run into user issues for production environments.
Unless users accept the certificate in their browsers, they will be prompted when accessing an SSL-enabled site that the certificate comes from an untrusted source.
This may lead to support calls and confusion, making it easier to deploy a production certificate from a root CA.
It is possible to use the same IP address or the same port for multiple SSL-enabled sites.
The straightforward way is to use a fixed IP address and the same port for each site, so IIS can bind the site to the IP address and port.
Alternatively, if your configuration uses one root domain and multiple subsites, you can use a wildcard certificate or certificate with multiple site alternative names (SANs).
The process is mostly the same as for a regular certificate, but you cannot configure it in the IIS 7e screen under Site Bindings.
Instead, use appcmd and run the following command to bind SSL to the site and set the host header: C:\Windows\System32\inetsrv\appcmd set site /site.
name:<CustomSiteName> /+bindings.[protocol='https',bindingInformation='*:443:<FQDN>].
If done properly, you will see an SSL binding with the host header you specified under Site Bindings.
ISA Server Configuration
Regardless of whether you want to secure an existing or new SharePoint site with TLS, you must ensure that the traffic can traverse the firewall.
ISA Server provides several mechanisms that work with SharePoint and make traversal possible: FBA, HTTPS bridging, link translation through reverse proxy, and SharePoint publishing rules.
ISA Server uses a wizard to help you publish SharePoint sites.
This wizard creates a listener and an "allow" rule to enable SharePoint traffic.
Before running the wizard, export the SSL certificate installed via IIS on the front-end server hosting the site and import it to ISA Server using the Certificates MMC snap-in.
Import the certificate to the local computer account personal store.
Doing this enables the listener you create in ISA Server to decrypt incoming traffic, inspect it, and re-encrypt it.
For more details about configuring ISA Server for SharePoint, see Authentication in ISA Server 2006 and Configure ISA 2006 for Sharepoint 2007.
By the time you configure ISA Server to publish your SSL-enabled SharePoint sites, internal and external URLs are resolvable through DNS; user accounts and permissions have been configured; SharePoint zones and AAMs are configured; and you have installed the SSL certificate for the site through IIS.
At this point, enter the relevant details in the ISA Server.
When you configure the listener and publishing rule, keep the following in mind:
-
AAM: For alternate access mapping to work properly, you must configure the publishing rule to forward the original host header.
Also, make sure you specify the proper FQDN addresses for the internal and external URLs.
-
FBA: Make sure you select HTML Form Authentication and Windows (Active Directory) from the Authentication tab, unless you're using Kerberos or a custom authentication solution.
-
Deny access for non-authenticated users.
For enhanced security, make sure you add All Authenticated Users.
Alternativelyr select specific users under User Sets and make sure All Users is removed.
Ease Your Pain
Securing your SharePoint sites by using TLS can be full of issues.
Your firewall may not properly direct traffic as a reverse proxy or may do a poor job of link translation.
The routing configuration may not be configured properly in more complex topologies.
Or the AAM and zone configurations may not match the DNS or firewall settings.
The good news is that if you approach external security with a multi-layer approach, you can isolate issues and resolve them.
You can make your life even easier if you use ISA Server with FBA and Windows authentication.
Pick the appropriate topology, configure the site in SharePoint, enable it for SSL in IIS, bring it all together with ISA Server, and you have secured external communication through TLS.
Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication.
His publications include white papers, product manuals, and books with a focus on IT operations and system administration.
Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.
|
Explorando o SharePoint
Protegendo as comunicações externas com o SharePoint
Pav Cherny
Sumário
Criptografar o tráfego SharePoint em cenários acessível pela Internet usando TLS (Transport Layer Security) (Secure Sockets LAYER) é uma abordagem familiar para proteger a comunicação.
Desde 1995 quando Netscape introduzido SSL como um meio de proteger dados por meio de criptografia implementada na parte superior do protocolo HTTP, comunicação cliente/servidor baseados na Web tem dependia muito certificados SSL.
As tecnologias SharePoint aproveitam TLS através do IIS com. NET, que fornecem a plataforma de servidor Web compatíveis com TLS subjacente.
No entanto, ativar o TLS para sites é apenas um aspecto de proteger a comunicação externa.
Você também deve considerar outras facetas como baseado em host e firewalls, topologia de design e a base do Active Directory e dependências de rede física.
A coluna de julho de 2009, abordei opções para proteger a comunicação do servidor no ambiente interno aplicando diretivas de integridade através de (NAP) com IPSec e por seguintes gerais SharePoint as práticas recomendadas de segurança.
Um das principais premissas de proteger a comunicação interna é saber a identidade de computadores e usuários internos e, com base nisso, criar diretivas para conceder e restringir o acesso.
Este premissa é eficaz em um ambiente autenticado como um que usa o Active Directory e o Kerberos ou NTLM (NT LAN Manager), mas é incompleta em ambientes onde pelo menos alguns dos usuários são anônimos ou onde uma classe de usuários, como fornecedores ou parceiros, precisa diferentes diretivas aplicadas.
Segurança no contexto de sites voltados para a Internet requer uma abordagem semelhante do uso de várias camadas.
Dentre os princípios subjacentes de proteção de comunicações externas está bloqueando acesso indesejado como início possível, tendo a capacidade de executar log de auditorias de segurança e para os usuários não autenticados e autenticados.
A abordagem típica para atender a essa necessidade é usar, no mínimo, um firewall na borda da rede para usuário com monitoração de estado de autenticação e inspeção do tráfego HTTP.
No entanto, o TLS representa um desafio para inspeção de pacotes com monitoração de estado, pois o firewall deve ser capaz de descriptografar os pacotes, inspecioná-los, recriptografá-los e passá-las para um servidor front-end para processamento.
Além disso, o firewall (e qualquer solução de balanceamento de carga) devem preservar sessões HTTPS.
Internet Security and Acceleration (ISA) Server 2006 e Server Intelligent Application Gateway (IAG) 2007 oferecem uma solução de firewall que funciona junto com o IIS e o SharePoint para fornecer um meio de TLS compatível de proteger a comunicação.
Noções básicas sobre comunicação TLS no SharePoint requer uma compreensão de como a arquitetura de hospedagem e topologia afetam a maneira como IIS e qualquer firewalls lidar com certificados SSL.
Da mesma forma, há uma série de considerações para projetar e implantar soluções de SharePoint que são acessíveis pela Internet.
A arquitetura do SharePoint inclui alguns aspectos de configuração um desafio ao IIS, SSL e firewall considerações, como mapeamentos de acesso alternativo (AAM), autenticação e as zonas do SharePoint.
Considerações de design de topologia
Desenvolvimento de várias camadas de segurança para sites começa com definindo a topologia física da rede.
Se você pode reduzir ou eliminar o tráfego indesejado antes de ele atinge servidores front-end e back-end, você não apenas diminuir a carga do servidor mas também atenuar os riscos de vírus, spam e malware que acompanham o tráfego mal-intencionado.
A topologia de rede que acomoda TLS para SharePoint depende o cenário de uso necessário para sua organização.
A Figura 1 mostra uma árvore de decisão com algumas considerações e decisões topologia relevantes.
Você pode simplificar as decisões mais separando as várias opções de topologia em três áreas:
-
Tráfego antes de ele acessa o firewall.
-
Tráfego entre o firewall e a rede interna.
-
Tráfego dentro da rede interna.
Figura 1 Considerações sobre decisões topologias acessível pela Internet.
Em termos de configurar TLS, fazer essa distinção é vital porque você deve configurar regras de roteamento e firewall para ponte conexões HTTPS entre servidores front-end do IIS e solicitações de Internet, configurar o IIS para servir aplicativos do SharePoint e garantir que os recursos internos estão protegidos.
Dependendo da topologia da tráfego TLS talvez precise ser capaz de percorrer todas essas três áreas através de vários roteadores e firewalls.
Vamos dar uma olhada três opções de topologia de sites acessível pela Internet e considerar como as topologias afetam tráfego TLS.
Figura 2 mostra básico "margem"topologia com um firewall protegendo servidores internos.
Figura 2 Borda básica topologia com um firewall único.
Na topologia de borda, um firewall de rede único significa entre sites internos e usuários externos.
Ele tem a vantagem de usar um único ambiente do Active Directory para usuários internos e externos, que simplifica a manutenção e administração.
Para proteger o tráfego por meio de TLS, configure o firewall para atuar também como um proxy reverso.
O conceito de um proxy reverso integrado, como o ISA Server é fundamental para proteger sites voltados para a Internet, porque o proxy reverso intercepta as solicitações de entrada, pode autenticar os usuários externos, descriptografa o tráfego TLS, inspeciona-acordo com a regras de firewall e encaminha solicitações para servidores front-end.
URLs públicas podem diferir do URLs internas, portanto, o proxy reverso deve ter um meio para executar a tradução de links para converter URLs externas em URLs internas.
IAG Server fornece recursos de segurança adicionais, como pontos de extremidade, autorização com base em integridade através de uma diretiva de acesso com base no usuário integridade do computador cliente e de identidade e a capacidade de traduzir links para URLs internas do SharePoint quando estiver usando o Outlook Web Access.
Para adicionar uma camada adicional à topologia do e exercer controle mais granular sobre comunicação entre servidores, você pode criar uma rede de perímetro que hospeda os servidores do SharePoint.
Em uma rede de perímetro, os servidores do SharePoint são isolados da Internet por um firewall e da rede interna por um firewall.
Isso é uma topologia em frente e verso, como mostrado no figura 3.
Figura 3 Uma topologia “ em frente e verso ” com dois firewalls.
Obviamente, você não está limitado a apenas dois firewalls em uma topologia em frente e verso.
Você pode implementar as camadas adicionais separadas por firewalls ou roteadores para outras separam as funções do SharePoint.
Por exemplo, você pode usar uma abordagem de três camadas, colocando cada camada em um DMZ, onde os servidores front-end estão primeiro, seguido pelo servidor de aplicativo, banco de dados e/índice de pesquisa e concluída por servidores Active Directory/DNS.
Você também pode personalizar uma topologia em frente e verso para incluir um ambiente de teste interno em um farm separado e publicá-lo do farm na rede de perímetro.
Outra opção é dividir o farm do SharePoint entre a rede de perímetro e a rede interna para criar uma topologia de divisão em frente e verso, conforme mostrado no figura 4.
Acompanhando a abordagem de usar camadas de segurança a topologia, os servidores front-end residem na rede de perímetro e os servidores back-end executando o SQL Server residem na rede interna.
As funções restantes, como índice, pesquisa e administração central, podem estar em qualquer rede.
Figura 4 em uma topologia em frente e verso “ dividir ”, funções de servidor podem ser configuradas no DMZ ou a rede interna.
Coloque o servidor de pesquisa na rede interna para pesquisa ideal e rastreamento de desempenho.
Você pode dedicar o servidor de pesquisa para rastreamento.
Tenha em mente que a topologia em frente e verso divisão requer uma confiança unidirecional entre o perímetro e interno e ambientes de AD para dar suporte à comunicação.
Autenticação
Determinar a configuração de autenticação adequado para proteger a comunicação externa rapidamente pode se tornar difícil, devido às opções disponíveis e os níveis de topologia na qual autenticação e autorização ocorrerá.
Por exemplo, seu ambiente pode oferecer suporte a RSA SecureID, incorporar NPS (servidor de diretivas de rede) ou usar um diretório personalizado com base no protocolo LDAP.
No final, os aspectos de autenticação relevantes de proteger a comunicação externa do SharePoint incluem autenticação de usuários internos e externos e autenticação do IIS para sites.
Vamos simplificar esses aspectos mais rastreando o caminho de comunicação das solicitações de usuários externos para sites do SharePoint para ver como a autenticação e autorização acontecem.
-
Um usuário externo faz uma solicitação que é roteada para o firewall.
Se o firewall é um ISA Server configurado para usar autenticação baseada em formulários (FBA), o usuário é apresentado com um formulário de logon e autenticado.
Em seguida, a solicitação é enviada para um servidor front-end.
-
IIS no servidor front-end aceita a solicitação;Determina o site associado com a URL;verifica a configuração de autenticação para o site;autentica o tráfego;e o passa para o SharePoint para autorização.
-
SharePoint executa autorização.
As permissões de site do SharePoint e autorização são fora do escopo deste artigo, porque TLS está configurado para cada site no nível do IIS.
Para obter mais informações sobre autenticação e autorização do SharePoint, consulte plano autenticação métodos (Office SharePoint Server).
Site de configuração para suporte TLS
SharePoint depende muito IIS e a topologia subjacente e configuração de autenticação para fornecer a funcionalidade necessária para oferecer suporte a TLS.
Quando o tráfego será roteado para o SharePoint, ele já tem passado através do firewall e sido tratado pelo IIS.
Configurando sites para oferecer suporte a TLS é mais uma tarefa de informando SharePoint do ambiente subjacente para cada site que diretamente especificando certificados SSL, criar conta de serviço e assim por diante.
Ainda assim, é importante considerar dois detalhes específicos do SharePoint ao implantar o TLS: zonas e mapeamento de acesso alternativo (AAM).
Ambos são configurados no site Administração Central em gerenciamento de aplicativos.
Ao criar ou estender um aplicativo da Web, você pode especificar as zonas e insira os detalhes sobre o ambiente SharePoint usa para criar um conjunto inicial de AAMs (consulte figura 5).
As principais considerações de uma perspectiva de segurança são o provedor de autenticação e se o ISA Server usa o TLS para se comunicar com o servidor front-end, ou encerra as solicitações HTTPS do usuários externos no firewall e se comunique via HTTP.
Figura 5 SSL e outras opções de guration confi para um site do SharePoint.
Embora usando TLS para comunicação do ISA Server para servidores front-end cria adicional processamento de sobrecarga, ele fornece uma solução de ponta a ponta criptografada e é meu método preferido.
Encerrar TLS no ISA Server também pode quebrar alguns cenários de uso, como quando usando Web Parts personalizados que armazenam URLs em um banco de dados SQL Server.
O processo é semelhante para enabeing um site existente para TLS.
Você deve verificar o botão de opção usar SSL (Secure Sockets Layer), configurar outras opções e em seguida, navegue para as configurações do AAM e verificar que eles estão configurados corretamente.
Configuração de zona e AAM inter-relacionada.
SharePoint usa a idéia de zonas para permitir que lógico distinções entre partes de sua topologia, como Internet, extranet e intranet e as URLs disponíveis para as partes.
Definições do AAM especificam como o cabeçalho do URL deve procurar os usuários de várias zonas quando a URL for diferente do URL interna.
Se a URL interna é a mesma como uma URL pública que usa um nome de domínio totalmente qualificado (FQDN), você não precisa configurar AAM;SharePoint faz isso automaticamente.
Para outros cenários, configure AAMs para seus sites do SharePoint.
Troy Starr lançada uma visão geral abrangente de AAMs para SharePoint no blog da equipe do SharePoint, você pode encontrar em que cada administrador do SharePoint precisa saber sobre mapeamentos alternativos de acesso (parte 1 de 3).
Vale bem uma aparência;Configuração incorreta do AAM é uma das causas mais comuns dos problemas do cenário de extranet.
Configuração do IIS para certificados SSL
Como mencionado, habilitando o SSL para um site do SharePoint é feita no nível do IIS.
No IIS7, certificados SSL são configurados por meio de certificados de servidor.
Eles estão localizados sob a página Propriedades do servidor IIS.
A Microsoft já publicou instruções, considerações e cenários de uso para ter em mente ao ativar sites do IIS para usar o SSL;Lembre-se de que autoridade de certificação e IP endereço/porta ligação são especialmente relevantes para proteger sites acessível pela Internet.
Há várias opções para gerar um certificado SSL.
Você pode usar selfssl.exe, implante uma PKI com uma confiáveis Windows autoridade de certificação (CA) ou usar um provedor comercial.
Para fins de desenvolvimento e ambientes de laboratório, um certificado auto-assinado funciona bem, mas você pode executar para problemas do usuário para ambientes de produção.
A menos que os usuários aceitar o certificado em seus navegadores, eles serão solicitados ao acessar um site SSL habilitado que o certificado vem de uma fonte não confiável.
Isso pode levar a oferecer suporte a chamadas e confusão, tornando mais fácil implantar um certificado de produção de uma autoridade de certificação raiz.
É possível usar o mesmo endereço IP ou a mesma porta para vários sites habilitados para SSL.
A maneira simples é usar um endereço IP fixo e a mesma porta para cada site, portanto, o IIS pode acoplar o site para o endereço IP e porta.
Como alternativa, se sua configuração usa um domínio raiz e vários subsites, você pode usar uma certificado curinga ou um certificado com vários nomes alternativos de site (SANs).
O processo é principalmente o mesmo para um certificado regular, mas você não pode configurá-lo na tela de 7e IIS em ligações de site.
Em vez disso, use appcmd e execute o seguinte comando para vincular o SSL para o site e definir o cabeçalho do host: C:\Windows\System32\inetsrv\appcmd definir /site do site.
nome: < CustomSiteName >/ + ligações. [protocolo = 'https', o bindingInformation = ' *: 443: < FQDN >].
Se feito corretamente, você verá uma ligação SSL com o cabeçalho de host especificado em ligações de site.
Configuração do ISA Server
Independentemente de se você deseja proteger um site do SharePoint novo ou existente com TLS, você deve garantir que o tráfego pode atravessar o firewall.
O ISA Server fornece vários mecanismos que funcionam com o SharePoint e possibilitam a passagem: FBA, HTTPS ponte, tradução de links por meio de proxy reverso e SharePoint as regras de publicação.
ISA Server usa um Assistente para ajudar a publicar sites.
Este assistente cria um ouvinte e um "Permitir"regra para permitir tráfego do SharePoint.
Antes de executar o assistente, exporte o certificado SSL instalado por meio do IIS no servidor front-end que hospeda o site e importá-lo para o ISA Server usando o snap-in do MMC de certificados.
Importe o certificado no armazenamento pessoal de conta do computador local.
Isso permite que o ouvinte, você cria no ISA Server para descriptografar o tráfego de entrada, inspecioná-lo e recriptografá-lo.
Para obter mais detalhes sobre como configurar o ISA Server para SharePoint, consulte autenticação no ISA Server 2006 e configurar ISA 2006 para o SharePoint 2007.
No momento em que você configurar o ISA Server para publicar seus sites do SharePoint SSL habilitado, internos e URLs externos forem puder ser resolvidos por meio do DNS;contas de usuário e permissões tem sido configuradas;Zonas do SharePoint e AAMs são configurados;e você ter instalado o certificado SSL para o site através do IIS.
Neste ponto, insira os detalhes relevantes no ISA Server.
Quando você configura o ouvinte e regra de publicação, tenha em mente o seguinte:
-
AAM: Para mapeamento de acesso alternativo funcione corretamente, você deve configurar a regra de publicação para encaminhar o cabeçalho do host original.
Além disso, certifique-se de que você especificar os endereços FQDN corretos para as URLs internas e externas.
-
FBA: Verifique se que você selecionou autenticação de formulário HTML e do Windows (Active Directory) na guia autenticação, a menos que você esteja usando Kerberos ou uma solução autenticação personalizada.
-
Negar acesso de usuários não autenticados.
Para aumentar a segurança, verifique se que você adicionar todos os usuários autenticados.
Alternativelyr Selecione usuários específicos em conjuntos de usuário e verifique se todos os usuários é removido.
Facilitar o problema
Protegendo seus sites do SharePoint usando TLS pode ser cheia de problemas.
Seu firewall corretamente pode direcionar o tráfego como um proxy reverso ou pode fazer um trabalho ruim de tradução de links.
A configuração de roteamento não pode ser configurada corretamente em topologias mais complexas.
Ou as configurações do AAM e zona não podem corresponder às configurações de firewall ou DNS.
A boa notícia é que, se abordar segurança externa com uma abordagem multi-layer, você pode isolar problemas e resolvê-los.
Você pode facilitar sua vida mesmo se você usar ISA Server com autenticação FBA e do Windows.
Escolher a topologia apropriada, configurar o site no SharePoint, habilitá-lo para SSL no IIS, colocá-lo todos juntos com o ISA Server e você tiver protegido comunicação externa por meio de TLS.
Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada.
Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema.
Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.
|