O que o Office 365 Hybrids tem em comum?

Híbridos

Quando digo híbrido, tenho o objetivo de uma cooperação de tecnologias que é proprietária e que pode gerir na sua empresa com aquelas que administramos nos nossos Microsoft Cloud (s).

Esta definição funciona em não apenas no Azure, mas na maior parte das cargas de trabalho no Microsoft 365. Se não souber qual é a carga de trabalho, a caminho é uma aplicação que está a ser executada na Microsoft 365 plataforma de nuvem – o Skype para empresas online, o Exchange Online e o SharePoint Online são exemplos. ' Carga de trabalho ' é uma forma de guardá-los distintos de suas copartes no local, o que é útil para continuar a escrever e a conversar de forma confusa.

As utensílios híbridas utilizam todos os recursos à mão, onde quer que estejam.

Recursos de hardware no local em comum

Todos os híbridos que estou a falar aqui ligam um ambiente de cliente na Internet para Microsoft 365 (e o Azure Active Directory – AAD – em segundo plano, desde que funciona como o diretório para Microsoft 365 ). A infra-estrutura poderá parecer difícil de configurar. Apesar do que pode ter ouvido, este não tem um diploma de "tudo-ology". Na verdade, a maioria dos híbridos funciona da mesma forma com (para a maior parte) os mesmos requisitos de hardware.

A partir de 2016 aqui estão os elementos de que todos os híbridos necessitam. Onde estão as coisas opcionais, vou dizer.

Todas as Microsoft 365 s cargas de trabalho híbridas têm estas boas coisas:

1. Alguns servidores no local (como um farm do SharePoint ou um ambiente do Skype para empresas).

2. O Active Directory no local onde os utilizadores residem ou estão "domésticos" (na terminologia S4B).

3. Um servidor do Azure Active Directory Connect (AAD Connect) (que pode ter sido criado ou combinado com outro servidor, como, por exemplo, WA-P). Esta é representada pelo ícone "sincronizar" porque o AAD Connect é utilizado para sincronizar contas a partir do local para a nuvem num híbrido.

4. [Opcional] Um servidor proxy inverso, que, em todos os exemplos, será o servidor de proxy de aplicação Web (WA-P).

5. [Opcional] Também pode utilizar o servidor de Federação do Active Directory (ou ADFS).

Além disso, os assistentes híbridos estão incorporados em cada carga de trabalho para ajudá-lo a fazer parceria com a sua nuvem, para que possa utilizar todas as ferramentas à sua disposição (onde quer que estejam.

Se não tiver o ADFS, não tem demandas de conformidade que necessite do mesmo e não quer a complexidade adicional, não o utilize. O AAD Connect foi concebido para efetuar a tarefa (e o intervalo de duplicação está inativo de aproximadamente 3 horas para 30 minutos, o que é um aprimoramento útil para fazer).

Muitas empresas de grande porte têm alguns destes servidores no local. Muitos têm controladores de domínio do Active Directory ou podem ter servidores ADFS. Se estiver a pensar em configurar uma pessoa híbrida, poderá querer consultar outros administradores para saber quais os recursos no local que já estão no local. Irá ajudá-lo a determinar se pretende utilizar partes de infraestrutura existentes ou novas.

O que são estes servidores?

Pule esta secção se já souber o que estes servidores estão a fazer.

A maioria das pessoas estão habituadas às operações do Active Directory (AD) – como enumera os utilizadores e os objetos num domínio ou floresta (entre outras coisas) e, no caso do híbrido, é uma base para os utilizadores que serão replicados para a nuvem da Microsoft. As tarefas da sincronização (AAD Connect), ADFS e WA-P (o nosso exemplo de proxy inverso) são um pouco mais recentes e mais central para processar pedidos e identidades HTTPS híbridos, por isso vamos falar sobre os mesmos.

ADFS

Para rever, a tarefa dos serviços de Federação do Active Directory é ajudar os dois lados do híbrido a reconhecer um ao outro e, por isso, o Microsoft 365 é conhecer e confiar no serviço ADFS (ou no cluster ADFS) a que um nome de domínio público verificado pertence. Isto permite um início de sessão único. Isto significa que, quando os utilizadores com um UPN associado são apresentados para autenticar os recursos online, Microsoft 365 irá saber o respectivo UPN e o servidor ADFS específico para o qual os utilizadores lhe podem autenticar. Quando o Heidi@contoso.com percorre o processo de início de sessão do Exchange Online, Microsoft 365 irá enviar um pedido para o seu local, de modo a que o ADFS possa interferir na autenticação e confirmar que a pessoa alega ou negar o mesmo. Isto pode acontecer rapidamente se a rede e a configuração permitirem. O ADFS é utilizado se pretender aproveitar o início de sessão único: quando os utilizadores iniciarem sessão numa sessão de ADFS, o servidor ADFS interceptará todos os outros pedidos de autenticação (tal como acontece ao alternar entre cargas de trabalho, por exemplo) para lembrá-lo Microsoft 365 de que ainda está a dizer que está. Uma vez que alguns departamentos de ti têm definições de segurança de conformidade ou de informações que necessitam de palavras-passe no local e alguns não, o ADFS é opcional.

Proxy inverso

Web Access-proxy é um proxy inverso (RP) incorporado nos sistemas operativos do Windows Server desde o 2012 R2 lançado. Um proxy inverso significa o seu ponto de saída para agir em nome do seu farm. Tem um "lado" que enfrenta a Internet e conhece o nome de domínio público do seu Microsoft 365 híbrido e um "lado" que enfrenta a sua rede de intranet ou de perímetro e conhece o nome de domínio dos seus recursos internos (como o URL do seu site do SharePoint, por exemplo). O adquirente intercepta todas as solicitações que chegam à sua empresa e permite-lhe bloquear portas, limitar o tráfego que irá aceitar da Internet e ocultar os endereços e URLs internos da sua rede a partir do mundo exterior. Tal como o RPs, é um proxy para servidores internos na sua rede sempre que os utilizadores fora da rede tentam aceder a um recurso.

Os híbridos do SharePoint 2013 utilizam um proxy inverso como WA-P para interceptar o tráfego de entrada (de utilizadores no SPO fazer consultas com um índice de pesquisa no local no caso de Federação de pesquisa), mas como os híbridos da nuvem do SharePoint 2016 colocam o índice completo na nuvem, o botão a nova geração já não precisa de uma (que é a única razão pela qual está marcada como opcional nos diagramas). Mas o SharePoint 2013 não é o único local onde verá um proxy inverso utilizado para interceptar o tráfego não solicitado proveniente da Internet. O Skype para empresas 2016 utiliza uma com a sua configuração de periféricos e o Exchange 2016 também utiliza uma na sua margem. Uma vez que algumas situações exigem, WA-P é opcional.

Sincronizar

O gráfico que utilizo mostra "sincronizar" para o Azure Active Directory Connect. Na verdade, a sincronização efetuada por AAD Connect envolve o tráfego contínuo de utilizadores e/ou informações de utilizador do seu local e para a nuvem. O AAD Connect pode fazer duas coisas: Replica contas de utilizador para o Microsoft 365 (replicação) e pode sincronizar as informações de palavra-passe no Microsoft 365 (não está a sincronizar a palavra-passe, mas um hash não reversível que representa a palavra-sincronização). Não tem de "sincronizar a sua palavra-passe", mas esta sempre sincroniza (Replica) as suas contas de utilizador a partir do Active Directory (ou algumas versões filtradas do seu diretório de utilizadores no local)!

O AAD Connect funciona com controladores de domínio íntegros no seu domínio do Active Directory para permitir o "mesmo início de sessão", em vez do "início de sessão único" do ADFS. O mesmo início de sessão significa que, em vez de iniciar uma sessão única e ter o ADFS interveniente para todos os pedidos para a sua sessão, iniciará sessão com a mesma palavra-passe de local (e, provavelmente, selecione a opção para se manter o seu início de sessão para reduzir o número de pedidos que resultado da navegação em múltiplas cargas de trabalho). O AAD Connect para sincronização não é opcional.

Internet e peças híbridas disponíveis na Internet em comum

Oposto aos servidores no local no seu Microsoft 365 híbrido e na Internet é a nuvem da Microsoft, onde, independentemente da carga de trabalho do Microsoft 365, irá utilizar algumas tecnologias familiares. Isto dá-se:

• Registos DNS públicos

• Autoridades de certificação públicas

• Azure Active Directory (AAD)

• Microsoft 365 (licenças/sub-rotinas) e Microsoft 365 assistentes híbridos

• Uma relação de confiança de servidor para servidor (S2S)

• Tráfego de encaminhamento e/ou de Internet expresso

• Módulos do PowerShell

Os registradores de DNS públicos, como o GoDaddy, gerenciam e permitem o registo de nomes de domínio. Se pretender utilizar híbrido, terá de registar um nome de domínio com DNS público (isto já pode ter sido feito por si em grandes empresas). Este nome de domínio será adicionado ao Microsoft 365, o que também irá verificar que é o proprietário do nome de domínio público que adicionar.

Tradicionalmente, este nome de domínio público é o mesmo que o UPN do Active Directory associado a utilizadores híbridos no local, mas não se preocupe com este detalhe. Com o advento do atributo "onpremisessecurityidentifier" no PowerShell, que mapeia a identidade para o SID no local, a correspondência do domínio registado no Microsoft 365 com o UPN dos utilizadores no local não é mais crucial tal como estava. É mais importante saber que irá necessitar de um nome de domínio público que possa comprovar, este nome de domínio público será registado no Microsoft 365 e irá representar a sua presença Microsoft 365 em qualquer lado da ligação híbrida.

As autoridades de certificação públicas dão-lhe certificados SSL/TLS fidedignos para encriptar o seu tráfego de rede. Em todas as cargas de trabalho, as comunicações híbridas ocorrem através de uma ligação encriptada. Irá necessitar de um certificado de uma autoridade de certificação pública na Internet. O recebimento de certificados SSL/TLS é uma prática padrão e, normalmente, são processados processos de certificados públicos em grandes empresas para facilitar isto. Em pequenas empresas, poderá ter de consultar a sua pessoa de ti, Microsoft 365 documentação e o seu ISP.

O Azure Active Directory ou o Azure AD está em segundo plano quando sincroniza/replica os utilizadores a partir do seu local para a sua subscrição do Microsoft 365 (a sua empresa). É o mesmo Active Directory utilizado no Azure mais largo. Eficaz e misturado de forma transparente para Microsoft 365. Irá gerir os seus utilizadores e licenças de utilizador neste directório. A gestão de licenças no Microsoft 365 não é concluída automaticamente por qualquer assistente híbrido. As licenças custam dinheiro para os clientes, por isso, a decisão de quem e quantas licenças Get não são efetuadas automaticamente.

aMicrosoft 365 é completamente uma metade do seu híbrido. Tem assistentes híbridos online por carga de trabalho. Isto não é muito eficiente, mas esta é a forma como o híbrido funciona a partir de 2016 (ou, em outras palavras, a partir do lançamento do SharePoint Server 2016, do Exchange Server 2016 e do Skype para empresas Server 2015, no local). Mas esta não é a forma mais simples de configurar todos os elementos numa forma híbrida. Um único assistente híbrido que permitia que os clientes escolhessem as cargas de trabalho a tornar híbridas e que o processo por carga de trabalho, bem como um centro de comandos híbrido, um Dashboard administrativo do Microsoft 365, que poderia comunicar se as tecnologias utilizadas por todos os híbridos e/ou já estão em vigor ainda não existem.

O que é que isto significa? Significa que todos os assistentes realizam os mesmos passos e muitas vezes mais do que uma vez. Todos os assistentes ativam o OAuth (confiança S2S) por exemplo (falaremos sobre o OAuth mais tarde). Alguns assistentes, como, por exemplo, o seletor híbrido da carga de trabalho do SharePoint Online, instalam o OAuth independentemente do botão que clicar (para todas as seleções que fizer), se o OAuth é necessário para o seu cenário híbrido. Outros assistentes, como, por exemplo, o assistente do Exchange híbrido, configurou o OAuth em segundo plano e apenas uma vez.

Uma confiança S2S não precisa de cruzar a Internet, mas, no caso de híbrido, esta confiança tem de. Um S2S não é como uma confiança de domínio ou floresta. Não existem grandes quantidades de portas a abrir e nenhuma integração mais profunda para criar entre diretórios ativos. O S2S compila uma ligação fidedigna entre o seu farm do SharePoint no local e uma parte da nuvem de Microsoft 365 denominada serviço de controlo de acesso ou ACS (um servidor de autorização). A confiança baseia-se em um certificado SSL/TLS que aprova os tokens emitidos em nome dos utilizadores, que o seu local e o Microsoft 365 ACS concordam que são fidedignos – pense nisso como um grande cinco entre o SharePoint local (e o serviço de proxy do ACS) e o ACS do Azure para todos os utilizadores válidos que acedam ao serviço. A comunicação de identidades de utilizador (a razão desta confiança) é feita através de HTTP/443.

Os híbridos podem utilizar certificados auto-assinados ou públicos aqui. Muitas empresas de grande porte irão escolher os certificados públicos devido aos seus padrões do InfoSec – em grande parte porque o tráfego cruza/pode cruzar a Internet, um segmento não fidedigno. Para o SharePoint híbridos, este certificado pode ser um novo certificado auto-assinado ou um que tenha sido extraído do certificado de assinatura de tokens STS no local. (Se tiver utilizado um novo certificado (público ou auto-assinado) num SharePoint híbrido, tem de substituir o certificado de assinatura de tokens STS do SP em todos os nós no farm do SharePoint.)

O tráfego num híbrido deixa uma empresa/organização do cliente, cruza a Internet e entra na nuvem Microsoft Organization/Microsoft Microsoft 365. Existe uma forma de ignorar este segmento não fidedigno e não controlado e isto é através de um fornecedor de terceiros baseado na sua empresa ou organização na nuvem Microsoft 365. O Route Express ignora a Internet ao oferecer uma ligação de rede remota privada à nuvem da Microsoft. No entanto, é importante ter em conta que, em casos em que a WAN sofre uma falha, o fallback continua a ser a Internet.

Todos os híbridos utilizam os módulos do PowerShell para partes de gestão ou configuração. É provável que a maioria dos módulos que irá necessitar inclua o Assistente de início de sessão do Microsoft Online Servicese o módulo Azure Active Directory para Windows PowerShell. Pode preparar os servidores para a configuração e gestão dos seus híbridos com antecedência ao instalar estes módulos do PowerShell utilizados frequentemente.

Portas e protocolos em comum

Os híbridos são 1/2 o seu no local e o 1/2 Microsoft 365 (Azure SaaS ou PaaS híbridos não são abordados neste documento). É muito provável que ambas as metades sejam executadas em HTTPs, mas, no mínimo, o Microsoft 365 metade é 100% https/Encrypted por certificados TLS e significa que é executado através da porta padrão 443. Terá de certificar-se de que um certificado público está associado ao tráfego que sai do seu ponto de saída. Ou seja, terá de instalar um certificado no computador que está a falar na extremidade da sua rede – este tráfego será executado sobre o 443 e será encriptado.

Todos os híbridos irão utilizar o 443 (HTTPS) e o 53 (DNS), por predefinição, para o tráfego híbrido. Alguns vão utilizar portas adicionais, como a porta 25 (SMTP). Mas o caso mais complexo em cargas de trabalho híbridas para portas é o Skype para empresas. Felizmente, as portas estão documentadas.

O protocolo standout utilizado por todos os híbridos (separados de benchmarks utilizados para a pesquisa DNS, o tráfego HTTPS, o SMTP e outros padrões) é o OAuth (autorização aberta), que também é utilizado na biblioteca de autenticação do Active Directory. É utilizado quando um recurso de servidor de um lado da ligação tem de agir em nome de um utilizador para aceder a recursos noutro servidor, em geral, na nuvem. É um meio pelo qual o nível de acesso do utilizador a um ficheiro ou recurso pode ser mensurado para um utilizador autenticado. Isto também é denominado "autenticação moderna" (apesar de o OAuth referir-se a autorização).

Todas as cargas de trabalho utilizam o OAuth/S2S quando num híbrido (embora não seja para todas as funcionalidades híbridas). Os assistentes híbridos normalmente configuram este protocolo útil automaticamente. No entanto, não existe unificação deste esforço em todas as cargas de trabalho, sem qualquer relatório do estado do OAuth para o cliente e sem uma forma centralizada de gestão deste recurso universal a partir do 2016.

Em alguns casos, os assistentes híbridos tornam o OAuth ativado quando não é necessário (tal como quando o OneDrive para empresas é ativado para o OneDrive para empresas reencaminhar para a nuvem) ou em todas as seleções de uma opção híbrida no assistente (novamente, consulte o seletor do SharePoint híbrido) ou mesmo fora do seletor híbrido em scripts de configuração personalizados, como a pesquisa híbrida na nuvem.

Tabela de elementos comuns em Microsoft 365 híbridos

Agora, temos uma lista de elementos comuns que tem o seguinte:

Por fim, em todas as cargas de trabalho, o objetivo é que os utilizadores tenham o mesmo limite de limites, para que possamos simplificar duas das funções mais importantes que um híbrido faz – calcular a identidade do utilizador e o que a pessoa tem permissão para fazer com as informações que ela tem permissão para ver.

Uma nota em "opcional"

Alguns destes elementos estão definidos como "Optional", mas como irá saber se são necessários? Alguns elementos em Microsoft 365 híbridos são verdadeiramente opcionais ou não opcionais ao longo do quadro:

Dentro de um híbrido funcional, existem outras funcionalidades que se enquadram numa área de cinzento. Provavelmente, a mais importante é a confiança S2S/OAuth. Esta confiança é criada por todos os assistentes híbridos criados dentro da Microsoft e a relação de confiança é incorporada por predefinição, mesmo quando não é necessária, para a "verificação híbrida" futura. Depois de entrar no modo híbrido através de um assistente, esta funcionalidade será ativada. Mas (como vimos anteriormente), este não é atualmente utilizado em todos os casos.

É necessário um proxy inverso (WA-P no nosso exemplo) sempre que existir um pedido não solicitado recebido à organização do cliente para obter dados ou informações (como, por exemplo, ao utilizar o BCS híbrido, ao publicar o Office Web Apps ou o Office Online Server para a pré-visualização do documento na pesquisa resultados). Também é necessário ao publicar um ponto final num DMZ da sua empresa, tal como quando o Exchange utiliza WA-P como um proxy ADFS (por isso, se estiver a utilizar o ADFS num Exchange híbrido, vai necessitar de WA-P).

São necessárias extremidades para manter canais de comunicação consistentes para conversas em curso no Skype para empresas híbrido e pode ser utilizado para encaminhar o tráfego SMTP para a rede a partir de um perímetro num Exchange híbrido. Tal como discutido, o ADFS é utilizado para o início de sessão único.

Existem tabelas similares para o S2S, tal como esta tabela para servidores SharePoint em configurações híbridas. As tabelas como esta podem ser criadas com a lógica do protocolo S2S, que é utilizada quando um recurso de servidor de um lado da ligação híbrida tem de agir em nome de um utilizador para aceder a recursos noutro servidor na nuvem.

* O selecionador híbrido do SharePoint irá continuar a ativar o OAuth, mas isto é para as futuras configurações híbridas futuras.