10 votes

Safari 7 ne peut pas se connecter à l'intranet en utilisant l'authentification HTTP

Voir la mise à jour ci-dessous pour de nouvelles informations sur les requêtes HTTP réelles qui se déroulent sous le capot.

J'ai donc commencé un nouveau travail en octobre. Il s'agit principalement d'un atelier Windows, et ils utilisent IIS et Active Directory pour tout un tas de choses internes. Ils ont un site intranet à intranet.companyname.com .

Dans Chrome sous Mavericks, lorsque j'y accède, j'obtiens la petite liste déroulante d'authentification HTTP attendue :

What Chrome does; this is the sort of thing I SHOULD be getting in Safari

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

En octobre dernier, la première fois que j'ai essayé cette fonction dans Safari, j'ai eu un comportement étrange : j'ai vu le mot de passe, mais cela n'a pas fonctionné lorsque j'ai entré mes informations d'identification. Je ne me souviens pas exactement de ce qui s'est passé.

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

What Safari 7 on Mavericks does when I try to connect to my intranet

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


UPDATE

J'ai lancé une application pour espionner les requêtes HTTP, et j'ai découvert ce qu'elle faisait en coulisse. Il ne se contente pas de rester là, Safari demande en fait à la page près de 1000 fois par seconde et à chaque fois, il obtient une erreur 401 et une page d'erreur HTML avec le titre "You are not authorized to view this page".

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

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Et le serveur répond avec ceci WWW-Authenticate en-tête :

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

Lors de la requête suivante, Safari envoie un message identique à celui de la requête précédente. Authorization et le serveur répond avec un en-tête très légèrement différent. WWW-Authenticate en-tête :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Répéter à l'infini.


J'ai essayé de supprimer tous les éléments qui correspondent intranet dans Keychain Access et en effaçant tout mon cache/cookies, pour voir si je pouvais rétablir le comportement bizarre d'origine, mais cela n'a pas fonctionné.

Est-ce que j'ai une sorte de domaine funky en cours ? Que puis-je essayer d'autre pour diagnostiquer ce problème ?

8voto

Otto G Points 186

Je peux confirmer que je rencontre 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'auteur de l'article original, j'ai découvert que ce problème ne se produit que si le serveur Windows dispose d'une authentification Windows intégrée (également connue sous le nom d'authentification NTLM). et Authentification négociée activée.

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

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari répondra :

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Et à partir de là, la boucle sera bouclée.

Mais si l'authentification négociée n'est pas activée 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 du genre :

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Cela fonctionnera très bien. Essentiellement, il semble que Negotiate ne fonctionne pas dans Safari, et puisque le serveur envoie Negotiate en premier, indiquant une préférence pour celui-ci, Safari va essayer et entrer dans une boucle infinie qui l'empêche de revenir à NTLM.

Ainsi, si l'on peut persuader l'administrateur du serveur de désactiver la fonction 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 "Authorization : NTLM ...", que le serveur fournisse ou non Negotiate en plus de NTLM. On peut supposer que 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 à 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.

Mise à jour 2

Je peux confirmer la constatation 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.

3voto

ban-G Points 390

Safari 7.0.5 présente toujours le même problème : l'authentification est interrompue si le finder 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 une authentification correcte.

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

1voto

Daniel Points 11

Nous avons le même problème. C'est pourquoi nous n'avons pas encore mis à niveau nos Macs vers Mavericks. Il semble qu'il essaie de se connecter à l'Intranet sans les informations d'identification du domaine (Intranet\'blank'). Il devrait utiliser le domaine \username. Je peux comprendre que cela puisse être frustrant mais il semble que l'authentification soit manquante dans safari.

En quelques secondes, les bûches vont s'envoler.

Firefox semble cependant fonctionner parfaitement.

1voto

castinbronze Points 34

C'est peut-être un peu long, mais si vous disposez d'un ticket Kerberos (obtenu en vous connectant à 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 des informations d'identification.

0voto

Tony Williams Points 11219

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

Dans Safari, si vous regardez sous l'onglet Safari vous verrez Reset Safari... Sélectionnez cette option et un certain nombre de caches seront effacés.

Maintenant ouvert Safari > Preferences > Autofill et éteindre User names and passwords . Sélectionnez maintenant Passwords et supprimez tous les mots de passe qui y figurent. Sélectionnez Privacy et cliquez sur Remove All Website Data . Sélectionnez Extensions et si vous avez des extensions installées, passez-les à l'option Off .

Maintenant, allez-y et essayez votre site web. Une fois que vous avez fait l'essai, allez jeter un coup d'oeil à Privacy pour voir si des cookies ont été laissés et Passwords pour voir si Safari a enregistré votre mot de passe.

Cela pourrait vous rapprocher d'une solution. Dis-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 pièces évidemment) et voyez ce qui se passe.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X