Windows Server 2008 üzerinde IIS 7'de, uygulama havuzları NetworkService hesabı yerine "ApplicationPoolIdentity" hesabı olarak çalıştırılabilir.
Bu "ApplicationPoolIdentity" hesabına nasıl izinler atayım. Makinede yerel kullanıcı olarak görünmüyor. Hiçbir yerde grup olarak görünmez. Hiçbir yerde uzaktan hiçbir şey görünmez. Yerel kullanıcılar, gruplar ve yerleşik hesaplara göz attığımda, listede görünmez ve listede de benzer bir şey görünmez. Ne oluyor?
Bu sorunla tek ben değilim: bkz. IIS 7.5 + Windows 7'de ApplicationPoolIdentity ile ilgili sorun örnek olarak.
"Bu ne yazık ki, Windows Server 2008 / Windows Vista'da nesne seçicinin bir sınırlamasıdır - zaten birçok kişi bunu keşfettiğinden, komut satırı araçlarını kullanarak uygulama havuzu kimliği için ACL'yi hala değiştirebilirsiniz. icacls."
Güncelleştirme: Asıl soru Windows Server 2008 idi, ancak çözüm Windows Server 2008 R2 ve Windows Server 2012 (ve Windows 7 ve 8) için daha kolay. Kullanıcıyı doğrudan yazarak NTFS UI aracılığıyla ekleyebilirsiniz. Ad, IIS APPPOOL \ {uygulama havuzu adı} biçimindedir. Örneğin: IIS APPPOOL \ DefaultAppPool.
IIS APPPOOL\{app pool name}
Not: Aşağıdaki yorumlara göre, farkında olmak için iki şey vardır:
- Dizeyi doğrudan arama alanına değil "Kullanıcı veya Grup Seç" seçeneğine girin.
- Bir etki alanı ortamında Konumunuzu önce yerel bilgisayarınıza ayarlamanız gerekir.
Microsoft Docs makalesine başvuru: Uygulama Havuzu Kimlikleri> Kaynakların Güvenliğini Sağlama
Orijinal cevap: (Windows Server 2008 için) Bu harika bir özellik, ancak bahsettiğiniz gibi henüz tam olarak uygulanmadı. Uygulama havuzu kimliğini komut isteminden icecls gibi bir şeyle ekleyebilir, ardından GUI'den yönetebilirsiniz. Örneğin, komut isteminden böyle bir şey çalıştırın:
icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)
Ardından, Windows Gezgini'nde, wwwroot klasörüne gidin ve güvenlik izinlerini düzenleyin. DefaultAppPool adında bir gruba (grup simgesi) benzeyen şeyleri göreceksiniz. Artık izinleri düzenleyebilirsiniz.
Bununla birlikte, bunu hiç kullanmanıza gerek yoktur. Eğer istersen kullanabileceğin bir bonus. Uygulama havuzu başına özel bir kullanıcı oluşturmanın ve özel kullanıcıyı diske atamanın eski yolunu kullanabilirsiniz. Bu tam UI desteği var.
Bu SID enjeksiyon yöntemi güzeldir çünkü tek bir kullanıcı kullanmanıza izin verir, ancak her bir uygulama havuzu için benzersiz kullanıcılar oluşturmaya gerek kalmadan her bir siteyi birbirinden tamamen izole eder. Oldukça etkileyici ve UI desteği ile daha da iyi olacak.
Not: Uygulama havuzu kullanıcısını bulamıyorsanız, Uygulama Ana Bilgisayarı Yardımcı Hizmeti adlı Windows hizmetinin çalışıp çalışmadığını kontrol edin. Uygulama havuzu kullanıcılarını Windows hesaplarına eşleyen hizmettir.
'Bu konumdan' alanının alan adını değil yerel makineye ayarlandığından emin olmanız gerekir.
Aynı sorunu yaşadım ve bir kez değiştirdiğimde iyi çalıştı.
Gerçekten "rol" başına grup oluşturmalı ve o grup erişimini dosya sistemine atamalısınız. Ardından, uygulama havuzuna gereken role özel gruplara ekleyin. Bu şekilde, uygulama havuzunu daha sonra kaldırsanız bile (ve sanal kullanıcı gider nonoş), tüm izinleri yeniden tasarlamak konusunda endişelenmenize gerek yoktur, sadece yedek uygulama havuzunu mevcut gruba eklersiniz.
@Scott Forsyth - MVP yanıtını okuduktan sonra, Uygulama Ana Bilgisayarı Yardımcı Hizmetini yeniden başlatmayı denedim. Bu benim için problemi çözdü.
WS8 R2 kullanıyordum ve ekleyemedim
IIS APPPOOL\DefaultAppPool Windows Gezgini ile. Çalışmanın tek yolu komut satırı ile yapıldı:
cacls [DOSYA YOLU] / T / E / G "IIS APPPOOL \ DefaultAppPool": C
Bu soru, msdb veritabanında (msdb'de SQL Gönderme Veritabanı Postası saklı yordamını kullanarak) _sp_send_dbmail'in nasıl çalıştırılacağıyla ilgili ise, işte bir miktar iş var.
Veritabanınızın .net uygulamasının kullanıcı adını (.net uygulamanızdaki bağlantı dizenizde tanımlanır) msdb kullanıcısına "DatabaseMailUserRole" rol üyeliğine ekleyin.