Im Prinzip ist alles sehr einfach. Das Konto mit dem ein Dienst laufen soll, soll möglichst nur die Rechte besitzen, die es für die Ausführung seiner Dienste benötigt.
Im memoria
Ich kann mich noch gut an die Zeiten erinnern, als so gut wie alle Dienst – auch SQL Server – mit Local System betrieben worden sind. Warum? Damit alles funktioniert. Naja, so gut wie alles. Mit Local System war der Zugriff auf Netzwerkressourcen nicht mehr möglich, daher hat man in diesen Fällen schon mal einen Admin-Account verwendet. Und.. sie werden es nicht glauben: es hat alles funktioniert. Neben Backups, Logshipping oder anderen wichtigen Aufgaben, funktionierten auch Trojaner einwandfrei.
Im Lauf der Zeit hat man sich doch ein wenig besonnen und verwendete Netzwerkdienst, um wenigsten minimale Rechte und Netzwerkfunktionalität zu haben. Aber auch das ist heute absolut nicht mehr zeitgemäß. Ein Konto muss viele Dinge erfüllen, aber vor allem muss es sicherer sein, durch etwa regelmäßiges Ändern der Kennwörter beispielsweise. Und genau hier setzt man mit virtuellen Dienstkonten und virtuelle Konten an.
Virtuelles Konto
Virtuelle Konten sind verwaltete lokale Konten. Genauer gesagt wird bei dem Zugriff auf Ressourcen, das Computerkonto verwendet in Form von DOMÄNERechner$. Eine Verwaltung des Kennworts ist somit obsolet. Das Konto werden in folgender Form erstellt:
NT SERVICE<SERVICENAME>
Wobei Instanzen per$ getrennt angegeben werden.
Standardinstanz des SQL Servers
NT SERVICEMSSSQLSERVER
SQL Instanz: Paris
NT SERVICEMSSQL$PARIS
SQL Server Agent-Dienst auf der Standardinstanz von SQL Server
NT SERVICESQLSERVERAGENT
SQL Server-Agent-Dienst auf einer Instanz von SQL Server mit dem Namen PARIS
NT SERVICESQLAGENT$PARIS
Zugriffe auf Ressourcen per Computerkonto
Nicht in jeden Fall wäre ein virtuelles Konto für SQL Server geeignet. Virtuelle Konten können nicht für eine SQL Server-Failoverclusterinstanz verwendet werden, da das virtuelle Konto nicht dieselbe SID auf allen Knoten des Clusters besäße.
Empfehlenswerter als virtuelle Konten sind allerdings verwaltete Dienstkonten.
Verwaltetes Dienstkonto – Managed Service Account (MSA und gMSA)
Verwaltete Dienstkonten haben den Vorteil, dass sie einerseits über sehr komplexes Kennwort verfügen (240 Zeichen) und andererseits Kennwortänderungen der Domänencontroller übernimmt. Vorsicht ist geboten ab Windows 2012. Hier wurden sogenannte Gruppenverwaltete Dienstkonten verwendet (gMSA). Der Unterschied liegt in folgendem. MSA hatten den Nachteile, dass das verwaltete Dienstkonto auf einen Domänenserver beschränkt ist und die Kennwörter vom Computer verwaltet werden. Daher mussten diese Konten regelmäßig gewartet werden, damit das Kennwort nicht abläuft. Bei gMSA ist dies nicht mehr notwendig, da sie von mehreren Domänencontrollern verwaltet werden und von mehreren Server auch abgerufen werden können.
..und nun: wie gehts?
Anlegen eines gMSA
Zunächst legen wir auf einem Domänencontroller einen Service Account an.
New-ADServiceAccount –Name “Name des Dienstkontos” –Path “LDAP zu Managed Service Accounts” enabled $true
New-ADServiceAccount –Name “Name des Dienstkontos” –Path “LDAP zu Managed Service Accounts” enabled $true
Läßt man den Parameter weg, so wird das Gruppenverwaltete Dienstkonto im Standard OU “Managed Service Accounts” eingetragen.
Unter Windows 2012 bekommen Sie vermutlich noch eine Fehlermeldung, wenn die bei der Nachfrage nach dem DNSHostname ihren Domänencontroller eingegeben haben. Das hat grundsätzlich etwas damit zu tun, dass ab Windows 2012 eben diese Gruppenverwaltete Managed ServiceAccounts eingeführt worden sind. Letztendlich bedeutet es, dass nun mehrere Server die Verwaltung der MSA (Managed Service Accounts) übernehmen können. Dazu ist ein Dienst, der Kerberos Schlüsselverteilungsdienst”, notwendig. In Kurzform: Dieser hilft die hochsicheren Kennwörter zu generieren bzw. zu verschlüsseln. Dazu braucht man ein root-key. (zum Nachlesen: http://technet.microsoft.com/en-us/library/jj128430.aspx)
Für Testzwecke empfiehlt Microsoft folgendes Script zu verwenden, dass den Schlüssel mit einem Zeitstempel in der Vergangenheit setzt (wg Replikation).
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Weiterhin müssen den betreffenden Servern das Recht eingeräumt werden ,sich Kennwörter holen zu dürfen.
$SQLs=”SQLNODES” SET-ADServiceAccount –PrincipalsAllowedToRetrieveManagedPassword $SQLs –Identity svcSKUHEL
Wobei $SQLs nichts anderes ist als eine Windows Gruppe, in der die entsprechenden SQL Server enthalten sind, die mit dem Konto verwaltet werden sollen.
Nun sollte das Anlegen des Dienstkontos funktioniert haben.
Nun gehts auf dem entsprechenden SQL Server weiter, auf dem wir das Servicekonto installieren müssen. Da wir der Powershell auf AD Komponenten zugreifen müssen, installiert man die entrechtende Shellerweiterung über Features:
Für alle Fälle: Die Powershell bitte als Administrator starten. (wg. UAC)
Import-Module ActiveDirectory Install-ADServiceAccount –Identity svcKUHEL;
Servicekonto zuweisen
Als letztes – und leichtesten Schritt – benötigen wir nur noch den SQL Server Configuration Manager um unserer SQL Instanz das Konto zuzuweisen.
Wichtige Regel: Jegliche Änderungen am SQL Dienstkonten immer per SQL Server Configuration Manager erledigen. Er macht alles was notwendig ist, wie setzen der notwendigen Registry Key, Gruppenzuweisen etc.
Entweder tippen Sie das Servicekonto manuell ein, beachten, dass am Ende nu ein $ Zeichen steht und kein Kennwort angegeben wird…
Oder Sie suchen in AD nach dem Konto. Die Dienstkonten müssen sie natürlich in der Domäne suchen. Um nicht hunderte von Einträgen durchsuchen zu müssen, lohnt es sich nur noch Dienstkonten anzeigen zu lassen
Hier unser neues Dienstkonto…
Auswählen.. übernehmen.. fertig 
