Safari 7 non può connettersi alla rete Intranet utilizzando l'autenticazione HTTP

Vedere l'AGGIORNAMENTO di seguito per nuove informazioni sulle effettive richieste HTTP in corso sotto il cofano.

Così ho iniziato un nuovo lavoro a ottobre. È principalmente un negozio di Windows e usano IIS e Active Directory per un sacco di cose interne. Hanno un sito intranet all'indirizzo intranet.companyname.com.

In Chrome su Mavericks, quando ci vado, ottengo il piccolo menu a discesa di autenticazione HTTP previsto:

dove posso digitare il mio nome utente e password. Non sono molto veloce con Active Directory, ma immagino msgdsia il dominio di Active Directory in cui mi trovo, quindi scrivo msgd\lheidbredere la mia password e posso accedere con successo in Chrome.

Già nel mese di ottobre, la prima volta che ho provato questo in Safari, ho avuto un comportamento strano; come, ho visto la cosa della password, ma poi non ha funzionato quando ho inserito le mie credenziali. Non ricordo esattamente cosa abbia fatto.

Ma dopo quel primo tentativo, e ad ogni tentativo da allora, quando provo ad andare intranet.companyname.com, Safari mostra una schermata vuota:

Lo schermo non cambia e la barra di avanzamento si riempie di circa il 20% e rimane lì.

AGGIORNARE

Ho eseguito un'app per ficcare richieste HTTP e ho scoperto cosa stava facendo dietro le quinte. Non è solo seduto lì; Safari in realtà richiede la pagina quasi 1000 volte al secondo e ogni volta riceve un errore 401 e una pagina di errore HTML con il titolo "Non sei autorizzato a visualizzare questa pagina".

Su una richiesta di esempio durante un tentativo di caricamento, Safari invia questa Authorizationintestazione:

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

E il server risponde con questa WWW-Authenticateintestazione:

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

Alla richiesta successiva, Safari invia Authorizationun'intestazione identica , quindi il server risponde con WWW-Authenticateun'intestazione leggermente diversa :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Ripeti all'infinito.

Ho provato a eliminare tutto ciò che corrisponde intraneta Keychain Access e a cancellare tutta la mia cache / cookie, per vedere se potevo ripristinare il comportamento strano originale, ma non ha funzionato.

Ho una specie di roba di dominio funky in corso? Cos'altro posso provare a diagnosticare questo?

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

Tuttavia, sebbene ciò possa o meno aiutare il poster originale, ho riscontrato che questo problema si verifica solo se il server Windows ha l'autenticazione integrata di Windows (nota anche come autenticazione NTLM) e l'autenticazione di negoziazione 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 inizierà.

Ma se Negotiate Authentication non è abilitato sul server, ci sarà solo un'intestazione WWW-Authenticate:

WWW-Authenticate: NTLM

E la risposta di Safari sarà qualcosa del tipo:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Funzionerà bene. In sostanza, sembra che Negozia sia interrotto in Safari, e poiché il server invia prima Negozia, indicando una preferenza per esso, Safari lo proverà ed entrerà in un ciclo infinito che gli impedisce di tornare a NTLM.

Pertanto, 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 Negozia in aggiunta a NTLM o meno. Presumibilmente, Negoziare non è implementato in Firefox.

Aggiornare

Safari 7.0.3 (9537.75.14) presenta ancora lo stesso problema.

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

Aggiornamento 2

Posso confermare la conclusione di Hauns che l'autenticazione funziona con Safari 7.0.4 (9537.76.4).

Aggiornamento 3

Questo problema si ripresenta 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 volumi cifs o smb montati.

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

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 corrispondente bug Apple 22990203 è ancora attivo. Nessun mortale è autorizzato a vederlo (cf.bugreporter.apple.com)

Vedi anche: https://discussions.apple.com/message/27727310#27727310

Abbiamo lo stesso problema. Ecco perché non abbiamo ancora aggiornato i nostri Mac a Mavericks. Sembra tentare di accedere a Intranet senza credenziali di dominio (Intranet \ 'vuoto'). Dovrebbe usare il dominio \ nome utente. Capisco che può essere frustrante, ma sembra che in Safari manchi l'autenticazione.

Solo pochi secondi spazzerà via i registri.

Firefox sembra funzionare alla grande però.

Potrebbe essere un colpo lungo, ma se si dispone di un ticket Kerberos (dall'accesso a un altro servizio), Safari potrebbe tentare di utilizzarlo.

Apri / Sistema / Libreria / CoreServices / Ticket Viewer.app per vedere se hai dei 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 verifica se funziona con Safari.

Firefox e Chrome non utilizzano Kerberos, non credo, motivo per cui ti chiederanno separatamente le credenziali.

I portachiavi erano una buona idea ma non sei andato abbastanza lontano.

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

Ora aperto Safari> Preferences> Autofille spegnere User names and passwords. Ora seleziona Passwordse rimuovi tutte le password elencate lì. Seleziona Privacye fai clic su Remove All Website Data. Selezionare Extensionse se sono state installate estensioni, passare a estensioni Off.

Ora vai e prova il tuo sito web. Una volta che hai fatto il tentativo vai e dai un'occhiata Privacyper vedere se sono rimasti dei cookie e Passwordsper vedere se Safari ha salvato la tua password.

Questo potrebbe avvicinarti a una soluzione. Dicci come va dopo. Se Chrome funziona mi piacerebbe sapere esattamente cosa sta facendo che funziona. Potrebbe essere necessario un po 'più di snooping?

Solo per le risatine prova l'URL http://username:password@intranet.example.com/(sostituendo i bit ovviamente) e vedi cosa succede.

Ho avuto un problema simile anche nel mio ufficio. La chiave era assicurarsi che la mia ricerca DNS escludesse i siti locali (società / intranet) dall'andare a cercare un indirizzo DNS. Questa è stata la causa del mio sistema che voleva uscire dal proxy e ottenere la schermata di accesso costante. Quello che stava succedendo è che la mia richiesta per l'URL di intranet.company.com veniva accettata dal server proxy e inviata al web. Il server web principale vedrebbe che mi stavo collegando attraverso un IP aziendale e rispondendo alla ricerca di credenziali che erano state rimosse dal proxy ... Penso.

Fondamentalmente assicurarsi che il sito Intranet non fosse inviato a un proxy ha risolto il mio problema. Oltre a rendere Chrome il mio browser predefinito ...

Utilizzare il biglietto Viewer.app , /System/Library/CoreServices/Ticket Viewer.appe aggiungere un nuovo biglietto.

Nel nuovo ticket, utilizzare il nome utente e la password per l'autenticazione dell'URL Intranet.

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

Questo potrebbe non essere d'aiuto, ma ho scoperto che se mi connetto 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 nella mia directory attiva. Sono legato a un server di directory attivo.

Non l'ho testato su una macchina non associata. Ho anche testato Chrome e FireFox e queste app non hanno alcun problema. Aurora non funziona più in entrambi i modi.

Modifica da un altro utente:

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

In Yosemite, sembra che sia possibile connettersi a un massimo di due condivisioni SMB e Safari funzionerà comunque. Se sono connesso a tre o più condivisioni SMB, il problema si manifesta. Non sono ancora sicuro se sia il numero di condivisioni o se forse le diverse condivisioni hanno autorizzazioni diverse che potrebbero influire sulla situazione. Ho bisogno di fare alcuni test più rigorosi su questo fronte.