SQL Server gMSA Kurulumu: Group Managed Service Account Adım Adım

Bir SQL Server servisi kendi makinesinin dışındaki bir kaynağa erişmek zorunda kaldığı anda bir etki alanı (domain) kimliğine ihtiyaç duyar: yedeklerin yazıldığı paylaşım, Always On availability group endpoint’leri, Kerberos delegasyonu kullanan bir linked server. Bunun klasik çözümü olan “şifresi hiç değişmeyen domain kullanıcısı” aynı zamanda klasik zayıf noktadır. Şifre bir dokümana yazılır, kimse değiştirmeye cesaret edemez ve hesap bir gün güvenlik denetiminde karşınıza çıkar.

Group managed service account (gMSA) bu zayıf noktayı ortadan kaldırır. Active Directory hesap için uzun ve rastgele bir şifre üretir, bu şifreyi otomatik olarak değiştirir; izin verdiğiniz sunucular şifreyi kendileri alır ve kimse şifreyi hiçbir yere yazmaz. Bu rehberde SQL Server için gMSA kurulumunu baştan sona anlatıyoruz: KDS root key, hesabın oluşturulması, sunuculara atanması, her sunucuda yüklenip test edilmesi ve SQL Server kurulumunda kullanılması.

gMSA Nedir, SQL Server Ne Zaman İhtiyaç Duyar?

gMSA, etkileşimli oturum açmak için kullanılamayan ve şifresi domain controller’lar tarafından yönetilen bir domain hesabıdır. Şifre varsayılan olarak 30 günde bir değişir ve hesabı kullanan servisler yeniden başlatma gerektirmeden çalışmaya devam eder. Tek sunuculu managed service account’un (sMSA) aksine bir gMSA birden çok sunucuda kullanılabilir; availability group ve failover cluster instance’ların tam olarak ihtiyaç duyduğu da budur.

Microsoft’a göre SQL Server, gMSA’yı tek başına çalışan instance’larda SQL Server 2014’ten, failover cluster instance ve availability group’larda SQL Server 2016’dan itibaren destekler. İşletim sistemi Windows Server 2012 R2 ya da üzeri olmalıdır.

Ön Koşullar

• Windows Server 2012 ya da üzeri domain ve forest işlevsellik düzeyi.
• gMSA nesnesi oluşturma yetkisi (Domain Admins ya da msDS-GroupManagedServiceAccount nesneleri için devredilmiş yetki).
• Hesabı oluşturacağınız makinede ve hesabı kullanacak her SQL Server’da Active Directory Module for Windows PowerShell.
• Domain’de bir KDS root key (bir sonraki adım).

Active Directory modülünü Windows Server’a şu komutla yükleyin:

Install-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory

1. Adım: KDS Root Key Oluşturmak (Domain Başına Bir Kez)

Domain controller’lar gMSA şifrelerini Key Distribution Service (KDS) root key ile üretir. Bu anahtar domain başına bir kez oluşturulur. Önce var olup olmadığını kontrol edin:

# Domain controller'da ya da AD modülü yüklü bir makinede, Domain Admin olarak
Get-KdsRootKey

# Sonuç dönmüyorsa oluşturun
Add-KdsRootKey -EffectiveImmediately

2. Adım: gMSA Hesabını Oluşturmak

Hesaba en fazla 15 karakterlik (sAMAccountName sınırı), ne işe yaradığını anlatan bir ad verin ve Windows istediği yerlerde sonuna $ ekleyin. Aşağıdaki örneklerde domain sirket.local, sunucular SQL01 ve SQL02‘dir.

Sunuculara tek tek değil bir güvenlik grubu üzerinden izin vermek, sunucu eklendiğinde ya da değiştiğinde yönetimi kolaylaştırır:

# Hesabı kullanabilecek sunucuları içeren güvenlik grubu
New-ADGroup -Name "gmsa-sqlprod-hosts" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "gmsa-sqlprod-hosts" -Members "SQL01$", "SQL02$"

# Database Engine için gMSA; şifresini yalnızca grubun üyeleri alabilir
New-ADServiceAccount -Name "gmsa-sqlprod" `
    -DNSHostName "gmsa-sqlprod.sirket.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "gmsa-sqlprod-hosts"

Hesap yalnızca tek bir sunucuda çalışacaksa grup yerine doğrudan bilgisayar hesabını da verebilirsiniz (-PrincipalsAllowedToRetrieveManagedPassword "SQL01$"); var olan bir gMSA’yı Set-ADServiceAccount ile değiştirebilirsiniz. Hesap, Active Directory’de Managed Service Accounts konteynerinde oluşur.

SQL Server Agent için aynı yöntemle ayrı bir gMSA oluşturun (örneğin gmsa-sqlagt). Her servise ayrı hesap, yetkileri küçük tutar ve denetim kayıtlarını okumayı kolaylaştırır.

3. Adım: Her Sunucuda gMSA’yı Yüklemek ve Test Etmek

Hesabı kullanacak her SQL Server’da AD modülünü yükleyin, ardından yönetici olarak açılmış bir PowerShell penceresinde gMSA’yı yükleyip test edin:

Install-WindowsFeature RSAT-AD-PowerShell

Install-ADServiceAccount -Identity "gmsa-sqlprod"
Test-ADServiceAccount -Identity "gmsa-sqlprod"    # True dönmelidir

Şifrenin en son ne zaman değiştiği ve şifreyi kimlerin alabildiği dahil hesabın tüm özelliklerini görmek için:

Get-ADServiceAccount -Identity "gmsa-sqlprod" -Properties * |
    Select-Object Name, Enabled, PrincipalsAllowedToRetrieveManagedPassword,
                  ManagedPasswordIntervalInDays, PasswordLastSet, LastLogonDate, ServicePrincipalNames

4. Adım: SQL Server Kurulumunda gMSA Kullanmak

Kurulumun Server Configuration sayfasında Database Engine için hesabı SIRKET\gmsa-sqlprod$, SQL Server Agent için SIRKET\gmsa-sqlagt$ olarak girin ve şifre alanını boş bırakın. Kurulum, servisin ihtiyaç duyduğu hakları kendisi verir. Sessiz (unattended) kurulumda hesapları şifre parametresi olmadan verin:

.\setup.exe /Q /ACTION=Install /FEATURES=SQLENGINE /INSTANCENAME=MSSQLSERVER `
    /SQLSVCACCOUNT="SIRKET\gmsa-sqlprod$" /AGTSVCACCOUNT="SIRKET\gmsa-sqlagt$" `
    /SQLSYSADMINACCOUNTS="SIRKET\SQL-DBA" /IACCEPTSQLSERVERLICENSETERMS

Var olan bir instance’ta hesabı Windows Services konsolundan değil SQL Server Configuration Manager‘dan değiştirin: Configuration Manager, veri klasörleri ve registry anahtarları üzerindeki yetkileri de günceller. Yeni hesap için instant file initialization’ı da açın; nasıl kontrol edileceğini instant file initialization rehberimizde anlatıyoruz.

Servis yeniden başladıktan sonra hesabı SQL Server içinden doğrulayın:

SELECT servicename, service_account, status_desc, instant_file_initialization_enabled
FROM sys.dm_server_services;

SPN ve Kerberos

Kerberos ile kimlik doğrulama için instance’ın service principal name’lerinin (SPN) gMSA üzerine kayıtlı olması gerekir. SQL Server açılışta bunları kendisi kaydetmeye çalışır, ancak hesabın kendi SPN’ini yazma yetkisi olmalıdır. Ya bu yetkiyi Active Directory’de gMSA’ya verin ya da SPN’leri bir kez elle kaydedin:

setspn -S MSSQLSvc/SQL01.sirket.local:1433 SIRKET\gmsa-sqlprod$
setspn -S MSSQLSvc/SQL01.sirket.local SIRKET\gmsa-sqlprod$
setspn -L SIRKET\gmsa-sqlprod$

Sonra bir istemci bağlantısından kontrol edin: SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID; sorgusu NTLM değil KERBEROS döndürmelidir.

Always On Availability Group’larda gMSA

Database Engine’i her replikada aynı gMSA ile çalıştırmak availability group’ları sadeleştirir: endpoint yetkisi her replika için ayrı bir login yerine tek bir login’e verilir.

CREATE LOGIN [SIRKET\gmsa-sqlprod$] FROM WINDOWS;
GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [SIRKET\gmsa-sqlprod$];

Her replikanın bilgisayar hesabını, instance’ı o sunucuya kurmadan önce şifreyi alabilen gruba ekleyin. Genel tasarım için Always On rehberimize bakın.

Kontrol Listesi

• Domain’de bir KDS root key var ve en az 10 saat önce oluşturuldu.
• Database Engine ve SQL Server Agent için ayrı, adı en fazla 15 karakter olan gMSA’lar oluşturuldu.
• Sunuculara güvenlik grubu üzerinden izin verildi ve gruba eklendikten sonra Kerberos biletleri yenilendi.
• Test-ADServiceAccount her sunucuda True döndürüyor.
• Kurulumda DOMAIN\ad$ boş şifreyle kullanıldı; var olan instance’larda değişiklik Configuration Manager’dan yapıldı.
• SPN’ler kayıtlı ve istemci bağlantıları Kerberos kullanıyor.
• Hesaplar, gruplar ve SPN’ler kurulum dokümanına işlendi.

Kurulumun geri kalanı için SQL Server kurulum kontrol listemize bakın. Sunucular hiç domain üyesi değilse, seçenekleri Active Directory olmadan SQL Server kurulumu yazımızda anlatıyoruz.