Arquivo mensal: novembro 2013

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.

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….

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;

3) Agora que o objeto se encontra como deletado no Office 365, basta restaurarmos o mesmo para a listagem de usuários ativos;

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 ;

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;

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!

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!

Anúncios