Safari 7 no se puede conectar a la intranet mediante autenticación HTTP

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?

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:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari responderá:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Y a partir de ahí, el ciclo comenzará.

Pero si Negotiate Authentication no está habilitado en el servidor, solo habrá un encabezado WWW-Authenticate:

WWW-Authenticate: NTLM

Y la respuesta de Safari será algo así como:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

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.

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:

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

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

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.

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.

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 apague User names and passwords. Ahora seleccione Passwordsy elimine las contraseñas enumeradas allí. Seleccione Privacyy haga clic en Remove All Website Data. Seleccione Extensionsy si tiene alguna extensión instalada, cambie las extensiones a Off.

Ahora ve y prueba tu sitio web. Una vez que hayas hecho el intento, ve Privacya ver si quedan cookies y Passwordssi 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:password@intranet.example.com/(reemplazando bits obviamente) y mira qué sucede.

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 ...

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.

1. Crea un nuevo usuario en la Mac.
2. Cambie a este nuevo usuario. Puede hacerlo mientras mantiene abierta su sesión actual.
3. Lanzamiento de Safari. Este es un Safari virgen.
4. Intenta conectarte al sitio. Normalmente, obtendrá el cuadro de diálogo de autenticación.

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.