Frage zum SPN / Netdom Befehl

[phatair 39]

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

[MurdocX 949]

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

 

[phatair 39]

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 949]

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" ;)

[phatair 39]

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.

[MurdocX 949]

Danke, das wünsche ich Dir auch 👋

[NilsK 2.930]

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

[daabm 1.348]

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... )

[phatair 39]

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.348]

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...

[phatair 39]

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.348]

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 Freitag um 19:05 von daabm

[NorbertFe 2.027]

vor 2 Stunden schrieb daabm:

Aber wir schweifen ab

Das macht doch nix. ;)