Planejar a conectividade do Microsoft 365 para o SharePoint Server
APLICA-SE A:
2013 2016 2019 Subscription Edition SharePoint no Microsoft 365
Este artigo foi concebido para o ajudar a planear e preparar a configuração da conectividade de entrada do Microsoft 365 para empresas para o SharePoint Server através de um dispositivo proxy inverso. Isto é necessário para os seguintes ambientes híbridos:
Pesquisa híbrida de entrada (apresentando resultados de pesquisa do SharePoint Server no Microsoft 365)
Serviços Corporativos de Conectividade híbrido
Neste artigo, fornecemos-lhe as informações que precisa de saber, como pré-requisitos e uma folha de cálculo para recolher as informações necessárias antes de iniciar o processo de configuração.
Este tópico vai ajudá-lo a fazer o seguinte:
Compreender os pré-requisitos e requisitos para a conectividade de entrada
Planejar sua arquitetura de aplicativos Web
Planejar Certificados SSL
Registrar decisões-chave e informações
Reunir e registrar informações de log de compilação
Folha de cálculo. durante o processo de planejamento, será preciso coletar informações e arquivos. É importante utilizar a folha de cálculo híbrida do SharePoint para controlar as informações de planeamento e implementação para referência e partilhar com outros membros da sua equipa de implementação. Não é possível sublinhar a importância de utilizar esta folha de cálculo para organizar as suas informações antes de iniciar o processo de configuração.
Criar um log de compilação. Como em qualquer projeto de implementação complexa, um registro detalhado de todas as decisões de design, configuração do servidor, procedimento, saída de comandos e erros é uma referência muito importante para a solução de problemas, o suporte e o reconhecimento. É altamente recomendável que você documente completamente seu processo de implantação.
Cuidado
Por motivos de segurança, armazene a folha de cálculo e o registo de compilação num local com segurança melhorada, como uma partilha de ficheiros segura ou o SharePoint na biblioteca de documentos do Microsoft 365, e conceda permissões apenas aos administradores envolvidos no processo de implementação e que tenham de conhecer estas informações.
Coletar e registrar informações de URL e nome de host
Nesta seção, você registrará informações sobre as URLs e os nomes de hosts do seu ambiente. Essas informações serão usadas durante o processo de implantação.
Registe o nome de domínio DNS público da sua empresa (como adventureworks.com).
Registe o URL do ponto final destinado ao público do dispositivo proxy inverso que irá utilizar para o SharePoint híbrido. Essa é a URL externa. Se este ponto final ainda não existir, terá de decidir qual será este URL.
Registre o endereço IP do ponto de extremidade externo do dispositivo de proxy reverso.
Verifique se um registro A (também conhecido como um registro de host) existe na zona de pesquisa direta de DNS pública para seu domínio público que mapeia a URL Externa para o endereço IP do ponto de extremidade voltado para a Internet no dispositivo de proxy reverso. Se ainda não tiver este registo A, crie-o agora.
Certifique-se de que existe um registo A na zona de pesquisa de reencaminhamento de DNS da intranet que mapeia o nome do anfitrião do farm do SharePoint Server para o respetivo endereço IP. Se ainda não tiver este registo A, crie-o agora.
Importante
Se você configurar URLs internas para acessar um aplicativo Web durante o processo de implantação, crie também registros A para essas URLs na zona de pesquisa direta de DNS da intranet e registre-os na planilha.
|
Anote as seguintes informações na Tabela 3 da planilha do SharePoint híbrido: O nome de domínio do domínio DNS da empresa voltado ao público no nome Internet Public Domain linha. A URL do terminal voltado ao público do dispositivo de proxy reverso no URL externa linha. O endereço IP do ponto de extremidade externo do dispositivo de proxy reverso na linha Endereço IP do ponto de extremidade externo. |
Planejar sua arquitetura de aplicativos Web
Esta secção ajuda-o a planear a arquitetura das aplicações Web do SharePoint Server que irá utilizar no seu ambiente híbrido.
A conectividade de entrada requer um canal de comunicação seguro entre o farm do SharePoint Server no local e o SharePoint no Microsoft 365. Os dados são trocados entre uma coleção de sites no SharePoint no Microsoft 365 e uma aplicação Web no local através deste canal de comunicação.
O SharePoint no Microsoft 365 envia pedidos para um servidor proxy inverso que reencaminha os pedidos para uma aplicação Web específica no farm do SharePoint Server no local que está configurado para o SharePoint híbrido. Nós o chamaremos de aplicativo Web principal.
Dica
Independentemente de quantas soluções híbridas planeja configurar, você normalmente usará apenas um aplicativo Web principal. Não tem de criar aplicações Web primárias adicionais para cada solução híbrida adicional.
A aplicação Web principal e uma única coleção de sites na aplicação Web primária têm de ser configuradas para aceitar ligações de entrada do SharePoint no Microsoft 365.
O administrador do SharePoint associa os serviços e objetos de ligação necessários para suportar as soluções híbridas que estão a ser implementadas com a aplicação Web primária. As ligações de saída podem ser efetuadas a partir de qualquer aplicação Web do SharePoint Server no local através das configurações específicas da funcionalidade.
Uma aplicação Web do SharePoint Server é composta por um site dos Serviços de Informação Internet (IIS) que funciona como uma unidade lógica para as coleções de sites que criar. Cada aplicativo Web é representado por um site diferente do IIS, com um pool exclusivo ou compartilhado de aplicativos, uma URL pública exclusiva, e pode também ser configurado para usar até cinco URLs internas por meio do AAM (Mapeamento Alternativo de Acesso). Um determinado aplicativo Web é associado a um único banco de dados de conteúdo e é configurado para usar um método de autenticação específico para se conectar ao banco de dados. Vários aplicativos Web podem ser configurados para usar diferentes métodos de autenticação e, opcionalmente, AAMs para fornecer um único banco de dados de conteúdo.
O URL público de uma aplicação Web é sempre utilizado como o URL de raiz em todas as ligações para sites e conteúdos acedidos através da aplicação Web. Considere uma aplicação Web com o URL https://spexternal.adventureworks.com público que tem um URL https://sharepoint interno configurado na AAM. Quando navega para o URL https://sharepointinterno, o SharePoint Server devolve o site com o URL https://spexternal.adventureworks.come todas as ligações no site terão URLs com base nesse caminho.
O mapeamento de acesso alternativo (AAM) só é necessário quando está a configurar a conectividade de entrada através de uma coleção de sites baseada no caminho com um URL público diferente do URL externo. A AAM permite-lhe associar o URL externo ao URL interno de um site do SharePoint no Microsoft 365 na sua organização. Isto permite ao SharePoint Server encaminhar pedidos de URLs internos configurados no AAM para a aplicação Web primária correspondente.
Para obter mais informações sobre aplicações Web baseadas em afirmações, veja Criar aplicações Web baseadas em afirmações no SharePoint Server.
Para obter mais informações sobre como expandir uma aplicação Web, veja Expandir aplicações Web baseadas em afirmações no SharePoint.
Para obter mais informações sobre coleções de sites, consulte Descrição geral de sites e coleções de sites no SharePoint Server.
Escolher uma estratégia de conjunto de sites
Antes de decidir pelo uso de um aplicativo Web existente ou pela criação de um novo, você precisa entender os requisitos de configuração que o aplicativo Web e o conjunto de sites devem cumprir para dar suporte à funcionalidade híbrida. Use as informações desta seção para determinar sua estratégia de criação de um aplicativo Web e de um conjunto de sites ou para determinar se um conjunto de sites em um aplicativo Web existente pode ser usado no ambiente híbrido.
A figura a seguir mostra o fluxo de decisão para determinar sua estratégia de conjunto de sites.
Requisitos para aplicativos Web híbridos
Aplicativos Web usados para a funcionalidade híbrida devem atender a todos estes requisitos:
A URL pública do aplicativo Web deve ser idêntica à URL externa.
O protocolo OAuth fornece a autorização do usuário em soluções híbridas do SharePoint. O cabeçalho do pedido de anfitrião em todas as comunicações do SharePoint no Microsoft 365 para o SharePoint no local contém o URL para o qual o pedido foi originalmente enviado. Para autenticar pedidos de entrada do SharePoint no Microsoft 365, o serviço de Autenticação do SharePoint no local tem de conseguir corresponder este URL em todo o tráfego do SharePoint no Microsoft 365 ao URL público da aplicação Web primária. Essa é a URL externa. Uma vantagem de usar um conjunto de sites nomeado por host para ambientes do SharePoint híbridos é que você pode configurar um conjunto de sites nomeado por host para usar a mesma URL como a URL externa. Isso elimina a necessidade de configurar o Mapeamento de Acesso Alternativo.
O aplicativo Web deve ser configurado para usar a autenticação integrada do Windows usando NTLM.
A autenticação integrada do Windows com NTLM é necessária para aplicativos Web que são implantados em cenários que dão suporte à autenticação de servidor para servidor e à autenticação de aplicativos. Para saber mais, veja Plano de autenticação servidor-para-servidor no SharePoint Server.
Requisitos para configurações de conjuntos de sites específicos
Os conjuntos de sites usados para a funcionalidade híbrida devem atender a todos esses requisitos e também devem existir ou ser criados em um aplicativo Web que atenda aos requisitos de aplicativos Web:
Conjuntos de site nomeados por host
O aplicativo Web deve dar suporte a conjuntos de sites nomeados por host.
Para criar um conjunto de sites nomeado por host, o aplicativo Web deve ser criado para habilitá-los. Você não pode habilitar essa funcionalidade após o aplicativo Web foi criado.
Para obter mais informações sobre como criar uma coleção de sites com o nome de anfitrião, veja Arquitetura e implementação de coleções de sites com nome de anfitrião no SharePoint Server.
Observação
Embora esta seja uma exigência de aplicativo Web, ela é listada aqui por se aplicar somente a ambientes que possuem conjuntos de sites nomeados por host.
Seu servidor DNS local deve ser configurado com DNS de divisão. Tem de criar uma zona de pesquisa para a frente para o domínio da Internet Pública que utilizou para o URL público e um registo A (anfitrião) na zona de pesquisa de reencaminhamento que tem o endereço IP do SharePoint Server e o nome do anfitrião do URL Externo.
Importante
O dispositivo proxy inverso tem de conseguir resolver os nomes de anfitrião nesta zona de pesquisa para reencaminhar pedidos de entrada para o farm do SharePoint Server.
Conjuntos de sites baseados em caminho
Se a URL pública for idêntica à URL externa:
Seu servidor DNS local deve ser configurado com DNS de divisão. Tem de criar uma zona de pesquisa para a frente para o domínio da Internet Pública que utilizou para o URL público e um registo A na zona de pesquisa de reencaminhamento que tem o endereço IP do SharePoint Server e o nome do anfitrião do URL Externo.
Importante
O dispositivo proxy inverso tem de conseguir resolver os nomes de anfitrião nesta zona de pesquisa para reencaminhar pedidos de entrada para o farm do SharePoint Server.
Esse é um modo fácil de configurar um aplicativo Web para um híbrido do SharePoint. O objetivo é fazer a correspondência do campo URL Pública do novo aplicativo Web com a URL do ponto de extremidade público no proxy reverso, que também é conhecido como a URL externa.
Se a URL pública for diferente da URL externa:
Tem de configurar um mapeamento de acesso alternativo (AAM) para reencaminhar pedidos de entrada do SharePoint no Microsoft 365.
Estenda o aplicativo Web principal e use a URL externa como a URL Pública. Em seguida, crie uma URL interna (via Adicionar URLs internas) na mesma zona de segurança que o aplicativo Web estendido para usar como um URL de ponte. Também irá configurar o dispositivo proxy inverso para reencaminhar pedidos de entrada do SharePoint no Microsoft 365 para este URL de bridging.
Lembre-se de que o mapeamento de acesso alternativo (AAM) só é necessário quando estiver a configurar a conectividade de entrada através de uma coleção de sites baseada no caminho com um URL público diferente do URL externo.
Observação
Lembre-se de que a URL externa é a URL do ponto de extremidade voltado para a Internet do dispositivo de proxy reverso.
|
|
Registre sua escolha de estratégia de conjunto de sites na planilha, na linha Estratégia de conjunto de sites da tabela 2. |
Selecionar um aplicativo Web existente ou criar um novo
Você pode usar um aplicativo Web existente ou criar um para usar como o aplicativo Web principal.
Se preferir gerenciar o aplicativo Web usado para a funcionalidade híbrida de forma independente ou se o aplicativo Web existente não atender aos requisitos listados na seção Escolher uma estratégia de conjunto de sites, você deverá criar um novo aplicativo Web.
|
|
Registre sua decisão na linha Aplicativo Web novo ou existente da tabela 2. |
Planejar o uso de um aplicativo Web existente
Se decidir usar um aplicativo Web existente como o aplicativo Web principal, obtenha a URL do aplicativo Web principal e a URL do conjunto de sites de nível superior e liste-as na planilha.
|
|
Registre as seguintes informações na planilha: Dependendo de sua estratégia de conjunto de sites, registre a URL do aplicativo Web principal na linha URL do aplicativo Web principal da Tabela 5a, 5b ou 5c. Se usar um conjunto de sites nomeado por host, registre a URL do conjunto de sites de nível superior na linha URL do conjunto de sites nomeado por host da tabela 5a. |
Planejar a criação de um novo aplicativo Web
Se você decidir criar um novo aplicativo Web, vamos orientá-lo sobre como fazer isso quando você estiver configurando a topologia híbrida.
Planejar Certificados SSL
Os certificados SSL estabelecem a identidade do servidor e fornecem autenticação de certificado para vários serviços e conexões em um ambiente híbrido do SharePoint. Tem de ter dois certificados SSL: um certificado SSL de Canal Seguro e um certificado STS.
Para obter mais informações sobre como os certificados SSL são utilizados em ambientes híbridos do SharePoint, veja Topologia Híbrida do SharePoint 2013: Modelo de Certificado e Autenticação.
Observação
Se optar por ajudar a proteger o farm do SharePoint local com SSL, você também precisará de um certificado SSL para o aplicativo Web principal. Não existem considerações específicas híbridas para este certificado, pelo que pode seguir as melhores práticas gerais para configurar o SharePoint Server com SSL.
Observação
"Canal Seguro" não é uma classe de certificado; utilizamos o termo como uma forma de diferenciar este certificado específico de outros certificados SSL utilizados no ambiente.
Sobre certificados SSL de Canal Seguro
Um certificado SSL de Canal Seguro fornece autenticação e encriptação para o canal de comunicação segura entre o dispositivo proxy inverso e o Microsoft 365, atuando como um servidor e um certificado de cliente. Também verifica a identidade do ponto final de proxy inverso utilizado para publicar a coleção de sites do SharePoint Server no local.
Esse certificado deve ser um curinga ou certificado SAN e ser emitido por uma autoridade de certificação raiz pública. O campo de entidade do certificado deve conter o nome de host do ponto de extremidade externo do servidor de proxy reverso ou uma URL curinga que abranja todos os nomes de host no namespace. Ele deve usar pelo menos a criptografia de 2048 bits.
Importante
Certificados curinga só podem proteger um único nível de um namespace DNS. Por exemplo, se o URL externo for https://spexternal.public.adventureworks.com, o assunto do certificado de caráter universal tem de ser *.public.adventureworks.com, não *.adventureworks.com.
Em cenários em que o SharePoint no Microsoft 365 está configurado para pedir informações ao SharePoint Server, é necessário um certificado SSL para fazer o seguinte:
Criptografar o tráfego através do canal de segurança.
Habilite o dispositivo de proxy reverso para autenticar conexões de entrada usando Autenticação de Certificado.
Permitir que o SharePoint no Microsoft 365 identifique e confie no ponto final externo.
Durante a implementação, irá instalar o certificado SSL no dispositivo proxy inverso e numa aplicação de destino do SharePoint no Arquivo Seguro do Microsoft 365. Isso é configurado durante a configuração da infraestrutura de ambiente híbrido.
Obter um certificado SSL de Canal Seguro
Obtenha um certificado SSL de Canal Seguro ou SAN (Nome Alternativo do Requerente) para o seu domínio público no local a partir de uma autoridade de certificação conhecida, por exemplo DigiCert, VeriSign, Thawte ou GeoTrust.
Observação
O certificado deve dar suporte a vários nomes e deve ter pelo menos 2048 bits. Certificados normalmente expiram em intervalos de um ano. Por isso, é importante planear antecipadamente as renovações de certificados para evitar interrupções do serviço. Os administradores do SharePoint devem agendar um lembrete para a substituição de certificados que lhe dê tempo de início de sessão suficiente para evitar uma paragem de trabalho.
Sobre certificados STS
O certificado STS do farm do SharePoint no local requer um certificado predefinido para validar os tokens de entrada. Num ambiente híbrido do SharePoint, o Microsoft Entra ID atua como um serviço de assinatura de tokens fidedigno e utiliza o certificado STS como certificado de assinatura. Se optar por utilizar um certificado diferente do certificado STS predefinido (por exemplo, um certificado de uma autoridade de certificação pública), substitua o certificado predefinido antes de iniciar o processo de configuração híbrida.
Registre as contas necessárias para configuração e testes
Uma configuração de ambiente híbrido do SharePoint requer várias contas de utilizador no seu Active Directory no local e no diretório do Microsoft 365 (Microsoft Entra ID que é apresentado no diretório do Microsoft 365). Essas contas têm diversas permissões e associações de grupos ou funções. Algumas dessas contas serão usadas para implantar e configurar software e algumas serão necessárias para testar recursos específicos, para ajudar a garantir que os sistemas de segurança e autenticação estão funcionando conforme o esperado.
Vá para Accounts needed for hybrid configuration and testing para obter uma explicação completa das contas de usuário necessárias, incluindo observações sobre o provedor de funções e identidades.
Registe as informações de conta necessárias na folha de cálculo conforme indicado.
Retorne a este artigo de planejamento após concluir esta etapa.
Próximas etapas
Neste momento, deverá ter concluído o preenchimento da folha de cálculo necessária para conectividade de entrada e estar pronto para iniciar o processo de configuração. O próximo passo é escolher um mapa de configuração.