Visão geral
Algumas pessoas me perguntam se é possível utilizar o Office 365 com usuários criados em meu AD DS local. Bom, a resposta é sim. É possível utilizar uma estrutura local para servir como fonte de dados de objetos para a autenticação do Office 365.
Para tal, será necessário criar e refinar uma estrutura de AD FS utilizando o Microsoft Windows Server. O AD FS é uma das principais ferramentas dentro do mundo cloud e tem ganho cada vez mais adeptos. Esta solução (quando bem configurada), permite a implementação de logon único em inúmeros serviços. O AD FS sincronizada com a nuvem e mantem a estrutura e segurança do AD por meio de um túnel seguro. O AD FS não é exatamente uma novidade e esta presente tanto no Windows Server 2012 quanto no Windows Server 2016 (inclusive são assuntos de prova MCSA).
Falando em Office 365 e o AD FS (configuração de ambiente em nuvem_, podemos citar aqui o Live AD FS. O Serviço de Federação deve implantar uma nova infraestrutura do AD FS sob versão 2.0 para fornecer acesso dos usuários do Active Directory, que estejam conectados a computadores localizados fisicamente na rede corporativa ou que estejam conectados remotamente ao mundo corporativo.
A rede com acesso de logon único de serviços do Office 365 utiliza credenciais de domínio corporativo com grande facilidade. Depois de implantar o ambiente de produção do AD FS 2.0 no local, será preciso estabelecer uma relação de confiança da parte confiável entre o farm de servidores de federação do AD FS 2.0 e o Office 365. Essa confiança da parte confiável funciona como um canal seguro onde os tokens de autenticação podem passar entre sua organização e o Office 365 facilitando o acesso de logon único.
A versão 2.0 do AD FS (presente já no Windows Server 2012) oferece suporte à virtualização de software das funções de servidor de federação e proxy de servidor de federação.
Devo ainda ressaltar que os certificados digitais correlatos ao AD FS, desempenham o papel mais importante na proteção de comunicações entre servidores de federação, proxies de servidor de federação, Office 365 e clientes web. Os requisitos para certificados variam, dependendo de diversas configurações e arquiteturas. A dependência fica relacionada ao desenho de arquitetura das soluções.
Arquitetura ADFS
A arquitetura principal do AD FS requer uma instância do Active Directory (AD) ou do Modo de Aplicativo do Active Directory (ADAM) que contenha credenciais de usuário; lembrando que o ADFS não substitui o repositório de conta existente; em vez disso, amplia a visibilidade do repositório para outras organizações de maneira altamente controladora.
O AD FS é um serviço baseado em token de segurança, utilizado principalmente para compilar instruções sobre a conta de usuário em formato de tokens de segurança. Para aplicativos personalizados, o ADFS também preenche declarações, que são instruções sobre a entidade de segurança (por exemplo, nome de usuário, título do usuário).
Aplicativos desenvolvidos para a Web verificam o nível de acesso que deve ser dado ao usuário solicitante. O AD FS também gerencia as relações de confiança de federação compartilhadas com os serviços federados de outras organizações.
Uma relação de confiança de federação não é a mesma coisa que uma relação de confiança de floresta; em vez disso, é uma relação de confiança especial que usa certificados para assinatura de tokens entre organizações. Uma relação de confiança de floresta fornece dados de controladores de domínio a cada uma das pontas, já relações de confiança baseadas em federação utilizam tokens e um alto nível de restrições.
A floresta confiante não pode utilizar a relação de confiança de federação para consultar informações sobre objetos e contas dentro da floresta que oferta a confiança. Quem efetua a leitura ve somente aquilo que foi determinado e não a estrutura inteira da floresta.
A única informação que a confiança sempre vê é quando usuários específicos tentam acessar os serviços Web em sua floresta e, em seguida, vê apenas as informações de conta designadas como apropriadas para essa relação.
Servidores de serviços federados em diferentes organizações nunca se comunicam entre si e toda comunicação ocorre por meio do cliente solicitante. Isso significa que as portas que precisam ser abertas para um trust de domínio típico não são necessárias para uma confiança federada. Menos portas abertas significa uma redução da superficie de ataques e menos portas a se monitorar.
A criação da confiança federada é feita com out-of-band apenas com o certificado de assinatura para o lado da conta de confiança necessária em ambas as extremidades, que pode ser enviada por email ou gravada na mídia e enviada via operadora. Toda comunicação do cliente é via HTTP Secure (HTTPS, porta 443).
Logon único
O logon único, também conhecido como federação de identidades, permite que você e seus usuários acessem serviços no Microsoft Office 365 para empresas com credenciais corporativas do Active Directory. Sem o logon único, você, o administrador de redes e seus usuários precisarão manter nomes de usuário e senhas separados para suas contas on-line e locais.
O logon único do Office 365 (pelo menos até os dias atuais) requer o AD FS em sua versão 2.0 e a sincronização do Active Directory. Quando você configura o logon único, estabelece uma relação de confiança entre o AD FS 2.0 e o Office 365. Os usuários do Active Directory local obtêm tokens de autenticação do AD FS 2.0 que redirecionam as solicitações dos usuários por meio da confiança da terceira parte confiável. Isso permite que seus usuários acessem o Office 365 sem precisar entrar com credenciais diferentes.
Requisitos para logon único
Para utilizar as maravilhas do logon único será necessário ter o Active Directory implantado e em execução. Você pode utilizar controladores de domínio Windows Server 2003, 2008, 2008R2, 2012, 2012R2 ou 2016, desde que com um nível funcional de modo misto ou nativo.
Planeje com muito cuidado todo o processo de implantação o AD FS 2.0 no em qualquer versão de sistema operacional que possua antes de levar as configurações a produção. Além disso, se o usuário estiver se conectando de fora da rede de sua empresa, será necessário implantar o proxy do AD FS 2.0. É necessário refinar as necessidades antes de efetuar a implantação completa.
Antes de implantar o AD FS em uma relação de terceira parte com o Office 365, será necessário validar em sua infraestrutura de redes os seguintes itens:
1. Requisitos de Software.
2. Requisitos de certificado
3. Requisitos de rede.
O AD FS 2.0 pode ser instalado em qualquer servidor que esteja preparando para a função de servidor de federação ou proxy de servidor de federação.
Plataforma de instalação: Windows Server 2008, 2012, 2012R2 e 2016.
Durante o processo de instalação do AD FS 2.0, o assistente de instalação tenta verificar automaticamente a necessidade para instalar os aplicativos de pré-requisitos e os hotfixes dependentes. O próprio assistente faz uma verificação da lista de dependências durante o processo de instalação.
Na grande maioria dos casos, o assistente fará a instalação de todos os aplicativos obrigatórios necessários para o AD FS 2.0 funcionar corretamente. Recomendo no entanto que seja verificado antes se o .NET 3.5 SP1 está instalado nos servidores que executam o Windows Server antes de instalar o software do AD FS 2.0, pois trata-se de um pré-requisito.
Certificados
Com o intuito de proteger a comunicação entre servidores de federação, proxies de servidor de federação, Office 365 e clientes da web, o AD FS 2.0 requer um certificado SSL ao definir as configurações do servidor de federação.
Trata-se de um certificado padrão SSL utilizado para proteger as comunicações entre servidores de federação, clientes e computadores proxy do servidor de federação. É exigido que esse certificado não contenha um nome de assunto sem ponto (nome curto).
Como esse certificado deve ser confiável para clientes do AD FS 2.0, é possível utilizar um certificado SSL emitido por uma autoridade de certificação pública (de terceiros) ou por uma autoridade de certificação subordinada a uma raiz publicamente confiável.
Conclusão
Este post segue a linha de anotações sobre um determinado assunto, para analistas que recebem a missão de integrar sua estrutura on premisses com o Office 365. Espero ter ajudado com sua missão.
Forte abraço e sucesso.