SFTP Public Key Authentication

Merhaba Arkadaşlar,

İki makina arasında iletişimi kolaylaştırmak veya iki makina arasında otomatik dosya transferi yapabilmek için makianalar arasında iletişim kurulabilir. Bu yönteme sftp public key authentication denir. Böylece herhangi bir şifre olmadan, key ile bağlantı sağlanmış oluyoruz.

Öncelikle kendi makinamızdan bağlanacağın user'a geçiş yaparız. (ör: dzdo -iu wlsadmin)
Kendi makinamızda .ssh adında bir directory oluşturulur:
mkdir .ssh

ls -la komutu ile oluşturduğumuz .ssh directory'sini görürüz.

chmod 777 .ssh
diyerek  directory'e full yetki verdik. Tabi bu istenen bir şey değildir; 777 benim işime gelir ama os admin'ler bir şekilde bu yetkiyi iptal etmek için kapınızı çalar. =)

Şimdi erişimde kullanmak için private/public anahtar çiftini oluşturacağız. Bunun için de şu komutu çalıştırırız:
ssh-keygen

Gelen her soruya Enter deyip geçebilirsiniz. Sizden passphrase isteyecektir. Bir şifre belirleyip, onu iki defa girmenizi isteyecektir. Onu da girdiğinizde, wlsadmin userımın altında .ssh directory'si altında, id_rsa ve id_Rsa.pub adında iki dosya oluşacaktır.
chmod 777 id_rsa*   ile yine yetkileri dibine kadar alıyoruz.

more id_rsa.pub komutu ile dosya içeriğindeki açık anahtarını karşı sunucuya girilmek üzere alabilirsiniz.

Karşı sunucuda da login olup, aynı şekilde:
mkdir .ssh   komutuyla .ssh folderı oluştururuz.
Akabinde chmod 777 .ssh komutuyla yetkileri açarız.

Şimdi bu sunucuda authorized_keys adında bir dosya oluştururz bu defa(dizin değil)
touch authorized_keys
Ve bir klasik olarak=)   chmod 777  authorized_keys

Diğer sunucudaki, id_Rsa.pub içinde oluşturduğumuz key'i, authorized_keys altına kopyalarız.

Hepsi bu kadar. Şimdi minik bir test yaparız:

İlk sunucumuza girerek:
ssh wlsadmin@IkinciSunucuIPsi

Eğer password olmadan erişirsek ikinci sunucu konsoluna, her şey tamam demektir. :)

Sonra görüşürüz.

Oracle'da Kolondaki Data Formatlarını Bulmak

Merhaba Arkadaşlar,

Oracle'da bir kolonunuz var diyelim ki. Best practice olarak kolonu data tipi, gerekirse validasyonlarla kontrol edebiliriz. Ancak bazen dba'lerin önem vermemesi ya da uygulama operasyonlarının ilgisizliği veyahut ilgili analist/geliştiricinin kötü tasarımı/geliştirmesi ile(bazen de hızlı canlıya çıkma ihtiyacının bir sonucu olarak) bazı alanlarda bozuk formatlarda data girilebilir.

Bizim ihtiyacımız da bu formatları bulmak ve düzenlemek idi. Örneğin müşteri numarası ya da telefon numarası gibi nümerik bir alan girişi olduğunu düşünün. Tüm formatları nasıl bulurdunuz?

Şöyle yapabiliriz, ki muhtemelen daha güzel çözümler vardır, tüm sayıları 0'a çevirip, öncelikle sayıları eşitledik. Sonra da distinct kolonu çektik. Böylece kaç tipte data var görmüş oluruz.

select distinct

replace(

replace(

replace(

replace(

replace(

replace(

replace(

replace(replace(a.TelNo,9,0),8,0),7,0),6,0),5,0),4,0),3,0),2,0),1,0) as alan

from gurkan_tablo_yedek a 

Örneğin şöyle sonuçlar dönebilir:

00/000/-000-00

00/000/-000000

00/000/00000/00

00/000/000000

00/000/00

0/000/0000000

0000000000

00/0000000000

00/000/000000/00

Hepsini sıfıra çevirme nedenim de, sonuçlardan göreceğimiz üzere, her bir sayı için farklı sonuç gelmemesi içindi.

Sonra görüşürüz.

Agile Yaklaşımlar için Tuckman Modeli

Merhaba Arkadaşlar,

Agile ekiplerimiz ortaya çıktıktan sonra hangi açıdan bakarsanız farklı farklı evrelerden geçtiğini görebilirsiniz. =) Türk usulü bakarsak, her işi üstüne alan ekipten, her iş üstüne yıkılan ekibe kadar birçok aşama var. =)  İşin mizahı bir yana, yıllar önce psikolog abimiz Bruce Tuckman, küçük gruplardaki gelişim modelleri üzerine bir teori geliştirmiş. Çevik yaklaşımlar da, bu modeli kendine uyarlamış diyebiliriz.

Tuckman Modeli 4 temel aşamadan oluşur:

1.Forming aşaması

2.Storming aşaması

3.Norming aşaması

4.PErforming aşaması

Beni tanıyanların da bildiği üzere, görsel çizimi yerine, yine internetten hazır bir resimle konuyu anlatacağım. =)

Şimdi bu aşamalar nedir, kısaca bakalım.

Forming Adımı: Ekip olmanın ilk aşamasıdır. Agile yaklaşımda, board oluştulur, squad'a isim bulunur, ekip mottosu bulunur, ekip üyeleri birbirini tanımaya başlar. Bu aşamada yöneticiler biraz daha direktiflerle ilerler.

Storming Adımı: Bu aşamada ekip artık birbirini tanımıştır. Ekip artık kibarlığı ve çekingenliği bir tarafa koyup, eleştirilere başlıyor. Retro'lar bu aşamada verimli ve sert geçmeye başlar. =) Ekip kendi içinde sınırlarını anlamaya da çalışır. Yöneticiler bu aşamaya geçmiş ekiplere daha ziyade koçluk yapar.

Norming Adımı: Storming sonrasıdır. Ekip kaynaşmıştır artık. Retro'lar daha geliştiricidir. İnsanlar birbirleriyle çalışmayı öğrenmiştir. 

Performing Adımı: Ekip artık tek kişi gibi çalışmıştır. Her konuyu herkes iyi bilir diyebiliriz. Yöneticiler delegasyonu devreye sokar bu tip ekiplerde. Artık müdahaleye gerek yoktur zira bu ekip için.

Hep bu adımlar anlatılır edilir de, peki Performing'e ulaştıktan sonra ne olur? Her şey sürekli iyi gidecek diye bir kaide yok. Ekip geriye de gidebilir. Geçişken bu süreçlerin hepsi. Gelen işler, işlerin baskısının ekip üzerine etkisi, ayrılık, yönetici değişimi vb sebeplerle, bir anda Forming adımına geri dönülebilir.

Sonra görüşürüz.

WIP (Work in Progress) Limit

Merhaba Arkadaşlar,

Bugün biraz da çevik felsefeden bir kavramla karşınızdayım: WIP Limit.

Kanban Board'larda üretim bandının hızı, en yavaş adımının hızı kadardır. Hatta geçen gün öğrendim ki, en yavaş adıma da "şişman çocuk" denmekteymiş. :)

Şöyle düşünelim, Analizler yapılıyor; geliştirmeler ve testler yapılıp canlıya çıkılıyor. Analistler işleri bitirdikçe Analiz Done'a işleri çekmeye başladılar. 1-2-5-7 derken, Analiz Done şişmeye başladı diyelim ki. Bu noktada bu şişmeye dur demek için WIP Limit konuyor. Böylece develoeprların önündeki yığınak engellenmeye çalışılıyor. Hedefimiz Canlı'ya doğru üretimi arttırmak. Eğer Analiz Done'ı durdurmazsak, canlıya çıkmaktan öte, board'da sıkıntı çıkartır. Bunun için Analizleri durdurmak, analistleri testlere yöneltmek gerekebilir. Belki de analistleri development'a yönlendirmek gerekebilir. =)

Örnek resim kanbanize sitesinden, çizmeye üşendim. =)

Bu Work in Progress limiti deneyimlerle belirlenir. Fazla yaparsanız paralel işlere gider iş; verim düşer. Çok düşük verirseniz, üretim sıkıntıya girer. Bu değeri deneyerek bulmak en idealidir. Hızlı ve kaliteli üründen taviz vermemek lazım. :)

Sonra görüşürüz.

Client IP'yi IIS Loguna Yazdırmak

Selam Herkese,

IIS logunuza baktığınızda client bilgisine ihtiyaç duyabilirsiniz, ki bence fazlasıyla duymalısınız. Zira her daim firewall ya da başka bir network cihazı IPsi görmek size anlam ifade etmez. Sonra user bazında anlamaya çalışırsınız ki, o daha da zorlaşır.

Sizi çağıran clientın IPsini görebilmek için, öncelikle firmanızdaki network ekiplerince bu bilginin paketin içinde gönderilmesi lazım. Bu kısmı network ekipleriyle hallettikten sonra, IIS'te Logging'e girin.

Select field deyin. 

Çıkan ekranda Add Fields diyoruz.

En kritik kısım sarı ile boyadığım yer. XFF yani X-Forwarded-For seçmelisiniz. Siyah kutu içine aldığım yere, network ekibiniz firewalldan geçirip paketi size iletirken, paket içinde nasıl tutuyorsa, o ismi yazmalısınız. 

Sonra görüşürüz.

WinDBG ile Dump Analizi

Merhaba Arkadaşlar,

Daha önceki yazılarımda envai çeşit dump alma yöntemini paylaşmıştım. Şimdi ise aldığımız bu dump'ları çok kısa nasıl inceleyebileceğimize bakalım. Burada her şeyiyle dumpı analiz etmekten bahsetmiyorum. Onu yapmak başlı başına bir sanat. Ciddi bir tecrübe ve pratik gerektiriyor(ben de çoğunuz gibi bu konuda guru değilim, kendime de söylüyorum bu kısmı=) ). Burada daha ziyade konsept olarak ve belli komutlarla neler yapılabilir ona değineceğim. 

WinDBG tool'u ile almış olduğumuz dump'ı inceleyeceğiz. Dump'ı her önüne gelene vermemenin ne kadar öenmli olduğuna da değineceğiz, subliminal mesaj olarak. =)

Uygulamayı açıyoruz öncelikle, File sekmesinden, Open crash dump tıklanır. Ve dump'ınızı burdan verirsiniz.(benim dump adına takılmayın, full dump almakta tereddüt ettiğim bir andı=) )

Burada aldığınız dump ile, dump aldığımız sunucu ile de ilgili bazı bilgileri görebiliyoruz. 

System Uptime: uygulama sunucunuzun ne kadar süredir ayakta olduğunu gösterir. Bu süre çok uzunsa, demek ki uzun süredir sunucu restart almamış. Atıyorum sunucu 120 gündür restart görmediyse, son 4 aylık patch'leri de geçilmediğini anlayabiliriz. Ve kötü niyetli kişiler bunu kullanır.

Process Uptime: Process'in ne kadar süredir ayakta olduğudur. Bu süre çok uzunsa, process'in recycle edilmediğini gösterir. IIS dump'ı ise bu, application pool recycle'ı düşünmek gerektiğini gösterebilir. Genelde günde 1 defa recycle geçilmesi best practise olarak geçer.

Symbol search path alanı boş gelmiş. Kısaca Symbol şudur: uygulamalar, işletim sistemi ile vs iletişim kurduğunda, ki bildiğiniz üzere bu makina diliyle oluyor, dll veya exe gibi dosya yarattığında bir de pdb dosyası oluşturur. Symbol tam da budur. Symbol içinde assembly için debugging sembolleri vardır. Windbg'nin dumpı çözebilmesi için global, Microsoft'un sitesinden bu sembolleri indirmesi gerekmektedir.

File sekmesi altından, Symbol File Path deyip, Symbol Path'e tıklanır. Sonrasında SRV*https://msdl.microsoft.com/download/symbols yazılır. Artık symboller de hazır.

.sympath yazarak symbollerin nereden alındığını da görebiliyoruz.

.reload yazarak ilgili adresten cache'imize çekebiliriz de bu sembolleri:

!analyze -v komutu ile crash analizi başlatılabilir.

Analiz sonrası !threads komutu ile dump alınan sistem üzerindeki aktif threadlerin durumunu görebiliyoruz.

En soldaki 164-166 olanlar threadIDlerdir. ThreadID alanında XXX yazanlar ise, işini bitiren threadlerdir ve dump aldığımız esnada henüz Garbage Collector işini tamamlamamıştır. 

Mex diye bir extension var debuggingi incelemek için. Onu kurabiliriz.

!us komutu ile unique stacklerin listesini verir. Çalışan threadler işini yaparken, biz dump alarak, onları böldük. Onlar da işlerini bırakıp bize dump verdi. 

36 stack(s) with 203 threads displayed (203 Total threads) à 36 farklı iş yapan thread var. 203 total treadin.

Şimdi bir threade bakalım mesela.

~(tilda): thread demektir.

87s: 87 nolu threadi select ediyor. Onu çağırıyor yani.

!clrstack2 :  .net stacki döker.(mex ile gelen komuttur)

0:000> ~87s

eax=00000000 ebx=00000001 ecx=00000000 edx=00000000 esi=00000001 edi=00000001

eip=7741c8ac esp=39b2ec10 ebp=39b2ed98 iopl=0         nv up ei pl nz ac po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212

ntdll!NtWaitForMultipleObjects+0xc:

7741c8ac c21400          ret     14h

0:087> !clrstack2  à artık başında a görüldüğü gibi 87 nolu thread'e geçti.

DbgId ThreadId Apartment Kind CLR              GC Mode    GC Suspending?

   87    11fc4 MTA            v4.0.30319.34209 Preemptive no

 

MonitorWait

-----------

Method          XXXXXXX.Esb.Queue.QueueManager.GetNextMessage()

Monitor Address 0x0000000020421088

 

SP       IP       Function                                                                                                                                   Source

39b2ef7c 00000000 GCFrame                                                                                                                                   

39b2f02c 00000000 HelperMethodFrame_1OBJ [System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)]      à alttaki de bunu çağırmış.                                            

39b2f0b0 72625d16 System.Threading.Monitor.Wait(System.Object, Int32, Boolean)     à alttaki getnextmessage methodu bir yerde threadslep yapıyor; bekliyor yani. 87 nolu thread bekliyor.                                                                        

39b2f0c0 39006df7 XXXXXX.Esb.Queue.QueueManager.GetNextMessage()                                                                                         

39b2f104 39006ff5 XXXXXXXX.Esb.Queue.WorkerThread.Run()                                                                                                     

39b2f128 7259ab43 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)                                                                          

39b2f134 725ada07 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

39b2f1a0 725ad956 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)        

39b2f1b4 725ad921 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)        à http contextin içine konup istek gelir soaptan vs. burda contextin içi kounuyor.         

39b2f1cc 7259aacc System.Threading.ThreadHelper.ThreadStart()       à threadim burda başlar.                                                                                         

39b2f320 00000000 GCFrame                                                                                                                                   

39b2f500 00000000 DebuggerU2MCatchHandlerFrame                                                                                                              

39b2f56c 00000000 ContextTransitionFrame                                                                                                                     

39b2f6f4 00000000 DebuggerU2MCatchHandlerFrame

System'den ziyade XXXXX ile başlayanlar önemli. Bunları ben maskeledim. Kütüphaneler vs belli olmasın diye. =) Sizinkiler ne ise onu yazar.

!name2ee * XXXXXX.Esb.Queue.WorkerThread.Run        komutu ile bu classın bu methodunu tüm kütüphanelerde ararız.

 

--------------------------------------

Module:      3647869c   à esb.dll’in memorydeki adresi

Assembly:    XXXXXX.Esb.dll

Token:       0600d745

MethodDesc:  38f4b56c

Name:        XXXXX.Esb.Queue.WorkerThread.Run()

JITTED Code Address: 39006fd0

--------------------------------------

 

!savemodule 3647869c C:\Temp\XXXXX.Esb.dll     à bu komut ile esb.dll’i Temp dizinine oluşturmuş oluruz.

Yani dump dosyasından dll'i elde etmek de mümkün. 

Dediğim gibi temel komutlara kısaca baktık. Yoksa dump analizi başlı başına bir alan.

Birazdan görüşürüz.

Unix'te Text/IP Replacement

Merhaba Arkadaşlar,

Üst üste Windows konuları yazdım. Bu defa da unix'te kullanabileceğiniz bir bilgi paylaşalım. Unix makinanızda bir text ya da IP aramak istiyorsunuzdur, yetkiniz dahilinde. Bunu çok hızlı yapabileceğiniz mini bir shell scriptini aşağıda paylaşıyorum:

for x in `find . -name \* | xargs grep -l "127.0.0.1"`;
do
echo $x
done

Sarı ile verdiğim IPyi bulunduğunuz dizin ve onun alt dizinlerinde aratacak, yetkiniz varsa da listeleyecektir.

Mesela bir connection string değişimi veyahut server IP değişimi yapacaksınız. IPleri listelettiniz yukarıdaki gibi. Tek tek elle mi değiştireceksiniz? Tabi ki hayır. Küçük bir ilave ile onu da aşağıdaki gibi yapabilirsiniz:

for x in `find . -name \* | xargs grep -l "127.0.0.1"`;
do
echo $x
sed "s@127.0.0.1@19.86.19.03@g" $x > temp;
mv temp $x;
done

Sarı ile yazılı olan IP yerine --> yeşil ile yazılı olan IP yazılacaktır. 

Sonra görüşürüz.

DebugDiag ile Dump Almak

Merhaba Arkadaşlar,

Daha önceki yazımda WER ile otomatik IIS Dump almasını paylaşmıştım. Şimdi ise DebugDiag toolu ile nasıl dumplar alabileceğimize bakacağız.

Öncelikle DebuDiag'ın msi dosyasını indirip kurulumunu yapmanız gerekiyor. (Windows server'lar için anlattığımdan direkt msi dedim)

Kurulumlar sonrası, DebugDiag Collection tool'unu açalım. Bu sayede örneğin crash ya da response time 'a göre dump alabiliriz. Diyelim ki uzun response time'ı olan bir webservice'niz var. Onu izlemek ve dump'ını almak istiyorsunuz. 

Toolu açınca şöyle bir ekran göreceksiniz:

Add Rule diyerek ilerliyoruz. Akabinde aşağıdaki ekranı görmeniz gerekiyor:

Performance'a tıklayıp, gelen ekrandan HTTP Response Times tıklanır:

Çıkan ekrandan Add URL deriz:

Yukarıda değindiğim webservice'nizi başına / koymadan, sonuna / koyarak burada yazıyorsunuz. Örneğin webserviceniz https://ml.googleapis.com/$discovery/rest?version=v1 olsun. Tamamen atıyorum; arama kısmına discovery/ yazıyorsunuz.

Webservice'nizin 30 sn ve üstü sürelerdeki cevap anlarının dump'ını almak isteyelim.  Timeout after alanına kaç yazarsam, o kadar süre geçtikten sonra dump almaya başlar.

OK dedikten sonra, aşağıdaki ekran gelir; orada da next'e tıklanır.

Aşağıdaki ekran çıkacaktır. Bu ekrandan da  Add Dump Target butonuna tıklanır.

Çıkan ekrandan target type: web application pool deyip, hangi application pool'u seçersek, onun üstündeki uygulama servislerini izleyebiliriz. Uygulamalarımın listesi görüneceğinden, hepsini buzlamak da uzun iş, burayı yazılı olarak geçtim. :)

OK deyip, gelen ekranda Next dediğinizde, aşağıdaki ekrana geçmeniz lazım. İlk alanda şartı sağlar sağlamaz (yani 30saniyeyi geçtiği an servisimizin cevap verme süresi) 5 sn aralıklarla, 3 adet dump alacak demektir. Son seçimde de full mu mini mi onu seçiyorsunuz. 

Çıkan ekrandan Next deyip, Activate dediğinizde alt ekranda kuralın adı ve path'i yazar.

Dump'ınız hazır. Bu tool ile istediğiniz parametreye göre, çok kolay bir şekilde dump alabilirsiniz.

Sonra görüşürüz.

WER ile Otomatik IIS Dump Almak

Merhaba Arkadaşlar,

Windows Error Reporting (WER), bildiğiniz üzere, Microsoft'un bize sunduğu, uygulama hatalarını, crahslerini, cevap vermeyen işlemlerini, kernel hatalarını vs raporlayan bir feature'dır. Biz de IIS'imiz için DebugDiag vb tool'lar yerine, direkt olarak WER üzerinden otomatik dump aldırabiliriz(gerçi ben DebugDiag seviyorum; arayüzü çok basitleştiriyor=) ).

Öncelikle Regedit'e girilip, şuraya gidilir: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\

Burada LocalDumps adında bir key var mı kontrol edilir. Yoksa Windows Error Reporting'e sağ tıklayarak: New Key deyin ve adını LocalDumps verin.

Sonra LocalDumps'a da sağ tıklayıp, orada tekrar New key diyerek, w3wp.exe adında yeni bir key oluşturun. Artık w3wp.exe için otomatik dump almasını sağlayacak parametreleri girebilir durumdayız.

DumpFolder, DumpType, DumpCount adında 3 value yaratırız burada.

DumpFolder: Oluşacak olan dump dosyası nerede yaratılsın
DumpCount: Kaç adet dump alsın
DumpType: Ne tür bir dump alınsın(1:mini , 2: Full -- Bir de 0 var ama wer üstünden hiç denemedim, bilen arkadaşım dürtebilir; revize edebiliriz yazıyı)


Örneğimizde(üstteki görsel) F altında Dumps adında bir klasöre atıyoruz. 3 defa, full dump aldırıyoruz. Bu sayede crash anında, arıza telaşına düşmeden, arka planda birileri bizim için dump alabilir.


Burada oluşan dump'ı yine DebugDiag'a verip, raporunu inceleyebilirsiniz.


Sonra görüşürüz.

IIS Application Pool Identity

Merhaba Arkadaşlar,

IIS kullanan arkadaşlarımın malumu olacağı üzere, IIS'te güvenlik kontrolü baabında application pool identity diye bir feature var. Bu özellik, application pool'larınıza nevi şahsına münhasır bir kimlik kazandırır. Yani her application pool'unuz, bu application pool'un sağladığı kimlik(identity) üzerinden çalışmış olur. 

Elimdeki w3processlerimin hepsinde spesifik isimlendirme olmasından mütevellit, internetten yürüttüğüm yukarıdaki resimden de görüleceği üzere, bir w3wp process'imiz, yani IIS'in worker process'i, DefaultAppPool diye bir kimlik ile çalışmaktaymış, windows üzerinde. (Task Manager'ın ekran görüntüsüdür, yukarıdaki resim)

Şimdi IIS üzerindeki application pool'lar bu kimlik tiplerinin neler olduğuna ve farklarına bakalım.

Önce IIS'e giriyoruz ve herhangi bir application pool'a normal tıklıyoruz ve sağ panelden Advanced Settings'e tıklıyoruz.

Burada Process Model altındaki, Identity kısmında 3 nokta var, üstteki ekrandan da göreceğiniz üzere. Ona tıklıyoruz.

Gördüğünüz üzere 4 adet Identity tipi var burada. Bunlara değinelim şimdi.

Local System: Verilebilecek en sakat yetkidir. :) Server'ınızın C dizini altındaki Windows'u bile kilitleyebilir uzaktan çalıştırılabilir kodlarla. NW'e sisteme özetle her yere erişir. Çok büyük patlamışsınızdır, yetkiden şüphelenirken, deployment esnasında anlık verilebilir ama onun dışında kullanmamanız önerilir.

Network Service: Local System'in bir tık daha az yetkili hali gibi düşünebilirsiniz. NW'e çıkıp işlem yapma yetkisi vermiş olursun uygulamaya. ActiveDirectory'ne veyahut database'ine erişmeyi deneyebilirler. Hatta nw search işlemi bile yapılabilir. Bu da örneğin bir NFS ortak diskiniz vardır; erişim sorununuz olduğunu düşünüyorsunuzdur, yine identity kaynaklı. Onu test etmeniz için faydalı olacaktır. Ancak yine önerilmez.

Local Service: Network Service'in network'e çıkamayan versiyonudur. :) Tavsiye edilmez. NW'den şüphelenmediğiniz durumlarda, yine sorun tespitinde kullanın en fazla derim.

Application Pool Identity: Yukarıdakilere göre en masum yetkilendirmedir.  IIS'te siz bir app pool yarattığınızda, IIS de sizin için app ppol ile aynı isimde bir sanal account yaratır. O account ile app pool'u kullanırsınız. Bu user sadece bulunduğu ilgili server'da iş yapar. Örneğin aynı örneği vereyim; NFS'e gideyim; veyahut ortak makinalarımın ftp'sine bağlanayım derseniz, bu user ile sorun yaşarsınız. 

 

Peki hepsine bir kulp taktık. O zaman ne yapmak lazım. Çözüm çok sevimli: Custom Account.

Yani ActiveDirectory üzerinde bir user yaratırsınız. Bu user ile gerekli yetkileri, ihtiyaç duyduğu ölçüde kontrollü verirsiniz. Bu sayede kontrolünüz dışında security açığı ortaya çıkmamış olur.

Sonra görüşürüz.