Safari 7 non può connettersi alla rete intranet usando l'autenticazione HTTP

Posso confermare che vedo lo stesso problema con Safari 7.0.2 (9537.74.9), con tutti gli aggiornamenti di Mac OS X Mavericks installati. (Migliaia di pacchetti di richieste al secondo con lo stesso tipo di contenuto come descritto sopra.)

Tuttavia, mentre questo può o non può aiutare il poster originale, ho trovato che questo problema si verifica solo se il server Windows ha Autenticazione integrata di Windows (anche conosciuta come autenticazione NTLM) e Negozia autenticazione abilitata .

Il server invia quindi queste due intestazioni:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari risponderà:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

E da lì, il ciclo andrà avanti.

Tuttavia, se Negotiate Authentication non è abilitato sul server, ci sarà solo una intestazione WWW-Authenticate:

WWW-Authenticate: NTLM

E la risposta di Safari sarà qualcosa di simile a:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Questo funzionerà bene. Essenzialmente, sembra che Negotiate sia rotto in Safari, e poiché il server invia prima Negotiate, indicando una preferenza per esso, Safari lo proverà e inserirà un ciclo infinito che gli impedirà di tornare a NTLM.

Quindi, se l'amministratore del server può essere persuaso a disattivare la negoziazione nelle impostazioni di autenticazione, il problema potrebbe essere risolto.

Potrei aggiungere che Firefox invia l'intestazione "Autorizzazione: NTLM ..." indipendentemente dal fatto che il server fornisca Negotiate oltre a NTLM o meno. Presumibilmente, la negoziazione non è implementata in Firefox.

Aggiornamento

Safari 7.0.3 (9537.75.14) presenta ancora lo stesso problema.

In precedenza abbiamo segnalato il problema come bug su bugreport.apple.com, ma il bug è stato chiuso come duplicato di un bug precedente, il cui contenuto non è visibile, tranne che è ancora contrassegnato come aperto.

Aggiornamento 2

Posso confermare che hauns ha rilevato che l'autenticazione funziona con Safari 7.0.4 (9537.76.4).

Aggiornamento 3

Questo problema è tornato in Safari 7.0.5 (9537.77.4)

Aggiornamento 4

Questo problema è ancora presente in Safari 7.0.6 (9537.78.2), come notato da hauns, con montaggi di cifs o smb montati.

Safari 7.0.5 presenta ancora il problema: l'autenticazione si interrompe se il cercatore condivide le risorse di rete tramite SMB: (o CIFS :). Una volta smontati tutti i volumi di rete connessi, Safari ripristina l'autenticazione corretta.

Regressione:

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

Il bug Apple corrispondente 22990203 è ancora attivo. Nessun mortale è autorizzato a vederlo (cf.bugreporter.apple.com)

Vedi anche: link

Stiamo riscontrando lo stesso problema. Quindi, perché non abbiamo ancora aggiornato i nostri Mac con Mavericks. Sembra cercare di accedere alla Intranet senza credenziali di dominio (Intranet \ 'blank'). Dovrebbe usare il dominio \ username. Posso capire che questo può essere frustrante, ma sembra che l'autenticazione manchi in Safari.

Ho solo pochi secondi per cancellare i log.

Firefox sembra funzionare benissimo però.

Potrebbe essere una soluzione lunga, ma se hai un ticket Kerberos (dall'accesso a un altro servizio), Safari potrebbe tentare di usarlo.

Apri / Sistema / Libreria / CoreServices / Ticket Viewer.app per vedere se hai biglietti Kerberos. In tal caso, fai clic sul ticket, Rimuovi identità e riprova.

In alternativa, se non è elencato nulla, prova a utilizzare Aggiungi identità e controlla se funziona con Safari.

Firefox e Chrome non utilizzano Kerberos, non credo, ed è per questo che ti chiederanno le credenziali separatamente.

I portachiavi sono stati una buona idea, ma non sei andato abbastanza lontano.

In Safari se guardi sotto il menu Safari vedrai Reset Safari... Seleziona questo e un numero di cache verrà cancellato.

Ora apri Safari > Preferences > Autofill e disattiva User names and passwords . Ora seleziona Passwords e rimuovi tutte le password ivi elencate. Seleziona Privacy e fai clic su Remove All Website Data . Seleziona Extensions e se hai installato estensioni di estensioni su Off .

Ora vai e prova il tuo sito web. Una volta che hai fatto il tentativo vai a dare un'occhiata a Privacy per vedere se qualche cookie è stato lasciato e Passwords per vedere se Safari ha salvato la tua password.

Questo potrebbe avvicinarti a una soluzione. Diteci come va dopo. Se Chrome funziona, mi piacerebbe sapere esattamente cosa sta facendo. Potrebbe essere richiesto un po 'più di spionaggio?

Solo per le risate prova l'URL http://username:[email protected]/ (sostituendo ovviamente i bit) e guarda cosa succede.

Ho avuto un problema simile anche nel mio ufficio. La chiave era assicurarsi che la mia ricerca DNS escludesse i siti locali (aziendali / intranet) dall'andare a cercare un indirizzo DNS. Questo è stato il motivo per cui il mio sistema voleva andare al proxy e ottenere lo schermo di accesso costante. Quello che stava accadendo è che la mia richiesta per l'url di intranet.company.com è stata presa dal server proxy e inviata al web. Il server web principale vedrebbe che stavo connettendo tramite un IP aziendale e rispondevo alla ricerca di credenziali che sono state rimosse dal proxy ... Credo.

Fondamentalmente, assicurandomi che il sito intranet non fosse stato inviato a un proxy, ho risolto il problema. Questo oltre a rendere Chrome il mio browser predefinito ...

1. Crea un nuovo utente su Mac.
2. Passa a questo nuovo utente. Puoi farlo mantenendo aperta la sessione corrente.
3. Avvia Safari. Questo è un vergine Safari.
4. Prova a connetterti al sito. Normalmente, otterrai la finestra di autenticazione.

Questo può o non può essere d'aiuto, ma ho scoperto che se mi collego a una condivisione smb diversa da me, perdo la finestra di autenticazione in Safari 7.0.3 con OS 10.9.2

Come nel mio login e password della mia directory attiva. Sono collegato a un server di directory attivo.

Non l'ho provato su una macchina non vincolata. Ho anche testato Chrome e FireFox e queste app non hanno alcun problema. Aurora non funziona più in nessun modo.

Modifica da un altro utente:

Questa sembra essere la causa del problema. Questo è stato ora testato con una macchina non vincolata che esegue Mavericks e ora esegue Yosemite. Dopo essermi connesso a condivisioni SMB, Safari non presenterà più la finestra di autenticazione. In Mavericks, non appena mi disconnetto dalle condivisioni SMB, viene visualizzata la finestra di dialogo e posso accedere al sito Intranet dell'azienda Sharepoint 2013 della mia azienda. Non ho alcun problema su Sharepoint 2007 o altri siti intranet.

In Yosemite, sembra che posso connettermi a un massimo di due condivisioni SMB e Safari funzionerà ancora. Se sono connesso a tre o più condivisioni SMB, il problema si manifesta. Non sono ancora sicuro se è il numero di condivisioni o se forse le diverse condivisioni hanno permessi diversi che potrebbero influenzare la situazione. Ho bisogno di fare alcuni test più rigorosi su questo fronte.

Utilizza Ticket Viewer.app , /System/Library/CoreServices/Ticket Viewer.app e aggiungi un nuovo ticket.

Nel nuovo ticket, utilizza il nome utente e la password per l'autenticazione dell'URL della rete intranet.