28
Nach erster Reaktion gegen Print Nightmare keine GPO basierten Druckermappings mehr möglich
Hallo zusammen,
Als Reaktion auf die am vergangenen Donnerstag veröffentliche Sicherheitslücke "Print Nightmare" wurden meinerseits folgende Maßnahme ergriffen:
Nach Vorbild von diesem Artikel:
https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675 ...
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Druckermapping via GPO funktionieren nicht mehr - Problematisch.
Die logische Gegenmaßnahme war dann, die GPO "umzukehren" und dem System User den Zugriff auf den Ordner wieder zu gewähren.
Böses Erwachen: Dadurch wurde keine Besserung erzielt.
Nach vielem hin und her scheint es so zu sein, dass sich die Treiber zerschießen und oder die Berechtigung auf den Pfad "C:\Windows\System32\spool\drivers" korrupt sind.
Ich habe es nach vielen Anpassungen an der Registry, Löschung von dem ganzen Ordner "C:\Windows\System32\spool\drivers" und etlichen Spooler neustarts zwei Rechner wieder lauffähig bekommen, habe aber noch 25 Clients vor mir und brauche eine Skriptbasierte Lösung.
Hat irgendwer ähnliche Probleme und Tipps, wie man effizient die Clients wieder Druckfähig bekommen könnte?
Als Reaktion auf die am vergangenen Donnerstag veröffentliche Sicherheitslücke "Print Nightmare" wurden meinerseits folgende Maßnahme ergriffen:
Nach Vorbild von diesem Artikel:
https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675 ...
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Druckermapping via GPO funktionieren nicht mehr - Problematisch.
Die logische Gegenmaßnahme war dann, die GPO "umzukehren" und dem System User den Zugriff auf den Ordner wieder zu gewähren.
Böses Erwachen: Dadurch wurde keine Besserung erzielt.
Nach vielem hin und her scheint es so zu sein, dass sich die Treiber zerschießen und oder die Berechtigung auf den Pfad "C:\Windows\System32\spool\drivers" korrupt sind.
Ich habe es nach vielen Anpassungen an der Registry, Löschung von dem ganzen Ordner "C:\Windows\System32\spool\drivers" und etlichen Spooler neustarts zwei Rechner wieder lauffähig bekommen, habe aber noch 25 Clients vor mir und brauche eine Skriptbasierte Lösung.
Hat irgendwer ähnliche Probleme und Tipps, wie man effizient die Clients wieder Druckfähig bekommen könnte?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 894716439
Url: https://administrator.de/contentid/894716439
Ausgedruckt am: 25.11.2024 um 23:11 Uhr
28 Kommentare
Neuester Kommentar
Moin,
Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber
Gruß
C.C.
Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber
Gruß
C.C.
Zitat von @Durarain:
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.
Hey, warum entziehen?
Das Skript habe ich mir heute bei der angesehen und auf dem Printserver durchlaufen lassen.
SYSTEM bleibt aber nach wie vor Besitzer des Ordners, also wird da nichts entzogen?
P.S.: Gerade mal im Testlab probiert und an einem Client das Skript laufen lassen.
Keine Probleme mit den Netzlaufwerken per GPO festzustellen, allerdings kann der Benutzer sich dann keine Drucker mehr hinzufügen.
Wäre es möglich, dass du im Titel von Laufwerken schreibst, aber Druckernappings meinst?
Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.
Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.
Zitat von @DerWoWusste:
Wäre es möglich, dass du im Titel von Laufwerken schreibst, aber Druckernappings meinst?
Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.
Wäre es möglich, dass du im Titel von Laufwerken schreibst, aber Druckernappings meinst?
Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.
Ja, richtig. Ich meinte Druckermappings, habe ich im Eifer des Gefechts falsch angegeben.
Außerdem zur Info: Ich habe die GPO zu beginn so auf die Clients losgelassen:
Zitat von @dertowa:
Hey, warum entziehen?
Das Skript habe ich mir heute bei der angesehen und auf dem Printserver durchlaufen lassen.
Es gibt dem SYSTEM lediglich verweigernde Berechtigungen, dadurch kann das SYSTEM keine Änderungen mehr vornehmen.
SYSTEM bleibt aber nach wie vor Besitzer des Ordners, also wird da nichts entzogen?
P.S.: Gerade mal im Testlab probiert und an einem Client das Skript laufen lassen.
Keine Probleme mit den Netzlaufwerken per GPO festzustellen, allerdings kann der Benutzer sich dann keine Drucker mehr hinzufügen.
Zitat von @Durarain:
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.
Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.
Hey, warum entziehen?
Das Skript habe ich mir heute bei der angesehen und auf dem Printserver durchlaufen lassen.
SYSTEM bleibt aber nach wie vor Besitzer des Ordners, also wird da nichts entzogen?
P.S.: Gerade mal im Testlab probiert und an einem Client das Skript laufen lassen.
Keine Probleme mit den Netzlaufwerken per GPO festzustellen, allerdings kann der Benutzer sich dann keine Drucker mehr hinzufügen.
Okay, sehr Aufschlussreich. Ich denke ich lasse das Skript nun mal zur Reparaturzwecken laufen, schauen wir mal, eventuell stellt das die Funktion wieder her.
Ich denke das Problem ist, dass die Drucker in der GPO jedes mal neu gesetzt werden. Es werden quasi erst alle Druckermappings entfernt und dann neu zugewiesen, das wird der Grund sein, warum es dann nicht mehr funktioniert hat.
Zitat von @148656:
Moin,
Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber
Gruß
C.C.
Moin,
Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber
Gruß
C.C.
Das kann ich trotz Funktionstests zwischen meinen ausgeführten Schritten nicht genau fest machen. Ich habe in der Registry unter verschiedenen Pfaden die Drucker gelöscht (nach vorherigem Export natürlich), veruscht die Treiber zu bereinigen, unter dem Verzeichnis "C:\Windows\System32\spool\drivers" nach Recherche im Netz Dateien gelöscht usw. Und dann ging es an einem Client auf einmal wieder, nachdem ich mehrfach auf den Netzwerkdrucker geklickt habe. Ich bemühe mich weiter um eine einheitliche Lösung.
Diese Fehlermeldung erhalte ich, wenn ich versuche, eine Verbindung über die Freigabe herzustellen:
Natürlich erhältst du die Meldung, sobald an den Clients das Skript gelaufen ist und das SYSTEM eine Verweigerung der Rechte erhält, kann der Client keine Drucker mehr hinzufügen, am Printserver darf man mit dem Skript nicht mal Berechtigungen oder Einstellungen der Drucker anpassen.
Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.
Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.
Zitat von @dertowa:
Natürlich erhältst du die Meldung, sobald an den Clients das Skript gelaufen ist und das SYSTEM eine Verweigerung der Rechte erhält, kann der Client keine Drucker mehr hinzufügen, am Printserver darf man mit dem Skript nicht mal Berechtigungen oder Einstellungen der Drucker anpassen.
Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.
Natürlich erhältst du die Meldung, sobald an den Clients das Skript gelaufen ist und das SYSTEM eine Verweigerung der Rechte erhält, kann der Client keine Drucker mehr hinzufügen, am Printserver darf man mit dem Skript nicht mal Berechtigungen oder Einstellungen der Drucker anpassen.
Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.
Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
ich versteh die Aufregung auch nicht so sehr... Druckertreiber nachinstallieren war schon immer ein Sicherheitsloch, aber früher nur theoretisch und man glaubte sich seit Windows 7 sicher, nachdem das Installieren von unsignierten Treibern nicht mehr zugelassen wurde.
Und schon aus eigenem Interesse unterbindet man das Einbinden von Benutzerdruckern komplett auf Terminal und Citrix-Servern und bietet vorkonfigurierte Druckwarteschlangen an. Punkt aus fertig. Bzw bei Citrix bietet man den Unviersal Printer driver an und sonst nix
Und schon aus eigenem Interesse unterbindet man das Einbinden von Benutzerdruckern komplett auf Terminal und Citrix-Servern und bietet vorkonfigurierte Druckwarteschlangen an. Punkt aus fertig. Bzw bei Citrix bietet man den Unviersal Printer driver an und sonst nix
Zitat von @Durarain:
Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
Hä?
Also ich verstehe nicht was du getan hast.
Das Skript aus dem von dir genannten Blog weist nur dem SYSTEM die Verweigern - Berechtigungen zu.
Diese lassen sich mit dem "deaktivieren" Skript wieder rückgängig machen, von dem her klappt aus dem Blog alles wie versprochen.
Somit solltest du nach deiner GPO-Attacke mal checken wie die Berechtigungen nun effektiv aussehen und wer Besitzer der Dateien ist.
Zitat von @dertowa:
Hä?
Also ich verstehe nicht was du getan hast.
Das Skript aus dem von dir genannten Blog weist nur dem SYSTEM die Verweigern - Berechtigungen zu.
Diese lassen sich mit dem "deaktivieren" Skript wieder rückgängig machen, von dem her klappt aus dem Blog alles wie versprochen.
Somit solltest du nach deiner GPO-Attacke mal checken wie die Berechtigungen nun effektiv aussehen und wer Besitzer der Dateien ist.
Zitat von @Durarain:
Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
Hä?
Also ich verstehe nicht was du getan hast.
Das Skript aus dem von dir genannten Blog weist nur dem SYSTEM die Verweigern - Berechtigungen zu.
Diese lassen sich mit dem "deaktivieren" Skript wieder rückgängig machen, von dem her klappt aus dem Blog alles wie versprochen.
Somit solltest du nach deiner GPO-Attacke mal checken wie die Berechtigungen nun effektiv aussehen und wer Besitzer der Dateien ist.
Die Berechtigungen sind so wie sie sein sollten, in diesem Ordner. Dies habe ich auch nochmal mit dem Skript zur Zugriffswiederherstellung sichergestellt.
Pack mal bitte ein Bild her, denn wenn sie wären wie sie sollten, gäbe es wohl kein Problem mit dem Hinzufügen der Drucker, außer durch die Reparatur ist mehr kaputt gegangen. 
Zitat von @dertowa:
Pack mal bitte ein Bild her, denn wenn sie wären wie sie sollten, gäbe es wohl kein Problem mit dem Hinzufügen der Drucker, außer durch die Reparatur ist mehr kaputt gegangen.
Pack mal bitte ein Bild her, denn wenn sie wären wie sie sollten, gäbe es wohl kein Problem mit dem Hinzufügen der Drucker, außer durch die Reparatur ist mehr kaputt gegangen.
Danke, kein Problem, hier:
Spannend, hier mal von meinem Client...
Bis auf die nicht auf gelöste SID von dir und dass bei dir "jeder" und bei mir benutzer berechtigt sind, sehe ich keinen Unterschied.
Ich habe probehalber mal "jeder" auf die berechtigungsliste gesetzt, keine Änderung des Problems leider.
Naja lustig ist, dass die Berechtigungen hier auch in meiner privaten Umgebung so aussehen.
Beide Systeme sind Domainmember und Domainuser sind in den Berechtigungen gar nicht enthalten.
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Ich würde das Gebastel lassen.
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).
1
Zitat von @DerWoWusste:
Ich würde das Gebastel lassen.
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).
Ich würde das Gebastel lassen.
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).
thx! Erst mal so umgesetzt.
Ich hab das Thema zum Anlass genommen alle verbleibenden GUI Server mal zu checken ob der Druckspooler wirklich benötigt wird.
Also erstmal einfach überall aus. ;)
Verbleibend ist der Printserver übrig und der ist per Skript nun im Zugriff beschränkt.
Zudem habe ich das Thema noch mal zum Anlass genommen die Kollegen erneut zu sensibilisieren, denn irgendwo muss die Schadsoftware ja auch herkommen, die fällt ja nicht vom Himmel...
Zitat von @O-Marc:
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Zitat von @Durarain:
Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Zitat von @O-Marc:
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Moin,
nachdem du die Berechtigungen zurückgesetzt hast, hast du den Spooler aber schon auch neugestartet?
P.S.: Das Skript ist übrigens auch gar nicht für Clients gedacht.
Gruß
Moin,
ich sehe ebenfalls kein Problem bei den Clients. Lediglich für Printserver in zusammenhang mit DC's war es gemeint.
Um die Permissions zurückzusetzen, kannst du dich mit icacls und secedit auseinandersetzen:
How to reset File and Folder permission to default
ich sehe ebenfalls kein Problem bei den Clients. Lediglich für Printserver in zusammenhang mit DC's war es gemeint.
Um die Permissions zurückzusetzen, kannst du dich mit icacls und secedit auseinandersetzen:
How to reset File and Folder permission to default
Zitat von @ArnoNymous:
Moin,
nachdem du die Berechtigungen zurückgesetzt hast, hast du den Spooler aber schon auch neugestartet?
P.S.: Das Skript ist übrigens auch gar nicht für Clients gedacht.
Gruß
Zitat von @Durarain:
Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Zitat von @O-Marc:
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Hallo Durarain,
hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?
Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Moin,
nachdem du die Berechtigungen zurückgesetzt hast, hast du den Spooler aber schon auch neugestartet?
P.S.: Das Skript ist übrigens auch gar nicht für Clients gedacht.
Gruß
Den Spooler habe ich neugestartet - ja.
Nun zum aktuellen Fortschritt:
Es hat sich herausgestellt, dass an den meisten Clients die Vererbung erneut aktiviert werden muss, sodass auch sämtliche Unterordner von "C:\Windows\System32\spool\drivers" den "SYSTEM" User wieder mit Vollzugriffsrechten führen.
Nun gibt es einige Sonderfälle.
Zb via Remote Desktop gemappte/angebundene Drucker werden damit nicht wieder gangbar gemacht
Alle Rechner auf die ich auch nur zur "leichten" Fehleranalyse aufgeschalten war (also einfach nur Drucker entfernt und versucht über das mapping wieder hinzuzufügen), funktioniert es auch partout nicht mehr
hast du dafür mittlerweile eine Lösung gefunden? Ich stehe vor dem selben Problem. Ich habe mit dem Powershell Skript die ACL wieder entfernt, kann aber keine Drucker mehr hinzufügen. Auch das erneute Aktivieren der Vererbung bringt keinen Erfolg.
Hallo,
Also die Lösung in meinem Fall war, die Haken wie hier beschrieben zu setzen:
"Es hat sich herausgestellt, dass an den meisten Clients die Vererbung erneut aktiviert werden muss, sodass auch sämtliche Unterordner von "C:\Windows\System32\spool\drivers" den "SYSTEM" User wieder mit Vollzugriffsrechten führen."
Vor diesem Vorgang einmal als Admin den Besitz des Ordners übernehmen und den Spoolerdienst stoppen.
Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen. Ich habe zb anstelle von Kyocera dann die von dem Windows Update Treiberpaket genommen.
Also die Lösung in meinem Fall war, die Haken wie hier beschrieben zu setzen:
"Es hat sich herausgestellt, dass an den meisten Clients die Vererbung erneut aktiviert werden muss, sodass auch sämtliche Unterordner von "C:\Windows\System32\spool\drivers" den "SYSTEM" User wieder mit Vollzugriffsrechten führen."
Vor diesem Vorgang einmal als Admin den Besitz des Ordners übernehmen und den Spoolerdienst stoppen.
Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen. Ich habe zb anstelle von Kyocera dann die von dem Windows Update Treiberpaket genommen.
Zitat von @Durarain:
Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen.
Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen.
Wenn man nicht alles verfummelt hat braucht es weder nen neuen Printserver noch neue Treiber...
Ich habe beim Printserver einfach das Skript wieder rückgängig gemacht und fertig.
