Safari 7 no puede conectarse a la intranet usando la autenticación HTTP

Puedo confirmar que veo un problema idéntico 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 se describió anteriormente).

Sin embargo, aunque esto puede o no puede ayudar al cartel original, he encontrado que este problema solo ocurre si el servidor de Windows tiene Autenticación de Windows integrada (también conocida como Autenticación NTLM) y La Autenticación de negociación está habilitada .

El servidor envía estos dos encabezados:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari responderá:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Y a partir de ahí, el bucle se pondrá en marcha.

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 como:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Esto funcionará bien. Esencialmente, parece que Negociar está roto en Safari, y como el servidor envía Negociar primero, lo que indica una preferencia por ello, Safari lo intentará e ingresará en 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, Negociar no está implementado en Firefox.

Actualizar

Safari 7.0.3 (9537.75.14) aún presenta 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 aún está marcado como abierto.

Actualización 2

Puedo confirmar el hallazgo de 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 aún está presente en Safari 7.0.6 (9537.78.2), como lo señalan los sitios, con los volúmenes cifs o smb montados.

Safari 7.0.5 sigue teniendo el problema: la autenticación se interrumpe 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 Capitán 10.11.2 / Safari 9.0.2
3. presente en Safari 10.0.1

El error de Apple correspondiente 22990203 todavía está activo. Ningún mortal puede verlo (cf.bugreporter.apple.com)

Vea también: enlace

Estamos teniendo el mismo problema. Por lo tanto, ¿por qué aún no hemos actualizado nuestros Mac a Mavericks? Parece que intenta iniciar sesión en la Intranet sin credenciales de dominio (Intranet \ 'en blanco'). Debería estar usando el dominio \ nombre de usuario. Puedo entender que esto puede ser frustrante, pero parece que falta la autenticación en un safari.

En solo unos segundos se borrarán los registros.

Firefox parece funcionar muy bien, sin embargo.

Esto podría ser una posibilidad remota, pero si tienes un ticket de Kerberos (por iniciar sesión en otro servicio), Safari podría estar intentando usarlo.

Abra / System / Library / CoreServices / Ticket Viewer.app para ver si tiene boletos para Kerberos. Si es así, haga clic en el ticket, Eliminar identidad e intente nuevamente.

Alternativamente, si no hay nada en la lista, intente usar Agregar identidad y ver si funciona con Safari.

Firefox y Chrome no utilizan Kerberos, no lo creo, por eso te pedirán credenciales por separado.

Los llaveros fueron una buena idea, pero no fuiste lo suficientemente lejos.

En Safari, si busca en el menú Safari , verá Reset Safari... . Seleccione esto y se borrarán varios cachés.

Ahora abre Safari > Preferences > Autofill y desactiva User names and passwords . Ahora seleccione Passwords y elimine todas las contraseñas que figuran allí. Seleccione Privacy y haga clic en Remove All Website Data . Seleccione Extensions y si tiene alguna extensión instalada, cambie las extensiones a Off .

Ahora ve y prueba tu sitio web. Una vez que lo hayas intentado, ve a Privacy para ver si quedan algunas cookies y Passwords para ver si Safari ha guardado tu contraseña.

Esto podría acercarte a una solución. Cuéntanos cómo va después de eso. Si Chrome funciona, me encantaría saber exactamente qué está haciendo lo que funciona. ¿Podría requerirse un poco más de espionaje?

Solo para risitas, intente con la URL http://username:[email protected]/ (reemplazando los bits obviamente) y vea qué sucede.

También tuve un problema similar en mi oficina. La clave fue asegurarse de que mi búsqueda de DNS excluyera a los sitios locales (compañía / intranet) de buscar una dirección DNS. Ese fue el motivo por el que mi sistema quería salir al proxy y obtener la pantalla de inicio de sesión constante. Lo que estaba sucediendo es que el servidor proxy tomó mi solicitud de la url de intranet.company.com y la envió a la web. El servidor web principal vería que me estaba conectando a través de la IP de la empresa y respondería buscando credenciales que fueron eliminadas por el proxy ... creo.

Básicamente, asegurarse de que el sitio de la intranet no se estaba enviando a un proxy resolvió mi problema. Eso además, solo hace que Chrome sea mi navegador predeterminado ...

1. Crea un nuevo usuario en la Mac.
2. Cambiar a este nuevo usuario. Puede hacer esto mientras mantiene abierta la sesión actual.
3. Inicia Safari. Este es un safari virgen.
4. Intenta conectarte al sitio. Normalmente, obtendrás el diálogo de autenticación.

Esto puede o no puede ayudar, pero he descubierto que si me conecto a un recurso compartido de smb que no sea yo mismo, perderé la ventana de autenticación en Safari 7.0.3 con OS 10.9.2

Yo mismo como en mi inicio de sesión de directorio activo y contraseña. Estoy vinculado a un servidor de directorio activo.

No he probado esto en una máquina no encuadernada. También he probado 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 que ejecuta Yosemite. Después de conectarme a los recursos compartidos SMB, Safari ya no presentará el cuadro de diálogo de autenticación. En Mavericks, tan pronto como me desconecto de los recursos compartidos de SMB, se presenta el cuadro de diálogo y puedo iniciar sesión en el sitio de intranet de 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 SMB, el problema se manifiesta. No estoy seguro aún de si es el número de acciones o si tal vez las diferentes acciones tienen permisos diferentes que pueden afectar la situación. Necesito hacer algunas pruebas más rigurosas en ese frente.

Use Ticket Viewer.app , /System/Library/CoreServices/Ticket Viewer.app , y 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.