Safari 7 tidak dapat terhubung ke intranet menggunakan otentikasi HTTP

9

Lihat UPDATE di bawah ini untuk informasi baru tentang permintaan HTTP aktual yang terjadi di bawah tenda.

Jadi saya memulai pekerjaan baru pada bulan Oktober. Ini sebagian besar toko Windows, dan mereka menggunakan IIS dan Active Directory untuk banyak hal internal. Mereka memiliki situs intranet di intranet.companyname.com.

Di Chrome on Mavericks, ketika saya pergi ke sana, saya mendapatkan dropdown auth HTTP kecil yang diharapkan:

Apa yang dilakukan Chrome; ini adalah hal yang HARUS saya dapatkan di Safari

tempat saya dapat mengetik nama pengguna dan kata sandi saya. Saya tidak terlalu cepat menggunakan Active Directory, tetapi saya kira msgdadalah domain Active Directory yang msgd\lheidbredersaya gunakan , jadi saya mengetik dan kata sandi saya, dan saya bisa masuk dengan sukses di Chrome.

Kembali pada bulan Oktober, pertama kali saya mencoba ini di Safari, saya mendapat beberapa perilaku aneh; seperti, saya melihat kata sandi, tetapi kemudian tidak berfungsi ketika saya memasukkan kredensial saya. Saya tidak ingat persis apa yang terjadi.

Tetapi setelah upaya pertama itu, dan pada setiap upaya sejak saat itu, ketika saya mencoba untuk pergi intranet.companyname.com, Safari menunjukkan layar kosong:

Apa yang dilakukan Safari 7 di Mavericks ketika saya mencoba terhubung ke intranet saya

Layar tidak berubah, dan bilah kemajuan mengisi sekitar 20% dan tetap di sana.

MEMPERBARUI

Saya menjalankan aplikasi untuk mengintip permintaan HTTP, dan saya mengetahui apa yang dilakukan di balik layar. Bukan hanya duduk di sana; Safari sebenarnya meminta halaman hampir 1000 kali per detik , dan setiap kali, ia mendapatkan kesalahan 401 dan halaman kesalahan HTML dengan judul "Anda tidak berwenang untuk melihat halaman ini".

Pada satu contoh permintaan dari tengah upaya pemuatan, Safari mengirimkan Authorizationtajuk ini :

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Dan server merespons dengan WWW-Authenticatetajuk ini :

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

Pada permintaan berikutnya, Safari mengirimkan Authorizationheader yang identik , dan kemudian server merespons dengan WWW-Authenticateheader yang sangat berbeda :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Ulangi tak terhingga iklan.

Saya telah mencoba menghapus semua yang cocok intranetdi Akses Keychain dan membersihkan seluruh cache / cookie saya, untuk melihat apakah saya dapat mengembalikan perilaku aneh yang asli, tetapi tidak berhasil.

Apakah saya memiliki beberapa hal domain funky yang terjadi? Apa lagi yang bisa saya coba untuk mendiagnosis ini?

mavericks safari active-directory Trombone ke-75
sumber
Alih-alih masalah gantungan kunci, itu mungkin terkait dengan cookie. Anda bisa mencoba menghapusnya dari bagian "Privasi" di panel preferensi Safari.
Kent
Nggak. Saya mengomentari jawaban di bawah ini; Saya membersihkan cache, cookie, semuanya, dan melakukan hal yang persis sama. Saya seharusnya mendapatkan popup otentikasi HTTP, jadi saya tidak berpikir cookie secara langsung berkaitan dengan itu.
Trombone ke
Pikiran acak ... apakah Anda juga memeriksa gantungan kunci iCloud Anda (jika Anda menautkan gantungan kunci ke iCloud, itu)? Di Akses Keychain, ada entri terpisah untuk keychain masuk dan gantungan kunci iCloud Anda .
ithos67
Sebuah pemikiran yang bagus, tetapi saya memiliki Keychain iCloud dimatikan di komputer ini, dan dalam hal apapun, pencarian di Akses Keychain mencari semua gantungan kunci yang tersedia.
Trombone ke
1
Saya tahu itu tidak akan membantu Anda, tetapi saya baru tahu bahwa saya memiliki masalah yang sama persis dengan Safari 7.0.4 dan SharePoint intranet. Saya dapat terhubung dengan baik dengan Chrome dan Firefox tetapi Safari mulai memuat, seperti yang Anda jelaskan, dan kemudian hanya duduk di sana. Sangat menyebalkan.
nemesys

Jawaban:

7

Saya dapat mengonfirmasi bahwa saya melihat masalah yang sama dengan Safari 7.0.2 (9537.74.9), dengan semua pembaruan Mac OS X Mavericks yang diinstal. (Ribuan paket permintaan per detik dengan jenis konten yang sama seperti yang dijelaskan di atas.)

Namun, sementara ini mungkin atau mungkin tidak membantu poster asli, saya telah menemukan bahwa masalah ini hanya terjadi jika server Windows memiliki Otentikasi Windows Terpadu (juga dikenal sebagai Otentikasi NTLM) dan Negosiasi Otentikasi diaktifkan.

Server kemudian mengirimkan dua header ini:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari akan membalas:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Dan dari sana, loop akan berjalan.

Tetapi jika Negosiasi Otentikasi tidak diaktifkan di server, hanya akan ada satu header WWW-Otentikasi:

WWW-Authenticate: NTLM

Dan jawaban Safari akan menjadi seperti:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Ini akan bekerja dengan baik. Pada dasarnya, tampaknya Negosiasi rusak di Safari, dan karena server mengirim Negosiasi terlebih dahulu, menunjukkan preferensi untuk itu, Safari akan mencobanya dan memasukkan loop tak terbatas yang mencegahnya kembali ke NTLM.

Jadi, jika administrator server dapat dibujuk untuk mematikan Negosiasi dalam pengaturan otentikasi, masalahnya dapat diselesaikan.

Saya dapat menambahkan bahwa Firefox mengirimkan tajuk "Otorisasi: NTLM ..." terlepas dari apakah server menyediakan Negosiasi selain NTLM atau tidak. Agaknya, Negosiasi tidak diterapkan di Firefox.

Memperbarui

Safari 7.0.3 (9537.75.14) masih menunjukkan masalah yang sama.

Kami sebelumnya melaporkan masalah ini sebagai bug di bugreport.apple.com, tetapi bug itu ditutup sebagai duplikat bug sebelumnya — konten yang tidak dapat kami lihat, kecuali bahwa bug itu masih ditandai sebagai terbuka.

Perbarui 2

Saya dapat mengkonfirmasi temuan hauns bahwa otentikasi bekerja dengan Safari 7.0.4 (9537.76.4).

Perbarui 3

Masalah ini kembali pada Safari 7.0.5 (9537.77.4)

Perbarui 4

Masalah ini masih ada di Safari 7.0.6 (9537.78.2), sebagaimana dicatat oleh hauns, dengan cifs atau volume seseorang dipasang.

Otto G
sumber
Terimakasih atas infonya. Anda harus mempertimbangkan menyalin laporan bug resmi Anda ke Open Radar dan menautkannya di sini.
Trombone ke
1
Masalah ini telah diatasi dalam OS X 10.11.5
Claus Jørgensen
3

Safari 7.0.5 masih memiliki masalah: otentikasi rusak jika pencari berbagi sumber daya jaringan melalui SMB: (atau CIFS :). setelah semua volume jaringan yang terhubung dilepas, Safari melanjutkan otentikasi yang tepat.

Regresi:

  1. hadir di Yosemite 10.10.1 / Safari 8.0.2
  2. hadir di El Capitan 10.11.2 / Safari 9.0.2
  3. hadir di Safari 10.0.1

Bug Apple 22990203 yang sesuai masih aktif. Tidak ada manusia yang diizinkan melihatnya (cf.bugreporter.apple.com)

Lihat juga: https://discussions.apple.com/message/27727310#27727310

haun
sumber
1

Kami memiliki masalah yang sama. Karena itu mengapa kami belum memutakhirkan Mac kami ke Mavericks. Tampaknya mencoba masuk ke Intranet tanpa kredensial domain (Intranet \ 'blank'). Itu harus menggunakan domain \ username. Saya bisa mengerti ini bisa membuat frustasi tetapi tampaknya otentikasi hilang di safari.

Saya hanya beberapa detik itu akan meniup log.

Firefox tampaknya bekerja dengan baik.

Daniel
sumber
1
"Aku [n] hanya beberapa detik saja akan mengeluarkan log" - Benarkah? Saya tidak menunjukkan itu mencatat apa pun di Console.app. Log apa yang ditulis untuk Anda?
Trombone ke
Kami menggunakan Solarwinds untuk logging kami. Namun itu mengenai log Sistem di server intranet kami.
Daniel
1

Ini mungkin sulit, tetapi jika Anda memiliki tiket Kerberos (dari masuk ke layanan lain), Safari mungkin mencoba menggunakannya.

Buka / System / Library / CoreServices / Ticket Viewer.app untuk melihat apakah Anda memiliki tiket Kerberos. Jika demikian, klik tiketnya, Hapus Identitas, dan coba lagi.

Atau, jika tidak ada yang terdaftar, coba gunakan Tambah Identitas dan lihat apakah itu berfungsi dengan Safari.

Firefox dan Chrome tidak menggunakan Kerberos, saya tidak berpikir, itulah sebabnya mereka akan meminta Anda secara terpisah untuk kredensial.

mudah terbakar
sumber
1
Saya tidak memiliki apa-apa yang terdaftar di sana, dan ketika saya mencoba untuk memasukkan kredensial, ia mengatakan "Kata sandi salah".
Trombone ke
1
Saat Anda menambahkan tiket, Anda menggunakan msgd \ lheidbreder sebagai nama pengguna, benar?
terbakar
1
Ya, tentu saja.
Trombone ke
0

Gantungan kunci adalah ide yang bagus tetapi Anda tidak cukup jauh.

Di Safari jika Anda melihat di bawah Safarimenu Anda akan melihat Reset Safari...Pilih ini dan sejumlah cache akan dihapus.

Sekarang buka Safari> Preferences> Autofilldan mematikan User names and passwords. Sekarang pilih Passwordsdan hapus semua kata sandi yang tercantum di sana. Pilih Privacydan klik Remove All Website Data. Pilih Extensionsdan jika Anda memiliki ekstensi yang akan dipasang, alihkan ekstensi Off.

Sekarang pergi dan coba situs web Anda. Setelah Anda melakukan upaya, lihat Privacyuntuk melihat apakah ada cookie yang tersisa dan Passwordsuntuk melihat apakah Safari menyimpan kata sandi Anda.

Ini mungkin membuat Anda lebih dekat ke solusi. Beritahu kami bagaimana hasilnya setelah itu. Jika Chrome berfungsi, saya ingin tahu persis apa yang dilakukannya. Bisakah sedikit lebih banyak pengintaian diperlukan?

Hanya untuk cekikikan coba URL http://username:[email protected]/(ganti bit jelas) dan lihat apa yang terjadi.

Tony Williams
sumber
Tidak ada kata sandi atau cookie untuk intranet.companyname.comsitus ini, tetapi saya tetap membersihkan semuanya, dan seperti yang diharapkan, saya mendapatkan perilaku yang sama persis. Perhatikan bahwa yang harus saya dapatkan adalah modal otentikasi HTTP browser, jadi jika itu akan ada di mana saja, itu akan berada di Akses Keychain, bukan di cookie.
Trombone ke
1
Menambahkan sedikit lebih banyak ketika hal itu datang kepada saya.
Tony Williams
1
Tidak ada yang berguna terjadi ketika saya mencoba format URL itu.
Trombone ke
1
Cobalah https://juga.
Tony Williams
0

Saya memiliki masalah serupa di kantor saya juga. Kuncinya adalah memastikan bahwa pencarian DNS saya mengecualikan situs lokal (perusahaan / intranet) agar tidak keluar untuk mencari alamat DNS. Itu sebabnya sistem saya ingin pergi ke proxy dan mendapatkan layar masuk yang konstan. Apa yang terjadi adalah bahwa permintaan saya untuk url intranet.company.com diambil oleh server proxy dan dikirim ke web. Server web utama akan melihat bahwa saya terhubung melalui IP perusahaan dan merespons mencari kredensial yang dilucuti oleh proxy ... saya pikir.

Pada dasarnya memastikan bahwa situs intranet tidak dikirim ke proxy menyelesaikan masalah saya. Plus itu hanya menjadikan Chrome sebagai browser default saya ...

Bradford Benn
sumber
0

Gunakan Tiket Viewer.app , /System/Library/CoreServices/Ticket Viewer.app, dan menambahkan tiket baru.

Di tiket baru, gunakan nama pengguna dan kata sandi untuk otentikasi URL intranet.

serbanc
sumber
1
Seperti ditunjukkan di atas, setiap kali saya mencoba menambahkan tiket baru di aplikasi itu, ia memberi tahu saya bahwa saya memiliki kombinasi nama pengguna / kata sandi yang buruk. Saya sudah mencoba keduanya lheidbrederdan msgd\lheidbredersebagai nama pengguna saya; tidak berhasil.
Trombone ke
Ini sebenarnya bekerja untuk saya. Saya harus menambahkan identitas untuk domain tempat intranet saya aktif, jadi misalnya 'domainusername @ workdomain', menggunakan kata sandi domain saya.
tjeerdhans
0
  1. Buat pengguna baru di Mac.
  2. Beralih ke pengguna baru ini. Anda dapat melakukan ini sambil menjaga sesi Anda saat ini terbuka.
  3. Luncurkan Safari. Ini adalah Safari perawan.
  4. Coba sambungkan ke situs. Biasanya, Anda akan mendapatkan dialog otentikasi.
Nicolas Barbulesco
sumber
0

Ini mungkin atau mungkin tidak membantu tetapi saya telah menemukan bahwa jika saya terhubung ke share seseorang selain diri saya, saya kehilangan Window Otentikasi di Safari 7.0.3 yang menjalankan OS 10.9.2

Diriku seperti di direktori aktif saya login dan kata sandi. Saya terikat ke server direktori aktif.

Saya belum menguji ini pada mesin yang tidak terikat. Saya juga telah menguji Chrome dan FireFox dan aplikasi ini tidak memiliki masalah dengan cara layu. Aurora tidak bekerja lagi.

Edit oleh pengguna lain:

Ini tampaknya menjadi penyebab masalah. Ini sekarang telah diuji dengan mesin tidak terikat yang menjalankan Mavericks dan sekarang menjalankan Yosemite. Setelah saya terhubung ke saham SMB, Safari tidak akan lagi menyajikan dialog otentikasi. Di Mavericks, segera setelah saya memutuskan sambungan dari saham SMB, dialog disajikan dan saya dapat masuk ke situs intranet Sharepoint 2013 perusahaan saya. Saya tidak punya masalah dengan Sharepoint 2007 atau situs intranet lainnya.

Di Yosemite, tampaknya saya dapat terhubung ke maksimum dua saham SMB dan Safari akan tetap berfungsi. Jika saya terhubung ke tiga atau lebih saham SMB, masalah akan muncul. Saya belum yakin apakah ini jumlah saham atau apakah mungkin saham yang berbeda memiliki izin berbeda yang dapat mempengaruhi situasi. Saya perlu melakukan beberapa pengujian yang lebih ketat di bagian depan itu.

Christopher Lee
sumber