Varsayalın ayarlarla çalıştırılan bir IIS sunucusu NETWORK SERVICES hesabı veya IISUSR_<MAKINEADI> hesabı ile ilgili klasörlere ve sql veritabanına erişir. Ancak bazı durumlarda bizim kendi oluşturduğumuz bir lokal veya domain kullanıcısını Application Pool kısmında kimlik olarak göstermemiz ve bu kullanını yetkileri ile web uygulamasını çalıştırmamız gerekebilir. Bu durumun gerekli olduğu bir senaryo şöyle olabilir.
Web sunucunuz bir sharepoint portal server üzerinde koşuyorsa varsayılan olarak sql sunucunuzun güvenlik ayarlarında Server Authentication kısmında Windows Authentication mode seçilidir. Bu yüzden eğer kendi .net uygulamanızda bir sql login ile bağlantı kurmak isterseniz, “Trusted mode is not allowed” benzeri bir hata alırsınız. Ayrıca sharepoint uygulaması kurulum sırasında belli kimliklerle ayarlanmıştır. Eğer portal yöneticisi değilseniz veya sharepoint ayarları ile oynamak istemiyorsanız veya bu ayarları değiştirmenin nelere yol açabileceğini kestiremiyorsanız yukarıda bahsettiğimiz çözüm gibi bir çözüme ihtiyacınız olacaktır.
Şimdi sırası ile kendi lokal kullanıcımızı oluşturalım ve bu kullanıcıya IIS’de , SQL’de ve ilgili klasörde ne tür yetkilendirmeler yapacağımıza bakalım.
IIS uygulama havuzumuz, web uygulaması klasörümüz ve sql veritabanımızın ilk halinin ekran görüntüleri aşağıdaki gibidir.
IISUser1 username’i ile bir lokal user ekliyoruz. Password never expires olsun ve Pass123 diye şifresi olsun. Şimdilik giç bir lokal gruba eklemedik. Hatalarımızı aldıktan sonra grup eklemesi yapacağız.
IIS’dedeki net uygulamamızı demo için 8080 portundan çalıştırdım ki sharepoint ile çaışmasın diye.
Evet henüz app pool’a bir kimlik tanıtmadık sql’e de bir login eklemedik ve bu şekli ile uygulaması browse edersek aşağıdaki gibi gayet sıkıcı gözüken ve sıklıkla sql ve IIS ile ilk uygulama deployment zamanı görünen mesajı görürüz.
SQL security kısmından bir windows user ekleyelim. Burada istersek zaten sharepoint zamanı ekli genelde sistemde admin yetkisi olan kullanıcıyı kullanabilir ve tüm dertlerimizden kurtulabiliriz. Ancak biz daha bizim uygulamaya özel yetkileri sınırlı bir kullanıcı kullanarak daha güvenli bir yaklaşım sergileyebiliriz.
Sonra IIS Uygulama Havuzumuzun özelliklerine geliyoruz ve orada kimlik (Identity) kısmında aşağıdaki gibi lokal user’ımızı ayarlıyoruz.
Tabiki sql sunucuya trusted_connection=true ayarı ile bağlantı yapan .net uygulamamızın kimlik bilgisini özelleştirdiğimiz Pool’da çalışması gerekiyor.
Evet bütün bu ayarlar ve eklemelerden sonra artık hata mesajımız değişti:
Bu hata mesajının kaynağını çözmek için ve genel bir uygulama olarak hataların nereden kaynaklandığını anlayabilmek için Event Log Viewer kullanılabilir.
Görüldüğü gibi yeni eklediğimiz identity ile ilgili bir sıkıntı var. Demek ki bu kimlikteki kullanıcı bir yerelere erişmekte sıkıntı çekiyor. Düşündüğümüz zaman bir .net web uygulaması çalışma zamanında nereleri kullanır? Tabiki framework klasöründeki Temporary ASP.NET files klasörü ve uygulamamızın bulunduğu wwwroot’daki klasör.. bunlara gerekli okuma yazma erişimini vermemiz gerekli. Ancak IISUser1 kullanıcısına yetki vermek yerine IIS_WPG = yani IIS Work Proccess Grup grubuna ekler isek bu kimlik kullanıcısını ve daha sonra ekleyeceğimiz IIS pool kimlik kullanıcılarını ekstra yetkilendirmeyle uğraşmamıza gerek kalmaz. Çünkü aşağıda görüldüğü gibi zaten IIS_WPG grubunun gerekli okuma yazma yetkisi var bahsi geçen klasöre.
IIS_WPG lokal grubuna kullanıcımızı ekliyoruz. Görüldüğü gibi daha önceden NETWORK SERVICES bu grupta ekli.
Daha sonra tekrar browse edelim uygulamayı. Unutmadan bu yetkileri vermeden önce her browse edişimizde uygulama havuzumuz stop modunu düşer bunu tekrar başlatmamız gerekir. Çalıştığından emin olduktan sonra browse edersek artık uygulamamız veri erişimini yapıp arayüzümüze bilgileri getirecektir.
Hiç yorum yok:
Yorum Gönder