HERKES'e yazma erişimi çalışır, IUSR, IIS_IUSRS, DefaultAppPool çalışmaz. neden?


10

Tamam. Burada, Windows Server 2008 R2'de IIS 7.5'te bir Klasik ASP web sitesi kurmaya çalışıyoruz. Web sitesinin kökü altında dbc adında bir klasör vardır ve her sayfa işlenirken belirli bilgileri okumak ve yazmak için kullanılan bir dosya vardır.

Sorun, IUSR Yazma İzinleri ve IIS_IUSRS Yazma İzinleri veya DefaultAppPool Yazma İzinleri verirseniz, "E: .. \ websiteroot \ dbc \ dosyaadı.txt 'yoluna erişim reddedildi"

Ama eğer o dbc klasöründe HERKESE Yazma erişim izni verirseniz, o zaman herhangi bir hata almıyorum, her şey mükemmel görünüyor.

Daha Fazla Bilgi: Web sitesi Klasik Boru Hattı modunda çalışır, Anonim Kimlik Doğrulama Etkin (belki de etkin olan tek kimlik doğrulamasıdır) .. Ve IUSR hesabını ve Uygulama Havuzu Kimliği'ni kullanarak Anonim kimlik doğrulamasını denedim. Benim durumumda, ApplicationPoolIdentity web sitesinin kimlik doğrulaması için kimliktir. I / O dosyası için bir COM + kullanıyoruz. Ve bir nesneyi örneklemek için Klasik ASP Server.CreateObject. COM + bir ağ hizmeti olarak çalışır.

Düşünceler? HERKES'e Yazma izni vermek istemiyorum. Bir şey mi kaçırıyorum?

ÇÖZÜLDÜ: İşte yaptığım şey.

CipherDemo adlı web sitem, IIS 7.5'te bir AppPoolIdentity altında çalışıyordu ve bu kimlik IIS AppPool \ CipherDemo tarafından bulunabilir. Bu klasörde RW izinleri vermek için ICACLS kullandım.

ve aslında G / Ç dosyasını yapan COM +, Ağ Hizmeti Kimliği altında çalışıyordu. Erişim Engellendi Hatasını izlemek için İşlem İzleyicisi'ni kullanırken, Ağ Hizmeti'nin bu klasörde yalnızca Okuma izni olduğu döndü.

Bu klasöre Yazma erişimi vermek için ICACLS "klasör adı" / grant: r "NT AUTHORITY \ NETWORKSERVICE" :( OI) (CI) RXW / T kullandım.

Ve çözdüm.

Web sitesi CipherDemo Identity olarak çalıştığı için, bu COM + üzerinden dosyaya erişmek için kullanılacak hesap olacak niyetindeydim. Ancak COM + 'nın hala kendi Kimlik sınırları üzerinde çalışacağını bulmak utanç vericidir.

Yanıtlar:


5

IIS 7.5 altında (ve isteğe bağlı olarak IIS 7'de) tüm çalışanlar Uygulama Havuzu Kimliği ile çalışır: kullanıcı "IIS AppPool * PoolName *".

Herkes yerine bu kullanıcıya erişim izni verin (adı, seçili kimlik iletişim kutularına yazmanız gerekir; Bul işlevinde görünmez).

İis.net'te işleri daha ayrıntılı bir şekilde kapsayan çok kullanışlı bir sayfa var .

Ayrıca dikkat: IIS7 (Server 2008) altında:

  • Uygulama havuzu kimliğini, gelişmiş ayarlarda uygulama başına havuz temelinde ayarlarsınız.
  • GUI desteği yoktur, bu nedenle izinleri ( icacls.exe) ayarlamak için komut satırına ihtiyacınız olacaktır .

Son olarak SQL Server'ın kimlik seçimi, uygulama havuzu kimliği hakkında da bilgi sahibi değildir: kullanın CREATE LOGINve CREATE USERbaşlangıçta GUI rolleri vermek için kullanılabilir.


@Richard - Evet. Hızlı yanıt için teşekkürler. msdn forumları bugünlerde çok kullanışsız. Geri dönün ... Birkaç gündür IIS.net web sitesi ve serverfault'u dolaşıyorum. IIS 7.5 / Win sunucusu 2008 R2'imde varsayılan Uygulama havuzu kimliğini kullanıyorum. Ve böylece, 'dbc' klasörümde IIS APPPOOL \ DefaultAppPool Wite izinlerini verdim. Ayrıca bu klasörde IUSR ve IIS_IUSRS Yazma izinleri verdim. HERKES Yazma izinleri vermek hala işe yaramaz. Kaçırdığım bir şey olduğunu biliyorum .. Yardımcı olabilir misiniz?
gmaran23

@ gmaran23: Açık adımlar işe yaramazsa , tam olarak neyin başarısız olduğunu görmek için Process Monitor'ü kullanırım (ve genellikle açık dosya çok fazla erişim ister, ACL'yi doğru şekilde ayarlayamadım veya bir şey aksi halde dosya açıktır).
Richard

@Richard - FileMode.Open, FileAccess.ReadWrite ile bir dosya okuyucu ile Okuma / Yazma işlemleri yaparım. - Sanırım bu kısım iyi. Dosyada başka bir şey açık - sanırım bu göz ardı edilebilir, çünkü herhangi bir olasılık yok .. ACL'de bir sorun var. Bunu kontrol edip buraya göndereceğim. Ayrıca İşlem Monitörü'nü de deneyeceğim. Yardımınız için teşekkürler :)
gmaran23

@ gmaran23: Eğer işe yaramazsa, her zaman test ettiğiniz bir şey bildiğinizi varsaymayın. Yıllar boyunca çok fazla zaman harcadım çünkü bir şeyin doğru olduğunu veya doğru olmadığını biliyorum - çoğu zaman yanılmışım.
Richard

1
@ gmaran23: Neler olup bittiğini tam olarak görmek için araçları kullanın: tahmin ediyorsunuz ve sorunlar üzerinde sistematik olarak çalışmıyorsunuz. (1) Dosyanın açık olmadığını onaylamak için İşlem Gezgini'ni kullanın. (2) Hangi erişimin ve hangi kimliğe göre (ve doğru dosyaya sahip olduğunuzu) görmek için İşlem İzleyicisi'ni kullanın. (3) # 2 sonucunu dosyadaki ACL'ye karşı iki kez kontrol edin (ve tüm ayrıntılar için gelişmiş güvenlik özelliklerini açın). (4) Bir şeyi ayarlayın ve düzeltilinceye kadar 1 numaraya gidin. Birkaç yinelemeden sonra hala sıkışıp kalırsanız Q'yu tam ayrıntılarla genişletin (ve spesifik olun).
Richard

5

Hesabı doğrudan yazarak NTFS GUI aracılığıyla ekleyebilirsiniz. Ad IIS APPPOOL\<<app pool name>>, ör IIS APPPOOL\DefaultAppPool. (bu Microsoft destek makalesine bakın )

Alternatif bir çözüm: "Network Service" hesabını yazma izni veren uygulama havuzu kullanıcısı olarak kullanıyorum.


Doğru, Bu ipucu iyi, ama ben zaten yaptım. Uygulama havuzu için varsayılan "ApplicationPoolIdentity" kullanın. Ve 'dbc' klasörü için zaten IIS AppPool \ DefaultAppPool için Yazma izinleri verdim. Ama HERKES Yazma izni verene kadar hala çalışmaz.
gmaran23

1

Belirli bir kullanıcıya yalnızca WRITE klasörüne izin vermek istiyorsanız, sitenin 'Anonim kullanıcı kimliğini' 'Uygulama havuzu kimliği' yerine 'Belirli Kullanıcı' olarak değiştirmeniz gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.