Novo Azure AD Connect
Na semana passada a Microsoft liberou a nova ferramenta para sincronização de AD local com o Azure AD. Essa nova ferramenta tem as mesmas funcionalidades das anteriores DirSync e ADDSync, mas acrescesta facilidade na administração do serviço e acesso aos conectores.
Para baixar e ver detalhes: https://azure.microsoft.com/en-gb/documentation/articles/active-directory-aadconnect/
Instalação e Upgrade do Dirsync
Para quem já tem o Dirsync ou o ADDSync instalado o Azure AD Connect irá fazer o upgrade e solicitar apenas a credencial do Azure para configurar, mas após o upgrade é possivel alterar facilmente as configurações.
A sequencia abaixo mostra o upgrade, sendo bem simples pedindo apenas as contas online e on-premisse:
Configuração Pós-Instalação
A interface do Azure AD Connect é realizada com ferramentas gráficas acessiveis pelo Menu Iniciar:
A ferramenta que torna mais fácil configurar como comentado no inicio do artigo é o Synchronization Service, onde ao abrir já é possivel ver os conectores habilitados, o estado da sincronização, log das ultimas sincronizações e utilitários na lateral:
Por exemplo, para sincronizar manualmente basta clicar sobre uma das conexões e escolher como quer sincronizar (Connectors –> Run):
Visualização, Atualização e Criação de Conectores
Ao clicar em qualquer um dos conectores abre-se um wizard onde podemos alterar os conectores básicos ou criar novos conectores.
O wizard é muito simples e funcional, como mostram as imagens abaixo utilizando o Properties:
E para criar novos conectores, ao clicar em Create temos criar os diversos tipos de conectores on-premisse ou online utilizando o wizard das imagens acima.
Vale a pena fazer o upgrade para quem tem o Dirsync e o AADSync, pois esta nova ferramenta é muito completa e simples facilitando o acesso aos configurações, alterações e log das operações.
Integrando o System Center Orchestrator 2012 com o Active Directory
Anteriormente já iniciei alguns testes com o Orchestrator e se trata de uma excelente ferramenta (System Center Orchestrator 2012–Introdução)
A Microsoft disponibilizou a poucos dias (21/12/2011) um pacote para integrar tarefas de AD ao Orchestrator e ficou muito bom com tarefas como bloquear/desbloquear usuários e computadores, criar/editar/deletar usuarios, OUs, grupos e todas as outras tarefas conforme o print abaixo mostra a barra de ferramentas do Orchestrator Designer:
Para instalar estas ferramentas é necessário baixar o pacote em http://www.microsoft.com/download/en/details.aspx?id=28020, fazer a importação do pacote de integração (arquivo com extensão OIP) e distribuir para os servidores desejados. Segue a ordem em que as atividades são realizadas, iniciando com o registro do Integration Pack:
O passo seguinte é distribuir o Integration Pack para os servidores onde a tarefa será executada, lembrando que não tem a ver com os DCs e sim com os servidores que executam os RunBooks:
Ao terminar estará registrado no servidor como mostrado abaixo e irá aparecer automaticamente no Orchestrator Design como mostrado na primeira imagem.
Mais uma interessante funcionalidade a esta ferramenta que irá ser um importante aplicativo na nova familia de produtos System Center 2012.
Virtualizar Domain Controllers–Devo ou não?
Esta pergunta já ouvi inúmeras vezes. Em treinamento, palestras, emails e clientes sempre ouço a pergunta “Porque eu não posso virtualizar o Domain Controller?”
Esta semana em um grande cliente que atendo como consultor da Dell, alguns sites não permitiam logon, o Office Communicator não funcionava e outros problemas. Portanto, acho que este tema é bem apropriado com o crescimento dos ambientes virtualizados.
UPDATE: O Windows Server 2012 introduziu recursos próprios para virtualizar Domain Controllers sem as restrições com o NTP, porem a questão de logar no servidor Hyper-V pode continuar ativa.
Vamos começar com o fato concreto: Ninguem disse que não podem ser virtualizados, e sim que existem fatores a considerar. E é sobre isso que irei escrever.
Posso virtualizar todos os meus Domain Controllers?
Pode, mas terá sérios problemas de segurança e comprometer a réplica se o seu Domain Controller for Windows 2003.
Existem alguns pontos a se considerar ao pensar em virtualizar todos os servidores que podem ser consultados em http://support.microsoft.com/kb/888794/en-us quando vc ainda utilizar DCs com Windows 2000 ou Windows 2003.
Não é a toa que se recomenda ter os FSMOs em servidor fisico, mas falaremos disso daqui a pouco.
Porque virtualizar todos os Domain Controller compromete a segurança?
Neste caso temos duas opções, a primeira deixar o Hyper-V utilizando segurança SAM (local) ou ingressar ele no dominio da VM e as duas podem lhe trazer problemas.
A primeira opção é um sistema de segurança antigo, não baseado em Kerberos e fácil de se quebrar.
A segunda é o risco de ao ter uma queda das VMs ou um desligamento para manutenção ou energia o servidor do Hyper-V não aceitar logon e mostrar a mensagem “No Domain Controllers for Authentication”.
Porque não é recomendado virtualizar FSMOs?
Porque os FSMOs desempenham papeis importantes na estrutura, normalmente é o Global Catalog e tambem o NTP Server.
Caso seja virtualizado as FSMOs o servidor poderá ficar com problemas de sincronização de horários, replicação atrasada, etc.
Se ele estiver em uma VM e esta for desligada por um certo tempo o risco de estar com problemas de USN é maior ainda.
E o pior momento é se o host Hyper-V perder o relógio e atrasar o horário, gerando inconsistencias sérias no AD.
Esta discussão é antiga, desde o inicio do Hyper-V e pode ser acompanhada em http://blogs.technet.com/b/robse/archive/2008/06/16/dc-virtualized-and-external-ntp-servers.aspx
Qual o problema com o NTP Server?
O NTP Server tem a função de ser o sincronizador de horário nos dominios. A principio é feito pelo PDC Emulator.
Maquina fisicas mantem relógio por consultar o RTC (Real Time Clock) na BIOS que é baseado em cristal e após isso o SO passa a usar algoritmos logicos para manter o relógio.
O problema em VMs é que este algoritmo pode ficar comprometido por conta da carga, já que ele não é fisico e sofre interferencia conforme o weight definido para as operações, ou seja, irá atrasar ou adiantar.
Para evitar isso o Hyper-V faz a sincronização usando as Integrations Features, e ai ocorrem as desincronizações e os usuários não conseguem logar, aplicaçoes dão erro, etc.
Ai temos um problema, no documento “Running Domain Controllers in Hyper-V” (http://www.microsoft.com/download/en/details.aspx?id=20164) diz para desligar esta feature dos DCs virtuais.
Por outro lado o blog do PM de virtualização (http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx) diz para não fazer isso.
O problema é muito bem abordado pelo Ben Armstrong e é real. Uma maquina fisica mantem o relógio quando desligada (RTC), mas a virtual não, portanto se todos os DCs forem virtuais e esta opção estiver desabilitada em um desligamento eles irão retornar com o horário em que foram desligados, e quem irá atualizá-los?
Minha Recomendação Final
Siga as práticas do documento “Running Domain Controllers in Hyper-V”, mas sempre tenha um servidor fisico QUE NÃO SEJA O HOST DO HYPER-V.
Configure todas as máquinas, incluindo os hosts do Hyper-V para sincronizar com esta fisica usando Net Time /SetSNTP:<servidor> e assim não terá problema com o relógio, já que o próprio host irá sincronizar com o fisico e consequentemente as VMs com ele.
É isso ai, espero ter ajudado e qualquer acrescimo podem me enviar pelos comentários ou email.