Safari 7 non è in grado di connettersi a intranet utilizzando l'authentication HTTP

Vedere l'aggiornamento qui sotto per get nuove informazioni sulle richieste HTTP effettive in corso sotto il cofano.

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

In Cromo su Mavericks, quando vado lì, ottengo il dropdown di authentication HTTP poco atteso:

Cosa fa Chrome; questo è il genere di cose che DOVREBBE essere in Safari

where posso scrivere il mio nome utente e password. Non sono molto veloce con Active Directory, ma suppongo che il msgd sia il dominio di Active Directory in cui sono acceso, quindi msgd\lheidbreder e la mia password e posso accedere correttamente a Chrome.

Tornato a ottobre, la prima volta che ho provato questo in Safari, ho un comportmento strano; come, ho visto la parola chiave, ma poi non funzionava quando ho messo le mie credenziali. Non ricordo esattamente quello che faceva.

Ma dopo quel primo tentativo e each tentativo da allora, quando cerco di andare a intranet.companyname.com , Safari mostra uno schermo vuoto:

Che cosa fa Safari 7 su Mavericks quando cerco di connettersi alla mia intranet

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


AGGIORNARE

Ho eseguito un'applicazione per ricall le richieste HTTP e ho scoperto che cosa stava facendo dietro le quinte. Non sta solo seduto; Safari effettua la richiesta della pagina quasi 1000 volte al secondo e each 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 dalla metà del tentativo di caricamento, Safari invia l'intestazione di Authorization :

 Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA= 

E il server risponde con questa intestazione WWW-Authenticate :

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

Alla richiesta successiva, Safari invia un'intestazione Authorization identica e quindi il server risponde con un'intestazione leggermente diversa WWW-Authenticate :

 Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA== 

Ripeti ad infinito.


Ho provato a eliminare tutto ciò che corrisponde a intranet in accesso portchiavi e per cancellare la mia intera cache / cookie, per vedere se riesco a ripristinare il comportmento originale strano, ma non funzionava.

Ho una sorta di roba di domini funky in corso? Che altro posso cercare di diagnosticare?

Posso confermare che vedo il problema identico con Safari 7.0.2 (9537.74.9), con tutti gli aggiornamenti correnti di Mac OS X Mavericks installati. (Migliaia di pacchetti di richiesta al secondo con lo stesso tipo di contenuto descritto in precedenza.)

Tuttavia, mentre questo può o non può aiutare il poster originale, ho scoperto che questo problema si verifica solo se il server Windows dispone di authentication integrata di Windows (conosciuta anche come authentication NTLM) e Negozia l'authentication 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.

Ma se negozia l'authentication non è abilitata sul server, ci sarà solo un'intestazione WWW-Authenticate:

 WWW-Authenticate: NTLM 

E la risposta di Safari sarà qualcosa di simile:

 Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA= 

Questo funziona bene. In sostanza, sembra che Negotiate sia rotto in Safari e poiché il server invia Negoziate innanzitutto, indicando una preferenza per esso, Safari lo proverà e entrerà in un ciclo infinito che impedisca di ricadere in NTLM.

Quindi, se l'amministratore del server può essere persuaso per distriggersre Negoziate nelle impostazioni di authentication, il problema può essere risolto.

Posso aggiungere che Firefox invia l'intestazione "Autorizzazione: NTLM …" indipendentemente dal fatto che il server fornisce negozia in aggiunta a NTLM o less. Presumibilmente, negoziazione non è implementata in Firefox.


Aggiornare

Safari 7.0.3 (9537.75.14) mostra ancora lo stesso problema.

Abbiamo precedentemente segnalato il problema come bug a bugreport.apple.com, ma il bug è stato chiuso come duplicato di un bug precedente, il contenuto di cui non possiamo vedere, salvo che sia ancora contrassegnato come aperto.

Aggiorna 2

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

Aggiornamento 3

Questo problema è tornato in Safari 7.0.5 (9537.77.4)

Aggiorna 4

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

Safari 7.0.5 ha ancora il problema: l'authentication si interrompe se il finder condivide le risorse di networking tramite SMB: (o CIFS :). una volta che tutti i volumi di networking collegati vengono smontati, Safari riprende l'authentication appropriata.

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 di Apple 22990203 è ancora attivo. Nessun mortale è permesso vederlo (cf.bugreporter.apple.com)

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

Stiamo avendo lo stesso problema. Per questo motivo non abbiamo ancora aggiornato i nostri Mac a Mavericks. Sembra cercare di accedere all'intranet senza credenziali di dominio (intranet \ 'blank'). Dovrebbe utilizzare il dominio \ username. Posso capire che questo può essere frustrante, ma sembra che l'authentication manca nel safari.

Solo pochi secondi farà uscire i ceppi.

Firefox sembra funzionare comunque.

Questo potrebbe essere un lungo colpo, ma se hai un biglietto Kerberos (da firmare in un altro servizio), Safari potrebbe cercare di utilizzare questo.

Apri / Sistema / Libreria / CoreServices / Ticket Viewer.app per vedere se hai dei biglietti Kerberos. Se è così, fare clic sul biglietto, Rimuovi identity framework; e riprovare.

In alternativa, se nulla è elencato, prova a utilizzare l'aggiunta di identity framework; e vedere se funziona con Safari.

Firefox e Chrome non utilizzano Kerberos, non credo, ecco perché ti chiedono separatamente per le credenziali.

Portachiavi era una buona idea, ma non hai abbastanza da fare.

In Safari, se si guarda sotto il menu Safari , verrà visualizzato Reset Safari... Seleziona questa opzione e un numero di cache verrà eliminato.

Ora apri Safari > Preferences > Autofill e distriggers i User names and passwords . Ora seleziona Passwords e rimuove tutte le password elencate. Seleziona Privacy e fai clic su Remove All Website Data . Seleziona Extensions e se le estensioni dell'interruttore sono state installate su Estensioni.

Ora vai e prova il tuo sito web. Una volta eseguito il tentativo e guardate la Privacy per vedere se sono stati lasciati i cookie e Passwords per vedere se Safari ha salvato la password.

Questo potrebbe avvicinarsi ad una soluzione. Dimmi come va dopo. Se funziona Chrome, mi piacerebbe sapere esattamente cosa sta facendo. Potrebbe essere richiesto un po 'più snooping?

Semplicemente per i pigiami provare l'URL http://username:[email protected]/ (sostituendo i bit ovviamente) e vedere cosa succede.

Avevo anche un problema simile al mio ufficio. La chiave era assicurarsi che la mia ricerca DNS escludesse i siti locali (società / intranet) da uscire per cercare un indirizzo DNS. Questa era la causa del mio sistema che voleva uscire al proxy e get il log costante nello schermo. Quello che stava succedendo è che la mia richiesta per l'url di intranet.company.com è stata presa dal server proxy e inviata al web. Il webserver principale vedrà che mi stavo collegando tramite un'indirizzo IP aziendale e rispondere alla ricerca di credenziali che sono stati spazzati via dal proxy … credo.

Fondamentalmente assicurarsi che il sito intranet non venisse inviato a un procuratore risolvesse il mio problema. Che solo rendere Chrome il mio browser predefinito …

  1. Crea un nuovo utente sul Mac.
  2. Passare a questo nuovo utente. Puoi farlo tenendo aperta la session corrente.
  3. Lancia Safari. Questo è un Safari vergine.
  4. Provare a connettersi al sito. Normalmente, si otterrà la window di authentication.

Questo può o non può aiutare, ma ho scoperto che se mi connetti a una condizione smb diversa da me stesso perde la window di authentication in Safari 7.0.3 che esegue OS 10.9.2

Io come nel mio login e password di Active Directory. Sono vincolato ad un server di directory attivo.

Non ho provato questo su una macchina non vincasting. Ho anche provato Chrome e FireFox e queste applicazioni non hanno alcun problema perire il modo. Aurora non funziona più in nessun modo.

Modifica da un altro utente:

Questo sembra essere la causa del problema. Questo è stato testato con una macchina senza fili con Mavericks e ora in esecuzione Yosemite. Dopo aver connessa alle condivisioni SMB, Safari non verrà più presentata la window di authentication. In Mavericks, non appena si disconnette dalle azioni SMB, viene presentata la window di dialogo e posso accedere al sito intranet Sharepoint 2013 della mia azienda. Non ho alcun problema su Sharepoint 2007 o su altri siti intranet.

A Yosemite, mi sembra di poter connettersi ad un massimo di due azioni SMB e che Safari continuerà a lavorare. Se sono collegato a tre o più azioni SMB, il problema si manifesta. Non sono ancora sicuro se è il numero di azioni o se forse le diverse parti dispongono di autorizzazioni diverse che potrebbero influenzare la situazione. Devo fare dei test più rigorosi su quella faccia.

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

Nel nuovo biglietto, utilizzare il nome utente e la password per l'authentication dell'URL intranet.