03.01.2024, aktualisiert um 11:51:02 Uhr

2454

New-PSDrive zu UNC-Pfad mit alternativen Credentials

Hey zusammen,

Ich bin gerade etwas am Verzweifeln. Leider finde ich auch 100 Beiträge zu dem Thema, nur leider hilft mir keiner davon:
Ich versuche, auf meinem Computer mit PowerShell einen Netzwerkpfad hinzuzufügen. Das funktioniert auch einwandfrei, bis ich versuche, das mit anderen Credentials durchzuführen.

JA, der andere Benutzer hat Berechtigungen, auf den Netzwerkpfad zuzugreifen. Das seltsame ist, wenn ich mich mit dem anderen Benutzer anmelde (am gleichen Computer), dann muss ich ja keine Credentials angeben und alles funktioniert. Jedoch kann ich wiederum hier nicht den Netzwerkpfad mit meinem eigenen Konto einbinden, mit dem ich es zuvor probiert hatte.....

New-PSDrive X FileSystem \\Server\Freigabe\Ordner

Funktioniert bei beiden Benutzern

New-PSDrive X FileSystem \\Server\Freigabe\Ordner -Cred username
New-PSDrive X FileSystem \\Server\Freigabe\Ordner -Cred DOMAIN\username
New-PSDrive X FileSystem \\Server\Freigabe\Ordner -Cred domain.de\username

Das alles gibt mir folgende Fehlermeldung, falls ich den jeweils ANDEREN Benutzernamen angebe (mit eigenen Credentials geht es...?):

New-PSDrive : Das System kann den angegebenen Pfad nicht finden
In Zeile:1 Zeichen:1
+ New-PSDrive X FileSystem '\\Server\Freigabe\Ordner\'  ...  
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (X:PSDriveInfo) [New-PSDrive], Win32Exception
    + FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand

Gibt es dafür irgend eine Sicherheitseinstellung (GPO?) die das verhindert?

Gruß,
Micha

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 73924822237

Url: https://administrator.de/contentid/73924822237

Ausgedruckt am: 24.11.2024 um 10:11 Uhr

16 Kommentare

Neuester Kommentar

Würde denn net use den Pfad verbinden können?

Quote from @8585324113:

Würde denn net use den Pfad verbinden können?

Leider nein, selber Fehler:

net use X: '\\Server\Freigabe\Ordner' /persistent:no /user:username password

Systemfehler 67 aufgetreten.

Der Netzwerkname wurde nicht gefunden.

Leider kenne ich mit aber mit DOS Befehlen nicht wirklich aus :\ Hier bekomme ich auch den Fehler, wenn ich es ohne Credentials probiere, bei PowerShell funktioniert es ja soweit aber wenigstens

Das heißt, dass ein Aufruf im Explorer auch funktioniert, so lange keine abweichenden User-Login-Daten mitgegeben werden?

Wenn du das Laufwerk im Explorer mit dem abweichenden User verbinden willst, passiert was?

Quote from @8585324113:

Das heißt, dass ein Aufruf im Explorer auch funktioniert, so lange keine abweichenden User-Login-Daten mitgegeben werden?

Wenn du das Laufwerk im Explorer mit dem abweichenden User verbinden willst, passiert was?

Kann ich im Explorer irgendwie Credentials direkt angeben? Oder müsste ich mich nun aus der Gruppe mit dem Zugriff entfernen, Neustarten und dann beim Zugriff die Credentials angeben?

Auf Netzlaufwerk verbinden und dann anklicken dass man andere Creds übergeben will.

Windows kann sich immer nur mit einem Satz Credentials an ein und dem selben Server gleichzeitig anmelden, wenn du dich mit unterschiedlichen Credentials gleichzeitig am selben Server anmelden willst musst du unterschiedliche Server-Adressen/Namen verwenden, z.B. IP oder ein CNAME (Achtung an Kerberos denken!). Oder alle Verbindungen/Sessions vorher trennen (net use * /delete | net session * /delete), oder das Kerberos Ticket (klist purge) löschen.

That's by design

pj.

Quote from @8585324113:

Auf Netzlaufwerk verbinden und dann anklicken dass man andere Creds übergeben will.

Leider bekomme ich nun hierfür nicht die Option... Manchmal bekomme ich diese Option, manchmal aber auch nur eine Zugriffsverweigerung, weiß aber nicht wann ich was bekomme :\ (Unabhängig von diesem Problem, wenn ich mich Zuhause über VPN verbinde werde ich nach Credentials gefragt (weil ich nicht in der Domain bin mit dem Laptop?), hier in der Firma bekomme ich aber nur eine Fehlermeldung:

Quote from @10138557388:

Oder alle Verbindungen/Sessions vorher trennen (net use * /delete | net session * /delete), oder das Kerberos Ticket (klist purge) löschen.

Habe ich beides probiert, leider hat hat sich mein Konto trotzdem angemeldet... Habe nun einfach mal mich aus den Gruppen entfernt und neu angemeldet, nun habe ich auch keinen Zugriff mehr auf den geteilten Ordner, nur leider werde ich wie oben beschrieben überhaupt nicht nach Credentials gefragt.

Ich glaube jedes mal, wenn ich mich auf eine neue Freigabe verbinden möchte werde ich nach Credentials gefragt, aber wenn ich schon einmal verbunden war (Neuanmeldung/-start haben nichts gebracht) bekomme ich nur die Fehlermeldung. Angaben ohne gewähr ^^

Ich vermute schon die ganze Zeit, das es ein Berechtigungsproblem ist.

Wie du siehst, sind die Fehlermeldung, auch im englischen, nicht sehr konsistent und passend.

Auch kann es an der Art der Authentisierung liegen. (Verweis auf Kerberos)

Kannst Du die Berechtigungen sicherstellen?

Quote from @8585324113:

Ich vermute schon die ganze Zeit, das es ein Berechtigungsproblem ist.

Wie du siehst, sind die Fehlermeldung, auch im englischen, nicht sehr konsistent und passend.

Auch kann es an der Art der Authentisierung liegen. (Verweis auf Kerberos)

Kannst Du die Berechtigungen sicherstellen?

Leider kenne ich mich da überhaupt nicht aus, wo prüfe ich das am besten? Auf dem TGS Server? Und wenn ja ist das vmtl der Domain Controller?

Kerberos läuft nicht über IP-Adressen deswegen kein Wunder das es da zu einem Fehler kommt.
Nimm für die alternativen Creds statt dem NETBIOSNAME den FQDN .Oder lege einen CNAME an und füge den alternativen Namen per netdom der Maschine hinzu und spreche die Freigabe mit den alternativen Credentials über diesen Namen an.

netdom computername myserver /add:myserver-alternate.example.com

SPNs nicht vergessen.

Kurios, Nach meinem klist purge, net session /DELETE, net use * /DELETE und anschließendem Neustart werde ich zwar im Explorer nicht nach Credentials gefragt, jedoch hat nun der Befehl New-PSDrive funktioniert

Ich habe es noch mit dem FQDN probiert und auch mit einem kompletten Random alternativen Namen, leider bekomme ich hier immer nur die Verweigerung.... Was bei uns (oder bei mir am Rechner) falsch konfiguriert ist, weiß ich nicht, aber immerhin hat das mit dem Mounten des Netzwerkpfades und anderen Credentials nun funkioniert :D

Dann gucke dir die Verbindung jetzt genauer an.

Zitat von @michi.wtr:
und auch mit einem kompletten Random alternativen Namen, leider bekomme ich hier immer nur die Verweigerung....

Ohne diesen Namen am Ziel zu registrieren und dort die SPNs korrekt zu hinterlegen eh sinnlos ... Du solltest dir die Kerberos-Anforderungen nochmal im Detail durchlesen, dann ist auch das kein böhmisches Dorf mehr.
Und die Security-Logs am Server erzählen dir das auch wenn du sie mal durchsiehst.

Quote from @8585324113:

Dann gucke dir die Verbindung jetzt genauer an.

Quote from @10138557388:

Zitat von @michi.wtr:
und auch mit einem kompletten Random alternativen Namen, leider bekomme ich hier immer nur die Verweigerung....

Kann es ein Problem sein, dass wir drei Domänencontroller haben, welche sich synchronisieren? Nun kann ich mich nämlich wieder nicht verbinden, ich habe einmal nach folgender Anleitung versucht:

nltest /dsgetdc:<Domain Name> /force /kdc

Auf Client und Server unterschiedliche Domaincontroller, aber ansonsten alles komplett gleich.

DNS funktioniert mit Ping und nslookup einwandfrei
Die Uhren werden über die Domänencontroller synchronisiert, jedoch ist bei beiden ein anderer Server angegeben. Die Domänencontroller snychronisieren sich jedoch ständig (zumindest was AD und GPO etc. angeht)

Kann das ein Problem sein? Kann mir evtl. noch wer sagen wo ich diese Logs finde? Das war bisher glaube ich noch nicht sehr vielversprechend, was ich hier gefunden habe

An dem SMB Port sollte es glaube ich nicht liege, da es ja zeitweise auch funktioniert. Leider geht es bei mir lokal nun schon wieder nicht, jedoch auf den Terminalservern einwandfrei, ich werde noch einmal klist purge etc. probieren, wenn es danach wieder geht denke ich, werde ich wohl eher bei lokal ein Problem haben?

Zitat von @michi.wtr:

net use X: '\\Server\Freigabe\Ordner' /persistent:no /user:username password

Moin,

u.a. steht dass Passwort an der falschen Stelle

net use X: \\Server\Freigabe\Ordner password /user:username /persistent:no

Zitat von @Kraemer:
Moin,

u.a. steht dass Passwort an der falschen Stelle

net use X: \\Server\Freigabe\Ordner password /user:username /persistent:no

Oh okay, gut zu wissen :D
Leider bekomme ich aber noch dieselbe Fehlermeldung. Ist also wohl dann auf kein Fall ein Berechtigungsproblem sondern tatsächlich findet der Befehl warum auch immer den Pfad im Netzwerk nicht