mehrfache Konten vom Typ DS_SERVICE_PRINCIPAL_NAME

[Andreas_Z 10]

Hallo!

 

Bei mir hat sich folgendes zugetragen:

 

Ausstattung:

- Domaincontroller Win2003 Standard R2 mit letztem SP und allen Patches (SERVER1)

- zusätzlicher Domaincontroller Win 2000 letztes SP und alles Patches, MSSQL-Server 2000 mit letztem SP, SQL-Server läuft unter einem speziell angelegten Dienste-Konto.(SERVER2)

 

Situation:

Der MSSQL-Server soll abgelöst werden. Für einen Übergangszeitraum soll er aber noch verfügbar bleiben. Deshalb habe ich einen neuen, modernen SQL-Server gebaut und den zum zusätzlichen Domaincontroller gemacht. Bisher läuft alles sauber und stabil. Nun habe ich den alten Server zum Mitgleidsserver gemacht. Auch das lief sauber über die Bühne. Der SQL-Server konnte zwar nicht mehr mit seinem Dienste-Konto gestartet werden, aber das habe ich kurzerhand gelöst, indem ich die entsprechenden Dienste vorläufig mit dem lokalen System-Konto starten ließ. Das Dienste-Konto habe ich nachträglich mit der Berechtigung "aLs Dienst starten" versehen. Seit dem läuft der SQL-Server auch wieder unter seinem angestammten Konto.

 

Fehler:

Auf dem Domainkontroller im Ereignisslog erscheint seitdem in der Rubrik "System" stündlich die folgende Meldung:

 

Ereignistyp: Fehler

Ereignisquelle: KDC

Ereigniskategorie: Keine

Ereigniskennung: 11

Datum: 11.09.2007

Zeit: 08:51:19

Benutzer: Nicht zutreffend

Computer: SERVER1

Beschreibung:

Es sind mehrfache Konten vom Typ DS_SERVICE_PRINCIPAL_NAME mit dem Namen MSSQLSvc/server2.domain.net:1433 vorhanden.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events And Errors Message Center: Basic Search.

 

Lösungsversuch:

Unter EventID.Net

und Ereigniskennung 11 im Systemprotokoll von Domänencontrollern habe ich herausgefunden, warum dieser Fehler kommt und wie man ihn theoretisch beseitigt.

1. Zuerst herausfinden, welches Konto einen SPN zuviel hat

2. SPN löschen

 

Für erstens habe ich gleich zwei Methoden probiert. Von der Evenid-Seite die von Brent Hudson und von der MS-Seite die Methode drei (cscript spnquery.vbs HOST/mycomputer* >check_SPN.txt). Heraus kam bei beiden (mit leichten Unterschieden in der Formulierung):

 

CN=SERVER2,OU=Server,DC=domain,DC=net

Class: computer

Computer DNS: server2.domain.net

-- MSSQLSvc/server2.domain.net:1433

-- HOST/server2.domain.net/INTERN

-- HOST/SERVER2

-- HOST/server2.domain.net

-- HOST/server2.domain.net/domain.net

-- NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/server2.domain.net

 

CN=dienste,CN=Users,DC=domain,DC=net

Class: user

User Logon: dienste

-- MSSQLSvc/server5.domain.net:1433

-- MSSQLSvc/server2.domain.net:1433

 

(Server5 ist hier der neue SQL-Server)

 

Mein eigentliches Problem:

Ich habe nun schwierigkeiten, den richtigen Eintrag zu identifizieren. Woran erkenne ich denn in der oben Ausgabe von spnquery.vbs das Lokale Systemkonto? Dort müßte sich ja der überflüssige SPN befinden. Und wie bekomme ich den gelöscht? Ich habe mit ADSIEDIT.msc schon rauf und runter gesucht. Ich kann um's verrecken nicht die richtigen Einträge finden. Dummer Weise hat das Tool auch keine Suchfunktion. Kann mir da jemand ein paar entscheidende Tipps geben?

 

MfG Andreas

[Andreas_Z 10]

Tja. Offensichtlich kennt auch hier keiner ADSIEDIT. Schade. Ich habe das Problem jetzt zwar selbst gelöst. Aber leider nicht so, wie es ursprünglich wollte. Mein SQL-Server läuft jetzt wieder mit dem lokalen Systemkonto. Den SPN für das Dienste-Konto habe ich dann mit SETSPN -D entfernt. Der war ja eindeutig zu erkennen. Falls doch noch jemand Tipps zum Umgang mit ADSIEDIT anbieten kann, bin sehr interessiert.

 

MfG Andreas Zettl

[Gulp 226]

Ich weiss ja nicht warum der SQL Server unbedingt ein DC sein muss (auch Microsoft empfiehlt das nicht), aber gut.

 

Selbst als Mitgliedsserver muss das Dienstkonto funktionieren, solange es ein Domänenaccount ist (muss es auch hier sein, ein DC hat nämlich gar keine lokale Kontendatenbank mehr).

 

Mir scheint, Du hast den Server auch aus der Domäne genommen, jedenfalls wenn das Dienstkonto nicht mehr funktionierte. Dass dann solche Meldungen auftauchen ist nicht verwunderlich. Da hilft ADSIEDIT auch nicht wirklich weiter, da es nicht die Ursache behebt.

 

Grüsse

 

Gulp

[Andreas_Z 10]

Ne, ne. Nicht falsch verstehen. Der Server ist definiv noch Mitgliedsserver. dcpromo ist sauber durchgelaufen. Damit wurden dann auf dem Server die lokale Benutzerdatenbank und die lokalen Sicherheitsrichtlinien aktiv. In desen Richtlinien hatte das Dienstekonto der Domäne kein Recht zum starten als Dienst. Das ist doch ganz normal so. Ich hab's korrigert und gut. Das hatte ich ja auch oben versucht, klar zu machen. Ich habe das alles aufgeschrieben, damit ihr versteht, warum es zu dieser Situation gekommen ist. Im Normalfall hätte ich die oben zitierte Ereignislog-Meldung nicht erhalten. Ich habe eben nur den Fehler gemacht und den SQl_Server als lokales System gestartet. Damit hat er dann gleich mal das AD entsprechend ergänzt aber den alten SPN-Eintrag nicht entfernt. Das mußte ich jetzt eben von Hand nachholen. Aber genau das ist ja mein Problem. Auf den verschiedenen Seiten, die ich zur Lösung des Problems gelesen habe (siehe oben und noch einige mehr), wurde immer wieder ADSIEDIT erwähnt. Leider wurde aber an keiner Stelle erläutert, wo man die zu löschenden Einträge findet.

 

Oder anders gesagt, die Ursache weiß ich, den Lösungsweg auch, nur mit dem Tool zur Problembeseitigung habe ich noch Verständnisschwierigkeiten.

 

Eine Lösung mit setspn habe ich ja gefunden und erfolgreich angewendet. Da mir aber niemand erklären konnte, wo in sich der Ausgabe:

 

CN=SERVER2,OU=Server,DC=domain,DC=net

Class: computer

Computer DNS: server2.domain.net

-- MSSQLSvc/server2.domain.net:1433

-- HOST/server2.domain.net/INTERN

-- HOST/SERVER2

-- HOST/server2.domain.net

-- HOST/server2.domain.net/domain.net

-- NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/server2.domain.net

 

das lokale Systemkonto versteckt, mußte ich leider doch den SPN vom Dienstekonto erntfernen. Das geht auch, ist aber nicht das, was ich wollte. Ich bin also weiter an Tipps interessiert.

 

MfG Andreas

[ufu 10]

Hi Andreas,

 

 

habe gerade ein aehnliches Problem. und ich versuche noch immer zu verstehen, was hinter dem ganzen steckt ;)

 

Bei mir:

Die kollegen der Fachabteilung stellten die Anmeldungen auf den SQLServern um (von lokalem Systemkonto auf einen richtigen User)

Dadurch erhielt ich ebenfalls die Meldung, die Du auch erhalten hast.

Lediglich meine Ausgabe des Scripts, welches du hier genannt hast, spuckte mir den genannten host aus aber mit 2 verschiedenen logins...also CLASS USER.

DAs war dann einfacher. Mit ADSIEDit den User suchen, der definitiv nicht mehr die Anmeldung der SQLDienste inne hat und in dessen Eigenschaften das Attribut serviecPrincipalName suchen und den genannten Host loeschen.

Denke das war es, da doppelt.

 

 

.... Da mir aber niemand erklären konnte, wo in sich der Ausgabe:

 

CN=SERVER2,OU=Server,DC=domain,DC=net

Class: computer

Computer DNS: server2.domain.net

-- MSSQLSvc/server2.domain.net:1433

-- HOST/server2.domain.net/INTERN

-- HOST/SERVER2

-- HOST/server2.domain.net

-- HOST/server2.domain.net/domain.net

-- NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/server2.domain.net

 

das lokale Systemkonto versteckt, mußte ich leider doch den SPN vom Dienstekonto erntfernen. Das geht auch, ist aber nicht das, was ich wollte. Ich bin also weiter an Tipps interessiert.

 

 

DAs Lokale Systemkonto muesste doch CLASS: USER sein, oder nicht !?

den Abschnitt, den Du hier gepostet hast, ist doch Class:Computer

 

CN=dienste,CN=Users,DC=domain,DC=net
Class: user
User Logon: dienste
-- MSSQLSvc/server5.domain.net:1433
-- MSSQLSvc/server2.domain.net:1433

 

so...wenn ich das nun einigermassen gerafft habe, dann hast du einen User Namens DIENSTE.

Dieser Startet die SQLServices sowohl auf Server 2 als auch auf Server 5, richtig ?

so..und diesen Eintrag:

-- MSSQLSvc/server2.domain.net:1433

hast du sowohl beim User DIENSTE als auch beim Computer Server2

 

Einer davon war nun zuviel, richtig ?

 

Also...nur mal, damit hier keine Missverstaendnisse aufkommen: ich kann hier keine loesung bieten, moechte aber einigermassen verstehen, was wir hier machen ;-)

 

Gruss

ufu

[ufu 10]

hmm...

 

also bei mir sind heute diese eintraege verschwunden.

JETZT wuerd ichs nur gerne verstehen, wo sowas her kommt ?!?!

 

ufu