ASP.NET'de yaygın izinler ve güvenlikle ilgili sorunları giderme

Bu makalede, ASP.NET'da yaygın izinlerin ve güvenlikle ilgili sorunların nasıl giderilir?

Orijinal ürün sürümü: ASP.NET
Özgün KB numarası: 910449

Yararlı araçlar

Bozuk olan bir şeyi düzeltmeye çalışmadan önce, sorunu daraltmanıza yardımcı olacak birkaç araç hakkında bilgi sahibi olmanız gerekir. Bizim örneğimizde FileMon, RegMon ve Güvenlik Denetimi gibi araçlarla ilgileniriz. FileMon hakkında daha fazla bilgi için bkz. Windows v7.04 için FileMon.

RegMon hakkında daha fazla bilgi için bkz. Windows Sysinternals.

Sorunu yalıtmak için detaya gitme

  • Uygulama hiç çalıştı mı? Evet ise, uygulamanın bozulmasına neden olabilecek değişiklik ne olabilir? Sunucuya yazılım güncelleştirmeleri veya güvenlik güncelleştirmeleri uygulanmış olabilir. Bir kod dağıtımı da soruna neden olmuş olabilir.
  • Basit .html ve .asp sayfaları IIS'den mi hizmet alır?
  • Uygulama farklı bir IIS sürümüne geçirildi mi?
  • Sunucudaki diğer ASP.NET uygulamaları aynı hatayla başarısız oluyor mu? Başarısız olan tek uygulama bu mu?
  • Sorun tüm kullanıcılar için mi yoksa yalnızca belirli kullanıcılar için mi oluşuyor?
  • Sorun Web sunucusunda yerel olarak gezinirken yeniden üretilebilir mi yoksa yalnızca birkaç istemci için yeniden üretilebilir mi?
  • Kimliğe bürünme kullanıyorsanız, kimliğine bürünülen kullanıcının kaynağa gerekli erişimi var mı?

Yukarıdaki sorular, bir sorunu tanılamak için yararlıdır. Sorununuzu ASP.NET forumlarından herhangi birinde yayınlıyorsanız ve bu soruların çoğuna zaten yanıtlara sahipseniz, sorununuz için hızlı bir işaretçi veya çözüm edinme olasılığınız yüksektir. Anahtar, "ASP.NET uygulamamı çalıştırmaya çalışırken Erişim Reddedildi hatası alıyorum" demek yerine, varsa tüm ASP.NET yığın izleme hatasını göndermektir. Yardım eden var mı?" Birinin yığın izlemesine bakabilmesi ve eksiksiz bir hata iletisi görebildiğinde size işaretçiler vermesi çok daha kolaydır. Bu yüzden kendinize sormanız gerekir...

Tam hata iletisi nedir?

Müşterilere sorduğumuz ilk soru şudur: "Tam hata iletisi nedir?" Microsoft .NET Framework tarafından oluşan hata iletisinin açık bir açıklamasınız varsa, bu bölümü atlayabilirsiniz. Uygulamanız gerçek hata iletisini maskeler ve bunun yerine size "Beklenmeyen bir hata oluştu. Ayrıntılar için web sitesi yöneticisine başvurun. Bunun kimseye pek bir anlamı yok. Gerçek hata iletisini almanıza yardımcı olacak birkaç adım aşağıdadır.

  • Uygulama dizininde Web.config dosyasını bulun ve açın ve customErrors değerini mode="Off" olarak değiştirin. Dosyayı kaydedin ve sorunu yeniden oluşturun.

  • Uygulama geliştiricisi tarafından gerçekleştirilen özel olay/hata işleme nedeniyle yukarıdaki adımı takip ettikten sonra gerçek hata iletisini görmek yine de mümkün olmayabilir. Global.asax dosyasında Application_Error olayını bulmayı deneyebilir ve özel bir hata sayfasına gitmek için işlevini kullanan Server.Transfer("Errors.aspx") herhangi bir kodu açıklama satırı yapabilirsiniz.

    //Global.asax 
    void Application_Error(object sender, EventArgs e) 
    { 
        // Code that runs when an unhandled error occurs 
        //Server.Transfer("Errors.aspx"); 
    }
    

Gerçek hata iletisini aldıktan sonra, hatanın yerel bir kaynakta veya ASP.NET uygulamanızın erişmeye çalıştığı uzak bir kaynakta eksik izinlerden kaynaklandığını belirlemek için okuyun.

İpucu

Gerçek hata iletisini nasıl göreceğinizi öğrenmek için geliştiricinize başvurabilirsiniz. Geliştiriciniz dosyayı bir dosyaya kaydediyor veya e-posta bildirimleri alıyor olabilir. Değiştireceğin herhangi bir dosyanın yedeğini oluşturmayı her zaman unutmayın. Bir yedekleme kullanılabilir durumdaysa, değişiklikleri istediğiniz zaman geri alabilirsiniz.

Sorun, ASP.NET uygulamasının erişmeye çalıştığı yerel bir kaynakta eksik izinler nedeniyle oluşur

Özel bir hata iletisi nedeniyle sorunun net bir açıklamasını alamıyorsanız, FileMon'u çalıştırın ve sorunu yeniden oluşturun. Yakalamayı durdurun ve FileMon.xls olarak kaydedin ve dosyayı Microsoft Excel'de açın. Veri menüsünde Filtre'ye tıklayın ve ardından Otomatik Filtre'ye tıklayarak Excel'in filtreleme özelliklerini kullanın. Şimdi sütundaki F açılan listeyi seçin ve "ERİşİm REDDEDİLDİ" hatalarını arayın.

Aşağıda örnek bir FileMon çıkışı gösterilmiştir.

10381 1:01:11 PM w3wp.exe:2320 OPEN C:\winnt\microsoft.net\framework\v1.1.4322\Temporary ASP.NET Files\sessiontest\8832e585\275ec327\global.asax.xml 
ACCESS DENIED NT 
AUTHORITY\NETWORK SERVICE

Filtrelenen sonuçlardan görebileceğiniz gibi sorunun nedenini daraltmış olduk. FileMon, NT AUTHORITY\NETWORK SERVICE hesabının klasörde NTFS izinlerinin C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files eksik olduğunu gösterir. Bunun düzeltilmesi doğrudan doğru olmalıdır.

İpucu

sorunu giderip gidermediğini görmek için ASP.NET işlem hesabını bir Yönetici hesabıyla değiştirmek iyi bir adım olabilir. IIS 6.0 ve sonraki sürümlerde, uygulamanın çalışıp çalışmadığını görmek için IIS AppPool kimliğini "Yerel Sistem" olarak değiştirirsiniz.

Not

Bu çözüm olarak değil, yalnızca sorun giderme adımı olarak kullanılmalıdır.

Çoğu kişi Microsoft .NET Framework yeniden yükleme eğilimindedir ve hatta işletim sistemini yeniden yükleme kapsamına bile gidebilir. Bu önerilen bir sorun giderme adımı değildir ve sorunun yeniden oluşmayacağını garanti etmez. Böyle bir örnek sağlayacağım. Aralıklı sorunları yalıtmak ve gidermek genellikle zordur. Bu senaryoda müşterinin uygulaması birkaç saat boyunca düzgün çalışır ve sonra aniden aşağıdaki hatayla başarısız olur. Müşteri hem .NET Framework hem de işletim sistemini yeniden yüklemeyi zaten denemişti. Bu işlem birkaç gün boyunca sorunu çözmüş gibi görünse de yeniden göründü.

FileMon çalıştırıldığında ACCESS DENIED hatası gösterilmiyor. ASPNET hesabı için gerekli tüm izinler yerindeydi. Sorundan kurtulmanın tek yolu kutuyu yeniden başlatmaktır. IIS sıfırlaması bile yardımcı olmaz. "Ah, Microsoft Software'in kurtarılması için her zaman yeniden başlatma gerekiyor mu?" diye düşünüyorsunuz. Evet, yanılıyorsun!

Buradaki anahtar, hata iletisine yakından bakmaktır. Hatanın her zamanki ACCESS DENIED hatası yerine "dosya yazmak için açılamıyor" olduğu açıkça belirtiliyor, bu nedenle dosya veya klasörde kilit tutan ve ASP.NET yazmasına izin verilmeyen başka bir işlem olduğunu düşünüyorum. Yeniden başlatmanın diğer işlemi sonlandırdığını ve ASP.NET uygulamanın, düzenbaz işlem dosyayı yeniden kilitleyene kadar yeniden çalışmaya başlaması mantıklıdır. Yapılacak mantıksal şey, tüm virüsten koruma programlarını, üçüncü taraf casus yazılımları veya sunucuda çalışan diğer dosya izleme yazılımlarını kapatmaktır. Herhangi bir üçüncü taraf yazılımına işaret etmek istemiyorum. Ancak genel olarak virüsten koruma yazılımının IIS ve ASP.NET uygulamaları için çok fazla sıkıntıya neden olduğu bilinmektedir. Virüsten koruma yazılımının neden olduğu bilinen bir diğer sorun da, Bin klasörüne veya .config dosyalarına dokunulduğunda AppDomain geri dönüşümlerinden kaynaklanan oturum kaybıdır.

İpucu

Üçüncü taraf hizmetlerini kapatmanın en kolay yolu:

  1. Başlat'a tıklayın, Çalıştır'a tıklayın ve ardından msconfig yazın.
  2. Hizmetler'i seçin ve Tüm Microsoft Hizmetlerini Gizle'yi işaretleyin.
  3. Üçüncü taraf hizmetleri durdurmak için Tümünü Devre Dışı Bırak'a tıklayın.
  4. Başlat'a tıklayın, Çalıştır'a tıklayın ve ardından CLR'yi çalışan işlemine yeniden yüklemek için iisreset yazın.

Sorunun tekrar olup olmadığını görmek için uygulamanızı izleyin. Birden çok virüsten koruma programı çalıştırıyorsanız, soruna hangi programın neden olduğunu belirlemek için deneme ve hata yöntemini kullanın.

Not

Aynı hata yüzde 100 yeniden üretilebilirse, bunun nedeni virüsten koruma yazılımınız olmayabilir. Bu hatanın başka nedenleri de olabilir. Bir Test.aspx sayfasında aynı hatanın oluşup oluşmadığını yalıtmak için basit bir ASP.NET test uygulaması oluşturmayı deneyin. Varsa, ASP.NET için gerekli Access Control Listeler (ACL)'lerin tümünün yerinde olduğunu doğrulayın.

Bkz. Gerekli Access Control Listeler (ACL'ler) ASP.NET.

İpucu

Klasör %SystemRoot%\Assembly , genel derleme önbelleğidir. Bu klasörün ACL'lerini düzenlemek için Windows Gezgini'ni doğrudan kullanamazsınız.

Bunun yerine, bir komut istemi kullanın ve aşağıdaki komutu çalıştırın:

cacls %windir%\assembly /e /t /p domain\useraccount:r

Alternatif olarak, Windows Gezgini'ni kullanmadan önce GUI üzerinden izin vermek için aşağıdaki komutla Shfusion.dll kaydını kaldırın:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32-u shfusion.dll

Windows Gezgini ile izinleri ayarladıktan sonra aşağıdaki komutla Shfusion.dll yeniden kaydedin:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32 shfusion.dll

Sorun, ASP.NET uygulamasının erişmeye çalıştığı uzak bir kaynakta eksik izinler nedeniyle oluşur

ASP.NET uygulamanız Microsoft SQL Server veya Evrensel Adlandırma Kuralı (UNC) paylaşımı gibi uzak bir kaynağa eriştiğinde, ters gidebilecek birçok şey vardır. Ayrıca, uzak kaynakta birçok şey yanlış ayarlanmış olabilir. Kaynağın çalışmasını sağlamak için bu sorunları gidermeniz gerekir.

İlk adımınız, Windows Gezgini aracılığıyla uzak sunucuya bağlanıp bağlanamadığını görmek olacaktır.

  1. Uzak sunucuda Test adlı bir klasör oluşturun. Test klasörünün Paylaşım ve Güvenlik sekmelerinde etki alanınızı/hesabınızı ve ASP.NET uygulamanız tarafından kullanılan işlem hesabını ekleyin ve her ikisine de Tam Denetim verin.

  2. IIS sunucusunda, etki alanınızla/hesabınızla oturum açın, Başlat'a tıklayın, Çalıştır'a tıklayın ve ardından uzak sunucunun UNC paylaşım yolunu yazın: \\RemoteServerName*\Test.

    Bu klasöre ulaşamıyorsanız, bu sorunu düzeltmek için Ağ Yöneticinize başvurun. Ancak ASP.NET uygulamanız paylaşıma erişebilir.

  3. Aşağıdaki kodla CreateUNCFile.aspx adlı bir dosya oluşturun ve dosyayı uygulama dizininize kaydedin.

    <%@ Page Language="vb" %>
    <%@ Import Namespace="System.IO" %>
    <html>
    <head>
    <title>Writing to a Text File</title>
    <script runat="server">
        Sub WriteToFile(ByVal sender As System.Object, ByVal e As System.EventArgs)
            Dim fp As StreamWriter
                fp = File.CreateText("\\<RemoteServerName>\Test\" & "test.txt")
                fp.WriteLine(txtMyFile.Text)
                lblStatus.Text = "The File Successfully created! Your ASP.NET process is able to access this remote share"
                fp.Close()
        End Sub
    </script>
    
    </head>
    <body style="font: 10pt verdana">
                <h3 align="center">Creating a Text File in ASP.NET</h3>
        <form id="Form1" method="post" runat="server">
                            Type your text:
                            <asp:TextBox ID="txtMyFile" TextMode="MultiLine" Rows="10" Columns="60" Runat="server" /><br>
                            <asp:button ID="btnSubmit" Text="Create File" OnClick="WriteToFile" Runat="server" />
                            <asp:Label ID="lblStatus" Font-Bold="True" ForeColor="#ff0000" Runat="server" />
        </form>
    </body>
    </html> 
    
  4. Aşağıdaki kod satırında RemoteServerName'i> değiştirdiğinizden< emin olun

    fp = File.CreateText("\\<RemoteServerName>\Test\" &"test.txt")
    

    Böylece uzak sunucunuzun adını yansıtır.

  5. Windows Internet Explorer'ı http://**IISServerName**/**AppName**/CreateUNCFile.aspx açın ve IIS sunucusu dışındaki bir istemci bilgisayardan adresine gidin.

  6. Test.txt dosyası başarıyla oluşturulursa, ASP.NET uygulamanız uzak kaynakta kimlik doğrulaması yapabilir.

  7. Dosya oluşturma işlemi Internet Explorer istemci tarayıcısından başarısız olursa ancak IIS sunucusunun kendisinden aynı sayfaya göz atarsanız işe yararsa, büyük olasılıkla bir "Çift Atlama" senaryosuyla karşılaşmış olursunuz. Kullanıcı kimlik doğrulaması ve yetkilendirme gerektiren uzak kaynaklara erişmek için özel olarak oluşturulmuş Web Bölümleri kullanıyorsanız, büyük olasılıkla "Çift Atlama" sorunuyla karşılaşırsınız. Uzak kaynağınıza erişmek için, kaynaktan gelen çıkışın son kullanıcının erişim iznine sahip olduğu verilerle sınırlı olması için son kullanıcının kimlik bilgilerini kaynağa sağlamanız gerekebilir.

Yukarıdaki adımlarda, IIS'de NTLM Kimlik Doğrulaması'nın açık olduğu varsayılır. Temel Kimlik Doğrulaması Kerberos kullanmaz.

Daha fazla bilgi için bkz. Internet Explorer'da Kerberos hatalarını giderme.

IIS kimlik doğrulama yöntemleri hakkında daha fazla bilgi için bkz. Visual Studio 2003 Kullanımdan Kaldırılacak Teknik belgeler.

İpucu

Uzak UNC paylaşımına bağlanabiliyorsanız ancak ASP.NET uygulamasından SQL Server çalıştıran uzak sunucuya bağlanamıyorsanız, SQL Server için Hizmet Asıl Adlarını (SPN) denetlemeniz veya ayarlamanız gerekebilir. IIS'de uygulamanız için yalnızca Temel Kimlik Doğrulaması'nı etkinleştirmeyi deneyin ve SQL Server çalıştıran uzak sunucuya bağlanıp bağlanamadığınıza bakın.

"Sunucu Uygulaması Kullanılamıyor" hata iletisinin çok sayıda başka nedeni vardır. Olay günlüğü, sorununuzun nedeni hakkında daha fazla ayrıntı almak için en iyi seçeneğinizdir.

IIS günlükleri, IIS kimlik doğrulamasıyla ilgili hatalarda kullanışlıdır.

Aramanız gereken, bu hatanın durum ve alt durum kodlarıdır.

2006-10-12 22:47:28 W3SVC1 65.52.18.230 GET /MyAPP/login.aspx - 80  
MyDomain\UserID_91 65.52.22.58 Mozilla/4.0+  
(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 401 3 5

"Kaynakta ACL nedeniyle yetkisiz" ifadesini gösteren 3 alt durumuna sahip bir 401 görüyoruz.

Bu, bir dosya veya klasördeki NTFS izinlerinin eksik olduğunu gösterir. Erişmeye çalıştığınız dosya için izinler doğru olsa bile bu hata oluşabilir, ancak diğer SYSTEM ve IIS klasörlerinde varsayılan izinler ve kullanıcı hakları eksik olabilir. Örneğin, IUSR_ComputerName hesabının C:\Winnt\System32\Inetsrv dizinine erişimi yoksa bu hatayı görebilirsiniz.

İpucu

Başlat'a tıklayın, Çalıştır'a tıklayın ve ardından logfiles yazarak IIS günlüklerini içeren klasörü açın. Alternatif olarak, IIS'deki Web Sitenizin özellikler sayfasında WebSiteName sekmesine tıklayın ve Etkin günlük biçimi'nin altında Özellikler'e tıklayarak Günlük dosyası dizinini ve adını görebilirsiniz.

Burada ilgi çekici olan bir diğer şey de durum kodu 5'tir. Bu durum kodu hakkında daha fazla bilgi edinmek için net helpmsg komutunu kullanabilirsiniz:

C:\Documents and Settings\User> net helpmsg 5

Erişim reddedildi.

Şimdi başka bir ortak durum kodu olan kod 50'yi deneyelim:

C:\Documents and Settings\User> net helpmsg 50

İstek desteklenmiyor.

İpucu

Başka bir genel "500 İç Sunucu Hatası" iletisi aldığınızda, kolay HTTP hata iletilerini devre dışı bırakmak iyi bir fikirdir; böylece hatanın ayrıntılı bir açıklamasını alabilirsiniz. Daha fazla bilgi içerebileceği için olay görüntüleyicisine bakmayı unutmayın.

Amaç, eldeki sorunla ilgili en fazla ayrıntıyı almak için mevcut olan tüm günlüğe kaydedilen bilgileri kullanmaktır.

Kaynaklar

Daha fazla bilgi için bkz.: