Office 365 – Alterando endereço de email @onmicrosoft.com (método alternativo)
Galera,
Voltando ao tópico Office 365, porém desta vez falando sobre sincronização de objetos do Active Directory On-Premises para o Active Directory Azure, na Nuvem.
Este ponto é um dos mais importante em um projeto de Office 365, se deseja ter uma administração centralizada dos usuários, e ainda posteriormente implementar o logon unificado (Single Sign On).
Vários problemas já foram percebidos por analistas durante a implementação e sincronização de objetos entre estes ambientes.
E os pontos de falha mais comuns são atributos inconsistentes, como UPN e Mail diferentes, SIP Addresses conflitando com SMTP Primary, e vários outros.
Porém um dos parâmetros que sempre vem causando problemas e ainda não possui uma “solução homologada” pela Microsoft é o bendito @domain.onmicrosoft.com. Este domínio faz parte da configuração de Routing Address do tenant do Office 365, e é usado para diversas tarefas, dentre elas o redirecionamento de emails usado em migrações parciais.
Há um artigo muito bom de um especialista em Office 365, citando como a Microsoft randomiza os parâmetros afim de criar o endereço de SMTP secundário @onmicrosoft.com. O ambiente valida diversos parâmetros, e se alguns não estiverem preenchidos, ele utiliza outros para definir o padrão a ser usado pelo @onmicrosoft. O artigo está neste link.
Há alguns dias, percebi que a Microsoft liberou uma atualização no tenant do Office 365, que permitia a recuperação de objetos deletados, mesmo se o vínculo com o objeto sincronizado não fosse encontrado.
Resumindo; se você possuía um usuário sincronizado e ele foi “acidentalmente” excluído do AD local, agora pode restaurar o mesmo da Lixeira do Office 365, e torná-lo um Cloud User. Essa é a parte mais importante para nossa solução proposta aqui.
Notem nas imagens abaixo o símbolo dos objetos. Primeiro, é mostrado uma seta dupla, indicando um Usuário Sincronizado. Depois, apenas um ícone simples de boneco, o que indica um Usuário da Nuvem. O usuário sincronizado tem restrições quanto à edições dos atributos, pois os mesmos devem ser definidos no AD local, e depois sincronizados com a nuvem. Como o atributo @onmicrosoft é gerado na primeira sincronização do DirSync, não há como alterar depois da primeira sincronização.
Já o usuário da Nuvem possui a gama de atributos editáveis diretamente neste disponível, uma vez que é o único local de gerenciamento de suas propriedades.
http://blogdolopez.files.wordpress.com/2013/11/image003.jpg?w=604&h=223
Para transformar um usuário sincronizado em um usuário da nuvem, sem ter que deletar o mesmo do Active Directory (AD) local é bem simples.
Então vamos aos seguintes passos:
1) Primeiro, iremos criar uma estrutura no AD que não será sincronizada com a Nuvem. Vamos criar uma Organizational Unit (OU) temporária, e desmarcá-la da sincronização no Forefront Identity Manager (FIM). Falaremos mais sobre o FIM em outras oportunidades….
http://blogdolopez.files.wordpress.com/2013/11/image006.jpg?w=604&h=386
2) Note na imagem acima que as OU’s com a checkbox marcadas serão sincronizadas, e as com as OU’s desmarcadas não serão sincronizadas. Agora, iremos mover o usuário referido para a OU não-sincronizada, fazendo com que o Office 365 entenda que este usuário foi deletado. Após forçar uma sincronização, o mesmo aparecerá como Deleted no FIM, e será movido para a Lixeira do Office 365;
http://blogdolopez.files.wordpress.com/2013/11/image008.jpg?w=604&h=485
3) Agora que o objeto se encontra como deletado no Office 365, basta restaurarmos o mesmo para a listagem de usuários ativos;
http://blogdolopez.files.wordpress.com/2013/11/image019.jpg?w=604&h=119
4) Com o usuário ativo, e definido como “Usuário da Nuvem”, podemos manipular todos seus atributos, inclusive o @onmicrosoft.com. Notem que no Exchange Online ele continua como “Federated User”, porém agora consiga editar seus atributos ;
http://blogdolopez.files.wordpress.com/2013/11/image020.jpg?w=604&h=546
5) Ressalto a importância de realizar a edição do atributo @onmicrosoft com critérios. Repita o mesmo endereço utilizado no UPN e no Mail Attribute do usuário, afim de facilitar a gestão e evitar duplicidade de parâmetros, que podem ocasionar falhas na sincronização de objetos.
6) Agora, basta deletar o usuário do tenant do Office 365, e somente aqui! No AD local o usuário original continua mantido em uma OU não-sincronizada. Isto se torna necessário uma vez que cada objeto do AD possui um ID único e específico, tornando cada usuário individual. Esse ID é sincronizado com a nuvem, o que permite que mesmo após a sua deleção, ele possa ser restaurado e suas informações preservadas;
http://blogdolopez.files.wordpress.com/2013/11/image021.jpg?w=604&h=164
7) Mova seu objeto para a OU correta, que está selecionada para sincronização, e execute um novo sincronismo de objetos do AD local com a Nuvem, afim de garantir o retorno das configurações iniciais de seu objeto, e consequentemente sua gestão centralizada pelo Active Directory. Após o retorno do objeto, seu atributo @onmicrosoft será mantido da forma como alteramos!
http://blogdolopez.files.wordpress.com/2013/11/image022.jpg?w=604&h=321
Pronto!
Já temos um usuário com os atributos corrigidos, e sem perder a centralização da administração do Office 365, mantendo os objetos como sincronizados com o AD local.
Não é uma “solução homologada”, como foi dito anteriormente, porém é de grande ajuda para resolver problemas que podem impactar os projetos e sua execução.
Um abraço e até o próximo post!
Bruno Lopes – MVP Office Servers and Services | Facebook Page | YouTube Channel | Twitter | LinkedIn