O Safari 7 não pode se conectar à intranet usando autenticação HTTP

Consulte a ATUALIZAÇÃO abaixo para obter novas informações sobre as solicitações HTTP reais em andamento.

Então eu comecei um novo emprego em outubro. É principalmente uma loja do Windows, e eles usam o IIS e o Active Directory para várias coisas internas. Eles têm um site na intranet em intranet.companyname.com.

No Chrome on Mavericks, quando vou para lá, recebo o pequeno menu suspenso esperado de autenticação HTTP:

onde posso digitar meu nome de usuário e senha. Não sou muito ágil com o Active Directory, mas acho que msgdé o domínio do Active Directory em que estou, então digito msgd\lheidbredere minha senha e posso efetuar login com êxito no Chrome.

Em outubro, na primeira vez que tentei isso no Safari, tive um comportamento estranho; vi a coisa da senha, mas não funcionou quando coloquei minhas credenciais. Não me lembro exatamente o que fez.

Mas após essa primeira tentativa, e em todas as tentativas desde então, quando tento acessar intranet.companyname.com, o Safari mostra uma tela em branco:

A tela não muda e a barra de progresso enche cerca de 20% e permanece lá.

ATUALIZAR

Eu executei um aplicativo para bisbilhotar solicitações HTTP e descobri o que isso estava fazendo nos bastidores. Não é só ficar sentado lá; Na verdade, o Safari está solicitando a página quase 1000 vezes por segundo e, a cada vez, ocorre um erro 401 e uma página de erro HTML com o título "Você não está autorizado a visualizar esta página".

Em um exemplo de solicitação do meio de uma tentativa de carregamento, o Safari envia este Authorizationcabeçalho:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

E o servidor responde com este WWW-Authenticatecabeçalho:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWKPhp0o8/Y/9gAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Na próxima solicitação, o Safari envia um Authorizationcabeçalho idêntico e o servidor responde com um WWW-Authenticatecabeçalho ligeiramente diferente :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Repita ad infinitum.

Tentei excluir tudo o que corresponde intranetao Keychain Access e limpar meu cache / cookies inteiros, para ver se eu conseguia restaurar o comportamento estranho original, mas não funcionou.

Eu tenho algum tipo de coisa de domínio funky acontecendo? O que mais posso tentar diagnosticar isso?

Posso confirmar que vejo o mesmo problema no Safari 7.0.2 (9537.74.9), com todas as atualizações atuais do Mac OS X Mavericks instaladas. (Milhares de pacotes de solicitação por segundo com o mesmo tipo de conteúdo descrito acima.)

No entanto, embora isso possa ou não ajudar o pôster original, eu descobri que esse problema ocorre apenas se o servidor Windows tiver Autenticação Integrada do Windows (também conhecida como Autenticação NTLM) e Autenticação de Negociação ativada.

O servidor envia esses dois cabeçalhos:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

O Safari responderá:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

E a partir daí, o loop continuará.

Mas se a opção Negociar autenticação não estiver ativada no servidor, haverá apenas um cabeçalho WWW-Authenticate:

WWW-Authenticate: NTLM

E a resposta do Safari será algo como:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Isso vai funcionar muito bem. Basicamente, parece que o Negotiate está quebrado no Safari e, como o servidor envia o Negotiate primeiro, indicando uma preferência, o Safari tenta e entra em um loop infinito que impede que ele volte ao NTLM.

Portanto, se o administrador do servidor puder ser persuadido a desativar Negociar nas configurações de autenticação, o problema poderá ser resolvido.

Devo acrescentar que o Firefox envia o cabeçalho "Autorização: NTLM ..." independentemente de o servidor fornecer Negociar além do NTLM ou não. Presumivelmente, o Negociar não está implementado no Firefox.

Atualizar

O Safari 7.0.3 (9537.75.14) ainda exibe o mesmo problema.

Anteriormente, relatamos o problema como um bug em bugreport.apple.com, mas o bug foi fechado como duplicado de um bug anterior - cujo conteúdo não podemos ver, exceto que ainda está marcado como aberto.

Atualização 2

Posso confirmar a descoberta de hauns de que a autenticação funciona com o Safari 7.0.4 (9537.76.4).

Atualização 3

Este problema está de volta no Safari 7.0.5 (9537.77.4)

Atualização 4

Esse problema ainda está presente no Safari 7.0.6 (9537.78.2), conforme observado por hauns, com volumes cifs ou smb montados.

O Safari 7.0.5 ainda tem o problema: a autenticação falha se o localizador compartilhar recursos de rede via SMB: (ou CIFS :). Uma vez que todos os volumes de rede conectados são desmontados, o Safari retoma a autenticação adequada.

Regressão:

1. presente no Yosemite 10.10.1 / Safari 8.0.2
2. presente no El Capitan 10.11.2 / Safari 9.0.2
3. presente no Safari 10.0.1

O bug correspondente da Apple 22990203 ainda está ativo. Nenhum mortal pode vê-lo (cf.bugreporter.apple.com)

Consulte também: https://discussions.apple.com/message/27727310#27727310

Estamos tendo o mesmo problema. Por isso, ainda não atualizamos nossos Macs para o Mavericks. Parece tentar entrar na Intranet sem credenciais de domínio (Intranet \ 'blank'). Deve estar usando o domínio \ nome de usuário. Eu posso entender que isso pode ser frustrante, mas parece que falta autenticação no safari.

Eu apenas alguns segundos ele vai explodir logs.

O Firefox parece funcionar muito bem.

Pode ser um tiro no escuro, mas se você tiver um tíquete Kerberos (de entrar em outro serviço), o Safari pode estar tentando usá-lo.

Abra / Sistema / Biblioteca / CoreServices / Ticket Viewer.app para verificar se você possui tickets do Kerberos. Nesse caso, clique no ticket, Remover identidade e tente novamente.

Como alternativa, se nada estiver listado, tente usar Adicionar identidade e verifique se isso funciona com o Safari.

O Firefox e o Chrome não utilizam o Kerberos, eu acho, e é por isso que eles solicitarão credenciais separadamente.

Chaveiros foi uma boa idéia, mas você não foi longe o suficiente.

No Safari, se você olhar no Safarimenu, verá Reset Safari...Selecione isso e vários caches serão limpos.

Agora abra Safari> Preferences> Autofille desligue User names and passwords. Agora selecione Passwordse remova as senhas listadas lá. Selecione Privacye clique em Remove All Website Data. Selecione Extensionse se você tiver alguma extensão instalada, alterne as extensões para Off.

Agora vá e experimente o seu site. Depois de fazer a tentativa, dê uma olhada Privacypara ver se algum cookie foi deixado e Passwordsse o Safari salvou sua senha.

Isso pode aproximá-lo de uma solução. Diga-nos como será depois disso. Se o Chrome funcionar, eu adoraria saber exatamente o que está fazendo. Poderia ser necessário um pouco mais de espionagem?

Apenas para rir, tente a URL http://username:password@intranet.example.com/(substituindo bits obviamente) e veja o que acontece.

Eu tive um problema semelhante no meu escritório também. A chave era garantir que minha pesquisa de DNS excluísse os sites locais (empresa / intranet) de procurar um endereço DNS. Essa foi a causa do meu sistema querer sair para o proxy e obter a tela de logon constante. O que estava acontecendo é que minha solicitação para o URL de intranet.company.com estava sendo atendida pelo servidor proxy e enviada à web. O servidor principal veria que eu estava me conectando através do IP de uma empresa e responderia à procura de credenciais removidas pelo proxy ... eu acho.

Basicamente, garantir que o site da intranet não estivesse sendo enviado para um proxy resolveu meu problema. Isso além de tornar o Chrome meu navegador padrão ...

Use o Viewer.app Ticket , /System/Library/CoreServices/Ticket Viewer.appe adicionar um novo bilhete.

No novo ticket, use o nome de usuário e a senha para a autenticação do URL da intranet.

1. Crie um novo usuário no Mac.
2. Mude para este novo usuário. Você pode fazer isso enquanto mantém sua sessão atual aberta.
3. Inicie o Safari. Este é um Safari virgem.
4. Tente se conectar ao site. Normalmente, você receberá a caixa de diálogo de autenticação.

Isso pode ou não ajudar, mas descobri que, se eu me conectar a um compartilhamento smb que não seja eu, perco a janela de autenticação no Safari 7.0.3 executando o OS 10.9.2

Eu mesmo, como no meu login e senha do diretório ativo. Estou vinculado a um servidor de diretório ativo.

Eu não testei isso em uma máquina não vinculada. Também testei o Chrome e o FireFox e esses aplicativos não têm nenhum problema. Aurora não funciona mais de nenhuma maneira.

Edite por outro usuário:

Essa parece ser a causa do problema. Agora isso foi testado com uma máquina não vinculada executando o Mavericks e agora executando o Yosemite. Depois de me conectar aos compartilhamentos SMB, o Safari não apresentará mais a caixa de diálogo de autenticação. No Mavericks, assim que eu me desconectar dos compartilhamentos SMB, a caixa de diálogo é apresentada e posso efetuar login no site de intranet do Sharepoint 2013 da minha empresa. Não tenho nenhum problema no Sharepoint 2007 ou em outros sites da intranet.

No Yosemite, parece que posso conectar-me a um máximo de dois compartilhamentos SMB e o Safari ainda funcionará. Se eu estiver conectado a três ou mais compartilhamentos SMB, o problema se manifesta. Ainda não tenho certeza se é o número de compartilhamentos ou se os compartilhamentos diferentes têm permissões diferentes que podem afetar a situação. Eu preciso fazer alguns testes mais rigorosos nessa frente.