O que fazer – meus usuários não conseguem se conectar no Outlook (parte 2)
By: Caio Ribeiro César e Cesar Augusto Hara
Mais de um ano se passou desde a última vez que escrevemos sobre este problema, e um dos tópicos líderes em suporte ainda é a conectividade do Outlook com o Exchange Online.
O troubleshooting varia muito em clientes federados e não federados. Este artigo foca na parte de troubleshooting em um ambiente 100% Cloud e federado (ADFS 3.0 &WAP).
Quando falamos em autenticação, ela pode ser ativa ou passiva. Um usuário se autenticando no portal adiciona suas informações pela web categoriza uma autenticação passiva – já uma conexão pelo Outlook, categoriza uma autenticação ativa.
Cenário: alguns usuários estão reclamando que não podem se conectar no Outlook. O acesso ao portal e OWA funciona sem problemas.
Neste cenário, uma das primeiras etapas de suporte é isolar o problema. Efetuamos acesso ao “EXRCA” e selecionamos a opção “Office 365> Outlook Connectivity”.
Em etapas, o teste irá coletar as informações da mailbox via autodiscover, autenticar o usuário e simular uma conexão com o Exchange Online (OAnywhere).
Na primeira etapa do teste de conexão, podemos ver o seguinte erro:
“An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN). HTTP Response Headers: request-id: 73238ecc-cdbc-492db5a X-CalculatedBETarget: ro1pr80mb1994.lamprd80.prod.outlook.com X-FEServer: DM2PR30CA0055 Content-Length: 0 Cache-Control: private Date: Fri, 12 Aug 2016 12:55:23 GMT Server: Microsoft-IIS/8.0 WWW-Authenticate: Basic Realm="" X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET “
Ao efetuar os testes automáticos do Outlook, temos o seguinte resultado em uma rede interna:
O httpstatus 401 (Unauthorized) confirma o problema de “authentication needed” para a conta.
Antes de pular para a conclusão e resolução do incidente, é necessário entender como o um token request de autenticação ativa funciona.
Conforme indicamos, uma autenticação Outlook classifica uma autenticação ativa. Isso significa que o processo de autenticação é:
- O usuário final efetua o login no computator que está na rede (AD);
- Outlook é iniciado;
- O Outlook envia um request de conexao para o Exchange Online (ExO), que pede Basic Credential;
- O Outlook responde com basic credential;
- O ExO chama o servico de Authentication Platform (AP/responsável pela autenticação dos requests de serviços do O365) para validar se o domínio federado está registrado. Se sim, ele informa o endpoint do ADFS;
- ExO leva a autenticação do cliente para o ADFS e faz o pedido de token;
- O ADFS consome o basic credential, autentica o usuário no AD e gera um ticket (contendo as informações sobre o objeto, tais como UPN/ImmutableID);
- O token retorna para o ExO, que encaminha o token que foi recebido do ADFS para o AP;
- O AP valida que o token foi assinado pelo ADFS trusted authority, e gera o novo token: que por sua vez é enviado para o ExO.
- ExO valida o token recebido pelo AP, checa que foi assinado pelo trusted party (OrgId) e libera o acesso para o usuário final.
Embora na rede interna, o cliente Outlook não se comunica diretamente com seu servidor AD FS. O Office 365 é responsável por essa interação, e por este motivo estamos lidando com uma solicitação de autenticação externa.
Continuando a análise do problema, vamos ao servidor AD FS. Investigamos logs do Event Viewer > Applications and Services Logs > AD FS:
Para este cenário encontramos o evento de erro 325: 
As mensagens destacadas são bem descritivas: “The Federation Service could not authorize token issuance for caller” e “See event 501 with the same Instance ID for caller identity.”
Procure pelos eventos 501 no servidor e observe que diversas informações dos claims são exibidas, como IP de origem e group membership:
Na maioria dos casos, quando o evento 325 é gerado, existe uma regra de bloqueio externo no AD FS,
ou Claim Authorization Rule.
Para confirmar, abra a console do AD FS e navegue até: Trust Relationships > Relying Party Trusts >
Clique com botão direito no RP do Office 365 e selecione a opção "Edit Claim Rules". Clique em Issuance Authorization Rules:
Clique em Edit Rule e verifique se o endereço IP que aparece no evento 501 (no nosso cenário, 187.75.105.36) está incluso na regra:
Inclua o IP utilizando o modelo de claim rules regular expressions (caso o mesmo seja da sua organização) e faça o teste novamente:
Resultado após o teste:
Em resumo, a regra de bloqueio estava funcionando de maneira correta - pois o IP que vimos no evento 501 não havia sido adicionado. Alterações/inclusões de IP público acontecem regularmente e por esse motivo é necessário que essa informação seja sempre incluída na regra.
Outro problema que acontece frequentemente é o bloqueio/liberação por grupo. Basta olhar os eventos 501 e verificar se o SID do grupo que existe na regra também aparece na lista de SID de usuários.
Caso os eventos padrões de AD FS não diagnostiquem o problema corretamente, outro método utilizado para troubleshooting é o de auditoria do AD FS.
- Maiores informações com possíveis soluções em códigos de erro ADFS.
Comments
- Anonymous
October 11, 2017
Excelente post. Informações muito importantes!