Merhaba

Son yıllarda hepimizin duyduğu bir cümle var: “Artık parola kullanmıyoruz.” Passwordless kimlik doğrulama, FIDO2 anahtarları, Windows Hello for Business, her yerde MFA… Modern kimlik dünyası gerçekten bu yöne gidiyor.

Ama Active Directory tarafına döndüğünüzde tablo genellikle bambaşka oluyor.

Çoğu kurumda AD, yıllar içinde katman katman büyümüş bir yapı. Devreden projeler, kapatılmayan servis hesapları, taşınan uygulamalar, ayrılan çalışanlar, bir kereye mahsus açılmış dış taraf hesapları… Ve bunların bir kısmı hala enabled durumda duruyor, parolası ise yıllardır hiç değişmemiş.

Bu yazıda ortamınızdaki bu hesapları nasıl tespit edeceğinizi, bulduktan sonra ne yapmanız gerektiğini ve süreci nasıl kalıcı hale getireceğinizi anlatacağım.

Neden Önemli?

Saldırgan tarafından bakalım. Karşınızda iki hesap var:

• MFA korumalı, düzenli parola politikası uygulanan, conditional access ile sınırlandırılmış bir kullanıcı hesabı
• 2006’dan beri parolası değişmemiş, MFA’sı olmayan, hangi uygulamada kullanıldığı bilinmeyen bir servis hesabı

Hiçbir saldırgan birinciyle vakit kaybetmez. İkincisi klasik anlamda low-hanging fruit, yani en az çabayla ulaşılabilecek hedef.

Eski parolaların risk yaratmasının birkaç somut nedeni var:

Sızıntı veri tabanlarında bulunma ihtimali yüksek. 15-20 yıl önce belirlenmiş bir parolanın, o dönemden bu yana yaşanan onlarca büyük veri sızıntısının içinde yer alma olasılığı ciddi şekilde artıyor. Credential stuffing ve password spraying saldırılarının beslendiği kaynak tam olarak burası.

O dönemin parola politikaları bugünküyle aynı değildi. 2006’da belirlenmiş bir parola büyük ihtimalle 8 karakter, tahmin edilebilir bir kalıpta ve kurum adı türevi içeriyor.

Kerberoasting için ideal hedef. SPN tanımlı servis hesaplarının parolası eskiyse ve karmaşıklığı düşükse, alınan servis biletinin offline kırılması çok daha kolay hale geliyor. Parola ne kadar eskiyse, o kadar zayıf bir algoritma ve kalıpla üretilmiş olma ihtimali yüksek.

Yetki birikimi. Yıllar içinde bu hesaplara “geçici” diye verilen yetkiler hiç geri alınmıyor. Sonuçta elinizde parolası hiç değişmemiş ama Domain Admin grubuna dolaylı yoldan bağlı bir hesap kalıyor.

Buradaki asıl mesele şu: Sorun tek bir eski hesap değil, o hesabın nereye eriştiğini kimsenin bilmemesi.

Tek Bir Hesabı Grafik Arayüzden İncelemek

Kullandığımız araç Active Directory Users and Computers (Active Directory Kullanıcıları ve Bilgisayarları). Başlat menüsünden ya da doğrudan dsa.msc komutuyla açabilirsiniz.

Aradığımız pwdLastSet özniteliği varsayılan görünümde yok. Bunun için önce gelişmiş görünümü açmak gerekiyor. Üst menüden View (Görünüm) menüsüne girin ve Advanced Features (Gelişmiş Özellikler) seçeneğini işaretleyin.

Bu Advanced Features aktif etme adımı atlarsanız, hesap özelliklerinde birazdan kullanacağımız Attribute Editor sekmesi hiç görünmez. Bu, konsolu ilk kez kullananların en sık takıldığı nokta.

Sol taraftaki ağaçtan domaininizi genişletip hesabın bulunduğu container ya da OU’ya gidin. Örnekte varsayılan Users container’ı üzerinden Administrator hesabına bakıyoruz.

Hesaba sağ tıklayın ve Properties (Özellikler) seçeneğini seçin.

Buradaki menüde Reset Password ve Disable Account gibi seçeneklerin de yer aldığını göreceksiniz. Denetim aşamasındayken bunlara dokunmayın; önce hesabın ne olduğunu anlamak, sonra aksiyon almak gerekiyor.

Açılan pencerede Account (Hesap) sekmesi, hesabın oturum açma isimlerini gösterir. User logon name (pre-Windows 2000) alanındaki değer, PowerShell çıktısında göreceğiniz SamAccountName ile aynıdır. Raporda gördüğünüz ismi doğru hesapla eşleştirmek için bu sekmeye bakarsınız.

Bu ekranda ayrıca Account options bölümündeki Password never expires kutusuna da dikkat edin. İşaretliyse, hesabın parolası hiçbir zaman sona ermeyecek demektir; eski parola bulgularının önemli bir kısmı tam olarak buradan çıkar.

pwdLastSet değerini okuyun
Şimdi asıl aradığımız yere geldik. Attribute Editor sekmesine geçin ve listeyi alfabetik olarak kaydırarak pwdLastSet satırını bulun.
Değer, parolanın en son ne zaman belirlendiğini yerel saat dilimiyle birlikte gösterir. Bu tarihin üzerinden geçen süre, hesabın parola yaşıdır.
Burada iki noktaya dikkat edin:

• Değer <not set> görünüyorsa, parola hiç belirlenmemiş demektir. Bu da riskli bir durumdur, “sorun yok” anlamına gelmez.
• Attribute Editor size değeri okunabilir formatta sunar, ancak AD bu bilgiyi arka planda 64-bit FileTime olarak tutar. PowerShell ile sorguladığınızda ham sayı ile karşılaşmanızın sebebi budur; birazdan bunu tarihe çevireceğiz.

Peki neden bu yöntemle yetinmiyoruz?

Gördüğünüz gibi tek bir hesap için işlem gayet basit. Sorun ölçekte: birkaç bin kullanıcılı bir domainde bu adımları tek tek tekrarlamak mümkün değil. Üstelik bu ekran size sadece baktığınız hesabı gösterir, “kim riskli” sorusunu cevaplamaz.

İşte bu yüzden asıl denetimi PowerShell ile yapacağız.

Tespit: PowerShell ile Hızlı Kontrol

Kontrol için ek bir araç gerekmiyor, RSAT (Remote Server Administration Tools) içindeki ActiveDirectory modülü yeterli.

Parolası 365 günden eski olan etkin hesaplar

Get-ADUser -Filter 'enabled -eq $true' -Properties Name, PwdLastSet, lastLogonTimestamp |
    Select-Object name,
        @{N='pwdLastSet'; E={[DateTime]::FromFileTime($_.PwdLastSet)}},
        @{N='LastLogonTimestamp'; E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}} |
    Where-Object { $_.pwdLastSet -le (Get-Date).AddDays(-365) } |
    Sort-Object -Property pwdLastSet

Komutun mantığı basit: AD, pwdLastSet ve lastLogonTimestamp değerlerini 64-bit FileTime formatında tutuyor. [DateTime]::FromFileTime() bunu okunabilir tarihe çeviriyor, ardından Where-Object ile eşik uygulanıyor.

Not: Aşağıdaki komutta eşik AddDays(-365), yani parolası 1 yıldan eski hesapları listeliyor. Bu yazıdaki ekran görüntülerini alırken kendi lab ortamımda bu değeri <AddDays(-3) olarak çalıştırdım. Sebebi basit: lab domaini yeni kurulduğu için hiçbir hesabın parolası 1 yıllık değil ve komut boş sonuç döndürüyordu. Siz kendi ortamınızda bu sayıyı ihtiyacınıza göre değiştirebilirsiniz 90, 180, 365, 730 gibi. Sayı ne kadar küçükse liste o kadar uzar; üretim ortamında 365 ve üzeri anlamlı bir başlangıç noktasıdır.

Çıktıyı okurken dikkat edilecek nokta

1/1/1601 01:00:00 şeklinde bir tarih görürseniz bu gerçek bir tarih değil, değerin hiç set edilmediği anlamına geliyor. FileTime’ın başlangıç noktası bu.

• pwdLastSet boşsa: hesap oluşturulmuş ama parola hiç belirlenmemiş ya da “kullanıcı bir sonraki oturumda parolasını değiştirsin” işaretli
• lastLogonTimestamp boşsa: hesap hiç oturum açmamış (ya da replikasyon aralığı nedeniyle henüz yazılmamış)

lastLogonTimestamp güvenilir değil, lastLogon ise dağınık

Burası, bulguları yorumlarken en çok hataya yol açan nokta. AD’de son oturum bilgisini tutan iki ayrı öznitelik var ve ikisi de farklı davranıyor.

lastLogonTimestamp domain controller’lar arasında replike olur, yani tek bir DC’ye sorarak tüm domain için bir cevap alırsınız. Ancak bu değer kasıtlı olarak gecikmeli güncellenir. Amaç, her oturum açma işleminde replikasyon trafiği yaratmamaktır. Varsayılan senkronizasyon aralığı 14 gün olup, üzerine rastgele bir pay uygulanır; pratikte 9-14 günlük bir sapma görürsünüz.

Bu ne demek? Ekranda 01.06.2026 yazan bir hesap, aslında iki hafta sonrasına kadar herhangi bir tarihte oturum açmış olabilir. Yaklaşık bir fikir verir, kesin bilgi vermez.

lastLogon ise gerçek zamanlı olarak güncellenir, ama replike edilmez. Her domain controller yalnızca kendi üzerinden yapılan kimlik doğrulamaları kaydeder. Tek bir DC’ye sorarsanız, hesabın başka bir DC üzerinden dün oturum açtığını göremezsiniz, ve o hesabı yanlışlıkla “ölü” olarak işaretlersiniz.

Doğru sonuç için tüm DC’leri tek tek sorgulayıp en büyük değeri almanız gerekir:

function Get-GercekSonOturum {
    param([Parameter(Mandatory)][string]$Hesap)

    $dcListesi = (Get-ADDomainController -Filter *).HostName
    $enSonTarih = $null

    foreach ($dc in $dcListesi) {
        try {
            $kullanici = Get-ADUser -Identity $Hesap -Properties lastLogon -Server $dc -ErrorAction Stop
            $tarih = [DateTime]::FromFileTime($kullanici.lastLogon)

            if (-not $enSonTarih -or $tarih -gt $enSonTarih) {
                $enSonTarih = $tarih
            }
        }
        catch {
            Write-Warning "$dc sorgulanamadi: $($_.Exception.Message)"
        }
    }

    [PSCustomObject]@{
        Hesap       = $Hesap
        SonOturum   = if ($enSonTarih -gt [DateTime]::FromFileTime(0)) { $enSonTarih } else { $null }
        SorgulananDC = $dcListesi.Count
    }
}

Get-GercekSonOturum -Hesap 'svc_eskiuygulama'

Hazır Script ile Toplu Rapor Almak

Yukarıdaki komutları tek tek çalıştırmak yerine, aynı kontrolleri tek seferde yapıp sonucu rapora dönüştüren hazır bir script kullanabilirsiniz. Özellikle birden fazla domain’in bulunduğu ortamlarda, her domain controller’a ayrı ayrı bağlanmak yerine bu yöntem çok daha pratik.

Çalıştırmak için:

1. Bir Domain Controller üzerinde oturum açın.
2. PowerShell 5.1 veya 7.x’i Run as administrator olarak çalıştırın.
3. Dizin yolunu C:\scripts olarak değiştirin.

cd "C:\scripts"

Ardından script’i çalıştırın:

.\Get-ADPwdLastSet.ps1

Script, Forest yapısı içindeki tüm Domain’ler ve Domain Controller’lar üzerinde sorguyu çalıştırır. Bu sayede tek bir DC’ye bağlı kalmadan, ortamın tamamına ait bir görüntü elde edersiniz.
İşlem tamamlandığında, sonuçlar C:\scripts klasörü içinde HTML formatında bir rapor olarak oluşturulur. Raporu tarayıcıda açtığınızda hesapları parola yaşına göre sıralanmış halde görürsünüz.

Raporu incelerken önceliğiniz şu sırada olsun:

• En üstteki tarihler: Listenin başındaki hesaplar en uzun süredir dokunulmamış olanlardır
• SPN tanımlı hesaplar: Kerberoasting açısından ilk bakılacak grup
• Son oturum bilgisi boş olanlar: Büyük ihtimalle terk edilmiş hesaplar

Bu raporu çeyreklik olarak alıp bir önceki dönemin çıktısıyla karşılaştırmak, ortamın gerçekten temizlenip temizlenmediğini gösteren en net ölçüdür. Liste kısalmıyorsa, süreç işlemiyor demektir.

Not: Script’in varsayılan eşiği -EsikGun 540, yani parolası 18 aydan (yaklaşık 1,5 yıl) eski hesapları listeliyor. Bu yazıdaki ekran görüntülerini alırken kendi lab ortamımda scripti -EsikGun 3 ile çalıştırdım. Sebebi basit: lab domaini yeni kurulduğu için hiçbir hesabın parolası bu kadar eski değil ve script boş sonuç döndürüyordu. Siz kendi ortamınızda bu değeri ihtiyacınıza göre verebilirsiniz — 90, 180, 365, 730 gibi. Sayı ne kadar küçükse liste o kadar uzar; üretim ortamında 365 ve üzeri anlamlı bir başlangıç noktasıdır. Script eşiği parametre olarak aldığı için dosya içinde herhangi bir değişiklik yapmanıza gerek yoktur.

Pratikte hangisini kullanmalı?

İkisini de, ama farklı aşamalarda:

Aşama	Öznitelik	Neden
Geniş tarama, ilk liste	lastLogonTimestamp	Tek sorgu yeterli, hızlı. Yaklaşık değer bu aşamada kabul edilebilir.
Kapatma kararı öncesi doğrulama	lastLogon	Yanlış pozitif, üretimde bir servisi durdurmak demektir.

Yani tarama sırasında lastLogonTimestamp ile listeyi daraltın; bir hesabı devre dışı bırakmadan hemen önce mutlaka lastLogon ile tüm DC’lerden doğrulayın.

Üçüncü bir seçenek de var: Search-ADAccount -AccountInactive komutu, lastLogonTimestamp üzerinden çalışır. Yani aynı gecikme payı burada da geçerlidir; “kesin sonuç” olarak görmeyin.

Son bir uyarı: her iki öznitelik de yalnızca interaktif kimlik doğrulamaları güncellenir. Bir servis hesabı yalnızca sertifika ile ya da uygulama içi bir mekanizmayla çalışıyorsa, oturum kaydı hiç oluşmayabilir. Bu nedenle “son oturum yok” bulgusunu tek başına kapatma gerekçesi saymayın; mutlaka sahibiyle teyit edin.

18 aylık eşik ve rapora hazır çıktı

Pratikte 365 gün çok fazla kayıt döndürüyor. Önceliklendirme için 18 ay daha kullanışlı bir eşik:

$esik = (Get-Date).AddDays(-540)

Get-ADUser -Filter 'enabled -eq $true' -Properties Name, SamAccountName, PwdLastSet, lastLogonTimestamp, ServicePrincipalName, MemberOf, Description |
    Select-Object SamAccountName, Name, Description,
        @{N='ParolaYasi'; E={[DateTime]::FromFileTime($_.PwdLastSet)}},
        @{N='SonOturum'; E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}},
        @{N='SPN'; E={ if ($_.ServicePrincipalName) { 'Evet' } else { 'Hayir' } }},
        @{N='GrupSayisi'; E={ $_.MemberOf.Count }} |
    Where-Object { $_.ParolaYasi -le $esik } |
    Sort-Object ParolaYasi |
    Export-Csv .\eski-parolalar.csv -NoTypeInformation -Encoding UTF8

SPN sütununu eklememin nedeni önceliklendirme. SPN tanımlı ve parolası eski bir hesap, Kerberoasting açısından listenin en üstünde yer almalı.

Parolası hiç sona ermeyen hesaplar

Bu kontrolü de aynı anda yapmakta fayda var:

Search-ADAccount -PasswordNeverExpires -UsersOnly | Where-Object { $_.Enabled -eq $true } | Select-Object SamAccountName, Name, LastLogonDate | Sort-Object LastLogonDate

Ekrana hiçbir şey gelmezse ne anlama gelir? Bu komut sonuç döndürmediğinde çoğu kişi bir hata yaptığını düşünür, oysa genellikle bu iyi bir haberdir: ortamda parolası hiç sona ermeyen etkin bir kullanıcı hesabı yok demektir. Yeni kurulmuş ya da az sayıda hesap barındıran ortamlarda bu sonuç normaldir.

Yine de emin olmak için filtreyi kaldırıp kontrol edin:

# Once devre disi hesaplar dahil, filtresiz bakalim
Search-ADAccount -PasswordNeverExpires -UsersOnly | Select-Object SamAccountName, Enabled

# Ayni kontrolu userAccountControl bayragi uzerinden dogrulayalim
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' -Properties PasswordNeverExpires |
    Select-Object SamAccountName, Enabled, PasswordNeverExpires

İlk komut sonuç döndürüp ikinci filtre sonrası liste boşalıyorsa, bulunan hesapların hepsi zaten devre dışıdır sorun yok. İkisi de boşsa, gerçekten böyle bir hesabınız yok.

Dikkat edilecek iki nokta var:

• Search-ADAccount yalnızca kullanıcı nesnelerine bakar (-UsersOnly ile). Bilgisayar hesapları ve krbtgt gibi yerleşik nesneler bu listeye girmez.
• Bu bayrak, hesabın userAccountControl özniteliğindeki DONT_EXPIRE_PASSWORD değeridir. Fine-Grained Password Policy ile parola süresini uzatmak aynı şey değildir ve bu komutta görünmez.

Bulguları Sınıflandırma

Liste elinize geçtiğinde asıl iş başlıyor. Doğrudan parola sıfırlamaya girişmek, özellikle servis hesaplarında üretim ortamını durdurabilir.

Kategori	Belirti	Öncelik	Aksiyon
Ölü hesap	Parola eski, son oturum yok veya çok eski	Yüksek	Devre dışı bırak, karantina OU’ya taşı
Servis hesabi	SPN var, oturum düzenli, sahibi belirsiz	Kritik	Sahibini bul, gMSA’ya geçir.
Dış taraf hesabı	Proje bazlı açılmış, süresi dolmuş	Yüksek	Sözleşme kontrolü, kapat
Aktif kullanıcı	Parola eski ama düzenli oturum açıyor	Orta	Politika ile zorunlu değişim
Yerleşik hesap	Administrator, krbtgt vb.	Kritik	Planlı rotasyon

Her hesap için cevaplanması gereken beş soru:

1. Hesap hala gerekli mi?
2. Sahibi kim? (İsim değil, birim ve sorumlu kişi)
3. Kullanıcı hesabı mı, servis hesabı mı?
4. Nerede kullanılıyor? (Scheduled task, IIS app pool, SQL servisi, uygulama config dosyası)
5. Nelere erişebiliyor? (Grup üyelikleri, delegasyon, ACL’ler)

Dördüncü soru en zorlusu. Parolasını değiştirmeden önce nerede kullanıldığını bulmanın en pratik yolu, hesabı devre dışı bırakmak yerine oturum açma saatlerini kısıtlayıp Event ID 4624 ve 4625 kayıtlarını izlemek. Böylece hangi sunucudan geldiğini görürsünüz.

Kalıcı Çözüm

Tek seferlik temizlik iki yıl içinde aynı noktaya geri döner. Kalıcı hale getirmek için:

Servis hesaplarını gMSA’ya taşıyın. Group Managed Service Account, parolayı 30 günde bir otomatik döndürür ve parolayı kimse bilmez. Zaten çözümün kendisi budur, elle parola yönetimini ortadan kaldırır.

New-ADServiceAccount -Name "gmsa-app01" `
    -DNSHostName "gmsa-app01.ad.domain.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "AppServers"

Fine-Grained Password Policy uygulayın. Servis hesapları için ayrı bir PSO tanımlayıp minimum uzunluğu 25+ karaktere çekin. Uzun parola, Kerberoasting sonrası offline kırma denemesini pratikte anlamsız hale getirir.

Hesap yaşam döngüsünü sahiplendirin. Her servis hesabının Description ve Info alanına sahibi, kullanıldığı sistem ve açılma nedeni yazılsın. Bu alanların boş olması, iki yıl sonra kimsenin o hesaba dokunamamasının tek sebebi.

Kontrolü otomatikleştirin. Yukarıdaki sorguyu aylık scheduled task olarak çalıştırıp çıktıyı ilgili ekibe mail atmak, uzun vadede en çok işe yarayan adım.

Uyumluluk Tarafında Bu Nereye Oturuyor?

Bu denetimi teknik bir iyi uygulama olarak yapıyoruz, ama çoğu kurumda aynı zamanda bir uyumluluk gerekliliğine karşılık geliyor. Denetçiye ne anlatacağınızı bilmek, bütçe ve öncelik almayı da kolaylaştırır.

Çerçeve	Bu Denetimle İlgisi
ISO 27001:2022	Ek A’daki kimlik yönetimi ve kimlik doğrulama bilgisi kontrolleri (A.5.16, A.5.17, A.5.18), hesapların yaşam döngüsü boyunca yönetilmesini ve gereksiz hale gelen erişimlerin kaldırılmasını bekler. Yıllardır dokunulmamış, sahibi belirsiz bir servis hesabı bu kontrollerin doğrudan konusudur.
PCI DSS 4.0	8. gereksinim, kullanıcı kimliklerinin ve kimlik doğrulamanın yönetimini kapsar. Uygulamalar ve sistemler tarafından kullanılan hesaplar için envanter tutulması, erişimin gerekli olanla sınırlanması ve kullanımın izlenmesi beklenir. Kart verisi ortamına dokunan bir servis hesabının sahibinin bilinmemesi kabul edilebilir değildir.
KVKK	Kanunun veri güvenliğine ilişkin yükümlülükleri, uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri alma sorumluluğunu veri sorumlusuna verir. Kurum rehberlerinde erişim yetkilerinin sınırlanması, gereksiz hesapların kapatılması ve yetki kontrollerinin düzenli yapılması açıkça yer alır.
TCMB / BDDK	Ödeme ve elektronik para kuruluşları için TCMB Bilgi Sistemleri Yönetmeliği; bankacılık tarafında ise BDDK düzenlemeleri, erişim yetkilerinin görev tanımlarıyla uyumlu olmasını, periyodik gözden geçirilmesini ve gereksiz yetkilerin kaldırılmasını bekler.

Fintech tarafında çalışıyorsanız, bu denetimi çeyreklik yetki gözden geçirme sürecinizin bir girdisi haline getirmek en pratik yaklaşım olur.

NIST ne diyor peki?

Burada haklı bir itiraz gelebilir: NIST SP 800-63B, zorunlu periyodik parola değişimi uygulamasından vazgeçti. Gerekçesi de mantıklı, zorunlu rotasyon kullanıcıyı tahmin edilebilir kalıplara itiyor (Parola2024 → Parola2025>). Bunun yerine uzunluk ve sızıntı listelerine karşı kontrol öneriliyor. PCI DSS 4.0 da benzer şekilde 90 günlük rotasyona alternatif yaklaşımlar kabul ediyor.

Peki bu, yazının konusuyla çelişiyor mu? Hayır. Çünkü buradaki mesele rotasyon değil, terk edilmişlik.

20 yıldır değişmemiş bir parola, “kullanıcı güçlü bir parola seçmiş ve değiştirmeye gerek duymamış” anlamına gelmez. Genellikle “bu hesapla kimse ilgilenmiyor, sahibi belli değil, o dönemin zayıf politikasıyla üretilmiş ve aradan geçen sürede onlarca sızıntının içine girmiş olabilir” anlamına gelir.

Yani pwdLastSet değerini bir parola politikası metriği olarak değil, bir terk edilmişlik göstergesi olarak kullanıyoruz. Bulduğunuz hesabın çözümü de otomatik bir parola sıfırlama değil; sahibini bulmak, hala gerekli olup olmadığını sorgulamak ve mümkünse gMSA’ya taşıyarak parolayı denklemden tamamen çıkarmaktır.

Genel görünüm

Active Directory güvenliği çoğu zaman yeni bir ürün almakla değil, halihazırda orada duran şeyi görmekle başlıyor. Parolası 20 yıldır değişmemiş etkin bir hesap, en pahalı EDR çözümünün bile arkasından dolaşan bir giriş noktası olabilir.

Bu kontrolü yılda bir kez değil, çeyreklik olarak yapmanızı öneririm. Tek bir PowerShell komutu, birkaç dakika sürüyor ve genellikle kimsenin beklemediği sonuçlar çıkıyor.

Başka bir yazımzda görüşmek dileğiyle…