Ungewöhnliches SQL-Dienstkonto - Dienst wurde aufgrund eines Anmeldefehlers nicht gestartet

Question

Das istverrückt, also bitte haben Sie Geduld. Dies ist KEIN falsches Passwort.

Ich habe ein SQL-Dienstkonto, das NICHT authentifiziert wird. Ich bin ein erfahrener Server-Typ und habe alle Grundlagen mit ein paar sachkundigen Kollegen ausprobiert (auch wenn sie Cisco-orientiert sind).

Szenario:

1. Active Directory an 3 Standorten mit jeweils 2 DC's und 1 Root-DC auf Server 2008 R2
2. Keine DNS-Probleme und die Site-Replikation funktioniert einwandfrei. Alle Kontoänderungen erfolgen innerhalb von Sekunden.
3. Neu erstelltes SQL 2016 R2, bereitgestellt auf 2 Server 2012 R2-Servern in der Domäne, die sich in einer Organisationseinheit befinden, in der sich auch SQL 2005 auf Server 2008 R2 befindet.
4. ALLE SQL-Server befinden sich in ihrem eigenen VLAN, DCs in einem anderen. Keine Firewall-Probleme dazwischen, Hand aufs Herz, wir können keine Protokolle sehen, da sie von Drittanbietern auf ESX-Clustern mit Cisco-Verträgen zwischen VLANs gehostet werden.
5. Der SQL 2005-Server hat keine Probleme bei der Authentifizierung mit DCs im anderen VLAN.

Das Einrichten eines bestehenden AD SQL-Dienstkontos auf den neuen SQL-Servern schlägt aufgrund des Fehlers 1069 fehl: Der Dienst konnte aufgrund eines Anmeldefehlers nicht gestartet werden.

Das Ereignis in den Ereignisprotokollen auf den DCs (je nachdem, welcher der beiden das Konto authentifiziert) besagt Folgendes:

Kerberos-Vorauthentifizierung fehlgeschlagen. Kontoinformationen: Sicherheits-ID: DOMAIN\sqlsvcaccount$ Kontoname: sqlsvcaccount$ (nicht der tatsächliche Kontoname) Dienstinformationen: Dienstname: krbtgt/DOMAIN (natürlich nicht unser Domänenname) Netzwerkinformationen: Clientadresse: ::ffff:10.30.xx (unsere IPv4-Adresse) Clientport: 49464 Zusätzliche Informationen: Ticketoptionen: 0x40810010 Fehlercode: 0x18 Vorauthentifizierungstyp: 2

Zertifikatsinformationen: Name des Zertifikatausstellers:
Seriennummer des Zertifikats:
Fingerabdruck des Zertifikats:

Nun ist 0x18 normalerweise ein schlechtes Passwort, aber wie erwähnt, die Konten sind in Ordnung und wenn sie deaktiviert werden, aktiviere ich sie wieder, setze das Passwort zurück und so weiter. Ich kann ein RunAs für eine Anwendung auf dem neuen SQL-Server ausführen und das funktioniert einwandfrei.

Ich habe eine Computergruppenrichtlinie festgelegt, um dem Dienstkonto Rechte für Dienste usw. zu gewähren, und ein gpresult ausgeführt, um zu bestätigen, dass das Gruppenrichtlinienobjekt angewendet wird.

Dateien und Verzeichnisse sichern DOMAIN\sqlsvcaccount$ Als Batch-Job anmelden DOMAIN\sqlsvcaccount$ Als Dienst anmelden DOMAIN\sqlsvcaccount$

Hatte sogar eine eingeschränkte Computer-GPO und habe das Domänenkonto als lokalen Administrator eingerichtet (wodurch die Dienst-GPO nicht mehr erforderlich gewesen wäre).

Habe eine neue Benutzer-OU für das Dienstkonto mit blockierter Vererbung erstellt und das Dienstkonto dorthin verschoben, nochmal gpupdate /force ausgeführt und gpresult nochmal zu html ausgeführt und alles sieht OK aus.

Außerdem zwischendurch ein paar Neustarts, das Übliche.

Wir haben Wireshark ausgeführt, was nie einen Fehler angezeigt hat, den SQL-Server auf dasselbe VLAN wie die DCs verschoben und wie bereits erwähnt, gibt es beim SQL 2005-Server auf dem DB-VLAN keine Authentifizierungsprobleme.

Schließlich habe ich eine neue Computer-Organisationseinheit erstellt, die Richtlinienvererbung blockiert und das Ganze noch einmal versucht. Aber beim Starten des SQL Server- oder Agent-Dienstes klappte es immer noch nicht.

Ich habe das SQL-Verwaltungstool zum Bearbeiten von Diensten wie vorgesehen und sogar nur von Windows Services.msc ausprobiert.

Als letztes haben wir uns die Chiffren angesehen und ob der Server 2012 versucht, sich mit RC4 zu authentifizieren und die Chiffren zu deaktivieren. Aber damit sind wir noch nicht weit gekommen.

Also, hat irgendjemand eine Idee, was los sein könnte? Ich freue mich über JEDES Feedback oder jeden anderen Weg, den ich versuchen könnte.

Für jeden, der die Antwort hat, gibt es eine virtuelle Kiste Bier?

Answer 1

Verwaltete Dienstkonten(MSA) hat das Problem gelöst. Server 2012 AD verwendet gMSA, was mich etwas verwirrt hat:

In AD (mit erweiterten Optionen) unter Novacroft gibt es eine Organisationseinheit namens Managed Service Accounts. Dort finden Sie Ihre erstellten MSAs, sobald Sie sie mit Powershell erstellt haben.

So installieren Sie ein Dienstkonto:

1. Den Account (ohne $) erstellst Du per Powershell.
2. Ordnen Sie das Konto anschließend einem Server zu – wiederum mithilfe von Powershell.
3. Installieren Sie auf dem Zielserver Powershell und das AD-Modul unter Features und AD-Tools. Installieren Sie außerdem .NET 3.5
4. Importieren Sie das Konto auf dem Zielserver innerhalb von Powershell auf den Host.
5. Richten Sie dann die Dienste ein (jetzt müssen Sie am Ende $ hinzufügen) und lassen Sie das Kennwort leer.

Schön und einfach, oder (wenn man weiß wie)? Dank an NedPyle [MSFT] Vollständiger ArtikelHIER Ich hoffe, das hilft jemandem :-)