Safari 7, HTTP kimlik doğrulaması kullanarak intranete bağlanamıyor

Gelişmiş HTTP istekleri hakkında yeni bilgiler için aşağıdaki GÜNCELLEME bölümüne bakın.

Bu yüzden Ekim ayında yeni bir işe başladım. Çoğunlukla bir Windows mağazası ve bir sürü dahili öğe için IIS ve Active Directory kullanıyorlar. Adresinde bir intranet sitesi var intranet.companyname.com.

Mavericks'teki Chrome'da, oraya gittiğimde, beklenen küçük HTTP yetkisi açılır menüsünü alıyorum:

burada kullanıcı adımı ve şifremi yazabilirim. Active Directory ile çok hızlı değilim, ama sanırım msgdaçık olduğum Active Directory etki alanı, bu yüzden yazıyorum msgd\lheidbrederve şifrem ve Chrome'da başarıyla giriş yapabilirim.

Ekim ayında, bunu Safari'de ilk kez denediğimde, garip bir davranış aldım; gibi, şifre şeyi gördüm, ama sonra benim kimlik bilgileri koymak zaman işe yaramadı. Ne yaptığını tam olarak hatırlamıyorum.

Ancak bu ilk denemeden sonra ve o zamandan beri her denemede, gitmeye çalıştığımda intranet.companyname.comSafari boş bir ekran gösteriyor:

Ekran değişmez ve ilerleme çubuğu yaklaşık% 20 dolar ve orada kalır.

GÜNCELLEME

HTTP isteklerini gizlemek için bir uygulama çalıştırdım ve bunun sahne arkasında ne yaptığını öğrendim. Sadece orada oturmak değil; Safari aslında sayfayı saniyede yaklaşık 1000 kez istiyor ve her seferinde 401 hatası ve "Bu sayfayı görüntüleme yetkiniz yok" başlıklı bir HTML hata sayfası alıyor.

Bir yükleme denemesinin ortasından gelen bir örnek istek üzerine, Safari bu Authorizationbaşlığı gönderir :

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Ve sunucu bu WWW-Authenticateüstbilgiyle yanıt verir :

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

Bir sonraki istekte, Safari aynı Authorizationüstbilgiyi gönderir ve ardından sunucu çok farklı bir WWW-Authenticateüstbilgiyle yanıt verir :

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

Reklam sonsuzluğunu tekrarlayın .

intranetOrijinal Garip davranışı geri yükleyebileceğimi görmek için Anahtarlık Erişimi ile eşleşen her şeyi silmeyi ve tüm önbelleği / çerezleri temizlemeyi denedim , ancak işe yaramadı.

Bir tür funky alan adı var mı? Bunu teşhis etmek için başka ne deneyebilirim?

Safari 7.0.2 (9537.74.9) ile aynı sorunu gördüğümü ve tüm güncel Mac OS X Mavericks güncellemelerinin yüklü olduğunu doğrulayabilirim. (Yukarıda açıklanan içeriğin aynısı olan saniyede binlerce istek paketi.)

Ancak, bu özgün poster yardımcı olabilir veya olmayabilir, ancak bu sorun yalnızca Windows sunucusunda Tümleşik Windows Kimlik Doğrulaması (NTLM Kimlik Doğrulaması olarak da bilinir) ve Kimlik Doğrulaması Anlaş etkinleştirilmişse oluşur.

Sunucu daha sonra şu iki başlığı gönderir:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari cevap verecektir:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

Ve oradan, döngü devam edecek.

Ancak Sunucuda Kimlik Doğrulaması Anlaşılamıyorsa, yalnızca bir WWW-Kimlik Doğrulama başlığı olacaktır:

WWW-Authenticate: NTLM

Ve Safari'nin yanıtı şöyle olacak:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

Bu işe yarayacak. Esasen, Anlaşmanın Safari'de bozulduğu ve sunucu ilk önce Anlaşmayı gönderdiğinden, bir tercih olduğunu belirttiği için Safari bunu deneyecek ve NTLM'ye düşmesini engelleyen sonsuz bir döngü girecektir.

Bu nedenle, sunucu yöneticisi kimlik doğrulama ayarlarında Anlaşmayı kapatmaya ikna edilebilirse, sorun çözülebilir.

Sunucunun NTLM'ye ek olarak Anlaşma sağlayıp sağlamadığına bakılmaksızın Firefox'un "Authorization: NTLM ..." başlığını gönderdiğini ekleyebilirim. Muhtemelen Müzakere, Firefox'ta uygulanmamıştır.

Güncelleme

Safari 7.0.3 (9537.75.14) hala aynı sorunu göstermektedir.

Sorunu daha önce bugreport.apple.com adresinde bir hata olarak bildirmiştik, ancak hata, hala açık olarak işaretlenmiş olması dışında, içeriğini göremediğimiz önceki bir hatanın kopyası olarak kapatıldı.

Güncelleme 2

Hauns'un kimlik doğrulamanın Safari 7.0.4 (9537.76.4) ile çalıştığını tespit ettiğini doğrulayabilirim.

Güncelleme 3

Bu sorun Safari 7.0.5'te (9537.77.4) geri döndü

Güncelleme 4

Bu sorun, hauns tarafından belirtildiği gibi cif veya smb hacimleri takılıyken Safari 7.0.6'da (9537.78.2) hala mevcuttur.

Safari 7.0.5'te hala sorun var: bulucu SMB yoluyla ağ kaynaklarını paylaşırsa kimlik doğrulaması bozulur: (veya CIFS :). bağlı tüm ağ birimlerinin bağlantısı kesildiğinde, Safari doğru kimlik doğrulamasına devam eder.

gerileme:

1. Yosemite 10.10.1 / Safari 8.0.2'de mevcut
2. El Capitan 10.11.2 / Safari 9.0.2'de mevcut
3. Safari 10.0.1'de mevcut

Karşılık gelen Apple hatası 22990203 hala etkindir. Hiçbir ölümcül göremez (cf.bugreporter.apple.com)

Ayrıca bkz: https://discussions.apple.com/message/27727310#27727310

Aynı sorunu yaşıyoruz. Bu yüzden neden Mac'lerimizi Mavericks'e yükseltmedik. Etki alanı kimlik bilgileri olmadan İntranet'e giriş yapmaya çalışıyor gibi görünüyor (İntranet \ 'boş'). Etki alanı \ kullanıcı adı kullanıyor olmalıdır. Bunun sinir bozucu olabileceğini anlayabiliyorum ama safaride kimlik doğrulama eksik görünüyor.

Sadece birkaç saniye kütükleri patlatacak.

Firefox harika çalışıyor gibi görünüyor.

Bu uzun bir atış olabilir, ancak Kerberos biletiniz varsa (başka bir hizmette oturum açarak), Safari bunu kullanmaya çalışıyor olabilir.

Kerberos biletiniz olup olmadığını görmek için / System / Library / CoreServices / Ticket Viewer.app uygulamasını açın. Öyleyse, Kimliği Kaldır'a tıklayın ve tekrar deneyin.

Alternatif olarak, hiçbir şey listelenmemişse Kimlik Ekle'yi kullanmayı ve Safari ile çalışıp çalışmadığını kontrol etmeyi deneyin.

Firefox ve Chrome Kerberos'u kullanmıyor, sanmıyorum, bu yüzden sizi kimlik bilgileri için ayrı olarak isteyecekler.

Anahtarlıklar iyi bir fikirdi ama yeterince ileri gitmediniz.

Safari'de Safarimenünün altına bakarsanız Bunu Reset Safari...seçin ve bir dizi önbellek temizlenir.

Şimdi açık Safari> Preferences> Autofillve kapatın User names and passwords. Şimdi Passwordsburada listelenen şifreleri seçin ve kaldırın. Seçin Privacyve tıklayın Remove All Website Data. ExtensionsUzantıları yükleyip eklemeyeceğinizi seçin ve uzantıları değiştirin Off.

Şimdi gidin ve web sitenizi deneyin. Girişimi yaptıktan sonra Privacyherhangi bir çerez bırakılıp bırakılmadığını ve PasswordsSafari'nin şifrenizi kaydedip kaydetmediğini kontrol edin.

Bu sizi bir çözüme yaklaştırır. Bize bundan nasıl geçtiğini söyle. Chrome çalışıyorsa, tam olarak ne işe yaradığını bilmek isterim. Biraz daha gözetleme gerekebilir mi?

Sadece kıkırdamalar için URL'yi deneyin http://username:password@intranet.example.com/(bitlerin açık bir şekilde değiştirilmesi) ve ne olduğunu görün.

Ofisimde de benzer bir sorun vardı. Anahtar, DNS aramamın yerel (şirket / intranet) sitelerin bir DNS adresi aramasını engellemesini sağlamaktı. Bu, sistemimin proxy'ye çıkmak ve sürekli giriş ekranını almak istemesinden kaynaklandı. Olan şey intranet.company.com URL'sine olan isteğimin proxy sunucusu tarafından alınıp web'e gönderilmesiydi. Ana web sunucusu bir şirket IP üzerinden bağlandığını görüyorum ve proxy tarafından elimden alındı ​​kimlik bilgileri arayan cevap ... Bence.

Temel olarak intranet sitesinin bir proxy'ye gönderilmediğinden emin olmak sorunumu çözdü. Bu da Chrome'u varsayılan tarayıcım yapıyor ...

Kullanım Bilet Viewer.app , /System/Library/CoreServices/Ticket Viewer.appve yeni bir bilet ekleyin.

Yeni bilette, intranet URL'sinin kimlik doğrulaması için kullanıcı adını ve şifreyi kullanın.

1. Mac'te yeni bir kullanıcı oluşturun.
2. Bu yeni kullanıcıya geç. Mevcut oturumunuzu açık tutarken bunu yapabilirsiniz.
3. Safari'yi başlatın. Bu bakir bir Safari.
4. Siteye bağlanmayı deneyin. Normalde, kimlik doğrulama iletişim kutusunu alırsınız.

Bu yardımcı olabilir veya olmayabilir ama kendim dışında bir smb paylaşımına bağlanırsam, OS 10.9.2 çalıştıran Safari 7.0.3'te Kimlik Doğrulama Penceresini kaybettiğimi fark ettim

Aktif dizin giriş ve şifremde olduğu gibi kendim. Etkin bir dizin sunucusuna bağlıyım.

Bunu bağlı olmayan bir makinede test etmedim. Ayrıca Chrome ve FireFox'u da test ettim ve bu uygulamalarda sorun yok. Aurora artık hiçbir şekilde çalışmıyor.

Başka bir kullanıcı tarafından düzenleme:

Sorunun nedeni bu gibi görünüyor. Bu, Mavericks ve şimdi Yosemite çalıştıran bağlı olmayan bir makine ile test edildi. SMB paylaşımlarına bağlandıktan sonra, Safari artık kimlik doğrulama iletişim kutusunu sunmayacak. Mavericks'te, KOBİ paylaşımlarından ayrılır ayrılmaz iletişim kutusu sunulur ve şirketimin Sharepoint 2013 intranet sitesine giriş yapabilirim. Sharepoint 2007 veya diğer intranet sitelerinde sorunum yok.

Yosemite'de, en fazla iki KOBİ paylaşımına bağlanabileceğim ve Safari hala çalışacak gibi görünüyor. Üç veya daha fazla KOBİ paylaşımına bağlıysam, sorun ortaya çıkıyor. Henüz hisse sayısı olup olmadığından veya belki de farklı hisse senetlerinin durumu etkileyebilecek farklı izinlere sahip olup olmadığından emin değilim. O cephede biraz daha titiz testler yapmam gerekiyor.