Fase 1: Assessment

 

• Relatórios de saúde e pré-requisitos

Obviamente temos alguns critérios a serem vistos antes de iniciarmos a replicação do AD da organização com o Azure AD. Existem algumas ferramentas que nos dizem o estado de saúde atual do ambiente On-Premises, e também se os objetos do AD estão aptos a serem sincronizados.

Em primeiro lugar nos devemos utilizar o IDFIX para ver a atual situação dos objetos no AD. Basicamente o IDFIX faz uma query LDAP no Active Directory e procura por erros que possam vir a ser problemas na sincronização com o Office 365. Listarei os erros mais comuns que o IDFIX encontrará:

TopLevelDomain: Se refere ao tema já abordado de usuários com o UPN não roteáveis (user1@contoso.local)

Character: Campos com caracteres não reconhecidos, como e-mails ou UPN que possuem vírgula, apóstrofe ou acento.

Duplicate: Campos que contem valores duplicados.

Em segundo lugar nos podemos verificar que tipo de contrato a organização tem com a Microsoft. Se houver um suporte premier, sugiro que seja solicitado a Microsoft a execução do RAP as a Service for Active Directory e do RAP as a Service for Exchange Server. Para saber mais sobre isso, segue veja esse link. Caso não exista a possibilidade de realizar o RAP as a Service, sugiro que veja a saúde do ambiente com as ferramentas convencionais, como o BPA do Exchange Server e as ferramentas DCDIAG e REPADMIN para validar a saúde do Active Directory.

Por último e não menos importante, o famoso Remote Connectivity Analyzer. É importante realizar testes, sobretudo de Synchronization, Notification, Availability, and Automatic Replies. Valide que está tudo OK, caso contrário deixe o ambiente 100% antes de iniciar a migração.

• Deixar o ambiente Up-to-Date

De uma forma sucinta, a recomendação da Microsoft é aplicar sempre o último rollup em todos os Exchange Servers da organização.

Considerando que o tema abordado é a migração do Exchange Server 2010, segue o link seguindo as boas práticas da Microsoft de como aplicar o último rollup no Exchange Server 2010.

• Certificado SSL

Basicamente nós precisamos de um certificado confiável para duas coisas; a primeira é a realização da federação com o Office 365, não é possível sem um certificado confiável. A segunda é para a configuração TLS no servidor hibrido.

Em ambos os casos, wildcard são suportados – certificados com caracter coringa, ex: *.contoso.com. Caso o cliente já possua um certificado WildCard, não existe a necessidade de compra de um novo certificado. Se acaso o cliente não possua o Wildcard, não tem jeito, informe que já seja contemplado a compra de um certificado. Por boa prática é recomendado se usar o nome sts para a URL da federação. Sendo assim, compre o certificado – se nao quiser wildcard – como sts.seudominio.com. A título de curiosidade, o nome sts se refere a Security Token Server.

A decisão de qual tipo de certificado comprar será baseada na particularidade de cada organização. Em boa parte dos casos, um wildcard atende perfeitamente a demanda, porem em outros casos não. Exemplo, um projeto que realizei de uma empresa que possuía 3 dominios diferentes, e todos seriam federados. Nesse caso, um wildcard não atenderia bem, pois digamos que os domínios sejam:

Contoso.com
Exemplo.com
Exemplo2.com

O Wildcard não pode ser usado nesse caso, pois ele trabalha apenas com o primeiro nível de subdomínio, por exemplo:

Exemplo.contoso.com
Exemplo2.contoso.com
*.contoso.com

Nesse caso cuja o qual os nomes dos domínios são diferentes, minha recomendação é comprar um certificado normal para o domínio principal – ex: sts.contoso.com – e adicionar os outros domínios como subject alternative name – ex: sts.exemplo.com e sts.exemplo2.com.

No caso do certificado para o Exchange Hybrid, o mesmo deverá ser o mesmo namespace do Exchange publicado externamente, por exemplo: mail.contoso.com

Segue aqui as recomendações da Microsoft voltadas a certificados:

• Desenhar a futura infraestrutura da organização

Agora que basicamente já possuímos todas as informações necessárias para a migração, nos resta desenhar a solução para o cliente.

A primeira coisa importante a ser considerada, é entender bem as opções e diferenças que temos para implementar a parte de acesso e identidade. Nos projetos em que realizei, os clientes sempre acabavam optando por federar o ambiente utilizando o Active Directory Federation Services. Porém nossa tarefa é explicar o benefício de cada opção, para que eles escolham que caminho trilhar. Indico portanto a leitura desse artigo, que aborda justamente a diferença entra cada opção de gestao de identidade.

No caso desse projeto, escolheremos a opção por federar o acesso ao Office 365, utilizando o ADFS.

Dessa forma, temos alguns requisitos a serem cumpridos. No geral, a boa pratica é ao menos 2 servidores ADFS internos para balanceamento de carga, e dois servidores na DMZ – Rede de perímetro – fazendo a parte de Proxy Reverso – WAP – para autenticações externas, ambos também com balanceamento de carga.

Como já mencionado, por haver um Load Balance BigIP, descartamos a hipótese do NLB do Windows. Mas para empresas que não possuem uma ferramenta terceira de balanceamento, o NLB poderá ser usado como solução para ambos os casos – ADFS e WAP.

Lembrando que para a função de proxy, é possível utilizar ferramentas terceiras – Bluecoat proxysg, UAG e TMG por exemplo. Segue uma documentação da Microsoft abordando os requisitos necessários. Essa documentação contém uma tabela comparativa entre o WAP e o UAG e TMG

Considere também a necessidade de um servidor para o Azure AD Connect. Ele será o responsável por sincronizar os usuários on-premises no Office 365. Os requisitos de hardware podem serem vistos aqui.

• Verificar se a Recycle Bin do Active Directory está habilitada

A Microsoft recomenda fortemente que a lixeira do AD esteja habilidata.

Esse é o ultimo post da fase de Assessment, a partir de agora iniciaremos o processo de migraçao, começando pela fase de instalaçao da estrutura de SSO (ADFS e WAP) e do Azure AD Connect.