Consulte la ACTUALIZACIÓN a continuación para obtener nueva información sobre las solicitudes HTTP reales que se realizan bajo el capó.
Entonces comencé un nuevo trabajo en octubre. Es principalmente una tienda de Windows, y usan IIS y Active Directory para un montón de cosas internas. Tienen un sitio de intranet en intranet.companyname.com.
En Chrome en Mavericks, cuando voy allí, obtengo el pequeño menú desplegable de autenticación HTTP esperado:
donde puedo escribir mi nombre de usuario y contraseña. No soy muy rápido con Active Directory, pero supongo que msgdes el dominio de Active Directory en el que estoy, así que escribo msgd\lheidbredery mi contraseña, y puedo iniciar sesión con éxito en Chrome.
En octubre, la primera vez que probé esto en Safari, tuve un comportamiento extraño; como, vi la contraseña, pero no funcionó cuando puse mis credenciales. No recuerdo exactamente lo que hizo.
Pero después de ese primer intento, y en cada intento desde entonces, cuando intento ir intranet.companyname.com, Safari muestra una pantalla en blanco:
La pantalla no cambia, y la barra de progreso se llena aproximadamente un 20% y permanece allí.
ACTUALIZAR
Ejecuté una aplicación para espiar las solicitudes HTTP, y descubrí lo que esto estaba haciendo detrás de escena. No es solo sentarse allí; Safari está solicitando la página casi 1000 veces por segundo , y cada vez recibe un error 401 y una página de error HTML con el título "No está autorizado para ver esta página".
En una solicitud de ejemplo de la mitad de un intento de carga, Safari envía este Authorizationencabezado:
Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=
Y el servidor responde con este WWW-Authenticateencabezado:
Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWKPhp0o8/Y/9gAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==
En la siguiente solicitud, Safari envía un Authorizationencabezado idéntico y luego el servidor responde con un WWW-Authenticateencabezado muy diferente :
Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==
Repetir ad infinitum.
Intenté eliminar todo lo que coincide intraneten Keychain Access y borrar todo mi caché / cookies, para ver si podía restaurar el comportamiento extraño original, pero no funcionó.
¿Tengo algún tipo de cosas de dominio funky pasando? ¿Qué más puedo tratar de diagnosticar esto?
fuente
Respuestas:
Puedo confirmar que veo el mismo problema con Safari 7.0.2 (9537.74.9), con todas las actualizaciones actuales de Mac OS X Mavericks instaladas. (Miles de paquetes de solicitud por segundo con el mismo tipo de contenido que el descrito anteriormente).
Sin embargo, si bien esto puede o no ayudar al póster original, descubrí que este problema solo ocurre si el servidor de Windows tiene la autenticación integrada de Windows (también conocida como autenticación NTLM) y la autenticación de negociación habilitada.
El servidor luego envía estos dos encabezados:
Safari responderá:
Y a partir de ahí, el ciclo comenzará.
Pero si Negotiate Authentication no está habilitado en el servidor, solo habrá un encabezado WWW-Authenticate:
Y la respuesta de Safari será algo así como:
Esto funcionará bien. Esencialmente, parece que Negotiate está roto en Safari, y dado que el servidor envía Negotiate primero, indicando una preferencia por él, Safari lo intentará e ingresará un bucle infinito que evita que vuelva a NTLM.
Por lo tanto, si se puede persuadir al administrador del servidor para que desactive Negociar en la configuración de autenticación, el problema puede resolverse.
Podría agregar que Firefox envía el encabezado "Autorización: NTLM ..." independientemente de si el servidor proporciona Negociar además de NTLM o no. Presumiblemente, Negotiate no está implementado en Firefox.
Actualizar
Safari 7.0.3 (9537.75.14) todavía exhibe el mismo problema.
Anteriormente informamos el problema como un error en bugreport.apple.com, pero el error se cerró como un duplicado de un error anterior, cuyo contenido no podemos ver, excepto que todavía está marcado como abierto.
Actualización 2
Puedo confirmar que hauns descubrió que la autenticación funciona con Safari 7.0.4 (9537.76.4).
Actualización 3
Este problema está de vuelta en Safari 7.0.5 (9537.77.4)
Actualización 4
Este problema todavía está presente en Safari 7.0.6 (9537.78.2), como lo señalan los hauns, con los volúmenes cifs o smb montados.
fuente
Safari 7.0.5 todavía tiene el problema: la autenticación se rompe si el buscador comparte recursos de red a través de SMB: (o CIFS :). Una vez que se desmontan todos los volúmenes de red conectados, Safari reanuda la autenticación adecuada.
Regresión:
El correspondiente error de Apple 22990203 todavía está activo. Ningún mortal puede verlo (cf.bugreporter.apple.com)
Ver también: https://discussions.apple.com/message/27727310#27727310
fuente
Estamos teniendo el mismo problema. Por eso todavía no hemos actualizado nuestros Macs a Mavericks. Parece intentar iniciar sesión en la Intranet sin credenciales de dominio (Intranet \ 'blank'). Debería estar usando el dominio \ nombre de usuario. Puedo entender que esto puede ser frustrante, pero parece que falta la autenticación en safari.
Yo solo unos segundos va a volar los registros.
Sin embargo, Firefox parece funcionar muy bien.
fuente
Esto podría ser una posibilidad remota, pero si tiene un ticket Kerberos (por iniciar sesión en otro servicio), Safari podría estar tratando de usarlo.
Abra / System / Library / CoreServices / Ticket Viewer.app para ver si tiene tickets de Kerberos. Si es así, haga clic en el ticket, Eliminar identidad e intente nuevamente.
Alternativamente, si no aparece nada, intente usar Agregar identidad y ver si eso funciona con Safari.
Firefox y Chrome no utilizan Kerberos, no creo, por eso te pedirán credenciales por separado.
fuente
Llaveros fue una buena idea, pero no fuiste lo suficientemente lejos.
En Safari, si mira debajo del
Safarimenú, veráReset Safari...Seleccionar esto y se borrarán varios cachés.Ahora abierta
Safari>Preferences>Autofilly apagueUser names and passwords. Ahora seleccionePasswordsy elimine las contraseñas enumeradas allí. SeleccionePrivacyy haga clic enRemove All Website Data. SeleccioneExtensionsy si tiene alguna extensión instalada, cambie las extensiones aOff.Ahora ve y prueba tu sitio web. Una vez que hayas hecho el intento, ve
Privacya ver si quedan cookies yPasswordssi Safari guardó tu contraseña.Esto podría acercarlo a una solución. Cuéntanos cómo va después de eso. Si Chrome funciona, me encantaría saber exactamente qué está haciendo que funcione. ¿Podría ser necesario un poco más de espionaje?
Solo por risas, prueba la URL
http://username:[email protected]/(reemplazando bits obviamente) y mira qué sucede.fuente
intranet.companyname.comsitio, pero las eliminé todas de todos modos y, como era de esperar, obtengo exactamente el mismo comportamiento. Tenga en cuenta que lo que debería obtener es el modal de autenticación HTTP del navegador, por lo que si estuviera en cualquier lugar, estaría en Keychain Access, no en cookies.https://también.Tuve un problema similar en mi oficina también. La clave era asegurarme de que mi búsqueda de DNS excluyera los sitios locales (empresa / intranet) de buscar una dirección DNS. Eso fue porque mi sistema quería ir al proxy y obtener la pantalla de inicio de sesión constante. Lo que sucedía es que mi solicitud de la URL de intranet.company.com estaba siendo tomada por el servidor proxy y enviada a la web. El servidor web principal vería que me estaba conectando a través de una IP de la compañía y respondería buscando credenciales que fueron eliminadas por el proxy ... creo.
Básicamente, asegurarme de que el sitio de intranet no se enviara a un proxy resolvió mi problema. Eso además de hacer que Chrome sea mi navegador predeterminado ...
fuente
Use Ticket Viewer.app ,
/System/Library/CoreServices/Ticket Viewer.appy agregue un nuevo ticket.En el nuevo ticket, use el nombre de usuario y la contraseña para la autenticación de la URL de la intranet.
fuente
lheidbrederymsgd\lheidbredercomo mi nombre de usuario; sin suerte.fuente
Esto puede o no ayudar, pero he descubierto que si me conecto a un recurso compartido de smb que no sea yo, pierdo la ventana de autenticación en Safari 7.0.3 con el sistema operativo 10.9.2
Yo mismo como en mi nombre de usuario y contraseña del directorio activo. Estoy vinculado a un servidor de directorio activo.
No he probado esto en una máquina no vinculada. También probé Chrome y Firefox y estas aplicaciones no tienen ningún problema. Aurora ya no funciona de ninguna manera.
Editar por otro usuario:
Esto parece ser la causa del problema. Esto ahora se ha probado con una máquina no vinculada que ejecuta Mavericks y ahora ejecuta Yosemite. Después de conectarme a recursos compartidos SMB, Safari ya no presentará el diálogo de autenticación. En Mavericks, tan pronto como me desconecto de los recursos compartidos de SMB, aparece el cuadro de diálogo y puedo iniciar sesión en el sitio de intranet Sharepoint 2013 de mi empresa. No tengo ningún problema en Sharepoint 2007 u otros sitios de intranet.
En Yosemite, parece que puedo conectarme a un máximo de dos recursos compartidos SMB y Safari seguirá funcionando. Si estoy conectado a tres o más recursos compartidos SMB, el problema se manifiesta. Todavía no estoy seguro si es la cantidad de acciones o si las diferentes acciones tienen diferentes permisos que podrían afectar la situación. Necesito hacer algunas pruebas más rigurosas en ese frente.
fuente