O que fazer - meus usuários não conseguem se logar no Outlook (ADFS 2.0+ADFS Proxy 2.0)
By: Caio Ribeiro César e Nuno Tavares
O dia a dia do suporte consiste em receber chamadas referentes a serviços de federação. O Single Sign On (SSO) pode ser efetuado pelo ADFS 2.0 (Ws2008) ou ADFS 3.0 (Ws2012) – cada cenário possui um troubleshooting diferente, porém o entendimento da arquitetura e do serviço é muito parecido.
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.
Vamos então ao cenário: um cliente liga para o suporte informando que nenhum usuário se conecta externamente utlizando o Outlook.
As primeiras perguntas seriam: você possui algum serviço de federação implementado (ADFS)? Os usuários conseguem se logar no portal?
Se as respostas foram sim e não respectivamente, podemos estar lidando com um problema de federação. Existe uma maneira de coletar dados que possam nos ajudar a chegar a esta conclusão – eliminando assim precipitações.
Uma das maneiras é coletar informações do Autodiscover. Mais especificamente, efetuar um EXRCA para o teste de descoberta automática para algum usuário que possa reproduzir o problema:
Neste teste, podemos expandir todos os resultados e coletar a seguinte informação:
X-AutoDiscovery-Error: LiveIdBasicAuth:FederatedStsUnreachable:<X-forwarded-for:>
<FederatedSTSFailure>System.Net.WebException: The remote server returned an error: (403) Forbidden. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
Temos então o entendimento que o serviço de autodiscover tentou efetuar uma autenticação com o STS (ADFS), porém este estava “unreachable” com o HTTP status code 403 Forbidden.
O cliente nos informa que o serviço de SSO funciona internamente. Isto nos leva a crer em algo externo (proxy/firewall) ou algum problema com a comunicação externa do serviço de autenticação.
Temos sempre que lembrar em focar em algo chamado “Troubleshooting Framework”. O framework consiste basicamente em: scoping, data collection, analysis, action plan.
Isto significa que o correto é não assumir nenhum comportamento ou plano de ação precipitado antes de obter os logs necessários e consequentemente a análise dos mesmos.
O segundo passo para o entendimento do problema é fazer uma análise geral no serviço de SSO, com o seguinte plano de ação:
1) Obter a mensagem de erro do usuário que tenta efetuar o login pelo portal;
2) Testar o federationmetadata externamente (usuários fora da rede interna);
3) Coletar um EXRCA SSO (exrca.com > Office 365 Single Sign-On Test) para algum usuário que possa reproduzir o problema.
1) Simulamos um acesso ao portal e recebemos a mensagem de erro abaixo:
Problema ao acessar o site. Tente navegar até o site novamente.
Se o problema persistir, contate o administrador do site e forneça o número de referência para identificar o problema.
Número de referência: 791f8e07-1ct5-4c9c-d132-76faf7108864
2) Tentamos acessar a url de metadata ( https://sts.c4iocesar.com/federationmetadata/2007-06/federationmetadata.xml ) porém a página web ficou em branco.
Ao efetuar um simples trace pelo internet explorer (F12>Network) recebemos a mensagem de erro:
GET HTTP 403
3) O resultado da coleta de SSO foi:
Com os dados coletados, podemos entender que o serviço que é publicado externamente está nos retornando uma resposta HTTP indesejada (403). Existem algumas maneiras de focar o troubleshooting para a próxima coleta de dados:
Opção 1) Já possuímos o Correlation ID “791f8e07-1ct5-4c9c-d132-76faf7108864” em um dos testes efetuados. Podemos habilitar um debug trace no ADFS e analizar os logs desta conexão, como demonstrado no exemplo:
Opção 2) Coletar um trace sem criptografia de uma sessão WEB para o serviço de federação utilizando a ferramenta Fiddler.
Opção 3) Exportar os logs de evento de ambos ADFS e ADFS Proxy.
A opção 1 nos ajudaria a obter mais informações do motivo da falha da conexão específica, nos dando uma idéia do que pode estar ocorrendo de errado no serviço de federação.
A opção 2 nos ajudaria a ter um log detalhado da falha tendo em vista um trace “Man in the Middle”, tendo assim um entendimento do que ocorre para o usuário final que tenta se conectar pelo browser.
A opção 3 é a mais simples e objetiva. Exportaríamos informações do que ocorre nos servidores que fazem parte do serviço de federação – esta opção faria mais sentido para uma análise rápida e objetiva – já que nenhum usuário esta conseguindo se autenticar pelo STS.
Pelo fato de que usuários conseguem se autenticar internamente, iremos coletar primeiro informações do ADFS Proxy. Exportamos então para .csv os logs de event viewer:
AD FS 2.0 364
"Erro durante a solicitação passiva da federação”
Dados Adicionais
Detalhes da exceção:
System.ServiceModel.Security.MessageSecurityException: Uma falha protegida incorretamente ou não protegida foi recebida da outra parte. Veja a FaultException interna para obter detalhes do código da falha. ---> System.ServiceModel.FaultException: An error occurred when verifying security for the message.
AD FS 2.0 248
O proxy do serviço de federação não pôde recuperara a lista de pontos de extremidade do Serviço de Federação em sts.c4iocesar.com. A mensagem de erro é 'Uma falha protegida incorretamente ou não protegida foi recebida da outra parte. Veja a FaultException interna para obter detalhes do código da falha.'.
Ação do Usuário - Verifique se o Serviço de Federação está em execução. Solucione os problemas de conectividade de rede. Se a confiança entre o proxy do serviço de federação e o Serviço de Federação for perdida, execute novamente o Assistente de Configuração de Proxy do Servidor de Federação.
AD FS 2.0 394
O proxy do serviço de federação não conseguiu renovar sua confiança com o Serviço de Federação.
Detalhes da exceção: Uma falha protegida incorretamente ou não protegida foi recebida da outra parte. Veja a FaultException interna para obter detalhes do código da falha.
Ação do Usuário: Verifique se o Serviço de Federação confia no proxy do serviço de federação. Se a confiança não existir ou tiver sido revogada, estabeleça uma relação de confiança entre o proxy e o Serviço de Federação usando o Assistente de Configuração de Proxy do Servidor de Federação fazendo logon no computador proxy."
Podemos confirmar que o trust entre ADFS<>ADFS Proxy está “quebrado”. O serviço de ADFS Proxy renova seu token com o ADFS periodicamente a cada 4 horas, e segundo as informações dos eventos 364/394 isto não está sendo feito.
Este problema pode demonstrar exatamente o que está ocorrendo – falha em acessos externos sendo eles autenticações passivas ou ativas e também o sucesso em autenticações internas para o ADFS.
A maneira mais prática e rápida para resolver este problema esta descrita no artigo “Troubleshooting federation server proxy problems with AD FS 2.0”:
| Event ID 394 The federation server proxy could not renew its trust with the Federation Service. | The federation server proxy is not trusted by the Federation Service. Either the trust does not exist, or it was revoked. | Ensure that the federation server proxy is trusted by the Federation Service. If the trust does not exist or has been revoked, renew trust by running the AD FS 2.0 Proxy Configuration Wizard again. |
Após efetuar o rerun, conseguimos com sucesso acessar o metadata externamente:
Para aqueles que ainda estão lendo e querem informações de Root Cause Analysis deste problema:
Assim que resolvemos o incidente de acesso, validamos que o certificado do ADFS havia expirado e o processo de renovação já havia sido efetuado, porém o trust do ADFS Proxy não havia sido estabelecido.
Para mais informações de como resolver este problema:
Scenario 1 : The AD FS token-signing certificate expired