Exportar (0) Imprimir
Expandir Tudo

Gerenciar identidades para ambientes híbridos de floresta única usando a autenticação local

Publicado: janeiro de 2014

Atualizado: agosto de 2014

Aplica-se a: Windows Server 2012 R2

Usuários corporativos querem ser capazes de usar aplicativos que residam na nuvem de qualquer lugar e em qualquer dispositivo, mas eles não podem porque não têm uma maneira de se autenticar. A TI corporativa deseja ser capaz de permitir que os usuários se autentiquem nesses aplicativos em nuvem e também deseja a capacidade de controlar em tempo real quem pode acessar esses aplicativos.

Este guia apresenta diretrizes prescritivas sobre como integrar um diretório local a um diretório de nuvem para que os usuários possam acessar facilmente aplicativos que residam na nuvem de qualquer lugar e em qualquer dispositivo. Isso é feito usando-se a autenticação local. Para obter um exemplo de como usar a autenticação de nuvem, consulte Gerenciar identidades para ambientes híbridos de floresta única usando a autenticação de nuvem.

Problema local

Neste guia de solução:

Esta seção descreve o cenário, a instrução do problema e as metas de um exemplo de organização.

A organização é uma empresa de grande porte com escritórios em todo o mundo, inclusive nas Américas do Norte e do Sul, Europa e Ásia. As equipes de pesquisa e desenvolvimento (R&D) trabalham principalmente na América do Norte e na Europa. Elas desenvolvem fórmulas que serão usadas pelos centros de fabricação localizados principalmente na Ásia.

As equipes de R&D trabalham bem próximas durante o desenvolvimento de novas fórmulas ou o aprimoramento das já existentes. Isso é feito com a realização de testes semelhantes, padronizados, em instalações na América do Norte e na Europa e, em seguida, o compartilhamento dos resultados. Em seguida, os resultados são finalizados e novas fórmulas são desenvolvidas. Essas fórmulas são consideradas segredos comerciais e são patenteadas. Depois que esse processo é concluído, as fórmulas são enviadas para as instalações de fabricação para iniciar a produção.

Atualmente, se um membro da equipe de R&D deseja compartilhar resultados com colegas em outra parte da empresa ou deseja enviar uma fórmula para uma das instalações na Ásia, a equipe usa o Encrypting File System (EFS) para criptografar e enviar os arquivos por email. Em seguida, a pessoa na outra extremidade descriptografa os arquivos.

A organização tem vários problemas com o processo atual:

  • Privacidade: Os dados são transferidos por email e, embora cheguem criptografados, eles ainda são suscetíveis a hackers pela Internet. Além disso, muitos funcionários estão acessando o email em seus próprios dispositivos e não há nenhuma garantia de que esses dispositivos sejam seguros.

  • Integridade: O certificado EFS usado para criptografar arquivos do EFS deve ser exportado e enviado para o destino. Os usuários estão usando o email para enviar esses certificados, o que pode violar a integridade do certificado.

  • Confidencialidade: O mesmo certificado costuma ser usado para criptografar os resultados do teste e as fórmulas. Funcionários nas instalações de produção terrão a capacidade de descriptografar esses resultados, se receberem uma cópia deles por engano.

Para solucionar esses problemas, a organização optou por configurar o Office 365 SharePoint na nuvem e usá-lo como seu portal no compartilhamento dos resultados de teste e das fórmulas. No entanto, a organização deseja usar o Active Directory local como o provedor de autenticação e não deseja usar a autenticação de nuvem.

Atualmente, a organização tem um provedor de autenticação, o Active Directory local, mas esse provedor é incapaz de autenticar funcionários no momento nos novos sites do Office 365 SharePoint que serão hospedados no Azure.

O problema geral que organização deseja resolver é:

Como um ou arquiteto de sistema ou um administrador de TI, como você pode oferecer aos usuários uma identidade em comum durante o acesso a recursos locais e baseados em nuvem? E como é possível gerenciar essas identidades e manter as informações sincronizadas entre vários ambientes sem o uso excessivo de recursos de TI?

Oferecer acesso aos sites do SharePoint da organização exigirá a capacidade de autenticar os funcionários com um provedor de autenticação, a instância local do Active Directory. Além disso, a organização deseja restringir o acesso a apenas os funcionários de R&D e fabricação que exigem acesso aos sites. Atualmente, eles são os únicos que precisam acessar os sites.

Depois de ter examinado as opções, você determinou ser possível aproveitar a instância existente dos Serviços de Federação do Active Directory (AD FS) para usar a autenticação local com o Azure. A organização configurou o AD FS há muitos anos. Isso economizará tempo e dinheiro porque a equipe de TI já está familiarizada com o uso do AD FS.

A gerência autorizou a compra de assinaturas do Office 365 e do Azure. Agora cabe aos administradores do Active Directory configurar a instância do AD Azure e federá-la com o Active Directory local.

Os administradores do Active Directory precisam ser capazes de aproveitar o Active Directory local para preencher a instância do Azure AD. Os administradores do Active Directory devem ser capazes de fazer isso rapidamente. Em seguida, os administradores do Active Directory precisarão federar a instância local do Active Directory com o Azure AD. Além disso, a organização deseja que os funcionários que acessarão os sites do SharePoint tenham uma experiência de logon verdadeiramente único e só possam acessar os sites quando conectados à rede corporativa. A organização não deseja que esses sites sejam acessados em computadores ou dispositivos externos. A organização gostaria de ter a capacidade de desabilitar rapidamente um usuário em caso de uma separação, de forma que o usuário não possa acessar o site do SharePoint após a conta ter sido desabilitada. Por fim, a organização gostaria de poder personalizar a página de logon para que os usuários soubessem que estão fazendo logon em um site corporativo.

As metas da organização para a solução de identidade híbrida são:

  • Capacidade de configurar rapidamente a sincronização com a instância local do Active Directory.

  • Capacidade de controlar quem e o que é sincronizado com o Azure AD.

  • Capacidade de oferecer logon único (SSO). Os alertas serão recebidos se a sincronização ou o SSO estiver desativado

  • Capacidade de restringir o acesso a apenas os usuários de R&D e que estão fazendo logon em um local seguro.

  • Capacidade de evitar o acesso do usuário em tempo real aos recursos da nuvem em caso de uma separação.

  • Capacidade de limpar e gerenciar rapidamente sistemas de identidade local para que eles possam ser a fonte do Azure AD.

  • Capacidade de personalizar a página de logon para que ela apresente uma identidade corporativa.

Esta seção descreve o design de solução que aborda o problema descrito na seção anterior e apresenta considerações de planejamento de alto nível para esse design.

Usando o Azure AD, a organização é capaz de integrar a instância local do Active Directory à instância do Azure AD. Essa instância será usada para redirecionar usuários para a página de logon do AD FS onde eles receberão um token que, em seguida, é apresentado ao Azure AD e a autenticação é concedida.

Solução local

A tabela a seguir lista os elementos que fazem parte do design da solução e descreve o motivo da escolha do design.

 

Elemento de design da solução Por que isso está incluído nesta solução?

Ferramenta de sincronização do Active Directory do Azure

É usada para sincronizar objetos do diretório local com o Azure AD. Para obter uma visão geral dessa tecnologia, consulte Mapa da sincronização do diretório.

Serviços de Federação do Active Directory

Um recurso do Windows Server 2012 R2 que é um serviço de token de segurança (STS) que usa o Active Directory como seu repositório de identidades. O STS no AD FS pode emitir tokens de segurança para o chamador usando vários protocolos, inclusive OAuth, WS-Trust, WS-Federation e Security Assertion Markup Language (SAML) 2.0. Para obter uma visão geral dessa tecnologia, consulte Visão geral dos Serviços de Federação do Active Directory.

Ferramenta de correção de erros IdFix DirSync

Oferece aos clientes a capacidade de identificar e corrigir a maioria dos erros de sincronização de objeto nas florestas do Active Directory. Para obter uma visão geral dessa tecnologia, consulte Ferramenta de correção de erros IdFix DirSync.

AD FS é um recurso do Windows Server 2012 R2 que permite a federação entre o Active Directory local e o Azure AD. Esse recurso permite que os usuários façam logon nos serviços do Azure AD (como Office 365, Intune e CRM Online) usando uma experiência de SSO. Isso dará aos usuários a possibilidade de ter SSO que usa a instância do Active Directory local como o provedor de autenticação.

A ferramenta de correção de erros IdFix DirSync pode ser usada para realizar a detecção e a correção de objetos de identidade e seus atributos em um ambiente do Active Directory local em preparação para a migração. Isso permitirá identificar rapidamente qualquer problema que possa ocorrer com a sincronização antes de iniciá-la. Usando essas informações, você pode fazer alterações no ambiente de forma que você possa evitar esses erros.

Esse design é recomendado porque abrange as metas de design da organização. Ou seja, há duas maneiras de oferecer autenticação aos recursos baseados no Azure: por meio da autenticação de nuvem ou da autenticação local usando um STS.

Uma das principais preocupações da organização é que eles têm a capacidade em tempo real de parar um usuário que foi separado da corporação de acessar os recursos baseados na nuvem. Existe um atraso de até três horas associado ao uso da ferramenta de sincronização do Active Directory do Azure e à autenticação de nuvem. Ou seja, se você desabilitar uma conta do usuário local, pode levar até três horas para essa alteração ser exibida no Azure. Isso não acontecerá se o usuário precisar voltar ao ambiente local e se autenticar. Se uma conta do usuário for desabilitada local, esse usuário não poderá receber um token e não será autorizado a acessar os recursos de nuvem.

A organização deseja a capacidade de fornecer SSO. Isso só pode ser feito federando-se a instância local do Active Directory ao Azure AD.

A capacidade de personalizar a página de logon só está disponível por meio do AD FS e da personalização do AD FS.

É possível usar as etapas nesta seção para implementar a solução. Não se esqueça de verificar a implantação correta de cada etapa antes de passar à próxima etapa.

  1. Preparar-se para logon único (SSO)

    Para se preparar, você deve se certificar de que o ambiente atenda aos requisitos de SSO e verifique se o locatário do Active Directory e do Azure AD estão configurados de forma que seja compatível com os requisitos de SSO. Para obter mais informações, consulte Preparar-se para logon único.

  2. Configurar o serviço de token de segurança local — AD FS

    Depois de preparar o ambiente para SSO, você precisará configurar uma nova infraestrutura do AD FS local para dar aos usuários do Active Directory locais e remotos acesso SSO ao serviço de nuvem. Se tiver o AD FS no ambiente de produção, você poderá usá-lo na implantação de SSO em vez de configurar uma nova infraestrutura, desde que ele seja compatível com o Azure AD. Para obter mais informações sobre como começar a configurar um STS do AD FS, siga as etapas indicadas na Lista de verificação: Use o AD FS para implementar e gerenciar o logon único.

  3. Instalar o Windows PowerShell para logon único com o AD FS

    O módulo AD Azure do Windows PowerShell é um download para o gerenciamento de dados da organização no Azure AD. Esse módulo instala um conjunto de cmdlets no Windows PowerShell que você executa para configurar o acesso SSO ao Azure AD e, em seguida, a todos os serviços de nuvem nos quais você está inscrito. Para obter mais informações, consulte Instalar o Windows PowerShell para logon único com o AD FS.

  4. Configurar uma relação de confiança entre o AD FS e o Azure AD

    Você precisa estabelecer uma relação de confiança entre o Azure AD e o Active Directory local. Cada domínio que você deseja federar deve ser adicionado como um domínio de logon único ou convertido para um domínio de logon único a partir de um domínio padrão. Adicionar ou converter um domínio configura uma relação de confiança entre o AD FS e o Azure AD. Para obter mais informações, consulte Configurar uma relação de confiança entre o AD FS e o Azure AD.

  5. Preparar a sincronização de diretórios

    Verifique os requisitos de sistema, crie as permissões corretas e possibilite as considerações de desempenho. Para obter mais informações, consulte Preparar a sincronização de diretórios. Depois de concluir esta etapa, verifique se que você tem uma planilha preenchida, mostrando as opções de design da solução selecionadas.

  6. Ativar a sincronização de diretórios

    Ative a sincronização de diretórios para a empresa. Para obter mais informações, consulte Ativar a sincronização de diretórios. Depois de concluir esta etapa, verifique se os recursos estão configurados.

  7. Configurar o computador de sincronização de diretórios

    Instale a ferramenta de sincronização do Azure AD. Se você já a instalou, saiba como atualizá-la, desinstalá-la ou movê-la para outro computador. Para obter mais informações, consulte Configurar o computador de sincronização de diretórios. Depois de concluir esta etapa, verifique se os recursos estão configurados.

  8. Sincronizar os diretórios

    Realize uma sincronização inicial e verifique se os dados estão sincronizados com êxito. Você também aprenderá a configurar a ferramenta de sincronização do AD Azure para configurar a sincronização recorrente e forçar a sincronização de diretórios. Para obter mais informações, consulte Usar o assistente de configuração para sincronizar os diretórios. Depois de concluir esta etapa, verifique se os recursos estão configurados.

  9. Ative os usuários sincronizados

    Ative os usuários no portal do Office 365 para que eles possam usar os serviços os quais você assinou. Isso envolve a atribuição de uma licença de uso do Office 365 a eles. É possível fazer isso individualmente ou em massa. Para obter mais informações, consulte Ative os usuários sincronizados. Depois de concluir esta etapa, verifique se os recursos estão configurados. Esta é uma etapa opcional e só será necessária se você estiver usando o Office 365.

  10. Verifique a solução.

    Depois que os usuários forem sincronizados, teste o logon em http://myapps.microsoft.com. Você deve ser redirecionado para a página de logon do AD FS. Depois que você tiver feito logon e o AD FS tiver autenticado o usuário, o usuário será redirecionado para http://myapps.microsoft.com. Se tiver aplicativos do Office 365, você os verá aqui. Um usuário normal pode fazer logon aqui sem a necessidade de uma assinatura do Azure.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2015 Microsoft