Ich will das Kennwort gar nicht wissen – Nutzung von gruppenverwalteten Dienstkonten für Microsoft SQL Server

Vor einigen Tagen habe ich in meiner Laborumgebung für Always-On-Verfügbarkeitsgruppen (Availability Groups) das Dienstkonto der SQL-Server-Instanzen ausgetauscht und verwende jetzt ein gruppenverwaltetes Dienstkonto (group-managed service account, gMSA). Die notwendigen Anpassungen stelle ich im Folgenden vor.

Welches Dienstkonto empfehlen wir?

Als Dienstkonto für den Microsoft SQL Server empfehlen wir inzwischen generell die Verwendung von lokalen Dienstkonten. Hierbei muss kein Kennwort verwaltet werden und der Zugriff auf Ressourcen im Netzwerk erfolgt über das Computerkonto. Dieses kann dann zum Beispiel auf Dateifreigaben berechtigt werden, um dort ein Backup schreiben zu können.

Bei der Einrichtung von Hochverfügbarkeitslösungen wie Always-On-Verfügbarkeitsgruppen wird jedoch ein gemeinsam von allen SQL-Server-Instanzen genutztes Konto empfohlen, da hier der Zugriff zwischen den Instanzen sehr einfach eingerichtet werden kann. Bei vielen unserer Kunden wird dazu noch ein klassisches Domänenbenutzerkonto mit Kennwort verwendet. Die von uns empfohlene Lösung ist hingegen die Verwendung von gruppenverwalteten Dienstkonten, da hier das Betriebssystem die Verwaltung des Kennworts übernimmt.

Wie wird ein gruppenverwaltetes Dienstkonto angelegt?

Eine notwendige Voraussetzung ist die Erstellung eines Microsoft-Schlüsselverteilungsdienst-Stammschlüssels. Der englische Begriff dafür ist vermutlich geläufiger: Key Distribution Service (KDS) Root Key. Der Schlüssel wird von den Domänenkontrollern benötigt, um gMSA-Kennwörter generieren zu können. Damit der Schlüssel in meinem Labor sofort nutzbar ist, überspringe ich die 10-stündige Wartezeit. Diese hat Microsoft vorgesehen, damit vor der ersten Verwendung auf jeden Fall alle Domänenkontroller den Schlüssel erhalten haben. Ich habe in meinem Labor nur einen einzigen und verwende daher folgenden Code: 

if (-not (Get-KdsRootKey)) {
    $null = Add-KdsRootKey -EffectiveTime ([datetime]::Now).AddHours(-10)
}
 

Bei der Erstellung des Dienstkontos wird bereits angegeben, welche Computer über ihre Computerkonten auf das Kennwort zugreifen dürfen. Hier müssen die Computer angegeben werden, auf denen später die SQL-Server-Instanzen installiert werden. In meinem Labor nutze ich dazu eine dynamische Abfrage auf das Active Directory und ermittle so alle Computer, deren Namen mit „SQL“ beginnen. Die Angabe kann später angepasst werden, wenn das Konto auf anderen Computern verwendet werden soll. Auch die anderen notwendigen Eigenschaften des Kontos werden von meinem Code dynamisch ermittelt.

Wichtig für die korrekte Funktion von Kerberos ist noch die Berechtigung zur Verwaltung des eigenen Service Principal Names (SPN) durch das Dienstkonto, die ich mit dem Dienstprogramm „dsacls“ einrichte. Weitere Informationen dazu finden Sie im Blog-Artikel „SQL Server und Kerberos: Bitte nicht die Service Principal Names vergessen“.

Um Berechtigungen nicht direkt an Dienstkonten zu erteilen, erstelle ich zudem eine passende Gruppe und füge das Dienstkonto dort als Mitglied hinzu. Zum Abschluss müssen die Zielcomputer noch neu gestartet werden, damit diese das neue Dienstkonto direkt nutzen können.

Hier der komplette Code, der auf jedem Computer ausgeführt werden kann, auf dem das PowerShell-Modul ActiveDirectory installiert ist:

$serviceAccountName        = 'gMSA-SQLServer'
$serviceAccountDescription = 'Group-managed service account for SQL Server'

$computerName              = (Get-ADComputer -Filter 'Name -like "SQL*"').Name
$computerAccountName       = $computerName | ForEach-Object { $_ + '$' }
$serviceAccountDNSHostName = "$serviceAccountName.$((Get-ADDomain).DNSRoot)"
$serviceAccountBenutzername    = "$((Get-ADDomain).NetBIOSName.ToUpper())\$serviceAccountName" + '$'

$adServiceAccountParams = @{
	Path                                       = $sqlUserOU.DistinguishedName
	Name                                       = $serviceAccountName
	Description                                = $serviceAccountDescription
	DNSHostName                                = $serviceAccountDNSHostName
	PrincipalsAllowedToRetrieveManagedPassword = $computerAccountName
	Enabled                                    = $true
}

$serviceAcccount = New-ADServiceAccount @adServiceAccountParams -PassThru
$null = dsacls $serviceAcccount.DistinguishedName /G "SELF:RPWP;servicePrincipalName"

New-ADGroup -Name SQLServiceAccounts -GroupCategory Security -GroupScope Global -Path $sqlUserOU.DistinguishedName
Add-ADGroupMember -Identity SQLServiceAccounts -Members (Get-ADServiceAccount -Identity $serviceAccountName)

Restart-Computer -ComputerName $computerName -Force
 

Wie wird der Zugriff auf Dateifreigaben erteilt?

Da ich meine Datenbanken im Labor auch per Backup und Restore auf die sekundären Replikate übertragen möchte, benötige ich zwingend eine Dateifreigabe, die von den SQL-Server-Instanzen mit dem gruppenverwalteten Dienstkonto verwendet werden kann.

Bisher habe ich ein Domänenbenutzerkonto als Dienstkonto verwendet und als Dateiserver einen nicht gehärteten Windows Server. Damit waren alle Verzeichnisse automatisch von allen Domänenbenutzern zur Speicherung von Dateien nutzbar, ich musste das Dienstkonto lediglich auf der Freigabe berechtigen.

Jetzt, mit dem gruppenverwalteten Dienstkonto, müssen auch noch die NTFS-Berechtigungen gesetzt werden. Ich verwende dazu folgenden Code (hier zur besseren Darstellung leicht abgewandelt):

$Path = 'C:\FileServer\Backup'
$AccountName = 'ORDIX\SQLServiceAccounts'
$AccessRight = 'Modify'
$accessRule = [System.Security.AccessControl.FileSystemAccessRule]::new(
	$AccountName,
	$AccessRight,
	[System.Security.AccessControl.InheritanceFlags]::ContainerInherit + [System.Security.AccessControl.InheritanceFlags]::ObjectInherit,
	[System.Security.AccessControl.PropagationFlags]::None,
	'Allow'
)
$acl = Get-Acl -Path $Path
$acl.SetAccessRule($accessRule)
Set-Acl -Path $Path -AclObject $acl
 

Sollten Sie häufiger NTFS-Berechtigungen setzen müssen, so empfehle ich die Verwendung des PowerShell-Moduls „NTFSSecurity“ des Microsoft-Mitarbeiters Raimund Andrée.

Die Einrichtung und Berechtigung der Dateifreigabe selbst erfolgen wie bisher mit folgendem Code (hier zur besseren Darstellung leicht abgewandelt):

$Path = 'C:\FileServer\Backup'
$ShareName = 'Backup'
$AccountName = 'ORDIX\SQLServiceAccounts'
$AccessRight = 'Change'
$null = New-SmbShare -Path $Path -Name $ShareName
$null = Grant-SmbShareAccess -Name $ShareName -AccountName $AccountName -AccessRight $AccessRight -Force
 

Was ändert sich bei der Installation der SQL Server-Instanz?

Hier sind die Änderungen sehr gering. Wie bisher wird für das Dienstkonto ein Credential-Objekt erstellt und dem Befehl Install-DbaInstance mitgegeben. Zu beachten ist nur das $-Zeichen am Ende des Benutzernamens sowie das leere Kennwort. Der Code sieht wie folgt aus: 

$DomainName = 'ORDIX'
$SQLServerServiceAccount = 'gMSA-SQLServer'
$sqlServerCredential = [PSCredential]::new("$DomainName\$SQLServerServiceAccount$", [SecureString]::new())
 

Was ändert sich bei der Einrichtung der Verfügbarkeitsgruppen?

Gar nichts. Ja, tatsächlich, Sie können sich die Änderungen auf GitHub gerne hier ansehen. Denn für den Betrieb der SQL-Server-Instanz und auch für die Einrichtung der Verfügbarkeitsgruppen macht die Art des verwendeten Kontos keinen Unterschied, solange eben für alle beteiligten Instanzen das gleiche Konto verwendet wird. 

Fazit

Die Einrichtung des ersten gruppenverwalteten Dienstkontos erfordert etwas neuen Code und bei Dateiservern vielleicht eine zusätzliche Konfiguration von NTFS-Berechtigungen. Aber ab dann ist es ganz einfach und im laufenden Betrieb werden Sie keinen Unterschied merken. Nur kann es jetzt nicht mehr zu doch versehentlich abgelaufenen oder kompromittierten Kennwörtern kommen.

Wenn Sie weitere Fragen haben oder Unterstützung bei der Umstellung auf gruppenverwaltete Dienstkonten benötigen, so sprechen Sie uns an. Wir helfen gerne.

Seminarempfehlung