none
SETSPN RRS feed

  • Frage

  • Hallo an alle,

    ich möchte über setspn mein Kerberos Problem lösen. Jedoch verzweifel ich hier noch!

    Meine Domain heißt test.domain

    Benutzeraccount: testzz

    Domainenname (Prä Windows 2000):

    testdomain

    deswegen schreibe ich wie folgt:

     
    setspn -A MSSQLSvc/myhost.test.domain testdomain.testzz

    Fehlermeldung: 0x21c7/8647

    laut :  https://docs.microsoft.com/de-de/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness

    ist das ein ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FORESTERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST

    aber es gibt das Benutzerkonto testzz nur einmal. Ich versteh das Problem nicht! Ich habe noch ein Benutzerkonto test damit hat es funktioniert!

    Bitte um Hilfe!

    Dienstag, 15. Januar 2019 16:23

Antworten

Alle Antworten

  • Moin, es geht ja nicht darum, dass das Konto nicht eindeutig ist, sondern darum, dass der SPN bereits vergeben ist. SETSPN -X -F ist Dein Freund.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Dienstag, 15. Januar 2019 16:46
  • Hi,
     
    Am 15.01.2019 um 17:46 schrieb Evgenij Smirnov:
    > Moin, es geht ja nicht darum, dass das Konto nicht eindeutig ist, sondern darum,
    > dass der SPN bereits vergeben ist. SETSPN -X -F ist Dein Freund.
     
    Ich hatte die Tage ein Problem, daß SETSPN löschen nicht so trivial war,
    da das Computer Konto nicht "auffindbar" war, zu dem es gehörte, oder so
    ... ich erinnere mich nicht mehr ganz, aber ich habe es dann über ein
    Script lösen können:
     
     
    Tschö
    Mark
     
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Dienstag, 15. Januar 2019 21:29
  • hallo an alle und danke für eure Antworten.

    @Evgenij wenn ich mit SETSPN -X -F nach doppelten Einträgen das AD durchsuche erhalte ich nur:

    0 Gruppe von doppelten SPNs gefunden.

    Das ließt sich so als ob keine doppelten Einträge vorhanden sind.

    Deswegen bin ich noch einmal wie folgt vorgegangen.

    Ich habe geschaut unter welchem Benutzeraccount mein SQL Server läuft. In meiner Testumgebung unter SRV-SQL

    setspn -A MSSQLSvc/sqlserver.test.domain testdomain\srv-sql

    jetzt erhalte ich die Fehlermeldung Unbekannter Parameter: MSSQLSvc/sqlserver.test.domain Überprüfen Sie die Verwendung.

    Was mach ich falsch? Der Name des Servers ist richtig.


    Nachtrag: das Benutzerkonto testdomain\srv-sql habe ich auch schon mit Domain-Admin Rechten versehen um das zu testen. Aber auch das ohne Erfolg. Ich hatte irgendwo mal gelesen das Benutzeraccounts über Domainadmin-Rechten verfügen müssen.
    Mittwoch, 16. Januar 2019 15:37
  • Am 16.01.2019 schrieb Toot_Braunstein:

    setspn -A MSSQLSvc/sqlserver.test.domain testdomain\srv-sql

    jetzt erhalte ich die Fehlermeldung Unbekannter Parameter: MSSQLSvc/sqlserver.test.domain Überprüfen Sie die Verwendung.



    Was mach ich falsch? Der Name des Servers ist richtig.

    Tausche den / gegen einen \ dann sollte es funktionieren.

    Servus
    Winfried


    WSUS Package Publisher:
    https://github.com/DCourtel/Wsus_Package_Publisher
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren:
    https://github.com/JochenKalmbach/communitybridge
    GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

    Mittwoch, 16. Januar 2019 17:06
  • Moin, das mit den Adminrechten ist definitiv nicht erforderlich. Ob der Servername exist, spielt keine Rolle. Man sollte -S statt -A benutzen, denn damit werden Duplikate geprüft. Versuch mal den User ohne Domäne zu schreiben

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Mittwoch, 16. Januar 2019 17:17
  • Hier nochmal zur Illustration: 

    Der User ist ein frisch angelegter Normaluser, den Server und sogar die Domäne zum SPN gibt es gar nicht.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Mittwoch, 16. Januar 2019 19:18
  • Hallo an alle,

    das scheint wieder nicht ganz so trivial zu werden.

    Folgendes habe ich getestet:

    Wenn ich wie Evgenij vorgeschlagen hat das ganze mit -S versuche erhalte ich eine Fehlermeldung

    "Doppelte SPN gefunden, Vorgang wird abgebrochen"

    Nachtrag:

    Im AD unter Attribur-Editor -> servicePrincipalName ist auch kein passender Eintrag zu finden.

    Auch mit setspn -l und dem passenden Server ist kein Eintrag zu finden.

    Wenn ich es mit -A mache dann erhalte ich den Fehler "0x21c7/8647"

    Um zu prüfen ob es nun doch doppelte Einträge gibt habe ich setspn -x -f ausgeführt und erhalte erneut

    "Eintrag 5 wird verarbeitet. 0 Gruppe von doppelten SPNs gefunden."

    Warum das richtige Skript nicht mehr funktionier hat lag daran das ich cmd unter einen bestimmten Benutzer ausgeführt habe. So stand im cmd stets C:\User\......  und das funktioniert nicht. Mit C:\Windows\system32 .... funktioniert das abrufen. Im Eifer des Gefechts ist mir dies einfach nicht aufgefallen.


    Donnerstag, 17. Januar 2019 10:55
  • Hallo an alle,

    ich habe nun festgestellt das ich für einen Server mehrere Einträge habe. Einmal den normalen Eintrag ohne Portangabe am Ende und einmal mit Port 1433 jedoch wir bei beiden Einträgen kein User mit angezeigt. 

    Wie kann ich die zwei Einträge jetzt löschen und warum stehen die nicht im AD unter Attribut-Editor? 

    Donnerstag, 17. Januar 2019 20:13
  • Wie genau hast Du es denn festgestellt?

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 17. Januar 2019 20:22
  • ich komme heute nicht mehr auf das System aber wenn ich mich recht erinnere habe ich die Abfrage setspn -q  ausgewählt. 

    ich poste hier morgen noch mal das Ergebnis der Abfrage. aber wie gesagt es stand kein Benutzeraccount dabei und es gibt kein Eintrag ins AD was mich arg wundert. 

    Donnerstag, 17. Januar 2019 20:46
  • Ich habe gestern noch den Testserver von mir mit setspn -q MSSQLSvc/sqlserver.test.Domain abgefragt.

    Als Ergebnis bekomme ich 2 Einträge:

                          MSSQLSvc/SQLSERVER.test.domain:1433

                          MSSQLSvc/SQLSERVER.test.domain

    Dazu erhalte ich noch die Meldung "Bestehender SPN gefunden"

    Deswegen habe ich mir im AD zu dem betroffenen Computer die Werte im Attribut-Editor angeschaut. Unter servicePrincipalName steht folgendes:

    HOST/SQLSERVER

    HOST/SQLSERVER.test.domain

    RestrictedKrbHost/SQLSERVER

    RestrictedKrbHost/SQLSERVER.test.domain

    TERMSRV/SQLSERVER

    TERMSRV/SQLSERVER.test.domain

    WSMAN/SQLSERVER

    WSMAN/SQLSERVER.test.domain

    Hier sind aus meiner Sicht auch doppelte Einträge vorhanden oder sehe ich das falsch?

    Wenn ja wie kann ich diese jetzt löschen und viel wichtiger ist die Frage welcher Eintrag ist der Richtige?

    Abschließend die alles entscheidende Frage! Warum wird der SQL Server nicht aufgelistet!?

    Freitag, 18. Januar 2019 06:12
  • Abschließend die alles entscheidende Frage! Warum wird der SQL Server nicht aufgelistet!?

    Weil der SPN nicht am Computer-Objekt hängt, sondern an einem anderen. Das ist ja schließlich auch das, was Du selber machen solltest.

    Nimm doch das Skript, zu dem Mark verlinkt hat, das sollte Dir das Objekt auswerfen, an dem die SPN hängt.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.


    Freitag, 18. Januar 2019 06:56
  • dsquery * -filter "(serviceprincipalname=*sqlserver.test.domain*)"

    :-)


    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq


    Freitag, 18. Januar 2019 07:18
  • dsquery * -filter "(userprincipalname=*sqlserver.test.domain*)"

    ...oder eher

    dsquery * -filter "(serviceprincipalname=*sqlserver.test.domain*)"

    ;-)


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 18. Januar 2019 07:40
  • Steht doch oben - wo kommt Dein Zitat her? :-P

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Freitag, 18. Januar 2019 07:48
  • So meine Damen und meine Herren,

    nach langen suchen habe ich tatsächlich einen Benutzeraccount gefunden der den SPN schon gesetzt hatte! Vielen Dank an alle die geholfen haben!

    nun hätte ich aber noch ein paar Verständnisfragen:

    Ich habe nun an einen Benutzeraccount nun den SPN gesetzt und dieser wird auch im Attribut-Editor im AD angezeigt.

    Muss ich jetzt am SQL Server auch noch einen SPN setzen und was ist jetzt wenn ein anderer Server auf den SQL Server zugreifen will?

    Freitag, 18. Januar 2019 11:36
  • Moin,

    der Benutzer, der MSSQLSvc-SPNs trägt, muss derjenige sein, in dessen Context der SQL Server-Dienst gestartet wird. Wird der Dienst als SYSTEM oder NTService gestartet, muss das Computerobjekt des Servers die SPNs tragen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 18. Januar 2019 12:33
  • Ok! danke für deine Antwort @Evgenij. Ich habe viele Server (Computerobjekt im AD) gesehen die Unterschiedliche Einträge schon aufweisen. 

    wie zb. 

    HOST/SQLSERVER

    HOST/SQLSERVER.test.domain

    RestrictedKrbHost/SQLSERVER

    RestrictedKrbHost/SQLSERVER.test.domain

    TERMSRV/SQLSERVER

    TERMSRV/SQLSERVER.test.domain

    WSMAN/SQLSERVER

    WSMAN/SQLSERVER.test.domain

    die wären dann ja überflüssig richtig?

    Samstag, 19. Januar 2019 20:49
  • die wären dann ja überflüssig richtig?


    Nein. Da ist halt für diesen Dienst das Maschinen-Account für Kerberos zuständig. Die von Dir angesprochenen Dienste können ja auch schwer unter einem separaten Service Account laufen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Sonntag, 20. Januar 2019 01:03