phatair 47 Geschrieben 13. November 2024 Melden Geschrieben 13. November 2024 Hallo zusammen,  ich habe folgends Problem bzw. verstehe das Verhalten nicht so ganz. Wir haben bei einigen Windows Server 2019 Servern den SPN ĂŒber den Netdom Befehl eingetragen.  Das Auslesen des SPN ĂŒber "netdom computername <server name> /enum" funktioniert dann manchmal mit dem DomĂ€nen Administrator und manchmal mit unseren "Server Admins". Die Fehlermeldung lautet dann einfach nur "Zugriff verweigert". Ein wirkliches Muster habe ich noch nicht rausgefunden. Beide User haben auf das Attribut "msDS-AdditionalDnsHostName" Leserechte.  Soweit ich das verstehe, sollte das doch ausreichen um mit dem oben genannten Befehl den SPN auszulesen. Schreibrechte auf das Attribut brauche ich ja nur, wenn ich den SPN mit dem User setzen will. Aber auch das Rechte hĂ€tte der User.  Oder was fĂŒr Voraussetzungen mĂŒssen noch gegeben sein, damit man den SPN auslesen kann?  Vielen Dank GrĂŒĂe
Beste Lösung MurdocX 1.039 Geschrieben 13. November 2024 Beste Lösung Melden Geschrieben 13. November 2024 vor 22 Minuten schrieb phatair: Oder was fĂŒr Voraussetzungen mĂŒssen noch gegeben sein, damit man den SPN auslesen kann? Das richtige Tool nutzen  Probiere es mal mit dem Tool fĂŒr SPN -> setspn.exe setspn.exe -L home-srvmgmt01  1
phatair 47 Geschrieben 13. November 2024 Autor Melden Geschrieben 13. November 2024 Hi Jan,  ha...das ist ja faszinierend. Damit funktioniert es. Das heiĂt dann wohl auch, dass wir setspn auch zum setzen der SPNs nehmen sollten und nicht mehr netdom, oder?  Wenn ich es richtig sehe, ist netdom dann die "alte" Variante? Ich war einfach nur verwundert, da das setzen der SPN bisher damit immer gut funktioniert hat. Nur beim auslesen ist nun aufgefallen, dass es bei unterschiedlichen Usern plötzlich Probleme gab (obwohl deren Berechtigung auf die AD Objekte identisch waren).  GruĂ, SteffenÂ
MurdocX 1.039 Geschrieben 13. November 2024 Melden Geschrieben 13. November 2024 vor 14 Minuten schrieb phatair: Das heiĂt dann wohl auch, dass wir setspn auch zum setzen der SPNs nehmen sollten und nicht mehr netdom, oder? Genau đ HĂ€ndisch im AD geht auch.  vor 15 Minuten schrieb phatair: Wenn ich es richtig sehe, ist netdom dann die "alte" Variante? SetSPN gibts schon eine Ewigkeit. Ich vermute schon lĂ€nger als 20 Jahre. Daher beantworte ich das mal mit "nein" ;) 1
phatair 47 Geschrieben 13. November 2024 Autor Melden Geschrieben 13. November 2024 Top, danke dir. Dann werden wir in Zukunft SetSPN verwenden und nicht mehr netdom. Mich wundert es zwar immer noch, warum es bei netdom den "Zugriff verweigert" Fehler gibt, aber mir fehlt die Zeit das jetzt zu klÀren :) Das die Berechtigungen passen, sieht man ja eigentlich am funktionierenden SetSPN Befehl.  Schönen Abend Dir. 1
MurdocX 1.039 Geschrieben 13. November 2024 Melden Geschrieben 13. November 2024 Danke, das wĂŒnsche ich Dir auch đ
NilsK 3.109 Geschrieben 13. November 2024 Melden Geschrieben 13. November 2024 Moin,  Nur weil das Tool behauptet, dass der Zugriff verweigert wurde, muss das ja nicht stimmen. Vielleicht versucht es den Zugriff auch nur auf einem Weg, der nicht funktioniert, fĂ€ngt diesen Fehler aber nicht adĂ€quat ab.  GruĂ, Nils 1
daabm 1.465 Geschrieben 13. November 2024 Melden Geschrieben 13. November 2024 netdom verwendet AFAIK den WinNT-Provider (wuĂte bisher auch nicht, daĂ das SPNs setzen kann?!?), SetSPN verwendet ADSI. So gesehen stimmt "netdom ist die alte Variante". Sollte aber nur eine Rolle spielen, wenn irgendwas mit dem Builtin-Container in AD gemacht wurde. Â Frau kann auch einfach direkt das Attribut servicePrincipalName bearbeiten mit LDAP-Mitteln ihrer Wahl (System.DirectoryServices, Powershell Set-ADObject/Set-ADComputer, dsmod.exe, csvde.exe, ldifde.exe usw... ) 1
phatair 47 Geschrieben 14. November 2024 Autor Melden Geschrieben 14. November 2024 Vielen Dank Martin.  Ich habe jetzt auch rausgefunden woran es liegt, dass ich mit dem DomĂ€nen Admin "Zugriff verweigert" beim abrufen der SPNs mit dem NetDom Befehl erhalte.  Bei uns sind die DomĂ€nen Admin Accounts auf den Servern und Clients aus der "Administratoren Gruppe" entfernt. Der NetDom Befel benötigt aber wohl die administrativen Rechte um den SPN auszulesen, da ich ja remote auf den Server zugreifen wĂŒrde (meine Vermutung). Wenn ich den DomĂ€nen Admin in die "Administratoren Gruppe" aufnehme, funktioniert auch der NetDom Befehl.  Wenn ich es also richtig sehe, dann fragt der setspn Befehl die Infos direkt aus dem AD Objekt ab, der netdom Befehl fragt diese dann wohl vom Server direkt ab. Das ist wahrscheinlich die Info vom Martin, dass Netdom WinNET-Provider nutzt und SetSPN ADSI nutzt.  Ich dachte auch immer, dass beim SPN setzen auch lokal auf der Maschine was verĂ€ndert werden muss und das mit dem netdom Befehl automatisch durchgefĂŒhrt wird. Die Info hatte ich hier gefunden: https://woshub.com/add-alternate-computer-name-windows/ Zitat The netdom command will register a CNAME record in DNS, add the new name to the AlternateComputerNames registry parameter (described below), and update the value of the servicePrincipalName and msDS-AdditionalDnsHostName attributes for the computer account in AD.  Macht das der setspn auch oder setzt der nur den Wert im AD Objekt und ich mĂŒsste den registry parameter dann manuell auf dem entsprechenden Server setzen?  GrĂŒĂe
daabm 1.465 Geschrieben 14. November 2024 Melden Geschrieben 14. November 2024 SetSPN macht nur AD, nichts mit DNS oder gar Registry. Ist i.d.R. auch nicht erforderlich, das ist alles altes KompatibilitĂ€tsgeraffel Um AlternateComputerNames in der Registry zu setzen, wirst Du wohl Adminrechte brauchen. Aber wie gesagt, ich wĂŒsste nicht wozu. Aber wieder was gelernt und ein Grund mehr, einen Bogen um netdom.exe zu machen. Ich hasse so "kombinierte" Tools, die an 4 Stellen gleichzeitig rumschrauben... 1
phatair 47 Geschrieben 15. November 2024 Autor Melden Geschrieben 15. November 2024 Hi Martin,  danke dIr! Dann nutzen wir ab sofort auch nur noch SetSPN. Soweit ich das verstanden haben, nutzt man die SPNs ja auch nur wegen der Kerberos Authentifizierung und da reicht es ja, wenn in der AD die EintrĂ€ge gesetzt werden. GruĂ, SteffenÂ
daabm 1.465 Geschrieben 15. November 2024 Melden Geschrieben 15. November 2024 (bearbeitet) Ich verwende noch nicht mal setspn - das ist nĂ€mlich grenzenlos unfĂ€hig, wenn es ĂŒber Forestgrenzen hinweg geht. Du kannst den Inhalt von servicePrincipalName auch "einfach so" direkt schreiben, und das geht dann immer und gegen jedes System, gegen das Du Dich authentifizieren kannst: Set-ADxyz <AccountName> -add @{ servicePrincipalName = 'HTTP/Tresor.Raffgier.com' } -Server 'Bank.Raffgier.com' ADxyz kann dabei ADServiceAccount, ADComputer, ADUser, ADObject sein. Aber wir schweifen ab bearbeitet 15. November 2024 von daabm 1
NorbertFe 2.375 Geschrieben 15. November 2024 Melden Geschrieben 15. November 2024 vor 2 Stunden schrieb daabm: Aber wir schweifen ab Das macht doch nix. ;)
phatair 47 Geschrieben 18. November 2024 Autor Melden Geschrieben 18. November 2024 Das mit Set-ADxyz ist natĂŒrlich der einfachste Weg, dass stimmt. Ich dachte immer, dass man die speziellen Tools wie netdom oder eben SetSPN dafĂŒr nutzen muss, da man sonst mehrere manuelle Schritte durchfĂŒhren muss. Aber dann schaue ich mir Set-AD mal an. Â Wenn wir jetzt bei dem Thema schon sind, vielleicht kann mir jemand die Frage auch beantworten :) Ich muss ja dann eine "Service class" mitgeben. Hier steht ja z.b. dann HOST/ oder RestrictedKrbHost/ mit dabei. Wir setzen den SPN vor allem fĂŒr Webservcies oder SMB Shares. Da reicht dann ja ein HOST oder irre ich mich da?
Dukel 468 Geschrieben 18. November 2024 Melden Geschrieben 18. November 2024 HOST wird normalerweise automatisch vergeben. Das braucht man dann nur wenn man einen Alias vergibt. Â FĂŒr Webdieste ist es "HTTP/". MSSQL ist auch so ein Kandidat fĂŒr einen SPN. 1
Empfohlene BeitrÀge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto fĂŒr unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden