pharaun
Goto Top

Drucker vom Printserver an nicht Domänenclient verbinden: keine ausreichenden Zugriffsrechte

Hallo zusammen,

wir haben bei einem Kunden die Situation, dass wir Drucker welche am Domänenprintserver eingerichtet sind, auch an Clients verbunden werden sollen welche nicht Mitglied der Domäne sind.

Leider bekommen wir es nicht hin, dass dies funktioniert.
Es kommt immer die Fehlermeldung "Die angegebenen Anmeldeinformationen beinhalten keine ausreichenden Zugriffsrechte auf den Drucker. Sollen neuen Anmeldeinformationen angegeben werden".

Am Printserver selbst haben wir die Rechte schon angepasst, sodass das "Jeder" auf den Drucker "drucken" darf.

Versucht haben wir die Verbindung mit einem User, welcher Rechte auf den Drucker hat, und mit dem Domänenadmin.

Der Printserver läuft auf Windows Server 2022 und der Testclient mit Windows 11, frisch installiert diese Woche.

Habt ihr noch Ideen was man tun könnte oder woran es liegen könnte?

Vielen Dank vorab!

LG

Content-ID: 7736516545

Url: https://administrator.de/forum/drucker-vom-printserver-an-nicht-domaenenclient-verbinden-keine-ausreichenden-zugriffsrechte-7736516545.html

Ausgedruckt am: 22.12.2024 um 05:12 Uhr

chiefteddy
chiefteddy 04.07.2023 um 12:00:37 Uhr
Goto Top
Warum geht ihr über den Print-Server? Drucker lokal direkt einrichten.

Jürgen
Pharaun
Pharaun 04.07.2023 um 12:17:47 Uhr
Goto Top
Weil das zum Einem mehr Aufwand ist und zum anderen auch schlicht und ergreifend die Druckereinstellungen und Treiber vom Printserver genommen werden sollen.

Das es lokal gehen würde steht außer Frage, das ist hier ja aber auch nicht gefragt.
lcer00
lcer00 04.07.2023 um 13:33:38 Uhr
Goto Top
Hallo,

der Client muss auf SMB-Freigaben der Domäne zugreifen, um z.B. die Druckertreiber zu laden. Daher:

Am besten Ihr nehmt den Client in die Domäne auf. So ist es gedacht.

Grüße

lcer
Pharaun
Pharaun 04.07.2023 um 13:43:00 Uhr
Goto Top
Zitat von @lcer00:

Hallo,

der Client muss auf SMB-Freigaben der Domäne zugreifen, um z.B. die Druckertreiber zu laden. Daher:

Am besten Ihr nehmt den Client in die Domäne auf. So ist es gedacht.

Grüße

lcer

Das der Client auf die SMB Freigabe Zugriff braucht, ist ein guter Hinweis. Wird der Zugriff auf diese Freigabe dann effektiv nicht mit abgefragten Credentials beim Verbinden des Druckers versucht?

Das wir den Client in die Domäne aufnehmen ist keine Option. Ist nicht vereinbar mit den Richtlinien des Unternehmens.
lcer00
lcer00 04.07.2023 um 14:22:10 Uhr
Goto Top
Zitat von @Pharaun:

Zitat von @lcer00:

Hallo,

der Client muss auf SMB-Freigaben der Domäne zugreifen, um z.B. die Druckertreiber zu laden. Daher:

Am besten Ihr nehmt den Client in die Domäne auf. So ist es gedacht.

Grüße

lcer

Das der Client auf die SMB Freigabe Zugriff braucht, ist ein guter Hinweis. Wird der Zugriff auf diese Freigabe dann effektiv nicht mit abgefragten Credentials beim Verbinden des Druckers versucht?
Nicht, wenn die Domäne es nicht zuläßt.

Das wir den Client in die Domäne aufnehmen ist keine Option. Ist nicht vereinbar mit den Richtlinien des Unternehmens.
Toller Spruch, aber Schrott. Ohne Domäne (mit NTLM) ist unsicherer als mit Domäne (Kerberos). Wer "Richtlinien" zur IT-Sicherheit aufstellt macht nicht solchen Schrott. Mal ehrlich, mit welcher Intention betreibt man heute im Unternehmen ein Windows-Netzwerk ohne Domäne? Vermutlich weil man kein Geld ausgeben will. Aber ohne Geld gehen manche Dinge eben nicht, zum Beispiel eine zentrale Druckerverwaltung.

Grüße

lcer
chiefteddy
chiefteddy 04.07.2023 um 14:56:25 Uhr
Goto Top
Hallo @Pharaun,

liest du eigentlich, was du schreibst?

Da macht jemand ein Sicherheitskonzept für eure IT, implementiert einen Verzeichnisdienst (M$ AD), der User, Ressourcen, Geräte und die Rechte zwischen ihnen verwaltet. Sichert das ganze gegen unautorisierte Fremdzugriffe ab.

Und dann kommt ihr und wollt mit fremden Geräten in diesen Sicherheitsbereich eindringen. Dann wundert ihr euch auch noch, dass das nicht gewollt ist und technisch verhindert wird.

Gibt es einen plausiblen Grund, warum die Rechner, die die Domänen-Drucker nutzen sollen, nicht Mitglied der Domäne sein können? Oder einer Sub-Domäne mit Sicherheitsgleichstellung oder, oder, oder.

Jürgen
emeriks
Lösung emeriks 04.07.2023 aktualisiert um 15:00:10 Uhr
Goto Top
Hi,
Zitat von @Pharaun:
Am Printserver selbst haben wir die Rechte schon angepasst, sodass das "Jeder" auf den Drucker "drucken" darf.
"Jeder" ist nicht jeder.

Auf einem Windows Computer gehört jedes bekannte Konto zu "Jeder". Bekannt sind aber nur lokale Konten oder die der eigenen Domäne. Wenn da ein Zugriff von einem Standalone-Computer oder einem, welcher zu einer anderen, nicht vetrauten Domäne gehört, erfolgt, dann ist das in diesem Sinne nicht "Jeder".
Also:
  1. mit einem lokalen Konto des Printservers an einer Freigabe des Servers anmelden
  2. oder mit einem Domänen-Konto an einer Freigabe des Servers anmelden
Danach hat man eine SMB-Sitzung am Server und kann auch Drucker verbinden.


z.B.
net use \\Printserver\freigegebenerDrucker /user:domäne\benutzername /persisten:yes
start \\Printserver\freigegebenerDrucker

Erster Befehl fragt nach dem Passwort.
Zweiter Befehl startet das Verbinden des Druckers.

Oder:
Vor dem Verbinden das Passwort mit CMDKEY ablegen

cmdkey /add:Printserver /user:domäne\benutzername /pass:Passwort

E.
Pharaun
Pharaun 04.07.2023 um 20:59:40 Uhr
Goto Top
Zitat von @lcer00:

Toller Spruch, aber Schrott. Ohne Domäne (mit NTLM) ist unsicherer als mit Domäne (Kerberos). Wer "Richtlinien" zur IT-Sicherheit aufstellt macht nicht solchen Schrott. Mal ehrlich, mit welcher Intention betreibt man heute im Unternehmen ein Windows-Netzwerk ohne Domäne? Vermutlich weil man kein Geld ausgeben will. Aber ohne Geld gehen manche Dinge eben nicht, zum Beispiel eine zentrale Druckerverwaltung.

Grüße

lcer


Zitat von @chiefteddy:

Hallo @Pharaun,

liest du eigentlich, was du schreibst?

Da macht jemand ein Sicherheitskonzept für eure IT, implementiert einen Verzeichnisdienst (M$ AD), der User, Ressourcen, Geräte und die Rechte zwischen ihnen verwaltet. Sichert das ganze gegen unautorisierte Fremdzugriffe ab.

Und dann kommt ihr und wollt mit fremden Geräten in diesen Sicherheitsbereich eindringen. Dann wundert ihr euch auch noch, dass das nicht gewollt ist und technisch verhindert wird.

Gibt es einen plausiblen Grund, warum die Rechner, die die Domänen-Drucker nutzen sollen, nicht Mitglied der Domäne sein können? Oder einer Sub-Domäne mit Sicherheitsgleichstellung oder, oder, oder.

Jürgen

Ja es gibt einen plausiblen Grund dafür.

Es geht hier weder um Geld noch darum, was ihr für Sinnvoll haltet. Das Unternehmen befindet sich schlicht und ergreifend in einer Migration zum globalen Konzern und dieser lässt es eben nicht zu, die von Ihnen per Autopilot verwalteten Geräte in die lokale (alte, vorhandene) Domäne, welche eben nicht vom Konzern ist, aufzunehmen. Eben gerade weil Sie hier Ihre eigenen Sicherheitstandard durchsetzen möchten.
An dieser Tatsache kann weder Ich, noch meine Firma, noch mein Kunde selbst etwas ändern. Punkt.

Desweiteren wird sich der Zeitraum der Übergangszeit vermutlich auf 9-15 Monate erstrecken, wieso hier alle einfach eine vernünftige Zwischenlösung brauchen/wünschen.

Sinnvoll oder nicht spielt doch hier auch keine Rolle.
Desweiteren war meine Frage doch wohl ziemlich klar definiert, spätestens in meiner 2. Antwort hier. Also tut mir und auch allen anderen, die eine vernünftige Anfrage stellen, einen gefallen und lasst dann lieber so sinnfreie Antworten wenn sie zum eigentlichen Problem nichts beitragen.

@emeriks
Danke für deine Antwort, ich werde dies morgen testen. Klingt plausibel.
dertowa
dertowa 04.07.2023 aktualisiert um 21:12:50 Uhr
Goto Top
Zitat von @lcer00:
Am besten Ihr nehmt den Client in die Domäne auf. So ist es gedacht.

Naja... vielleicht war das mal so gedacht.
Microsoft verfolgt doch mit der Cloudstrategie eine ganz eigene Philosophie der eigenen Berechtigungen.

Daher, der Client muss nicht Mitglied der Domäne sein, es genügt, wenn der Benutzer in der Domain bekannt ist und vom Domaincontroller entsprechend ein Ticket erhalten kann.
So wird es auch mit den Systemen gemacht, welche nur ans AzureAD angebunden sind, aber dennoch lokal auf Ressourcen zugreifen sollen.

Hier geht leider nicht hervor, ob die Benutzer in der Domain bekannt sind, daher stelle ich das hier einfach mal zur Information.

Grüße
ToWa