IUSR ve IWAM, ayrı olarak kurduğunuzda (işletim sistemi bileşeni olarak değil) IIS'nin ilk günlerine dayanır. Varsayılan olarak, bir web sitesi adsız kimlik doğrulamaya izin veriyorsa, IUSR hesabı işletim sistemi üzerindeki izinlerle ilgili olarak kullanılır. Bu, varsayılandan değiştirilebilir. En azından hesabı yeniden adlandırmak için bazı güvenlik önerileri vardır, bu yüzden bir sunucudaki yönetici hesabını yeniden adlandırmak gibi bir öneri olduğu gibi "bilinen" bir hesap değildir. MSDN'de IUSR ve kimlik doğrulama hakkında daha fazla bilgi edinebilirsiniz .
IWAM, herhangi bir işlem dışı uygulama için tasarlanmıştır ve yalnızca IIS 5.0 yalıtım modunda olduğunuzda IIS 6.0'da kullanılır. Genelde COM / DCOM nesnelerle gördünüz.
Uygulama havuzu kimlikleriyle ilgili olarak varsayılan, Şebeke Servisi olarak çalışmaktır. Yerel Sistem olarak çalıştırmamalısınız, çünkü bu hesap bir yöneticinin haklarından daha büyük haklara sahip. Bu temelde sizi Şebeke Servisi, Yerel Servis veya bu ikisinden başka bir yerel / etki alanı hesabına bırakacaktır.
Ne yapacağına gelince, buna bağlı. Bunu Ağ Hizmeti olarak bırakmanın bir avantajı, sunucuda sınırlı bir ayrıcalık hesabıdır. Ancak, ağdaki kaynaklara eriştiğinde, Domain \ ComputerName $ olarak görünür; bu, Ağ Hizmeti hesabının farklı bir kutuda çalışan SQL Server gibi kaynaklara erişmesine izin veren izinler atayabileceğiniz anlamına gelir. Ayrıca, bilgisayar hesabı göründüğü için, Kerberos kimlik doğrulamasını etkinleştirirseniz, web sitesine sunucu adına göre erişiyorsanız, SPN zaten yerinde olur.
Web tabanlı bir uygulama için SQL Server'a erişen bir hizmet hesabı gibi ağa bağlı kaynaklara erişmek için belirli bir hesabın olmasını istiyorsanız, uygulama havuzunu belirli bir Windows etki alanı hesabına değiştirmeyi düşünebilirsiniz. ASP.NET'te bunu uygulama havuzu kimliğini değiştirmeden yapmak için başka seçenekler var, bu yüzden artık kesinlikle gerekli değil. Bir etki alanı kullanıcı hesabı kullanmayı düşünmenizin bir başka nedeni de Kerberos kimlik doğrulaması yapıyor olmanız ve bir web uygulamasına hizmet eden birden fazla web sunucunuz olmasıydı. Bunun iyi bir örneği, SQL Server Raporlama Hizmetlerini sunan iki veya daha fazla web sunucunuz varsa. Ön uç, muhtemelen report.mydomain.com veya report.mydomain.com gibi genel bir URL’ye gider. Bu durumda, SPN, AD içindeki yalnızca bir hesaba uygulanabilir. Her bir sunucuda Ağ Hizmeti altında çalışan uygulama havuzlarınız varsa, bu işe yaramaz, çünkü sunuculardan ayrıldıklarında, Etki Alanı \ BilgisayarAdı $ olarak görünürler; Uygulamanın. Çözüm, bir etki alanı hesabı oluşturmak, tüm sunuculardaki uygulama havuzu kimliğini aynı etki alanı kullanıcı hesabına ayarlamak ve bir SPN oluşturmak, böylece Kerberos kimlik doğrulamasına izin vermektir. Kullanıcı kimlik bilgilerini arka uç veritabanı sunucusuna iletmek isteyebileceğiniz SSRS gibi bir uygulama söz konusu olduğunda, Kerberos kimlik doğrulaması bir zorunluluktur, çünkü Kerberos temsilcisini yapılandırmanız gerekir. Uygulamayı yapan sunucularınız olduğu kadar hesabınız olabilir. Çözüm, bir etki alanı hesabı oluşturmak, tüm sunuculardaki uygulama havuzu kimliğini aynı etki alanı kullanıcı hesabına ayarlamak ve bir SPN oluşturmak, böylece Kerberos kimlik doğrulamasına izin vermektir. Kullanıcı kimlik bilgilerini arka uç veritabanı sunucusuna iletmek isteyebileceğiniz SSRS gibi bir uygulama söz konusu olduğunda, Kerberos kimlik doğrulaması bir zorunluluktur, çünkü Kerberos temsilcisini yapılandırmanız gerekir. Uygulamayı yapan sunucularınız olduğu kadar hesabınız olabilir. Çözüm, bir etki alanı hesabı oluşturmak, tüm sunuculardaki uygulama havuzu kimliğini aynı etki alanı kullanıcı hesabına ayarlamak ve bir SPN oluşturmak, böylece Kerberos kimlik doğrulamasına izin vermektir. Kullanıcı kimlik bilgilerini arka uç veritabanı sunucusuna iletmek isteyebileceğiniz SSRS gibi bir uygulama söz konusu olduğunda, Kerberos kimlik doğrulaması bir zorunluluktur, çünkü Kerberos temsilcisini yapılandırmanız gerekir.
Katılacak çok şey olduğunu biliyorum, ancak kısa cevap Yerel Sistem hariç, buna bağlı.