16
Probleme mit Point-And-Print nach aktuellen Sicherheitsupdates
Hi zusammen,
ich habe gestern bei uns Sicherheitsupdates laufen lassen und dadurch Probleme mit der Treiberinstallation zwischen Printserver und Clients verursacht.
support.microsoft.com/de-de/topic/10-august-2021-kb5005076-monatliches-rollup-bf677fed-96d9-475e-87c1-a053fa75fef7
Wie hier im Artikel zu einem der aktuellen Updates zu sehen ist, wurden durch die Updates die Richtlinien zur Treiberinstallation auf Administratorrechte beschränkt.
Auf der Suche nach einer Lösung bin ich unter Anderem auf die Lösung von emeriks von 2018 gestoßen.
Windows 10 - Probleme mit Point-And-Print
Ich habe die Richtlinie in unseren GPOs verteilt und einige Male hin und her versucht, wegen dieser Art und Weise der Schreibung der Servernamen.
Letztlich funktioniert es bei uns noch am ehesten, wenn ich ausschließlich die FQDNs getrennt mit Semikolon schreibe und den NETBIOS Name nicht mit dazu schreibe.
Alles Andere ist exakt so wie emeriks es beschrieben hat.
Jetzt ist die Situation wie folgt: wir haben einen wichtigen Printserver um den es hier geht. Läuft auf 2012 R2.
Darauf greifen die Kollegen über deren Win10 Geräte zu, über SSL-VPN, IPsec-VPNs und direkt im Netzwerk.
Außerdem gibt es noch einige Kollegen die über MS Terminalserver auf 2012 R2 auf die Drucker zugreifen.
Nachdem ich die Richtlinie aktiviert habe, konnte ich bei meinen Test-Usern keine Probleme mehr feststellen.
Allerdings gibt es nach wie vor einige User, die auf der allergleichen Terminalserver-Sammlung arbeiten wie andere, dort sind in der Registry auch die Einträge der GPO verfügbar, aber bei Nutzer A kann der Drucker nicht installiert werden, während bei Nutzer B und C die Installation funktioniert.
Ohne die Richtlinie konnte ich in der Ereignisanzeige Fehlermeldungen nach der Anmeldung sehen, dass der Treiber nicht verfügbar wäre und es kam beim manuellen verbinden immer der folgende Fehler im Screenshot. Hier kommt noch erschwerend hinzu, dass bei der Bestätigung der Installation nur eine Fehlermeldung kommt. Es kommt keine Windows-Sicherheitsabfrage der Administrator-Zugangsdaten.
Genau das gleiche auch auf Windows 10. Einige Nutzer können ein und den selben Drucker wieder nutzen ohne tätig zu werden. Bei anderen wiederum kommt nach wie vor diesen Meldung. Hier kann ich wenigstens mit Hilfe des Authentifizierungsfensters meinen Admin-Zugang eingeben und dann aktualisiert sich der Treiber.
Wie genau kann ich mir das jetzt erklären, dass ich die Details aus der Richtlinie überall identisch in der Registry finden kann, aber es bei einigen Benutzern einfach nicht greifen will. Bei Terminalserver scheint es eher die Minderheit zu sein, bei Windows 10 eher die Mehrheit.
Wo im Ereignisprotokoll könnte ich noch mehr Meldungen zum Problem finden?
Hat noch jemand sonst hier das Gleiche Problem durch die Sicherheitsupdates vom August?
ich habe gestern bei uns Sicherheitsupdates laufen lassen und dadurch Probleme mit der Treiberinstallation zwischen Printserver und Clients verursacht.
support.microsoft.com/de-de/topic/10-august-2021-kb5005076-monatliches-rollup-bf677fed-96d9-475e-87c1-a053fa75fef7
Wie hier im Artikel zu einem der aktuellen Updates zu sehen ist, wurden durch die Updates die Richtlinien zur Treiberinstallation auf Administratorrechte beschränkt.
Auf der Suche nach einer Lösung bin ich unter Anderem auf die Lösung von emeriks von 2018 gestoßen.
Windows 10 - Probleme mit Point-And-Print
Ich habe die Richtlinie in unseren GPOs verteilt und einige Male hin und her versucht, wegen dieser Art und Weise der Schreibung der Servernamen.
Letztlich funktioniert es bei uns noch am ehesten, wenn ich ausschließlich die FQDNs getrennt mit Semikolon schreibe und den NETBIOS Name nicht mit dazu schreibe.
Alles Andere ist exakt so wie emeriks es beschrieben hat.
Jetzt ist die Situation wie folgt: wir haben einen wichtigen Printserver um den es hier geht. Läuft auf 2012 R2.
Darauf greifen die Kollegen über deren Win10 Geräte zu, über SSL-VPN, IPsec-VPNs und direkt im Netzwerk.
Außerdem gibt es noch einige Kollegen die über MS Terminalserver auf 2012 R2 auf die Drucker zugreifen.
Nachdem ich die Richtlinie aktiviert habe, konnte ich bei meinen Test-Usern keine Probleme mehr feststellen.
Allerdings gibt es nach wie vor einige User, die auf der allergleichen Terminalserver-Sammlung arbeiten wie andere, dort sind in der Registry auch die Einträge der GPO verfügbar, aber bei Nutzer A kann der Drucker nicht installiert werden, während bei Nutzer B und C die Installation funktioniert.
Ohne die Richtlinie konnte ich in der Ereignisanzeige Fehlermeldungen nach der Anmeldung sehen, dass der Treiber nicht verfügbar wäre und es kam beim manuellen verbinden immer der folgende Fehler im Screenshot. Hier kommt noch erschwerend hinzu, dass bei der Bestätigung der Installation nur eine Fehlermeldung kommt. Es kommt keine Windows-Sicherheitsabfrage der Administrator-Zugangsdaten.
Genau das gleiche auch auf Windows 10. Einige Nutzer können ein und den selben Drucker wieder nutzen ohne tätig zu werden. Bei anderen wiederum kommt nach wie vor diesen Meldung. Hier kann ich wenigstens mit Hilfe des Authentifizierungsfensters meinen Admin-Zugang eingeben und dann aktualisiert sich der Treiber.
Wie genau kann ich mir das jetzt erklären, dass ich die Details aus der Richtlinie überall identisch in der Registry finden kann, aber es bei einigen Benutzern einfach nicht greifen will. Bei Terminalserver scheint es eher die Minderheit zu sein, bei Windows 10 eher die Mehrheit.
Wo im Ereignisprotokoll könnte ich noch mehr Meldungen zum Problem finden?
Hat noch jemand sonst hier das Gleiche Problem durch die Sicherheitsupdates vom August?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1173415390
Url: https://administrator.de/contentid/1173415390
Printed on: April 27, 2024 at 22:04 o'clock
16 Comments
Latest comment
Da gibt's schon diverse Threads zu, bspw.
Patch PrintNightmare
KB5005033 - Druckertreiber Abfrage Admin Eingabe
Such dir was aus.
Patch PrintNightmare
KB5005033 - Druckertreiber Abfrage Admin Eingabe
Such dir was aus.
1
Zitat von @dertowa:
Da gibt's schon diverse Threads zu, bspw.
Patch PrintNightmare
KB5005033 - Druckertreiber Abfrage Admin Eingabe
Such dir was aus.
Da gibt's schon diverse Threads zu, bspw.
Patch PrintNightmare
KB5005033 - Druckertreiber Abfrage Admin Eingabe
Such dir was aus.
Danke für die Antwort. Ich habe die Möglichkeiten an Lösungen auch schon entdeckt und die Threats durchforstet. Diese beiden waren mir noch nicht bekannt, da sind aber auch keine Neuigkeiten mehr drin.
Mein Problem besteht wie gesagt darin, dass die GPOs von Microsoft für die Point and Print erlaubten Server nicht 100% greift und ich nicht verstehe warum...
Selbe TS-Sammlung. User1,2,3,4 greift die Regel nach einigen Minuten und bei User 5 nicht.
Windows 10 PC 1-4 greift sie, bei PC 5 nicht.
Getestet wurde immer mit den gleichen Druckern mit dem manuellen hinzufügen.
Wenn manuelles adden nicht funktioniert hat, haben auch die GPOs für die Drucker nicht funktioniert
Einige hatten das Update sogar installiert und hatten nie Probleme mit ihren Druckern.
Unsere Treiber sind bis auf einem alle auf "Paket" - "Wahr" und die ganzen Kyocera Treiber sind alle vom Typ3.
Moin,
mir stellt sich ja gerade die Frage, wie hoch eure Fluktuation bei den Usern/ Druckern/ Clients oder Servern ist. Wenn doch die Treiber einer Druckerreihe (ich nehme am liebsten Universal-Treiber) auf einem Endgerät vorhanden ist, können doch alle User die Drucker nutzen, wie sie wollen.
Beim Terminalserver gehst du als Admin einmal hin, verbindest alle Drucker vom Printserver manuell, entfernst die Drucker wieder aus deinem Konto und die Treiber sind auf dem TS vorhanden. Fertig EIne Sache von 2 Minuten pro TS.
Bei 3000 Clients sieht die Sache anders aus, aber die User müssten doch mittlerweile mal ihre Standarddrucker haben oder wechseln die User ständig den Arbeitsplatz und haben täglich einen neuen in der Hand?
Gruß
em-pie
mir stellt sich ja gerade die Frage, wie hoch eure Fluktuation bei den Usern/ Druckern/ Clients oder Servern ist. Wenn doch die Treiber einer Druckerreihe (ich nehme am liebsten Universal-Treiber) auf einem Endgerät vorhanden ist, können doch alle User die Drucker nutzen, wie sie wollen.
Beim Terminalserver gehst du als Admin einmal hin, verbindest alle Drucker vom Printserver manuell, entfernst die Drucker wieder aus deinem Konto und die Treiber sind auf dem TS vorhanden. Fertig EIne Sache von 2 Minuten pro TS.
Bei 3000 Clients sieht die Sache anders aus, aber die User müssten doch mittlerweile mal ihre Standarddrucker haben oder wechseln die User ständig den Arbeitsplatz und haben täglich einen neuen in der Hand?
Gruß
em-pie
Beim Terminalserver gehst du als Admin einmal hin, verbindest alle Drucker vom Printserver manuell, entfernst die Drucker wieder aus deinem Konto und die Treiber sind auf dem TS vorhanden. Fertig EIne Sache von 2 Minuten pro TS.
Und genau das funktioniert bei mir nicht ...
Die HP Universal Treiber sind in identischer Version auf allen Terminalservern vorhanden.
Der Drucker ist ja auch schon seit Ewigkeiten beim User verbunden.
Dennoch kommt dieses "Vertrauen Sie diesem Drucker?" bei jedem Druck!
Nur, wenn ich den RegKey
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators Ich blicke echt nicht mehr durch.
greetz
Der Rico
Zitat von @RicoPausB:
Und genau das funktioniert bei mir nicht ...
Die HP Universal Treiber sind in identischer Version auf allen Terminalservern vorhanden.
Der Drucker ist ja auch schon seit Ewigkeiten beim User verbunden.
Dennoch kommt dieses "Vertrauen Sie diesem Drucker?" bei jedem Druck!
Nur, wenn ich den RegKey einfüge und auf "0" setze, kann gedruckt werden.
Ich blicke echt nicht mehr durch.
greetz
Der Rico
Beim Terminalserver gehst du als Admin einmal hin, verbindest alle Drucker vom Printserver manuell, entfernst die Drucker wieder aus deinem Konto und die Treiber sind auf dem TS vorhanden. Fertig EIne Sache von 2 Minuten pro TS.
Und genau das funktioniert bei mir nicht ...
Die HP Universal Treiber sind in identischer Version auf allen Terminalservern vorhanden.
Der Drucker ist ja auch schon seit Ewigkeiten beim User verbunden.
Dennoch kommt dieses "Vertrauen Sie diesem Drucker?" bei jedem Druck!
Nur, wenn ich den RegKey
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators Ich blicke echt nicht mehr durch.
greetz
Der Rico
Jo genau so ist es bei uns auch. Das ist jetzt aber auch nicht so schlimm, ich habe den Registry Key gesetzt und um den Rest muss sich der Virenscanner kümmern ;) Wenn Microsoft da einen Käse macht müssten sie ja wenigstens die Drucker von GPOs erlauben. Kann ja nicht sein, dass sowas dann auch nicht mehr geht. Es ist ja ein Unterschied, ob der User manuell Treiber installieren will oder dies über eine GPO ausgeführt wird.
Wie in einigen Foren schon zu lesen ist, ist das setzen dieses Reg Keys auch kein Todesurteil. Jedes OS von MS steckt voller so vieler ungestopfter Sicherheitslücken, da macht es die eine auch nicht fett.
Zitat von @ITler7:
...
Jo genau so ist es bei uns auch. Das ist jetzt aber auch nicht so schlimm, ich habe den Registry Key gesetzt und um den Rest muss sich der Virenscanner kümmern ;)
...
So ein Schwachsinn. Wenn ein Angreifer ein System erfolgreich kompromittiert hat, was wird er wohl als erstes machen?...
Jo genau so ist es bei uns auch. Das ist jetzt aber auch nicht so schlimm, ich habe den Registry Key gesetzt und um den Rest muss sich der Virenscanner kümmern ;)
...
Richtig. Er wird den Virenscanner entweder deaktivieren oder seinen Programmpfad legitimeren. Und schon hast du den Salat…
So ein Schwachsinn. Wenn ein Angreifer ein System erfolgreich kompromittiert hat, was wird er wohl als erstes machen?
Richtig. Er wird den Virenscanner entweder deaktivieren oder seinen Programmpfad legitimeren. Und schon hast du den Salat…
Richtig. Er wird den Virenscanner entweder deaktivieren oder seinen Programmpfad legitimeren. Und schon hast du den Salat…
Na wenn der Angreifer das schafft und vorher nicht entdeckt wird, dann gute Nacht. Wenn es nach dem Hersteller und den Online Vorstellungen des Produkts mit KI, ML, usw. gegen die aktuellsten Viren und Ransomewares geht, dann ist das nicht möglich.
Zitat von @148656:
So ein Schwachsinn. Wenn ein Angreifer ein System erfolgreich kompromittiert hat, was wird er wohl als erstes machen?
Es mag sein dass ich mich wiederhole und das ich die Thematik zur Lücke nach wie vor noch nicht 100%ig begriffen habe, aber... :DSo ein Schwachsinn. Wenn ein Angreifer ein System erfolgreich kompromittiert hat, was wird er wohl als erstes machen?
Wenn das ganze so schwerwiegend wäre, dann würde es diesen Registrykey wohl kaum geben.
Zudem lese ich immer von veränderten Treiberdateien und darüber wird das Clientsystem kompromittiert.
Nun sehe ich das ein, wenn der unbedarfte Nutzer einen Link erhält indem ein angeblicher Drucker aus dem Word Wide Web enthalten ist und darüber die kompromittierten Treiberdateien bezogen werden.
In einer Firmenumgebung gibt es aber doch auch Restriktionen hinsichtlich der vertrauenswürdigen Printserver und wenn man diese GPOs nutzt muss eine manipulierte Treiberversion sich auf genau diesem Printserver befinden.
Wie soll sie dahin kommen?
Bzw. wenn sie da ist dann hab ich den Schädling sowieso im Netz oder der Admin hat unbedarft rumgefummelt. ;)
Was war denn jetzt die Lösung?
Du könntest so z.B. ein Skript schreiben, was den User kurzzeitig die Rechte zum Treiber installieren gibt und danach sofort wieder entzieht.
Wenn das ganze so schwerwiegend wäre, dann würde es diesen Registrykey wohl kaum geben.
Diese Logik versteh ich nicht.Du könntest so z.B. ein Skript schreiben, was den User kurzzeitig die Rechte zum Treiber installieren gibt und danach sofort wieder entzieht.
Zitat von @Drohnald:
Du könntest so z.B. ein Skript schreiben, was den User kurzzeitig die Rechte zum Treiber installieren gibt und danach sofort wieder entzieht.
Du könntest so z.B. ein Skript schreiben, was den User kurzzeitig die Rechte zum Treiber installieren gibt und danach sofort wieder entzieht.
Klar, ich könnte auch zum Mond fliegen (theoretisch - praktisch verdient man in der IT nicht genug, zumindest ich nicht).
Wie gesagt es mag sein, dass ich das Thema falsch einschätze, aber bislang sehe ich das einfach nicht.
Was ist denn hinsichtlich der Restriktion von Printservern?
Welches Szenario gibt es das mich/die Firmenumgebung/den Client ernsthaft in Bedrängnis bringen für einen Treiberexploit wenn der User nur bestimmte Server ansprechen kann um von diesen Treiber zu beziehen?
Ich lasse mich da gern aufklären.
wenn der User nur bestimmte Server ansprechen kann um von diesen Treiber zu beziehen?
Das ist aber nicht in jeder Umgebung der Fall.Es kann zig Varianten geben, wie eine Firma aussieht. Da ist es doch besser, wenn man die Möglichkeit mit dem Regkey hat.
Du darfst gerne die Lücke als unkritisch in deiner Firma ansehen. Kann durchaus sein, dass es so ist.
Aber die Schlussfolgerung: "Es gibt den Regkey, also ist die Lücke kein Problem", ist nicht haltbar.
Zitat von @Drohnald:
Aber die Schlussfolgerung: "Es gibt den Regkey, also ist die Lücke kein Problem", ist nicht haltbar.
Das hab ich auch nicht gesagt.Aber die Schlussfolgerung: "Es gibt den Regkey, also ist die Lücke kein Problem", ist nicht haltbar.
Ich sagte nur, dass es den Regkey gibt um den Patch außer Kraft zu setzen, da es Szenarien gibt in denen auch andere Möglichkeiten sinnvoll helfen - sofern sich jemand damit beschäftigt.
Dass Microsoft den Regkey automatisch auf "sicher" setzt ist sinnvoll für nicht verwaltete Umgebungen oder um den Admin in die Verantwortung zu nehmen. ;)
Als Hinweis... ich musste beim FQDN am Ende einen "Punkt" setzen. Vorher hat er den hinterlegten Server nicht korrekt akzeptiert. Vielleicht hilft es ja.
nicht funktional:
server.domain.tld
funktional:
server.domain.tld.
nicht funktional:
server.domain.tld
funktional:
server.domain.tld.
Wasn das für ne Umgebung?
https://de.wikipedia.org/wiki/Fully-Qualified_Host_Name
War tatsächlich auch hier so nachzulesen... hab es auch nicht geglaubt, ist aber so.
Ja ich kenne diesen Punkt und er macht auch keinen Unterschied.
Ich hab ihn in unserer 2019er Umgebung nicht drin, allerdings arbeiten wir auch mit servername.intern.domain.de fluppt trotzdem.
Ich hab ihn in unserer 2019er Umgebung nicht drin, allerdings arbeiten wir auch mit servername.intern.domain.de fluppt trotzdem.
