barisnetblog.space — gMSA (Group Managed Service Account) Kullanımı
Windows Server 21 Ekim 2026 5 dk okuma 3 görüntülenme

gMSA (Group Managed Service Account) Kullanımı

Servis hesaplarındaki statik parola derdini gMSA ile bitiriyoruz. KDS root key oluşturma, New-ADServiceAccount, Install-ADServiceAccount ve gMSA'yı servis ile zamanlanmış görevde kullanma.

Hemen her ortamda yıllardır parolası değişmemiş, "Password never expires" işaretli ve çoğu zaman Domain Admins grubunda unutulmuş bir svc_yedek hesabı vardır. Bu hesapların parolası script'lerde, dokümanlarda ve eski çalışanların hafızasında dolaşır. gMSA (Group Managed Service Account) bu sorunu kökten çözer: parola 240 baytlık rastgele bir değerdir, Active Directory tarafından otomatik olarak değiştirilir ve hiçbir insan bu parolayı bilmez. Bu yazıda firma.local domain'inde bir gMSA oluşturup FS01 üzerinde bir servis ve zamanlanmış görevde kullanacağız.

gMSA Nasıl Çalışır?

  • Parola AD tarafından yönetilir: Parola, Key Distribution Service (KDS) tarafından üretilir ve varsayılan olarak 30 günde bir değişir.
  • Birden fazla sunucuda kullanılabilir: Eski MSA'lardan farklı olarak gMSA, izin verilen tüm sunucularda aynı anda çalışabilir. Bu da kümeler ve yük dengeleyici arkasındaki web sunucuları için idealdir.
  • Parolayı kim alabilir belirlenir: Yalnızca PrincipalsAllowedToRetrieveManagedPassword listesindeki bilgisayarlar parolayı DC'den alabilir.
  • Etkileşimli oturum açılamaz: gMSA ile masaüstüne giriş yapılamaz; yalnızca servisler, zamanlanmış görevler ve IIS uygulama havuzları kullanabilir.

Gereksinimler: domain ve forest işlevsel seviyesinin en az Windows Server 2012 olması, gMSA'yı kullanacak sunucuların Windows Server 2012 veya üzeri olması, forest'ta oluşturulmuş bir KDS root key ve kurulum/test komutları için bu sunucularda Active Directory PowerShell modülü.

KDS Root Key Oluşturmak

KDS root key, forest genelinde yalnızca bir kez oluşturulur. Önce mevcut bir anahtar olup olmadığını kontrol edin:

PowerShell
Get-KdsRootKey

Çıktı boşsa DC01 üzerinde Enterprise Admin yetkisiyle anahtarı oluşturun:

PowerShell
Add-KdsRootKey -EffectiveImmediately

İsmine rağmen -EffectiveImmediately anahtarı hemen kullanılabilir yapmaz. Anahtarın tüm DC'lere replike olması için 10 saat beklenir; bu sürede gMSA oluşturmaya çalışırsanız hata alırsınız. Yalnızca tek DC'li bir test ortamında beklemeyi atlamak için şu yöntem kullanılabilir:

PowerShell
# SADECE LAB ORTAMI ICIN
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Üretim ortamında bu yöntemi kullanmayın; anahtarı henüz almamış bir DC'ye bağlanan sunucu parolayı alamaz. Anahtarın durumunu doğrulayın:

PowerShell
$key = Get-KdsRootKey
Test-KdsRootKey -KeyId $key.KeyId

Yetkili Sunucu Grubunu Hazırlamak

Parolayı alabilecek sunucuları tek tek yazmak yerine bir gruba toplamak, yönetimi kolaylaştırır:

PowerShell
New-ADGroup -Name "gMSA-Yedek-Sunuculari" -GroupScope Global -GroupCategory Security `
    -Path "OU=Sunucular,OU=Firma,DC=firma,DC=local" `
    -Description "gmsaYedek parolasini alabilecek sunucular"

Add-ADGroupMember -Identity "gMSA-Yedek-Sunuculari" -Members "FS01$"

Bilgisayar hesaplarının sonunda $ işareti olduğuna dikkat edin. Sunucu yeni grup üyeliğini ancak yeni bir Kerberos bileti aldığında görür. Yeniden başlatmak istemiyorsanız FS01 üzerinde bilgisayar hesabının biletlerini temizleyin:

Komut İstemi
klist -li 0x3e7 purge

gMSA Oluşturmak

DC01 veya RSAT kurulu bir yönetim sunucusunda:

PowerShell
New-ADServiceAccount -Name "gmsaYedek" `
    -DNSHostName "gmsaYedek.firma.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA-Yedek-Sunuculari" `
    -ManagedPasswordIntervalInDays 30 `
    -Description "FS01 gece yedek gorevi"

Dikkat edilmesi gerekenler:

  • İsim en fazla 15 karakter olmalıdır: sAMAccountName sınırı nedeniyle $ hariç 15 karakteri aşmayın.
  • Parola değişim süresi sonradan değiştirilemez: ManagedPasswordIntervalInDays yalnızca oluştururken belirlenir. Farklı bir değer gerekirse hesabı yeniden oluşturmanız gerekir.
  • Konum: gMSA'lar varsayılan olarak CN=Managed Service Accounts,DC=firma,DC=local container'ında oluşturulur.

Hesabı kontrol edin:

PowerShell
Get-ADServiceAccount -Identity "gmsaYedek" `
    -Properties PrincipalsAllowedToRetrieveManagedPassword, msDS-ManagedPasswordInterval, PasswordLastSet |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword, msDS-ManagedPasswordInterval, PasswordLastSet

Sonradan başka bir sunucuyu yetkilendirmek için hesabı değil, grubu güncellemeniz yeterlidir.

Sunucuya Kurmak ve Test Etmek

FS01 üzerinde AD PowerShell modülünü ekleyip gMSA'yı kurun:

PowerShell
Install-WindowsFeature -Name RSAT-AD-PowerShell

Install-ADServiceAccount -Identity "gmsaYedek"
Test-ADServiceAccount -Identity "gmsaYedek"

Test-ADServiceAccount komutu True dönmelidir. False dönüyorsa büyük ihtimalle sunucu henüz grup üyeliğini görmüyordur; klist komutunu çalıştırın veya sunucuyu yeniden başlatın.

gMSA'yı Bir Serviste Kullanmak

Bir Windows servisinin gMSA ile çalışması için services.msc içinde servisin Log On sekmesinde This account alanına FIRMA\gmsaYedek$ yazın ve parola alanlarını boş bırakın. Komut satırından da aynı işlem yapılabilir:

Komut İstemi
sc.exe config "YedekAjani" obj= "FIRMA\gmsaYedek$" password= ""
sc.exe qc "YedekAjani"

obj= ve password= sonrasındaki boşluk zorunludur. services.msc hesaba Log on as a service hakkını otomatik verir; sc.exe kullandığınızda bu hakkı GPO ile vermeniz gerekebilir. Bu GPO ayarı sunucudaki yerel listeyi tamamen değiştirir; gMSA ile birlikte o sunucuda bu hakka ihtiyaç duyan diğer hesapları da listeye ekleyin:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service

gMSA ile Zamanlanmış Görev

Zamanlanmış görevler için grafik arayüz gMSA'yı doğrudan desteklemez, PowerShell kullanmanız gerekir. -LogonType Password değeri, parolanın AD'den alınacağını belirtir:

PowerShell
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\gece-yedek.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At 02:00
$principal = New-ScheduledTaskPrincipal -UserId "FIRMA\gmsaYedek$" -LogonType Password

Register-ScheduledTask -TaskName "Gece-Yedek" -Action $action -Trigger $trigger -Principal $principal

Hesabın görevi çalıştırabilmesi için Log on as a batch job hakkına ihtiyacı vardır. Bunu yukarıdaki User Rights Assignment yolundan, ilgili sunuculara uygulanan bir GPO ile verin. Ayrıca gMSA'ya yalnızca ihtiyacı olan klasörlerde (örneğin \\FS01\Yedek) yetki tanıyın; Domain Admins grubuna eklemeyin.

IIS kullanıyorsanız uygulama havuzunun Identity ayarında Custom account seçip yine FIRMA\gmsaYedek$ yazarak parolayı boş bırakabilirsiniz. SQL Server da servis hesabı olarak gMSA'yı destekler.

Sık Karşılaşılan Hatalar

  • KDS root key yokken gMSA oluşturmak: New-ADServiceAccount "Key does not exist" hatası verir. Add-KdsRootKey çalıştırıp 10 saat bekleyin.
  • `Test-ADServiceAccount` sonucunun False olması: Sunucu yetkili grupta değil veya grup üyeliğini henüz görmüyor. klist -li 0x3e7 purge çalıştırın ya da sunucuyu yeniden başlatın.
  • Hesap adının sonuna `$` eklememek: Servis ve görev tanımlarında hesap FIRMA\gmsaYedek$ olarak yazılmalıdır.
  • Parola alanına bir şey yazmak: gMSA için parola her zaman boş bırakılır; aksi halde servis başlamaz.
  • Batch job hakkını unutmak: Zamanlanmış görev "logon failure" ile başarısız olur. Hakkı GPO ile verin.
  • gMSA'yı Protected Users grubuna eklemek: Bilet ve delegation kısıtlamaları servisleri bozabilir. Servis hesaplarını bu grubun dışında tutun.

Bir sonraki yazıda serinin son konusuna geçiyor; eski bir Domain Controller'ı güvenle kaldırmayı ve metadata temizliğini anlatıyoruz.

Okuma görünümü 3 görüntülenme