phatair 39 Geschrieben 13. November Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
Beste Lösung MurdocX 950 Geschrieben 13. November Beste Lösung Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 13. November Autor Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
MurdocX 950 Geschrieben 13. November Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 13. November Autor Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
MurdocX 950 Geschrieben 13. November Melden Teilen Geschrieben 13. November Danke, das wünsche ich Dir auch 👋 Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 13. November Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
daabm 1.354 Geschrieben 13. November Melden Teilen Geschrieben 13. November 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 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 14. November Autor Melden Teilen Geschrieben 14. November 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 Zitieren Link zu diesem Kommentar
daabm 1.354 Geschrieben 14. November Melden Teilen Geschrieben 14. November 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 Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 15. November Autor Melden Teilen Geschrieben 15. November 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 Zitieren Link zu diesem Kommentar
daabm 1.354 Geschrieben 15. November Melden Teilen Geschrieben 15. November (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 von daabm 1 Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 15. November Melden Teilen Geschrieben 15. November vor 2 Stunden schrieb daabm: Aber wir schweifen ab Das macht doch nix. ;) Zitieren Link zu diesem Kommentar
phatair 39 Geschrieben 18. November Autor Melden Teilen Geschrieben 18. November 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? Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 18. November Melden Teilen Geschrieben 18. November 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 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.