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?
fonte
Respostas:
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:
O Safari responderá:
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:
E a resposta do Safari será algo como:
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.
fonte
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:
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
fonte
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.
fonte
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.
fonte
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 desligueUser names and passwords. Agora selecionePasswordse remova as senhas listadas lá. SelecionePrivacye clique emRemove All Website Data. SelecioneExtensionse se você tiver alguma extensão instalada, alterne as extensões paraOff.Agora vá e experimente o seu site. Depois de fazer a tentativa, dê uma olhada
Privacypara ver se algum cookie foi deixado ePasswordsse 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:[email protected]/(substituindo bits obviamente) e veja o que acontece.fonte
intranet.companyname.comsite, mas eu as limpei de qualquer maneira e, como esperado, estou tendo exatamente o mesmo comportamento. Observe que o que eu deveria obter é o modal de autenticação HTTP do navegador; portanto, se ele estivesse em qualquer lugar, seria no Acesso às Chaves, não nos cookies.https://também.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 ...
fonte
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.
fonte
lheidbrederemsgd\lheidbredercomo meu nome de usuário; sem sortefonte
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.
fonte