Implementação das soluções de Federação e Azure AD Connect – Parte 2
- Setup do Azure AD Connect
Com todos os pontos acima realizados, podemos prosseguir para o momento ápice – na minha opinião – da instalação. Hoje a Microsoft desenvolveu o Wizard do Azure AD Connect para não apenas a instalação da aplicação que fará a sincronização do AD, mas também para já realizar automaticamente a instalação do ADFS e WAP durante o setup.
É possível não utilizar o setup do Azure AD Connect para instalar a farm de ADFS e WAP? Sim, é possível. Contudo, não irei abordar a instalação manual no artigo. Para quem deseja fazer a instalação manual, eu sugiro a leitura dos artigos abaixo:
https://blogs.technet.microsoft.com/rmilne/2014/04/28/how-to-install-adfs-2012-r2-for-office-365/
Primeiramente, faça o download da ferramenta Azure AD Connect através do seu Tenant.
Download efetuado, começamos a execução do wizard. A primeira opção nossa será Use Express Settings
Em seguida, escolheremos a opção Federate with ADFS
Em Connect to Azure AD, você deverá usar a credencial de administrador global do seu Tenant. Lembre-se que me refiro a uma conta que pertença ao domínio “onmicrosoft.com”. Caso tente logar com uma conta já convertida ao seu domínio, o setup não apresentara nenhum erro no momento, porem no último processo de Verify será relatado um erro, dizendo que você não pode realizar o trust do domino utilizando uma conta do mesmo.
Você deverá ver o seu domínio local como Not Added e seu domínio público como Verified. O parâmetro User Principal Name se refere ao atributo que será usado como username no Office 365. Abordamos isso na fase de assessment, então se você irá utilizar o Alternate Login ID, agora é a hora de ser alterado esse parâmetro. Esteja ciente de todas as limitações que o Alternate Login ID possui antes de usá-lo.
Selecione a sua floresta e Add Directory
O Azure AD Connect necessita de uma credencial Enterprise Admin para poder coletar todos os dados do AD e sincronizar com o Azure AD. No caso, temos a hipótese de usar uma conta já existente ou criar uma nova.
A boa pratica no que se refere a filtering diz que deverá ser replicado apenas os objetos que são necessários. O que isso quer dizer? Se você possui OU com usuários de serviços, ou usuários que jamais serão migrados ao Office 365, filtra-los será o mais indicado.
Notas:
- O container Computers deve ser sempre sincronizado caso deseje sincronizar o Windows 10 com o Azure AD. Se os computadores estiverem em outra OU, deverá ser sincronizada também.
- Havendo trust entre florestas, deverá ser sincronizado o container ForeignSecurityPrincipals.
- A OU RegisteredDevices deve ser sincronizada em caso de utilização da feature Device Write Back. Havendo utilização de qualquer outra feature de Writeback, todas as OUs que tenham objetos utilizados por Writeback deverão ser sincronizadas.
Para mais esclarecimentos, consultar o seguinte documento.
O match entre o Active Directory e o Azure AD eu deixarei como padrão. Esse era um step extremamente importante caso houvesse mais de uma floresta em seu ambiente e pretendesse posteriormente realizar migrações de usuários entre florestas. Porém quando eu digo era, é porque recentemente – Em Maio de 2017, a partir da versão 1.1.524.0 – a Microsoft fez uma ótima melhoria nesse aspecto, foi introduzido o msDS-ConsistencyGuid como o atributo default de sourceAnchor ao inves do objectGUID. Em poucas palavras o objectGUID é um atributo que muda ao se migrar o usuário de floresta, e o msDS-ConsistencyGuid não, o que torna uma dor de cabeça a menos para migrações em ambiente cross-forest. Para maiores detalhes, leia esse artigo.
