Safari 7 ne peut pas se connecter à l'intranet à l'aide de l'authentification HTTP

Voir la MISE À JOUR ci-dessous pour de nouvelles informations sur les requêtes HTTP réelles en cours sous le capot.

J'ai donc commencé un nouvel emploi en octobre. C'est principalement une boutique Windows, et ils utilisent IIS et Active Directory pour un tas de choses internes. Ils ont un site intranet à intranet.companyname.com.

Dans Chrome sur Mavericks, lorsque j'y vais, j'obtiens le petit menu déroulant d'authentification HTTP attendu:

où je peux taper mon nom d'utilisateur et mon mot de passe. Je ne suis pas très rapide avec Active Directory, mais je suppose que msgdc'est le domaine Active Directory sur lequel je me trouve, donc je tape msgd\lheidbrederet mon mot de passe, et je peux me connecter avec succès dans Chrome.

En octobre, la première fois que j'ai essayé cela dans Safari, j'ai eu un comportement étrange; comme, j'ai vu le mot de passe, mais ça n'a pas fonctionné quand j'ai mis mes informations d'identification. Je ne me souviens pas exactement de ce qu'il a fait.

Mais après cette première tentative, et à chaque tentative depuis lors, lorsque j'essaie d'y aller intranet.companyname.com, Safari affiche un écran vide:

L'écran ne change pas et la barre de progression se remplit d'environ 20% et y reste.

MISE À JOUR

J'ai exécuté une application pour espionner les requêtes HTTP et j'ai découvert ce que cela faisait en coulisses. Ce n'est pas seulement assis là; Safari demande en fait la page presque 1000 fois par seconde , et à chaque fois, il obtient une erreur 401 et une page d'erreur HTML avec le titre "Vous n'êtes pas autorisé à afficher cette page".

Sur un exemple de demande au milieu d'une tentative de chargement, Safari envoie cet en- Authorizationtête:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Et le serveur répond avec cet en- WWW-Authenticatetête:

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

À la demande suivante, Safari envoie un en- Authorizationtête identique , puis le serveur répond avec un en- WWW-Authenticatetête très légèrement différent :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Répétez à l' infini.

J'ai essayé de supprimer tout ce qui correspond intranetdans Keychain Access et de vider l'intégralité de mon cache / cookies, pour voir si je pouvais restaurer le comportement étrange d'origine, mais cela n'a pas fonctionné.

Ai-je une sorte de domaine génial en cours? Que puis-je essayer de diagnostiquer cela?

Je peux confirmer que je vois le même problème avec Safari 7.0.2 (9537.74.9), avec toutes les mises à jour actuelles de Mac OS X Mavericks installées. (Des milliers de paquets de requêtes par seconde avec le même type de contenu que celui décrit ci-dessus.)

Cependant, bien que cela puisse ou non aider l'affiche originale, j'ai constaté que ce problème se produit uniquement si le serveur Windows a l'authentification Windows intégrée (également connue sous le nom d'authentification NTLM) et l' authentification de négociation activée.

Le serveur envoie ensuite ces deux en-têtes:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari vous répondra:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Et à partir de là, la boucle commencera.

Mais si Negotiate Authentication n'est pas activé sur le serveur, il n'y aura qu'un seul en-tête WWW-Authenticate:

WWW-Authenticate: NTLM

Et la réponse de Safari sera quelque chose comme:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Cela fonctionnera très bien. Essentiellement, il semble que Negotiate est rompu dans Safari, et puisque le serveur envoie d'abord Negotiate, indiquant une préférence pour lui, Safari va l'essayer et entrer dans une boucle infinie qui l'empêche de retomber sur NTLM.

Ainsi, si l'administrateur du serveur peut être persuadé de désactiver Négocier dans les paramètres d'authentification, le problème peut être résolu.

Je pourrais ajouter que Firefox envoie l'en-tête "Autorisation: NTLM ...", que le serveur fournisse Negotiate en plus de NTLM ou non. Vraisemblablement, Negotiate n'est pas implémenté dans Firefox.

Mise à jour

Safari 7.0.3 (9537.75.14) présente toujours le même problème.

Nous avons précédemment signalé le problème en tant que bogue sur bugreport.apple.com, mais le bogue a été fermé en tant que doublon d'un bogue précédent, dont nous ne pouvons pas voir le contenu, sauf qu'il est toujours marqué comme ouvert.

Update 2

Je peux confirmer la conclusion de hauns que l'authentification fonctionne avec Safari 7.0.4 (9537.76.4).

Mise à jour 3

Ce problème est de retour dans Safari 7.0.5 (9537.77.4)

Mise à jour 4

Ce problème est toujours présent dans Safari 7.0.6 (9537.78.2), comme l'a noté hauns, avec des volumes cifs ou smb montés.

Safari 7.0.5 a toujours le problème: l'authentification tombe en panne si le chercheur partage des ressources réseau via SMB: (ou CIFS :). une fois que tous les volumes réseau connectés sont démontés, Safari reprend l'authentification appropriée.

Régression:

1. présent dans Yosemite 10.10.1 / Safari 8.0.2
2. présent dans El Capitan 10.11.2 / Safari 9.0.2
3. présent dans Safari 10.0.1

Le bogue Apple 22990203 correspondant est toujours actif. Aucun mortel n'est autorisé à le voir (cf. bugreporter.apple.com)

Voir aussi: https://discussions.apple.com/message/27727310#27727310

Nous avons le même problème. C'est pourquoi nous n'avons pas encore mis à jour nos Mac vers Mavericks. Il semble essayer de se connecter à l'Intranet sans les informations d'identification de domaine (Intranet \ 'vide'). Il doit utiliser le domaine \ nom d'utilisateur. Je peux comprendre que cela puisse être frustrant, mais il semble que l'authentification manque dans safari.

Je viens de quelques secondes, il va emporter les journaux.

Firefox semble cependant très bien fonctionner.

Cela peut être long, mais si vous avez un ticket Kerberos (de la connexion à un autre service), Safari peut essayer de l'utiliser.

Ouvrez / System / Library / CoreServices / Ticket Viewer.app pour voir si vous avez des tickets Kerberos. Si c'est le cas, cliquez sur le ticket, supprimez l'identité et réessayez.

Sinon, si rien n'est répertorié, essayez d'utiliser Ajouter une identité et voyez si cela fonctionne avec Safari.

Firefox et Chrome n'utilisent pas Kerberos, je ne pense pas, c'est pourquoi ils vous demanderont séparément les informations d'identification.

Les porte-clés étaient une bonne idée mais vous n'êtes pas allé assez loin.

Dans Safari, si vous regardez sous le Safarimenu, vous verrez Reset Safari...Sélectionner ceci et un certain nombre de caches seront effacés.

Maintenant ouvert Safari> Preferences> Autofillet désactiver User names and passwords. Maintenant, sélectionnez Passwordset supprimez tous les mots de passe qui y sont répertoriés. Sélectionnez Privacyet cliquez sur Remove All Website Data. Sélectionnez Extensionset si vous avez installé des extensions, basculez les extensions vers Off.

Maintenant, allez essayer votre site Web. Une fois que vous avez fait la tentative, allez Privacyvoir si des cookies ont été laissés et Passwordssi Safari a enregistré votre mot de passe.

Cela pourrait vous rapprocher d'une solution. Dites-nous comment ça se passe après ça. Si Chrome fonctionne, j'aimerais savoir exactement ce qu'il fait qui fonctionne. Un peu plus d'espionnage pourrait-il être nécessaire?

Juste pour rire, essayez l'URL http://username:password@intranet.example.com/(en remplaçant les bits évidemment) et voyez ce qui se passe.

J'ai également eu un problème similaire à mon bureau. La clé était de m'assurer que ma recherche DNS excluait les sites locaux (entreprise / intranet) de rechercher une adresse DNS. C'était la raison pour laquelle mon système voulait aller vers le proxy et obtenir l'écran de connexion constant. Ce qui se passait, c'est que ma demande pour l'url de intranet.company.com était prise par le serveur proxy et envoyée sur le Web. Le serveur Web principal verrait que je me connectais via une adresse IP d'entreprise et répondrait à la recherche d'informations d'identification supprimées par le proxy ... Je pense.

Le fait de m'assurer que le site intranet n'était pas envoyé à un proxy a résolu mon problème. Cela en plus de faire de Chrome mon navigateur par défaut ...

Utilisez Ticket Viewer.app , /System/Library/CoreServices/Ticket Viewer.appet ajoutez un nouveau ticket.

Dans le nouveau ticket, utilisez le nom d'utilisateur et le mot de passe pour l'authentification de l'URL intranet.

1. Créez un nouvel utilisateur sur le Mac.
2. Passez à ce nouvel utilisateur. Vous pouvez le faire tout en gardant votre session actuelle ouverte.
3. Lancez Safari. Il s'agit d'un Safari vierge.
4. Essayez de vous connecter au site. Normalement, vous obtiendrez la boîte de dialogue d'authentification.

Cela peut ou peut ne pas aider, mais j'ai constaté que si je me connecte à un partage smb autre que moi, je perds la fenêtre d'authentification dans Safari 7.0.3 exécutant OS 10.9.2

Moi-même comme dans mon login et mot de passe Active Directory. Je suis lié à un serveur Active Directory.

Je n'ai pas testé cela sur une machine non liée. J'ai également testé Chrome et FireFox et ces applications n'ont aucun problème au fil du temps. Aurora ne fonctionne plus de toute façon.

Modifier par un autre utilisateur:

Cela semble être la cause du problème. Cela a maintenant été testé avec une machine non liée exécutant Mavericks et maintenant exécutant Yosemite. Une fois que je me suis connecté aux partages SMB, Safari ne présente plus la boîte de dialogue d'authentification. Dans Mavericks, dès que je me déconnecte des partages SMB, la boîte de dialogue s'affiche et je peux me connecter au site intranet Sharepoint 2013 de mon entreprise. Je n'ai aucun problème sur Sharepoint 2007 ou d'autres sites intranet.

Dans Yosemite, il semble que je puisse me connecter à un maximum de deux partages SMB et Safari fonctionnera toujours. Si je suis connecté à trois partages SMB ou plus, le problème se manifeste. Je ne sais pas encore si c'est le nombre de partages ou si peut-être les différents partages ont des autorisations différentes qui pourraient affecter la situation. Je dois faire des tests plus rigoureux sur ce front.