SQL NT Account geht nicht mehr - Wo setze ich Account Passwort , oder ist besser einen anderen Account hinterlegen
Hallo,
ich habe einen SQL Server installiert. Der hat Standardmässig einen NT Account hinterlegt.
Nun heute aus heiterem Himmel startet der SQL Dienst nicht mehr und ich finde den Account nirgends um das neu zu setzen. Siehe Printscreen.
SQL NT Account geht nicht mehr Wo setze ich Account Passwort , oder ist besser einen anderen Account hinterlegen ?
SA Account, Domain Service User , oder einen Lokalen Account. Was ist besser ?
Oder ist die correcte Vorgehensweise der Locale System Account ?
Gruss
Jonas
ich habe einen SQL Server installiert. Der hat Standardmässig einen NT Account hinterlegt.
Nun heute aus heiterem Himmel startet der SQL Dienst nicht mehr und ich finde den Account nirgends um das neu zu setzen. Siehe Printscreen.
SQL NT Account geht nicht mehr Wo setze ich Account Passwort , oder ist besser einen anderen Account hinterlegen ?
SA Account, Domain Service User , oder einen Lokalen Account. Was ist besser ?
Oder ist die correcte Vorgehensweise der Locale System Account ?
Gruss
Jonas
Please also mark the comments that contributed to the solution of the article
Content-Key: 639714
Url: https://administrator.de/contentid/639714
Printed on: April 23, 2024 at 20:04 o'clock
11 Comments
Latest comment
Zitat von @itnirvana:
SQL NT Account geht nicht mehr Wo setze ich Account Passwort , oder ist besser einen anderen Account hinterlegen ?
SA Account, Domain Service User , oder einen Lokalen Account. Was ist besser ?
SQL NT Account geht nicht mehr Wo setze ich Account Passwort , oder ist besser einen anderen Account hinterlegen ?
SA Account, Domain Service User , oder einen Lokalen Account. Was ist besser ?
am besten sowenig rechte wie moeglich
muss der dienst aufs netzwerk zugreifen? wenn nein, lokaler user bzw. domain user mit wenig rechten
Windows Dienst SQL
Moin,
wie es bereits @tagol.de geschrieben hat, so wenig Rechte wie möglich. Daher verstehe ich nicht deinen Vorschlag mit dem Benutzer SA? Abgesehen davon, kann dieser nicht als Benutzer für Windows Dienste benutzt werden. Der Grund dafür ist, dass es sich dabei um einen Benutzer, der ausschließlich in der Benutzerverwaltung des SQL Servers existiert.
Hier noch ein wenig Lesestoff für das Homeschooling: Windows Service Accounts and Permissions.
Gruß,
Dani
wie es bereits @tagol.de geschrieben hat, so wenig Rechte wie möglich. Daher verstehe ich nicht deinen Vorschlag mit dem Benutzer SA? Abgesehen davon, kann dieser nicht als Benutzer für Windows Dienste benutzt werden. Der Grund dafür ist, dass es sich dabei um einen Benutzer, der ausschließlich in der Benutzerverwaltung des SQL Servers existiert.
Hier noch ein wenig Lesestoff für das Homeschooling: Windows Service Accounts and Permissions.
Gruß,
Dani
Hi,
es wäre hilfreich, wenn Du die SQL-Server Version und Edition (Vollversion oder Express), die Du installiert hast, dazuschreiben würdest.
Ggf. hat der User MSSQL$<Instanzname> einfach nur das Recht zum Anmelden als Dienst verloren. Das wäre in der GPO zu konfigurieren.
Schau auch mal ins Eventlog, was dort beim Startversuch des Dienstes reingeschrieben wird in Bezug auf den Benutzer.
Gruß
cykes
es wäre hilfreich, wenn Du die SQL-Server Version und Edition (Vollversion oder Express), die Du installiert hast, dazuschreiben würdest.
Ggf. hat der User MSSQL$<Instanzname> einfach nur das Recht zum Anmelden als Dienst verloren. Das wäre in der GPO zu konfigurieren.
Schau auch mal ins Eventlog, was dort beim Startversuch des Dienstes reingeschrieben wird in Bezug auf den Benutzer.
Gruß
cykes
Ob das so korrekt ist, kannst nur Du beantworten - laufen alle Dienste und hat Du mit der Anwendung Zugriff auf alles?
Ich würde es pauschal nicht so machen, sondern die genaue Ursache ermitteln und dazu die passende Lösung recherchieren.
So ist das Gefrikel, was Dir in x Tagen wieder auf die Füße fallen kann.
Ich würde es pauschal nicht so machen, sondern die genaue Ursache ermitteln und dazu die passende Lösung recherchieren.
So ist das Gefrikel, was Dir in x Tagen wieder auf die Füße fallen kann.
N'Abend.
Nein. Ein Dienstkonto sollte (darf) keine Adminrechte auf dem Hostsystem haben. Als allerallerallerletztes sollte ein SQL-Server als "Local System" laufen - das ist in punkto Sicherheit der Supergau.
Wenn der Server AD-joined ist, sollte man einen Group Managed Service Account verwenden; wenn nicht AD-joined, dann einen lokalen User _ohne!_ Adminrechte.
Cheers,
jsysde
Nein. Ein Dienstkonto sollte (darf) keine Adminrechte auf dem Hostsystem haben. Als allerallerallerletztes sollte ein SQL-Server als "Local System" laufen - das ist in punkto Sicherheit der Supergau.
Wenn der Server AD-joined ist, sollte man einen Group Managed Service Account verwenden; wenn nicht AD-joined, dann einen lokalen User _ohne!_ Adminrechte.
Cheers,
jsysde
Zitat von @jsysde:
N'Abend.
Nein. Ein Dienstkonto sollte (darf) keine Adminrechte auf dem Hostsystem haben. Als allerallerallerletztes sollte ein SQL-Server als "Local System" laufen - das ist in punkto Sicherheit der Supergau.
Wenn der Server AD-joined ist, sollte man einen Group Managed Service Account verwenden; wenn nicht AD-joined, dann einen lokalen User _ohne!_ Adminrechte.
Cheers,
jsysde
nun genau das tut ja der SQL Server, er legt bei der Installation genau so ein Konto an, das einzig und allein dafür da ist, lokal und auch nur innerhalb der SQL Server Installation bzw. in dem Stammverzeichnis für die Datenbanken zu arbeiten. Deshalb hat MS z.B. beim SQL Server Management Studio auch keine Optionen für den Zugriff auf Netzlaufwerke oder Shares eingebaut, z.B. bei Backups weil das Dienstekonto von solchen Stellen dann nichts lesen kann.N'Abend.
Nein. Ein Dienstkonto sollte (darf) keine Adminrechte auf dem Hostsystem haben. Als allerallerallerletztes sollte ein SQL-Server als "Local System" laufen - das ist in punkto Sicherheit der Supergau.
Wenn der Server AD-joined ist, sollte man einen Group Managed Service Account verwenden; wenn nicht AD-joined, dann einen lokalen User _ohne!_ Adminrechte.
Cheers,
jsysde
Und genau das Konto geht z.B. kaputt wenn der Server nachträglich eine Domäne joint.
Servus.
Die Infos vom TE sind leider mehr als spärlich (ist die Kiste nun im AD oder nicht?), daher ist es schwierig, hier detaillierter zu antworten.
Cheers,
jsysde
Zitat von @GrueneSosseMitSpeck:
[...]Und genau das Konto geht z.B. kaputt wenn der Server nachträglich eine Domäne joint.
Ok, gut zu wissen - ich hab' eher selten mit Maschinen außerhalb eines AD zu tun, daher ist mir das noch nie aufgefallen. Wobei ich wohl auch niemals einen bereits laufenden SQL-Server "mal eben" domain-joinen würde... [...]Und genau das Konto geht z.B. kaputt wenn der Server nachträglich eine Domäne joint.
Die Infos vom TE sind leider mehr als spärlich (ist die Kiste nun im AD oder nicht?), daher ist es schwierig, hier detaillierter zu antworten.
Cheers,
jsysde