Exportar (0) Imprimir
Expandir Tudo

Diretrizes para implantação do Active Directory do Windows Server em Máquinas Virtuais do Azure

Atualizado: junho de 2014

O artigo explica as diferenças importantes entre a implantação local dos Serviços de Domínio do Active Directory (AD DS) e os Serviços de Federação do Active Directory (AD FS) do Windows Server em comparação com a sua implantação em Máquinas Virtuais (VMs) do Microsoft Azure.

Sumário

Este artigo é destinado para os que já têm experiência com implantação em Active Directory local. O artigo aborda as diferenças entre a implantação do Active Directory em Máquinas Virtuais do Microsoft Azure/Redes Virtuais do Azure e as implantações tradicionais locais do Active Directory. As Máquinas Virtuais do Azure e a Rede Virtual do Azure fazem parte de uma oferta de Infraestrutura como um serviço (IaaS) para organizações aproveitarem os recursos de computação na nuvem.

Para os que não estiverem familiarizados com a implantação do AD, consulte o Guia de implantação do AD DS ou Planeje sua implementação do AD FS conforme apropriado.

O artigo supõe que o leitor esteja familiarizado com os seguintes conceitos:

  • Implantação e gerenciamento do Windows Server AD DS

  • Implantação e configuração do DNS para dar suporte à infraestrutura do Windows Server AD DS

  • Implantação e gerenciamento do AD FS do Windows Server

  • Implantando, configurando e gerenciando os aplicativos da parte dependente (sites e serviços da Web) que podem consumir tokens do AD FS do Windows Server

  • Conceitos gerais de máquina virtual, por exemplo, como configurar uma máquina virtual, os discos virtuais e as redes virtuais

O artigo realça os requisitos para um cenário de implantação híbrido no qual o Windows Server AD DS ou AD FS são implantados em parte localmente e em parte em Máquinas Virtuais do Azure. O documento primeiro aborda as diferenças críticas entre a execução do Windows Server AD DS e AD FS em máquinas virtuais do Azure em comparação com execução local, e as decisões importantes que afetam o design e a implantação. O restante do artigo explica as diretrizes para cada um dos pontos de decisão com mais detalhes, e como aplicar as diretrizes a vários cenários de implantação.

Este artigo não discute a configuração do Azure Active Directory, que é um serviço moderno e baseado em REST que fornece recursos de gerenciamento de identidade e de controle de acesso para seus aplicativos na nuvem. Porém, o Azure Active Directory (AD) e o Windows Server AD DS foram projetados para funcionar em conjunto, de modo a fornecer uma solução de gerenciamento de identidade e acesso para os ambientes de TI híbridos e os aplicativos modernos existentes hoje em dia. Para ajudar a entender as diferenças e as relações entre o Windows Server AD DS e o Azure AD, considere o seguinte:

  1. Você pode executar o Windows Server AD DS na nuvem em Máquinas Virtuais do Azure quando estiver usando o Azure para estender o datacenter local para a nuvem.

  2. Você pode usar o Azure AD para oferecer aos usuários o recurso de logon único em aplicativos de Software como Serviço (Software-as-a-Service - SaaS). O Microsoft Office 365 usa essa tecnologia, por exemplo, e os aplicativos executados no Azure ou outras plataformas de nuvem também podem usá-la.

  3. Você pode usar o Azure AD (seu Serviço de Controle de Acesso) para permitir que os usuários façam logon usando identidades do Facebook, do Google, da Microsoft e de outros provedores de identidade, em aplicativos hospedados na nuvem ou localmente.

Para obter mais informações sobre essas diferenças, consulte Identidade do Azure.

Os requisitos básicos para implantar o Active Directory do Windows Server em Máquinas Virtuais do Azure diferem muito pouco de implantá-lo em máquinas virtuais (e, até certo ponto, computadores físicos) locais. Por exemplo, no caso do Windows Server AD DS, se os controladores de domínio (DCs) que você implantar em máquinas virtuais do Azure forem réplicas em um domínio corporativo/floresta local existente, a implantação do Azure poderá ser tratada em grande parte da mesma forma que qualquer outro site adicional do Active Directory do Windows Server. Ou seja, as sub-redes devem ser definidas no Windows Server AD DS, um site criado, as sub-redes vinculadas a esse site e conectados a outros sites usando os links de site apropriados. Porém, existem algumas diferenças que são comuns a todas as implantações do Azure e outras que variam de acordo com o cenário de implantação específico. Duas diferenças fundamentais estão descritas abaixo e explicadas com mais detalhes nos parágrafos a seguir:

  1. As máquinas virtuais do Azure podem precisar de conectividade para a rede corporativa local.

    Para conectar máquinas virtuais do Azure novamente a uma rede corporativa local, é necessária uma rede virtual do Azure, que inclui um componente de VPN (rede virtual privada) site a site ou site a ponto capaz de conectar diretamente as máquinas virtuais do Azure e os computadores locais. Esse componente VPN também pode habilitar computadores de membro do domínio local para acessar um domínio do Active Directory do Windows Server cujos controladores de domínio são hospedados exclusivamente em máquinas virtuais do Azure. Entretanto, é importante observar que, se uma VPN falha, a autenticação e outras operações que dependem do Active Directory do Windows Server também falharão. Embora os usuários possam fazer logon usando credenciais armazenadas em cache existentes, haverá falha em todas as tentativas de autenticação ponto a ponto ou de cliente para servidor para as quais as permissões ainda não tiverem sido emitidas ou que se tornaram obsoletas.

    Consulte Rede Virtual para assistir a um vídeo de demonstração e uma lista de tutoriais passo a passo, incluindo Configurar uma VPN Site a Site no Portal de Gerenciamento Portal.

    noteObservação
    Você também pode implantar o Active Directory do Windows Server em uma rede virtual do Azure que não tenha conectividade com uma rede local. Porém, as diretrizes deste tópico pressupõem o uso de uma rede virtual do Azure, pois ela fornece recursos de endereçamento IP que são essenciais para o Windows Server.

  2. O endereço de IP estático deve ser configurado usando o Azure PowerShell.

    Os endereços dinâmicos são alocados por padrão, mas use o cmdlet Set-AzureStaticVNetIP para atribuir um endereço IP estático em vez de um dinâmico. Isso define um endereço IP estático que persistira durante a recuperação do serviço e o desligamento/reinício da VM. Para obter mais informações, consulte Configurar um endereço IP interno estático (DIP) para uma VM.

A seguinte lista de termos não está completa e define várias tecnologias pertinentes do Azure, além de ajudar a compreender este documento.

  • Máquinas Virtuais do Azure: a oferta de IaaS no Azure que permite que os clientes implantem VMs que executam praticamente qualquer carga de tradicionalmente executada por servidores locais.

  • Rede Virtual do Azure: o serviço de rede no Azure que permite que os clientes criem e gerenciem redes virtuais no Azure e as vinculem com segurança à sua própria infraestrutura de rede local usando uma rede virtual privada (virtual private network - VPN).

  • Endereço IP virtual (VIP): um endereço IP para a Internet não associado a um computador específico ou placa de interface de rede específica. Aos serviços de nuvem é atribuído um VIP para receber o tráfego de rede que é redirecionado a uma VM do Azure. Um VIP é uma propriedade de um serviço de nuvem que pode conter uma ou mais máquinas virtuais do Windows Azure. Observe também que uma rede virtual do Azure pode conter um ou mais serviços de nuvem. Os VIP fornecem recursos nativos de balanceamento de carga.

  • Endereço IP dinâmico (DIP): Este é o endereço IP que é somente interno. Ele deve ser configurado como endereço IP estático (usando o cmdlet Set-AzureStaticVNetIP) para VMs que hospedam as funções de servidor DC/DNS.

  • Recuperação de serviço: o processo no qual o Azure retorna automaticamente um serviço para um estado de execução depois de detectar que esse serviço falhou. A recuperação de serviço é um dos aspectos do Azure que dá suporte à disponibilidade e à resiliência. Embora seja improvável, o resultado após um incidente de recuperação de serviço para uma execução de DC em uma VM é semelhante a uma reinicialização não planejada, mas tem alguns efeitos colaterais:

    • O adaptador de rede virtual na VM será alterado

    • O endereço MAC do adaptador de rede virtual será alterado

    • A ID do Processor/CPU da VM será alterado

    • A configuração IP do adaptador de rede virtual não muda contanto que a VM seja anexada a uma rede virtual e o endereço IP da VM seja estático.

    No entanto, nenhum desses comportamentos afeta o Active Directory do Windows Server, pois ele não tem dependências em termos de endereço MAC ou ID de Processador/CPU. Além disso, recomenda-se que todas as implantações do Active Directory do Windows Server no Azure sejam executadas em uma rede virtual do Azure conforme descrito acima.

Implantar DCs do Active Directory do Windows Server em máquinas virtuais do Azure está sujeito às mesmas diretrizes que a execução de DCs locais em uma máquina virtual. Executar DCs virtualizados é uma prática segura contanto que as diretrizes para fazer backup e restaurar DCs sejam seguidas. Para obter mais informações sobre restrições e diretrizes para executar DCs virtualizados, consulte Como executar controladores de domínio no Hyper-V.

Os hipervisores fornecem ou trivializam tecnologias que podem causar problemas para muitos sistemas distribuídos, inclusive o Active Directory do Windows Server. Por exemplo, em um servidor físico, é possível clonar um disco, ou usar métodos sem suporte para reverter o estado de um servidor, inclusive usar SANs e assim por diante, mas fazer isso em um servidor físico é muito mais difícil do que restaurar um instantâneo de máquina virtual em um hipervisor. O Azure oferece a funcionalidade que pode resultar na mesma condição indesejável; por exemplo, você não deve copiar arquivos de VHD de DCs em vez de executar backups regulares porque restaurá-los pode resultar em uma situação semelhante ao uso dos recursos de restauração de instantâneo.

Essas reversões apresentam bolhas de USN que podem levar a um estado permanentemente divergente entre DCs. Isso pode, entre outras coisas, causar:

  • Objetos persistentes

  • Senhas inconsistentes

  • Valores de atributo inconsistentes

  • Incompatibilidades de esquema se o mestre de esquema é revertido

Para obter mais informações sobre como os DCs são afetados, consulte USN e reversão de USN.

começando com o Windows Server 2012, proteções adicionais são incorporados no AD DS. Essas proteções ajudam a proteger controladores de domínio virtualizados contra os problemas mencionados acima, contanto que a plataforma do hipervisor subjacente dê suporte à VM-GenerationID. O Azure dá suporte a VM-GenerationID, o que significa que os controladores de domínio que executam o Windows Server 2012 ou posterior em máquinas virtuais do Azure têm as proteções adicionais.

noteObservação
Você deve desligar e reiniciar uma VM que executa a função de controlador de comínio no Azure dentro do sistema operacional convidado em vez de usar a opção Desligar no Portal de Gerenciamento do Azure. A utilização do Portal de Gerenciamento para desligar uma VM reiniciará o VM-GenerationID, que é indesejável para um DC.

Muitos cenários de implantação do Windows Server AD DS são apropriados para implantação como máquinas virtuais no Azure. Por exemplo, suponha que você tenha uma empresa na Europa que precisa autenticar usuários em um local remoto na Ásia. A empresa não implantou anteriormente os DCs do Active Directory do Windows Server na Ásia devido aos custos para implantá-los e a experiência limitada para gerenciar a pós-implantação de servidores. Como resultado, as solicitações de autenticação da Ásia são atendidas pelos DCs na Europa com resultados de qualidade inferior. Nesse caso, você pode implantar um DC em uma VM que você especificou que deve ser executada dentro do datacenter do Azure na Ásia. Anexar esse DC a uma rede virtual do Azure conectada diretamente ao local remoto melhorará o desempenho da autenticação.

O Azure também é bem-apropriado como um substituto para sites de recuperação de desastres (DR) que, de outra forma, seriam muito caros. O custo relativamente baixo de hospedar um número pequeno de controladores de domínio e uma única rede virtual no Azure representa uma alternativa atrativa.

Finalmente, talvez você queira implantar um aplicativo de rede no Azure, como o SharePoint, que exige o Active Directory do Windows Server, mas não tem nenhuma dependência na rede local ou no Active Directory do Windows Server corporativo. Nesse caso, implantar uma floresta isolada no Azure para atender aos requisitos do servidor do SharePoint é ideal. Além disso, implantar aplicativos de rede que exigem conectividade para a rede local e o Active Directory corporativo também tem suporte.

noteObservação
Como ele fornece uma conexão de Camada 3, o componente de VPN que fornece a conectividade entre uma Rede Virtual do Azure e uma rede local também pode habilitar os servidores de membro que são executados no local para aproveitar os DCs executados como máquinas virtuais do Azure na Rede Virtual do Azure. Mas, se uma VPN não estiver disponível, a comunicação entre os computadores locais e os controladores de domínio baseados no Azure não funcionará, resultando em erros de autenticação e vários outros.  

  • Para qualquer cenário de implantação do Active Directory do Windows Server que incluir mais de uma VM, é necessário usar uma rede virtual do Azure para a coerência dos endereços IP. Observe que este guia pressupõe que os DCs estejam sendo executados em uma rede virtual do Azure.

  • Como com os DCs locais, são recomendados os endereços IP estáticos. Um endereço IP estático somente pode ser configurado usando o Azure PowerShell consulte Configurar um endereço IP interno estático (DIP) para uma VM. Se você tiver sistemas de monitoramento ou outras soluções que procuram por endereços IP Estáticos dentro do sistema operacional convidado, poderá atribuir o mesmo endereço IP estático às propriedades do adaptador de rede da VM. Mas esteja ciente de que o adaptador de rede será descartado se a VM for submetida a uma recuperação de serviço ou for desligada no Portal de Gerenciamento e o seu endereço será desalocado. Nesse caso, o endereço IP estático dentro do sistema operacional convidado precisará ser reiniciado.

  • Implantar máquinas virtuais em uma rede virtual não implica (nem exige) conectividade de volta para uma rede local; a rede virtual simplesmente habilita essa possibilidade. Você deve criar uma rede virtual para comunicação privada entre o Azure e sua rede local. Você precisa implantar um ponto de extremidade de VPN na rede local. A VPN é aberta do Azure para a rede local. Para obter mais informações, consulte Visão geral de redes virtuais e Configurar uma VPN site a site no Portal de Gerenciamento.

    noteObservação
    Uma opção para criar uma VPN de ponto a site está disponível para conectar computadores Windows individuais diretamente a uma rede virtual do Azure.

  • Independentemente de você criar uma rede virtual ou não, o Azure cobra pelo tráfego de saída, mas não de entrada. Várias opções de design do Active Directory do Windows Server podem afetar a quantidade de tráfego de saída gerada por uma implantação. Por exemplo, implantar um RODC limita o tráfego de saída porque não replica a saída. Mas a decisão para implantar um RODC precisa ser ponderada em relação à necessidade de executar operações de gravação no DC e a compatibilidade que os aplicativos e serviços no site têm com os RODCs. Para obter mais informações sobre taxas de tráfego, consulte Visão geral de preços do Azure.

  • Embora você tenha controle total sobre quais recursos de servidor devem ser usados para VMs locais, por exemplo, a quantidade de RAM, o tamanho do disco e assim por diante, no Azure, você deverá selecionar as opções de uma lista de tamanhos de servidor pré-configurados. Para um DC, um disco de dados é necessário além do disco do sistema operacional para armazenar o banco de dados do Active Directory do Windows Server.

noteObservação
O Azure possui alguns novos recursos que melhoram os recursos de rede. A equipe de AD FS está atualmente investigando como esses recursos afetam as melhores práticas de AD FS quando o AD FS é implantado no Azure. O documento será atualizado adequadamente. Por ora, verifique esses tópicos para obter mais informações:

O AD FS tem suporte para implantação em máquinas virtuais do Azure, e as práticas recomentadas para implantação do AD FS no local aplicam-se igualmente à implantação de AD FS no Azure, Conforme declarado em Planeje sua implementação do AD FS, a prática recomendada para implantação das funções do Serviço de Token de Segurança (STS) é *planejar o posicionamento de todos os servidores de federação em sua rede corporativa atrás de um host de Balanceamento de Carga de Rede (NLB) que pode ser configurado para um cluster de NLB com um DNS de cluster dedicado e um endereço IP de cluster.” Algumas destas práticas recomentadas de AD FS, como o balanceamento de carta e a alta disponibilidade, exigem tecnologias além daquelas que o próprio AD FS oferece. Como essas tecnologias não fazem parte do conjunto de recursos nativos do AD FS, elas devem ser fornecidas pela infraestrutura subjacente.

  1. Nunca exponha os STSs diretamente à Internet.

    Esta configuração de implantação evita a exposição do STS para a Internet, Isso é importante porque a função de STS emite tokens de segurança. Como resultado, eles devem ser tratados com o mesmo nível de proteção que um controlador de domínio. Se um STS estiver comprometido, usuários mal-intencionados terão a capacidade de emitir tokens de acesso podendo conter declarações de suas escolhas para aplicativos de terceira parte confiáveis e outros STSs em organizações confiáveis.

    Para permitir que usuários externos acessem AD FS na Internet, implante proxies do AD FS (ou seja, a função do Proxy de Aplicativo Web no Windows Server 2012 R2 do proxy do AD FS nas versões anteriores do Windows Server).

  2. O serviço do AD FS deve ter a carga balanceada e estar altamente disponível.

    Na maioria dos casos, a falha de um aplicativo que o AD FS permite é inaceitável porque esses aplicativos são geralmente de missão crítica. Como resultado disso e como o AD FS agora reside no caminho crítico para acessar os aplicativos, o serviço do AD FS deverá estar altamente disponível para manter o acesso ao aplicativo. Para obter a alta disponibilidade, os balanceadores de carga normalmente são implantados na frente dos proxies de AD FS e dos STSs.

    É possível alcançar alta disponibilidade para proxies do AD FS ao habilitar o balanceamento de carga do Azure para VIPs voltadas pra o público. A alta disponibilidade para STS pode ser obtida utilizando-se o Azure PowerShell para habilitar balanceamento de carga interno nas interfaces de rede privadas da máquina virtual (DIPs). O diagrama a seguir mostra esta configuração básica.

Para obter mais informações, consulte 2. AD FS: estenda para a Internet um aplicativo front-end local com reconhecimento de declarações.

Uma alternativa se a meta for o Office 365 somente

Se a meta for apenas o Office 365, basta implantar o DirSync com a sincronização de senha no local e obter o mesmo resultado final com complexidade de implantação quase zero. Observação: essa abordagem não exige o AD FS nem o Azure.

A tabela a seguir compara como os processos de logon funcionam com e sem implantar o AD FS.

 

Logon único do Office 365 usando AD FS e DirSync Mesmo logon do Office 365 usando DirSync + sincronização de senha
  1. O usuário faz logon em uma rede corporativa e é autenticado para o Active Directory do Windows Server.

  2. O usuário tenta acessar o Office 365 (eu sou @contoso.com).

  3. O Office 365 redireciona o usuário para o AD do Azure.

  4. Como o Azure AD não pode autenticar o usuário e entende que há uma confiança com o AD FS local, ele redireciona o usuário para o AD FS

  5. O usuário envia um ticket de Kerberos para o STS do AD FS.

  6. O AD FS transforma o tíquete do Kerberos para o formato/as declarações de token necessários e redireciona o usuário para o AD do Azure.

  7. O usuário autentica para o AD do Azure (outra transformação ocorre).

  8. O AD do Azure redireciona o usuário para o Office 365.

  9. O usuário é conectado silenciosamente ao Office 365

  1. O usuário faz logon em uma rede corporativa e é autenticado para o Active Directory do Windows Server.

  2. O usuário tenta acessar o Office 365 (eu sou @contoso.com).

  3. O Office 365 redireciona o usuário para o AD do Azure.

  4. O Azure AD não pode aceitar tickets de Kerberos diretamente e nenhuma relação de confiança existe, de modo que ele solicita as credenciais do usuário.

  5. O usuário insere a mesma senha local e o AD do Azure valida-a em relação ao nome de usuário e à senha que foram sincronizados pelo DirSync.

  6. O AD do Azure redireciona o usuário para o Office 365.

  7. O usuário pode fazer logon no Office 365 e OWA usando o token do AD do Azure.

No cenário de DirSync + sincronização de senhas (sem o AD FS), o logon único é substituído por "mesmo logon”, em que “mesmo” significa apenas que os usuários devem inserir novamente as mesmas credenciais locais ao acessarem o Office 365. Observe que esses dados podem ser memorizados para ajudar a reduzir avisos subsequentes.

Ideias adicionais

  • Se você implantar um proxy do AD FS do Windows Server em uma máquina virtual do Azure, será necessário haver conectividade para os STSs de AD FS. Se estiverem no local, é recomendável aproveitar a conectividade VPN de site a site fornecida pela rede virtual para permitir que os proxies se comuniquem com os STSs.

  • Se você implantar um STS do AD FS do Windows Server em uma máquina virtual do Azure, será necessário haver conectividade com os controladores de domínio do Active Directory do Windows Server, os Repositórios de Atributos e os bancos de dados de Configuração. Além disso, uma VPN de site a site também poderá ser necessária.

  • Os encargos são aplicados a qualquer tráfego de saída de máquina virtual do Azure. Se os custos forem um fator importante, é aconselhável implantar os proxies do AD FS no Azure, deixando os STSs no local. Se o STSs forem implantados em máquinas virtuais do Azure além disso, os custos adicionais serão incorridos para autenticar os usuários locais. O tráfego de saída incorre em custo independentemente de estar passando por uma VPN ou não.

  • Se você decidir usar recursos de balanceamento de carga nativos do servidor do Azure para alta disponibilidade de STSs de AD FS, observe que o balanceamento de carga fornece investigações que são usadas para determinar a integridade das máquinas virtuais no serviço de nuvem. No caso de Máquinas Virtuais do Azure (diferentemente das funções web e das funções de trabalho), deve ser usada uma investigação personalizada, pois o agente que responde às investigações padrão não está presente nas máquinas virtuais do Azure. Para simplificar, você pode usar uma investigação personalizada de TCP — isso exige somente que uma conexão TCP (uma confirmação de sincronização) seja estabelecida com êxito para determinar a integridade da máquina virtual. Você pode configurar a investigação personalizada para usar qualquer porta TCP que escute ativamente nas máquinas virtuais. Para fazer isso, consulte Investigação do balanceador de carga do Windows Azure.

    noteObservação
    Os computadores que precisarem expor o mesmo conjunto de portas diretamente para a Internet (como a porta 80 e 443) não podem compartilhar o mesmo serviço de nuvem. Consequentemente, é recomendável que você crie um serviço de nuvem dedicado para seus servidores do AD FS do Windows Server para evitar sobreposições potenciais entre os requisitos de porta para um aplicativo e o AD FS do Windows Server.

A seção a seguir descreve os cenários comuns de implantação que chamam a atenção para as considerações importantes que devem ser levadas em conta. Cada cenário contém links para mais detalhes sobre as decisões e os fatores a serem considerados.

Implantação de AD DS apenas na nuvem

Figura 1

O SharePoint é implantado em uma máquina virtual do Azure, e o aplicativo não tem nenhuma dependência dos recursos da rede corporativa. O aplicativo exige o AD DS do Windows Server, mas NÃO exige o AD DS do Windows Server corporativo. Nenhuma confiança de Kerberos ou federada é necessária porque os usuários são autoprovisionados pelo aplicativo no domínio do AD DS do Windows Server que também está hospedado na nuvem em máquinas virtuais do Azure.

  • Topologia de rede: crie uma Rede Virtual do Azure sem conectividade entre locais (também conhecida como conectividade site a site).

  • Configuração de implantação de DC: implante um novo controlador de domínio em uma nova floresta de domínio único do Active Directory do Windows Server. Isso deve ser implantado junto com o servidor DNS do Windows.

  • Topologia de site do Active Directory do Windows Server: use o site padrão do Active Directory do Windows Server (todos os computadores estarão em Primeiro-site-padrão)

  • Endereçamento IP e DNS:

    • Defina um endereço de IP estático para DC utilizando o cmdlet Set-AzureStaticVNetIP do Azure PowerShell.

    • Instale e configure o DNS do Windows Server nos controladores de domínio do Azure.

    • Configure as propriedades da rede virtual com o nome e o endereço IP da VM que hospeda as funções de servidor DNS e DC.

  • Catálogo global: o primeiro DC em uma floresta deve ser um servidor de catálogo global. Os DCs adicionais também devem ser configurados como GCs porque, em uma floresta de domínio único, o catálogo global não exige nenhum trabalho adicional do DC.

  • Colocação do banco de dados do Windows Server AD DS e SYSVOL: adicione um disco de dados a DCs em execução como VMs do Azure para armazenar o banco de dados, os logs e o SYSVOL do Active Directory do Windows Server.

  • Backup e restauração: determine onde você deseja armazenar backups de estados do sistema. Se necessário, adicione outro disco de dados à VM do DC para armazenar backups.

Federação com conectividade entre instalações

Figura 2

Um aplicativo com reconhecimento de declaração que foi implantado com êxito no local e usado por usuários corporativos precisa se tornar acessível diretamente da Internet. O aplicativo serve como um front-end da Web para um banco de dados SQL no qual armazena e recupera dados. Os servidores SQL usados pelo aplicativo também estão localizados na rede corporativa. Dois STSs do AD FS do Windows Server e um balanceador de carga foram implantados no local para fornecer acesso aos usuários corporativos. O aplicativo agora precisa ser acessado diretamente pela Internet por parceiros de negócios que usam suas próprias identidades corporativas e por usuários corporativos existentes.

Em um esforço para simplificar e atender às necessidades de implantação e configuração dessa nova exigência, decidiu-se que dois front-ends da Web adicionais e dois servidores proxy do AD FS do Windows Server foram instalados em máquinas virtuais do Azure. Todas as quatro máquinas virtuais serão expostas diretamente à Internet e terão conectividade com a rede local usando o recurso de VPN de site a site de rede virtual do Azure.

  • Topologia de rede: crie uma Rede Virtual do Azure e configure a conectividade entre locais.

    noteObservação
    Para cada certificado do AD FS do Windows Server, verifique se a URL definida dentro do modelo de certificado e os certificados resultantes podem ser alcançados pelas instâncias do AD FS do Windows Server executadas no Azure. Isso pode exigir conectividade entre os locais para as partes de sua infraestrutura de PKI. Por exemplo, se o ponto de extremidade do CRL for baseado em LDAP e hospedado exclusivamente no local, a conectividade entre os locais será necessária. Se isso não for desejável, poderá ser necessário usar certificados emitidos por uma CA cujo CRL seja acessível pela Internet.

  • Configuração de serviços de nuvem: verifique se você tem dois serviços de nuvem para fornecer dois VIPs com balanceamento de carga. O VIP do primeiro serviço de nuvem será direcionado às duas VMs de proxy do AD FS do Windows Server nas portas 80 e 443. As VMs de proxy do AD FS do Windows Server serão configuradas de forma a apontarem ao endereço IP do balanceador de carga local que está à frente dos STSs do AD FS do Windows Server. O VIP do segundo serviço de nuvem será direcionado às duas VMs que executam o front-end da Web novamente nas portas 80 e 443. Configure uma investigação personalizada para garantir que o balanceador de carga direcione o tráfego somente ao proxy do AD FS do Windows Server e às VMs front-end da Web.

  • Configuração de servidor de federação: configure o AD FS do Windows Server como um servidor de federação (STS) para gerar tokens de segurança para a floresta do Active Directory do Windows Server criada na nuvem. Definir relações de confiança do provedor de declarações de federação com os parceiros diferentes dos quais você deseja aceitar identidades e configurar relações de confiança das partes com os diferentes aplicativos para os quais você deseja gerar tokens.

    Na maioria dos cenários, os servidores proxy do AD FS do Windows Server são implantados em uma capacidade da internet para fins de segurança enquanto que suas contrapartes da federação do AD FS do Windows Server permanecem isoladas de conectividade direta da Internet. Independentemente de seu cenário de implantação, você deverá configurar o serviço de nuvem com um VIP que fornecerá um endereço IP e uma porta expostos publicamente que sejam capazes de balancear a carga entre as duas instâncias do STS do AD FS do Windows Server ou instâncias do proxy.

  • Configuração de alta disponibilidade do AD FS do Windows Server: convém implantar um farm do AD FS do Windows Server com pelo menos dois servidores para balanceamento de carga e failover. Talvez você queira considerar o uso do Banco de Dados Interno do Windows (WID) para dados de configuração do AD FS do Windows Server e usar o recurso nativo de balanceamento de carga interno do servidor do Azure para distribuir solicitações de entrada entre os servidores no farm.

    Para obter mais informações, consulte o Guia de implantação do AD FS.

Implantação do AD DS entre instalações

Figura 3

Um aplicativo com reconhecimento de LDAP que é compatível com a autenticação integrada do Windows e que usa o AD DS do Windows Server como repositório para dados de configuração e de perfil de usuários é implantado em uma máquina virtual do Azure. É recomendável que o aplicativo aproveite o AD DS do Windows Server corporativo existente e forneça logon único. O aplicativo não tem reconhecimento de declaração. Os usuários também precisam acessar o aplicativo diretamente da Internet. Para otimizar o desempenho e os custos, decidiu-se que dois controladores de domínio adicionais que fazem parte do domínio corporativo seriam implantados ao lado do aplicativo no Azure.

  • Topologia de rede: crie uma Rede Virtual do Azure com conectividade entre locais.

  • Método de instalação: implante DCs de réplica do domínio do Active Directory do Windows Server corporativo. Para um DC de réplica, você pode instalar o AD DS do Windows Server na VM e, opcionalmente, usar o recurso de Instalar da Mídia (IFM) para reduzir a quantidade de dados que precisam ser replicados para o novo DC durante a instalação. Para obter um tutorial, consulte Instalar uma réplica de controlador de domínio do Active Directory no Azure. Mesmo se você usar o IFM, poderá ser mais eficiente criar o DC virtual no local e mover o VHD inteiro para a nuvem em vez de replicar o AD DS do Windows Server durante a instalação. Para segurança, é recomendável que você exclua o VHD da rede local assim que tiver sido copiada para o Azure.

  • Topologia de site do Active Directory do Windows Server: crie um novo site do Azure em Sites e Serviços do Active Directory. Crie um objeto da sub-rede do Active Directory do Windows Server para representar a rede virtual do Azure e adicionar a sub-rede ao site. Crie um novo link de site que inclui o novo site do Azure e o site no qual o ponto de extremidade do VPN da rede virtual do Azure está localizado para controlar e otimizar o tráfego do Active Directory do Windows Server para e do Azure.

  • Endereçamento IP e DNS:

    • Defina um endereço de IP estático para DC utilizando o cmdlet Set-AzureStaticVNetIP do Azure PowerShell.

    • Instale e configure o DNS do Windows Server nos controladores de domínio do Azure.

    • Configure as propriedades da rede virtual com o nome e o endereço IP da VM que hospeda as funções de servidor DNS e DC.

  • DCs distribuídos geograficamente: configure redes virtuais adicionais conforme necessário. Se a topologia de seu site do Active Directory exigir DCs nas geografias que correspondem a diferentes regiões do Azure, você poderá criar sites do Active Directory de acordo.

  • DCs somente leitura: você pode implantar um RODC no site do Azure, dependendo dos seus requisitos para realizar operações de gravação no DC e da compatibilidade de aplicativos e serviços no site com os RODCs. Para obter mais informações sobre a compatibilidade de aplicativos, consulte Guia de compatibilidade de aplicativos dos controladores de domínio somente leitura.

  • Catálogo global: os GCs são necessários para atender a solicitações de logon em florestas de vários domínios. Se você não implantar um GC no site do Azure, incorrerá em custos de tráfego de saída porque as solicitações de autenticação causam consultas de GCs em outros sites. Para minimizar esse tráfego, você poderá habilitar o cache universal de associação de grupo para o site do Azure em sites e serviços do Active Directory.

    Se você implantar um GC, configure os links de site e os custos de links de site de modo que o GC no site do Azure não seja preferido como um DC de origem por outros GCs que precisam replicar as mesmas partições de domínio parcial.

  • Colocação do banco de dados do Windows Server AD DS e SYSVOL: adicione um disco de dados a DCs em execução em VMs do Azure para armazenar o banco de dados, os logs e o SYSVOL do Active Directory do Windows Server.

  • Backup e restauração: determine onde você deseja armazenar backups de estados do sistema. Se necessário, adicione outro disco de dados à VM do DC para armazenar backups.

Esta tabela resume as áreas tecnológicas do Active Directory do Windows Server que são afetadas nos cenários anteriores e as decisões correspondentes a serem consideradas e os links para mais detalhes abaixo. Algumas áreas tecnológicas podem não ser aplicáveis a todos os cenários de implantação e algumas áreas tecnológicas podem ser mais importantes para um cenário de implantação do que outras áreas tecnológicas.

Por exemplo, se você implantar um DC de réplica em uma rede virtual e sua floresta tiver apenas um domínio único, escolher implantar um servidor de catálogo global nesse caso não será fundamental para o cenário de implantação porque não criará os requisitos de replicação adicionais. Por outro lado, se a floresta tiver vários domínios, a decisão de implantar um catálogo global em uma rede virtual poderá afetar a largura de banda disponível, o desempenho, a autenticação, as pesquisas no diretório e assim por diante.

 

Número do item

Área de tecnologia do Active Directory do Windows Server

Decisões

Fatores

1

Topologia de rede

Você cria uma rede virtual?

Requisitos para acessar os recursos da corporação

Autenticação

Gerenciamento de contas

2

Configuração de implantação de DC

  • Implantar uma floresta separada sem nenhuma confiança?

  • Implantar uma nova floresta com federação?

  • Implantar uma nova floresta com confiança de floresta do Active Directory do Windows Server para Kerberos?

  • Estender a floresta da corporação implantando um DC de réplica?

  • Estender a floresta da corporação implantando um novo domínio filho ou árvore de domínio?

Segurança

Conformidade

Custo

Resiliência e tolerância a falhas

Compatibilidade com aplicativos

3

Topologia de site do Active Directory do Windows Server

Como você configura sub-redes, sites e links de site com a Rede Virtual do Azure para otimizar o tráfego e minimizar o custo?

Definições de sub-rede e site

Propriedades do link de site e notificação de alteração

Compactação de replicação

4

Endereçamento IP e DNS

Como configurar endereços IP e resolução de nome?

Use o cmdlet Set-AzureStaticVNetIP para atribuir um endereço IP estático

Instale o DNS do Windows Server e configure as propriedades da rede virtual com o nome e o endereço IP da VM que hospeda as funções de servidor DNS e DC.

5

DCs distribuídos geograficamente

Como replicar para DCs em redes virtuais separadas?

Se a topologia de seu site do Active Directory exigir DCs nas geografias que correspondem a diferentes regiões do Azure, você poderá criar sites do Active Directory de acordo. Configure conectividade VNet para VNet para replicar entre os controladores de domínio em VNets separadas.

6

DCs somente leitura

Use DCs somente leitura ou graváveis?

Filtrar atributos de HBI/PII

Filtrar segredos

Limitar o tráfego de saída

7

Catálogo global

Instalar o catálogo global?

Para uma floresta de domínio único, faça todos os GCs de DCs

Para uma floresta de vários domínios, GCs são necessários para a autenticação

8

Método de instalação

Como instalar o DC no Azure?

  • Instalar o AD DS usando o Windows PowerShell ou Dcpromo

-Ou-

  • Mover o VHD de um DC virtual no local

9

Colocação do banco de dados do Windows Server AD DS e SYSVOL

Onde armazenar o banco de dados, os logs e o SYSVOL do AD DS do Windows Server?

Alterar os valores padrão de Dcpromo.exe

ImportantImportante
Esses arquivos críticos do Active Directory DEVEM ser colocados em discos de dados do Azure em vez de em discos do sistema operacional que implementa o cache de gravação.

10

Backup e restauração

Como proteger e recuperar dados?

Criar backups do estado do sistema

11

Configuração de servidor de federação

Implantar uma nova floresta com federação na nuvem?

Implantar o AD FS no local e expor um proxy na nuvem?

Segurança

Conformidade

Custo

Acesso a aplicativos por parceiros de negócios

12

Configuração de serviços de nuvem

Um serviço de nuvem é implantado implicitamente da primeira vez que você cria uma máquina virtual Você precisa implantar serviços de nuvem adicionais?

Uma máquina virtual ou máquinas virtuais exigem a exposição direta à Internet?

O serviço exige o balanceamento de carga?

13

Requisitos do servidor de federação para endereçamento IP público e privado (DIP vs. VIP)

A instância do AD FS do Windows Server precisa ser acessada diretamente da Internet?

O aplicativo que está sendo implantado na nuvem exige seu próprio endereço IP da internet e porta?

Criar um serviço de nuvem para cada VIP que é necessário para sua implantação

14

Configuração de alta disponibilidade do AD FS do Windows Server

Quantos nós no meu farm de servidores do AD FS do Windows Server?

Quantos nós devem ser implantados no meu farm de proxy do AD FS do Windows Server?

Resiliência e tolerância a falhas

Para atender aos requisitos de DNS e de coerência de endereços IP do AD DS do Windows Server, primeiro é necessário criar uma Rede Virtual do Azure e conectar suas máquinas virtuais a ela. Durante a criação, você deve decidir se deseja opcionalmente estender a conectividade para a sua rede corporativa local, o que conecta de maneira transparente as máquinas virtuais do Azure a computadores locais — isso é feito com o uso de tecnologias de VPN tradicionais e exige que um ponto de extremidade de VPN seja exposto na borda da rede corporativa. Ou seja, a VPN é iniciada do Azure para a rede corporativa, não vice-versa.

Observe que os custos adicionais são aplicados ao estender uma rede virtual para sua rede local além dos encargos padrão que se aplicam a cada VM. Especificamente, há encargos para o tempo de CPU do gateway da Rede Virtual do Azure e para o tráfego de saída gerado por cada VM que se comunica com os computadores locais pela VPN. Para obter mais informações sobre taxas de tráfego de rede, consulte Visão geral de preços do Azure.

A maneira como você configura o DC depende dos requisitos para o serviço que você deseja executar no Azure. Por exemplo, você pode implantar uma nova floresta, isolada de sua própria floresta corporativa, para testar uma verificação de conceito, um novo aplicativo ou qualquer outro projeto de curto prazo que exige os serviços de diretório, mas não o acesso específico aos recursos corporativos internos.

Como benefício, um DC de floresta isolado não replica com DCs locais, resultando em menos tráfego de rede de saída gerado pelo próprio sistema, reduzindo custos diretamente. Para obter mais informações sobre taxas de tráfego de rede, consulte Visão geral de preços do Azure.

Como outro exemplo, suponha que você tenha requisitos de privacidade para um serviço, mas o serviço depende do acesso ao seu Active Directory do Windows Server interno. Se você tem permissão para hospedar dados para o serviço na nuvem, poderá implantar um novo domínio filho para sua floresta interna no Azure. Nesse caso, você pode implantar um DC para o novo domínio filho (sem o catálogo global para ajudar a resolver as preocupações de privacidade). Este cenário, junto com uma implantação do DC de réplica, requer uma rede virtual para conectividade com suas DCs locais.

Se você criar uma nova floresta, escolha se deseja usar Confiança do Active Directory ou Confiança da federação. Equilibre os requisitos ditados por compatibilidade, segurança, conformidade, custo e resiliência. Por exemplo, para aproveitar a autenticação seletiva, você poderá escolher implantar uma nova floresta no Azure e criar uma confiança do Active Directory do Windows Server entre a floresta local e a floresta de nuvem. Se o aplicativo tiver reconhecimento de declaração, no entanto, você poderá implantar a confiança de federação em vez da confiança de floresta do Active Directory. Outro fator será o custo de replicar mais dados estendendo seu Active Directory do Windows Server local para a nuvem ou gerenciar mais tráfego de saída como resultado da autenticação e da carga de consulta.

Os requisitos para disponibilidade e tolerância a falhas também afetam sua escolha. Por exemplo, se o link for interrompido, os aplicativos que usam uma confiança de Kerberos ou uma confiança da federação provavelmente serão todos descontinuados totalmente a menos que você tenha implantado a infraestrutura suficiente no Azure. As configurações alternativas de implantação como os DCs de réplica (graváveis ou RODCs) aumentam a probabilidade de ser capaz de tolerar interrupções de link.

Você precisa definir corretamente os sites e os links de site para otimizar o tráfego e minimizar o custo. Os sites, os links de site e as sub-redes afetam a topologia de replicação entre os DCs e o fluxo de tráfego de autenticação. Considere os seguintes encargos de tráfego e, em seguida, implante e configure os DCs de acordo com os requisitos do seu cenário de implantação:

  • Há uma taxa nominal por hora para o próprio gateway:

    • Pode ser iniciado e interrompido como você desejar

    • Se for interrompido, as máquinas virtuais do Azure serão isoladas da rede corporativa

  • O tráfego de entrada é livre

  • O tráfego de saída é cobrado de acordo com a Visão geral de preços do Azure. Você pode otimizar as propriedades do link de site entre sites locais e sites na nuvem da seguinte maneira:

    • Se você estiver usando várias redes virtuais, configure os links de site e seus custos apropriadamente para impedir que o AD DS do Windows Server priorize o site do Azure sobre um que possa fornecer os mesmos níveis de serviço sem custos. Você também pode desabilitar a opção de fazer a ponte de todos os links de site (BASL), habilitada por padrão. Isso garante que apenas os sites conectados diretamente repliquem uns com os outros. Os DCs em sites conectados transitivamente não podem mais replicar diretamente uns com os outros. Em vez disso, eles devem replicar por meio de um site ou sites comuns. Se os sites intermediários se tornarem indisponíveis por algum motivo, a replicação entre os DCs em sites conectados transitivamente não ocorrerá mesmo se a conectividade entre os sites estiver disponível. Finalmente, onde as seções do comportamento de replicação transitiva permanecer desejável, crie pontes de link de site que contenha os links de site e os sites apropriados, como, por exemplo, sites locais de rede corporativa.

    • Configurar custos de link de site corretamente para evitar o tráfego não intencional. Por exemplo, se a configuração Tentar Site mais Próximo estiver habilitada, verifique se os sites de rede virtual não estão mais próximos aumentando o custo associado do objeto do link de site que se conecta ao site do Azure de volta para a rede corporativa.

    • Configurar intervalos de link de site e agendas de acordo com os requisitos de consistência e taxa de alterações do objeto. Alinhe a agenda de replicação com a tolerância de latência. Os DCs replicam somente o último estado de um valor; portanto, diminuir o intervalo de replicação pode economizar custos se houver uma taxa suficiente de alteração do objeto.

  • Se for uma prioridade minimizar o custo, verifique se a replicação está agendada e se a notificação de alteração não está habilitada. Essa é a configuração padrão ao replicar entre sites. Isso não será importante se você estiver implantando um RODC em uma rede virtual porque o RODC não replicará nenhuma alteração de saída. Mas se você implantar um DC gravável, deverá ter certeza de que o link do site não está configurado para replicar atualizações com frequência desnecessária. Se você implantar um servidor do catálogo global (GC), verifique se todos os outros sites que contêm um GC replicam as partições de domínio de uma DC de origem em um site que está conectado com um link de site ou links de site que têm um custo mais baixo que o GC no site do Azure.

  • É possível reduzir ainda mais o tráfego de rede gerado pela replicação entre sites alterando o algoritmo de compactação de replicação. O algoritmo de compactação é controlado pela entrada do registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator de REG_DWORD. O valor padrão é 3, que se relaciona com o algoritmo de compactação Xpress. Você pode alterar o valor para 2, que altera o algoritmo para MSZip. Na maioria dos casos, isso aumentará a compactação, mas fará isso às custas da utilização da CPU. Para obter mais informações, consulte Como funciona a topologia de replicação do Active Directory.

As máquinas virtuais do Azure recebem "endereços concedidos via DHCP" por padrão. Como os endereços dinâmicas da rede virtual do Azure persistem com uma máquina virtual durante o tempo de vida da máquina virtual, os requisitos do AD DS do Windows Server são atendidos.

Como resultado, quando você usa um endereço dinâmico no Azure, está de fato usando um endereço IP estático porque ele é roteável para o período da concessão e o período da concessão é igual ao tempo de vida do serviço de nuvem.

No entanto, o endereço dinâmico será desalocado se a VM for desligada. Para impedir que o endereço IP seja desalocado, você pode usar o cmdlet Set-AzureStaticVNetIP para atribuir um endereço IP estático.

Para a resolução de nomes, implante sua própria infraestrutura de servidor DNS (ou utilize uma existente); o DNS fornecido pelo Azure não atende às necessidades avançadas de resolução de nomes do AD DS do Windows Server. Por exemplo, ele não oferece suporte a registros dinâmicos de SRV, e assim por diante. A resolução de nomes é um item de configuração fundamental para os DCs e clientes unidos por domínio. Os DCs devem ser capazes de gravar registros de recursos e resolver registros de recursos de outro DC.

Por razões de tolerância a falhas e desempenho, é ideal instalar o serviço de DNS do Windows Server nos DCs em execução no Azure. Em seguida, configure as propriedades da rede virtual do Azure com o nome e o endereço IP do servidor DNS. Quando outras VMs na rede virtual forem iniciadas, seus parâmetros de resolvedor de cliente DNS serão configurados com o servidor DNS como parte da alocação de endereços IP dinâmicos.

noteObservação
Você não pode unir computadores locais a um domínio do Active Directory AD DS do Windows Server que é hospedado no Azure diretamente pela Internet. Os requisitos de porta para o Active Directory e a operação de ingresso no domínio consideram impraticável expor diretamente as portas necessárias e, de fato, um DC inteiro, para a Internet.

As máquinas virtuais registram seu nome DNS automaticamente na inicialização ou quando há uma alteração de nome.

Para obter mais informações sobre esse exemplo e outro exemplo que mostra como provisionar a primeira VM e instalar o AD DS nela, consulte Instalar uma nova floresta do Active Directory no Windows Azure. Para obter mais informações sobre como usar o Windows PowerShell, consulte a Introdução ao Azure PowerShell e Cmdlets de gerenciamento do Azure.

O Windows Azure oferece vantagens ao hospedar vários DCs em redes virtuais diferentes:

  • Tolerância a falhas multissite

  • Proximidade física a filiais (latência mais baixa)

Para obter mais informações sobre como configurar a comunicação direta entre redes virtuais, consulte Configure conectividade VNet para VNet.

Você precisa escolher se deseja implantar DCs somente leitura ou graváveis. Você pode desejar implantar RODCs porque você não terá o controle físico sobre eles, mas RODCs são criados para serem implantados em locais onde a segurança física está em risco, como filiais.

O Windows Azure não apresenta os riscos de segurança física de uma filial, mas os RODCs ainda podem ser mais econômicos, já que os recursos que eles fornecem são apropriados para esses ambientes, embora por razões muito diferentes. Por exemplo, os RODCs não têm nenhuma replicação de saída e pode, popular seletivamente segredos (senhas). O lado negativo é que a falta desses segredos pode exigir que o tráfego de saída sob demanda valide-os quando um usuário ou computador autenticar. Mas os segredos podem ser seletivamente preenchidos previamente e armazenados em cache.

Os RODCs fornecem uma vantagem adicional sobre as preocupações de HBI e PII porque você pode adicionar atributos que contêm dados confidenciais ao conjunto de atributos filtrados do RODC (FAS). O FAS é um conjunto de atributos personalizável que não é replicado para RODCs. Você pode usar o FAS como proteção caso não possa ou não queira armazenar PII ou HBI no Windows Azure. Para obter mais informações, consulte Conjunto de atributos filtrados RODC.

Verifique se esses aplicativos serão compatíveis com os RODCs que você planeja usar. Muitos aplicativos habilitados para Active Directory do Windows Server funcionam bem com RODCs, mas alguns aplicativos podem executar de maneira ineficiente ou falharem se não tiverem acesso a um DC gravável. Para obter mais informações, consulte Guia de compatibilidade de aplicativos dos DCs somente leitura.

Você precisa escolher se deseja instalar um catálogo global. Em uma única floresta de domínio, você deve configurar todos os DCs como servidores do catálogo global (GC). Isso não aumentará o custo porque não haverá nenhum tráfego adicional de replicação.

Em uma floresta de vários domínios, os GCs são necessários para expandir as associações de grupo universais durante o processo de autenticação. Se você não implantar um GC, as cargas de trabalho na rede virtual que são autenticadas em um DC no Windows Azure gerarão indiretamente tráfego de saída de autenticação para consultar GCs locais durante cada tentativa de autenticação.

O custo associado com os GCs é menos previsível porque eles hospedam todos os domínios (parcialmente). Se a carga de trabalho hospedar um serviço da Internet e autenticar usuários no AD DS do Windows Server, os custos poderão ser completamente imprevisíveis. Para ajudar a reduzir consultas de GC fora do site de nuvem durante a autenticação, você poderá habilitar o Caching universal de associação de grupo.

Você precisa escolher como instalar os DCs na rede virtual:

Use apenas Máquinas Virtuais do Azure para DCs (em vez de VMs de funções "web” ou “de trabalho” do Windows Azure). Eles são duráveis e a durabilidade de estado para um DC é necessária. As Máquinas Virtuais do Azure são criadas para cargas de trabalho como DCs.

Não use SYSPREP para implantar ou clonar DCs. A capacidade de clonar DCs está disponível somente a partir do Windows Server 2012. O recurso de clonagem exige compatibilidade com VMGenerationID no hipervisor subjacente. O Hyper-V no Windows Server 2012 e nas Redes Virtuais do Windows Azure são compatíveis com VMGenerationID, da mesma forma que os fornecedores de software de virtualização terceirizados.

Selecione onde localizar o banco de dados, os logs e o SYSVOL do AD DS do Windows Server. Eles devem ser implantados em discos de dados do Azure. “

noteObservação
Os discos de dados do Azure são restritos a 1 TB.

As unidades de disco de dados não armazenam gravações em cache por padrão. As unidades de disco de dados conectadas a uma VM usam o cache de gravação. O cache de gravação assegura que a gravação seja confirmada no armazenamento durável do Azure antes que a transação seja concluída sob a perspectiva do sistema operacional da VM. Ele fornece a durabilidade, às custas de gravações um pouco mais lentas.

Isso é importante para o AD DS do Windows Server porque a gravação por trás do cache de disco invalida as suposições feitas pelo DC. O AD DS do Windows Server tenta desabilitar o cache da gravação, é tarefa do sistema de E/S do disco fazer isso. Se houver falha para desabilitar o cache de gravação, isso poderá, em determinadas circunstâncias, introduzir a reversão de USN resultando em objetos persistentes e outros problemas.

Como prática recomendada para DCs virtuais, faça o seguinte:

  • Defina a configuração Preferência de Cache do Host no disco de dados do Azure como NENHUMA. Isso evita problemas com o cache de gravação para operações do AD DS.

  • Armazene o banco de dados, os logs e o SYSVOL no mesmo disco de dados ou em discos de dados separados. Normalmente, esse é um disco separado do disco usado para o próprio sistema operacional. A consideração importante é que o SYSVOL e o banco de dados do AD DS do Windows Server não devem ser armazenados em um tipo de disco do sistema operacional Azure. Por padrão, o processo de instalação do AD DS instala esses componentes na pasta %systemroot%, que NÃO é recomendada para o Azure.

Lembre-se do que tem e não tem suporte para backup e restauração de um DC em geral, e mais especificamente, as executadas em uma VM. Consulte Considerações sobre backup e restauração para DCs virtualizados.

Crie backups do estado do sistema usando apenas o software de backup que está especificamente ciente dos requisitos de backup para o AD DS do Windows Server, por exemplo, o Backup do Windows Server.

Não copie nem clone arquivos de VHD de DCs em vez de executar backups regulares. Se uma restauração for necessária, fazer isso usando VHDs clonados ou copiados sem o Windows Server 2012 e um hipervisor com suporte introduzirá bolhas de USN.

A configuração dos servidores de federação (STSs) do AD FS do Windows Server depende em parte se os aplicativos que você deseja implantar no Azure precisam acessar os recursos em sua rede local.

Se os aplicativos atenderem aos seguintes critérios, você poderá implantar os aplicativos isoladamente de sua rede local.

  • Eles aceitam tokens de segurança de SAML

  • Eles são expostos à Internet

  • Eles não acessam os recursos locais

Nesse caso, configure os STSs do AD FS do Windows Server da seguinte maneira:

  1. Configure uma floresta isolada de domínio único no Azure.

  2. Forneça acesso federado à floresta configurando um farm de servidores de federação do AD FS do Windows Server.

  3. Configure o AD FS do Windows Server (farm de servidores de federação e farm de proxy de servidor de federação) em uma floresta local.

  4. Estabeleça uma relação de confiança da federação entre as instâncias locais e do Azure do AD FS do Windows Server.

Por outro lado, se os aplicativos precisarem acessar os recursos locais, você poderá configurar o AD FS do Windows Server com o aplicativo no Azure da seguinte maneira:

  1. Configure a conectividade entre redes locais e do Azure.

  2. Configure um farm de servidores de federação do AD FS do Windows Server em uma floresta local.

  3. Configure um farm de proxy de servidores de federação do AD FS do Windows Server no Azure.

Essa configuração tem a vantagem de reduzir a exposição de recursos locais, semelhante à configuração do AD FS do Windows Server com aplicativos em uma rede de perímetro.

Observe que, em qualquer cenário, você poderá estabelecer relações de confiança com mais provedores de identidade, se a colaboração entre negócios for necessária.

Os serviços de nuvem serão necessários se você quiser expor uma VM diretamente à Internet ou expor um aplicativo com balanceamento de carga com a Internet. Isso é possível porque cada serviço de nuvem oferece um único VIP configurável.

Cada máquina virtual do Azure recebe um DIP. Um DIP é um endereço privado acessível somente dentro do Azure. Na maioria dos casos, porém, será necessário configurar um VIP para suas implantações do AD FS do Windows Server. O VIP é necessário para expor pontos de extremidade do AD FS do Windows Server para a Internet, que serão usados por parceiros e clientes federados para autenticação e gerenciamento contínuo. Um VIP é uma propriedade de um serviço de nuvem que contém uma ou mais máquinas virtuais do Azure. Se o aplicativo com reconhecimento de declaração implantado no Azure e o AD FS do Windows Server forem para a Internet e compartilharem portas comuns, cada um exigirá um VIP próprio e, em virtude disso, será necessário criar um serviço de nuvem para o aplicativo e um segundo para o AD FS do Windows Server.

Para obter definições dos termos VIP e DIP, consulte Termos e definições.

Quando for possível implantar serviços autônomos da federação do AD FS do Windows Server, é recomendável implantar um farm com pelo menos dois nós para STS do AD FS e proxies para ambientes de produção.

Consulte Considerações sobre a topologia de implantação do AD FS 2.0 no Guia de design do AD FS 2.0 para decidir quais opções de configuração de implantação melhor se adaptam a suas necessidades específicas.

noteObservação
Para obter o balanceamento de carga para os pontos de extremidade do AD FS do Windows Server no Azure, configure todos os membros do farm do AD FS do Windows Server no mesmo serviço de nuvem e use o recurso de balanceamento de carga do Azure para portas HTTP (padrão 80) e HTTPS (padrão 443). Para obter mais informações, consulte Investigação do balanceador de carga do Azure.

O balanceamento de carga de rede do Windows Server (NLB) não tem suporte no Azure.

Mostrar:
© 2014 Microsoft