Definir uma estratégia híbrida de adoção de identidade
Nesta tarefa, define a estratégia de adoção de identidade híbrida para a sua solução de identidade híbrida para satisfazer os requisitos de negócio que foram discutidos em:
- Determinar as necessidades do negócio
- Determinar os requisitos de sincronização do diretório
- Determinar requisitos de autenticação de vários fatores
Definir estratégia de necessidades de negócio
A primeira tarefa aborda a determinação das necessidades empresariais das organizações. Isto pode ser muito amplo e pode ocorrer se não tiver cuidado. No início, mantenha-o simples mas lembre-se sempre de planear um design que irá acomodar e facilitar a mudança no futuro. Independentemente de se trata de um design simples ou de um design extremamente complexo, Azure Ative Directory é a plataforma Microsoft Identity que suporta Microsoft 365, Serviços Microsoft Online e aplicações de cloud aware.
Definir uma estratégia de integração
A Microsoft tem três cenários principais de integração que são identidades em nuvem, identidades sincronizadas e identidades federadas. Devias planear adotar uma destas estratégias de integração. A estratégia que escolhe pode variar e as decisões na escolha podem incluir, que tipo de experiência de utilizador quer fornecer, tem uma infraestrutura existente, e qual é a mais rentável.
Os cenários definidos na figura acima são:
- Identidades em nuvem: estas são identidades que existem apenas na nuvem. No caso da Azure AD, eles residiriam especificamente no seu diretório AD Azure.
- Sincronizado: estas são identidades que existem no local e na nuvem. Utilizando Ligação Azure AD, estes utilizadores são criados ou associados às contas AZURE AD existentes. O hash de palavras-passe do utilizador é sincronizado a partir do ambiente no local para a cloud no que é chamado de hash de palavras-passe. Ao utilizar sincronizado, a única ressalva é que, se um utilizador for desativado no ambiente no local, pode demorar até três horas para que o estado da conta apareça no Azure AD. Isto deve-se ao intervalo de tempo de sincronização.
- Federado: estas identidades existem tanto no local como na nuvem. Utilizando Ligação Azure AD, estes utilizadores são criados ou associados às contas AZURE AD existentes.
Nota
Para obter mais informações sobre as opções de Sincronização, leia integrando as suas identidades no local com Azure Ative Directory.
O quadro a seguir ajuda a determinar as vantagens e desvantagens de cada uma das seguintes estratégias:
| Estratégia | Vantagens | Desvantagens |
|---|---|---|
| Identidades em nuvem | Mais fácil de gerir para uma pequena organização. Nada para instalar no local. Não é necessário hardware adicional Facilmente desativado se o utilizador deixar a empresa |
Os utilizadores terão de fazer sedudas ao aceder às cargas de trabalho na nuvem As palavras-passe podem ou não ser as mesmas para identidades em nuvem e no local |
| Sincronizado | A palavra-passe no local autentica tanto no local como nos diretórios de nuvem Mais fácil de gerir para pequenas, médias ou grandes organizações Os utilizadores podem ter um único sign-on (SSO) para alguns recursos Método preferido da Microsoft para sincronização Mais fácil de gerir |
Alguns clientes podem estar relutantes em sincronizar os seus diretórios com a nuvem devido às políticas específicas da empresa |
| Federados | Os utilizadores podem ter um único sign-on (SSO) Se um utilizador for encerrado ou sair, a conta pode ser imediatamente desativada e o acesso revogado, Suporta cenários avançados que não podem ser realizados com sincronização |
Mais passos para configurar e configurar Maior manutenção Pode exigir hardware adicional para a infraestrutura STS Pode exigir hardware adicional para instalar o servidor da federação. É necessário software adicional se o AD FS for utilizado Requerer uma configuração extensiva para sSO Ponto crítico de falha se o servidor da federação estiver em baixo, os utilizadores não poderão autenticar |
Experiência do cliente
A estratégia que utiliza vai ditar a experiência de inscrição do utilizador. As tabelas que se seguem fornecem-lhe informações sobre o que os utilizadores devem esperar que a sua experiência de inscrição seja. Nem todos os fornecedores de identidade federados apoiam sSO em todos os cenários.
Aplicações de rede de domínio e privadas:
| Aplicação | Identidade sincronizada | Identidade federada |
|---|---|---|
| Navegadores Web | Autenticação baseada em formulários | único sinal- on, às vezes necessário para fornecer iD de organização |
| Outlook | Pedir credenciais | Pedir credenciais |
| Skype para Empresas (Lync) | Pedir credenciais | único sinal para Lync, pediu credenciais para Exchange |
| OneDrive para Empresas | Pedir credenciais | único sinal-on |
| Subscrição Office Pro Plus | Pedir credenciais | único sinal-on |
Fontes externas ou não fidedíss elas:
| Aplicação | Identidade sincronizada | Identidade federada |
|---|---|---|
| Navegadores Web | Autenticação baseada em formulários | Autenticação baseada em formulários |
| Outlook, Skype para Empresas (Lync), OneDrive para Empresas, Office subscrição | Pedir credenciais | Pedir credenciais |
| Exchange ActiveSync | Pedir credenciais | único sinal para Lync, pediu credenciais para Exchange |
| Aplicações móveis | Pedir credenciais | Pedir credenciais |
Se determinou a partir da tarefa 1 que tem um IdP de terceiros ou que vai usar um para fornecer à federação a AD AZure, precisa de estar ciente das seguintes capacidades suportadas:
- Qualquer fornecedor SAML 2.0 que esteja em conformidade com o perfil SP-Lite pode suportar a autenticação da Azure AD e aplicações associadas
- Suporta a autenticação passiva, o que facilita a autenticação para OWA, SPO, etc.
- Exchange Online clientes podem ser suportados através do Perfil de Cliente Melhorado (ECP)
Também deve estar ciente das capacidades que não estarão disponíveis:
- Sem o apoio da WS-Trust/Federação, todos os outros clientes ativos quebram
- Isto significa que nenhum cliente Lync, OneDrive cliente, Office Subscrição, Office Mobile antes de Office 2016
- A transição de Office para a autenticação passiva permite-lhes suportar idPs saml puros 2.0, mas o suporte continuará a ser numa base cliente-a-cliente
Nota
Para a lista mais atualizada leia a lista de compatibilidade da federação Azure.
Definir estratégia de sincronização
Nesta tarefa definirá as ferramentas que serão usadas para sincronizar os dados da organização no local para a nuvem e que topologia deve usar. Porque, a maioria das organizações usa Ative Directory, a informação sobre a utilização de Azure AD Ligação para responder às questões acima é fornecida em alguns detalhes. Para ambientes que não têm Diretório Ativo, existe informação sobre a utilização do FIM 2010 R2 ou MIM 2016 para ajudar a planear esta estratégia. No entanto, futuras libertações de Azure AD Ligação apoiarão os diretórios LDAP, pelo que, dependendo da sua linha temporal, estas informações poderão ser capazes de ajudar.
Ferramentas de sincronização
Ao longo dos anos, várias ferramentas de sincronização têm existido e usado para vários cenários. Atualmente Azure AD Ligação é a ferramenta de eleição para todos os cenários suportados. AAD Sync e DirSync também ainda estão por perto e podem até estar presentes no seu ambiente agora.
Nota
Para obter as informações mais recentes sobre as capacidades suportadas de cada ferramenta, leia o artigo de comparação de ferramentas de integração do Diretório .
Topologias suportadas
Ao definir uma estratégia de sincronização, a topologia que é utilizada deve ser determinada. Dependendo da informação determinada no passo 2, pode determinar qual a topologia adequada a utilizar. A única floresta, a topologia AD única Ad é a mais comum e consiste de uma única floresta de Diretório Ativo e um único exemplo de Azure AD. Isto vai ser usado na maioria dos cenários e é a topologia esperada quando se utiliza a instalação Azure AD Ligação Express, como mostra a figura abaixo.
Cenário único da floresta É comum que grandes e mesmo pequenas organizações tenham múltiplas florestas, como mostra a Figura 5.
Nota
Para obter mais informações sobre as diferentes topologias da AD no local e Azure AD com Azure AD Ligação sincronizar leia o artigo Topologias para Azure AD Ligação.
Cenário multi-florestal
Se for esse o caso, a topologia AD única multi-floresta deve ser considerada se os seguintes itens forem verdadeiros:
- Os utilizadores têm apenas uma identidade em todas as florestas – a secção de utilizadores que identificam de forma única abaixo descreve-a com mais detalhes.
- O utilizador autentica-se na floresta em que se encontra a sua identidade
- UPN e Source Anchor (id imutável) virão desta floresta
- Todas as florestas são acessíveis por Azure AD Ligação – isto significa que não precisa de ser unida ao domínio e pode ser colocada num DMZ se isso facilitar isso.
- Os utilizadores têm apenas uma caixa de correio
- A floresta que acolhe a caixa de correio de um utilizador tem a melhor qualidade de dados para atributos visíveis na Exchange Global Address List (GAL)
- Se não houver caixa de correio no utilizador, então qualquer floresta pode ser usada para contribuir com estes valores
- Se tiver uma caixa de correio ligada, então também há outra conta numa floresta diferente usada para iniciar sing.
Nota
Os objetos que existem tanto no local como na nuvem estão "ligados" através de um identificador único. No contexto da Sincronização do Diretório, este identificador único é referido como o SourceAnchor. No contexto do Sign-On Único, este é referido como o ImuttableId. Os conceitos de design para Azure AD Ligação para mais considerações sobre a utilização de SourceAnchor.
Se o acima não for verdade e tiver mais de uma conta ativa ou mais do que uma caixa de correio, a Azure AD Ligação escolherá uma e ignorará a outra. Se tiver cabines de correio ligadas mas nenhuma outra conta, estas contas não serão exportadas para a Azure AD e esse utilizador não será membro de nenhum grupo. Isto é diferente de como era no passado com o DirSync e é intencional para apoiar melhor estes cenários multi-florestais. Um cenário multi-florestal é mostrado na figura abaixo.
Multi-floresta múltiplo AD AD
Recomenda-se ter apenas um único diretório em Azure AD para uma organização, mas é apoiado que uma relação 1:1 é mantida entre um servidor de sincronização Azure AD Ligação e um diretório AD Azure. Para cada instância de Azure AD, você precisa de uma instalação de Azure AD Ligação. Além disso, o Azure AD, por design é isolado e os utilizadores em um caso de Azure AD não serão capazes de ver os utilizadores em outro caso.
É possível e suportado ligar uma instância no local do Ative Directory a vários diretórios Azure, como mostra a figura abaixo:
Cenário de filtragem de uma única floresta
Para tal, o seguinte deve ser verdade:
- Os servidores de sincronização AZure AD Ligação devem ser configurados para filtragem, de modo a que cada um tenha um conjunto de objetos mutuamente exclusivo. Isto feito, por exemplo, ao digitalizar cada servidor para um determinado domínio ou OU.
- Um domínio DNS só pode ser registado num único diretório AD Azure para que os UPNs dos utilizadores nas AD no local devem usar espaços de nome separados
- Os utilizadores de um caso de Azure AD só poderão ver os utilizadores a partir do seu caso. Não poderão ver utilizadores nos outros casos
- Apenas um dos diretórios AD do Azure pode permitir Exchange híbrido com a AD no local
- A exclusividade mútua também se aplica à ressartação. Isto faz com que algumas funcionalidades de back-back não suportadas com esta topologia, uma vez que estas assumem uma única configuração no local. O que está incluído:
- Desacrevição de grupo com configuração padrão
- Ressoução do dispositivo
O seguinte não é apoiado e não deve ser escolhido como uma implementação:
- Não é suportado para ter vários servidores de sincronização Azure AD Ligação que se conectam ao mesmo diretório AD Azure, mesmo que estejam configurados para sincronizar conjunto de objeto mutuamente exclusivo
- Não é suportado para sincronizar o mesmo utilizador para vários diretórios AD Azure.
- Também não é suportado para fazer uma alteração de configuração para fazer com que os utilizadores de um AD Azure apareçam como contactos em outro diretório AD Azure.
- Também não é suportado para modificar Azure AD Ligação sincronização para ligar a vários diretórios AD Azure.
- Os diretórios AD Azure são por design isolado. Não é suportado para alterar a configuração do Azure AD Ligação sincronização para ler dados de outro diretório AD Azure numa tentativa de construir uma GAL comum e unificada entre os diretórios. Também não é suportado para os utilizadores de exportação como contactos para outro AD no local usando Azure AD Ligação sincronização.
Nota
Se a sua organização restringir os computadores da sua rede de ligação à Internet, este artigo lista os pontos finais (intervalos de endereços FQDNs, IPv4 e IPv6) que deve incluir nas listas de saída e na Internet Explorer Trusted Sites Zone de computadores clientes para garantir que os seus computadores podem utilizar Microsoft 365 com sucesso. Para mais informações leia Office 365 gamas de ENDEREÇOS e ENDEREÇOS IP.
Definir estratégia de autenticação de vários fatores
Nesta tarefa definirá a estratégia de autenticação multi-factor a utilizar. A autenticação multi-factor Azure AD vem em duas versões diferentes. Um é baseado em nuvem e o outro está no local baseado no servidor Azure MFA. Com base na avaliação que fez acima, pode determinar qual a solução correta para a sua estratégia. Utilize a tabela abaixo para determinar qual a melhor opção de design que melhor satisfaz os requisitos de segurança da sua empresa:
Opções de design de vários fatores:
| Ativo para garantir | MFA na nuvem | MFA no local |
|---|---|---|
| Aplicativos da Microsoft | sim | sim |
| Aplicações SaaS na galeria de aplicações | sim | sim |
| Aplicações IIS publicadas através do Proxy de Aplicação do Azure AD | sim | sim |
| Aplicações IIS não publicadas através da App AD Proxy Azure | não | sim |
| Acesso remoto como VPN, RDG | não | sim |
Apesar de ter decidido uma solução para a sua estratégia, ainda precisa de utilizar a avaliação de cima sobre o local onde os seus utilizadores estão localizados. Isto pode fazer com que a solução mude. Utilize a tabela abaixo para o ajudar a determinar isto:
| Localização do utilizador | Opção de design preferida |
|---|---|
| Azure Active Directory | Multi-FactorAuthentication na nuvem |
| Azure AD e AD no local utilizando federação com o AD FS | Ambos |
| Azure AD e AD no local usando Azure AD Ligação sem sincronização de senha | Ambos |
| Azure AD e no local usando Azure AD Ligação com sincronização de senha | Ambos |
| No local, AD | Servidor Multi-Factor Authentication |
Nota
Deve também certificar-se de que a opção de design de autenticação multi-factor que selecionou suporta as funcionalidades necessárias para o seu design. Para mais informações leia Escolha a solução de segurança multi-factor para si.
Fornecedor multi-factor Auth
A autenticação multi-factor está disponível por padrão para administradores globais que tenham um inquilino Azure Ative Directory. No entanto, se pretender alargar a autenticação de vários fatores a todos os seus utilizadores e/ou pretender que os seus administradores globais possam tirar partido de funcionalidades como o portal de gestão, saudações personalizadas e relatórios, então deve adquirir e configurar o Fornecedor de Autenticação Multi-Factor.
Nota
Deve também certificar-se de que a opção de design de autenticação multi-factor que selecionou suporta as funcionalidades necessárias para o seu design.
Passos seguintes
Determinar os requisitos de proteção de dados