wznutzer

Das ist völlig klar und habe ich mit keiner Silbe angezweifelt. Es gibt hier aber, denke ich, ein Missverständnis. Beispiel: Du bist der böse Bube aus Malware-City und hast es geschafft meinen PC A zu kompromittieren. Deine Malware läuft mit Adminrechten und da du mit allen Wassern gewaschen bist, hast du die genannten Einschränkungen rückgängig gemacht, mit Mimikatz bist du auch auf du und du und evtl. hast du sogar das Passwort meines User0815 im Klartext. PC A kann man vergessen, darum geht es gar nicht mehr. Nun versuchst du auf PC B zuzugreifen, das wird dir dann so eher (derzeitiger Wissensstand) nicht gelingen. Daran hindern dich ein paar (nicht alle) der Einstellungen. Da du in Malware-City sitzt, kannst du nicht einfach hinlaufen und dich lokal anmelden, du musst das über das Netzwerk machen. Darum geht es, der Zugriff von PC A auf PC B. Es nützt dir nichts, wenn du auf PC B irgendwas rückgängig machen könntest wenn du Zugriff hast, weil du eben keinen Zugriff hast. Die konkrete Frage war: Ist es doch irgendwie möglich auf PC B zuzugreifen/Prozesse zu starten und wenn ja wie kann dann das verhindert werden (Voraussetzungen siehe oben). Ein schönes (langes?) Wochenende wünsche ich euch.

Hi, ich glaube wir sehen das durch unterschiedliche Brillen (Sichtweisen). Deine Brille ist die Consulting-Brille: Pflichtenheft, Anforderungen, Konzept, das große Ganze. Das ist schwierig in einem Forum. Deswegen, so dachte ich, dein Hinweis auf eine ganz konkrete Frage. Diese ganz konkrete Frage habe ich formuliert. Nun sagst du, dass die konkrete Frage nicht beantwortet werden kann ohne das große Ganze. Aber natürlich ist das OK, ich habe keinerlei Ansprüche. In einem Forum bittet man und fordert nicht (als Fragender). Schafft man es mit den oben genannten Einstellungen Prozesse von PC A auf PC B mit Kenntnis der Credentials zu starten? Ohne diese Einstellungen ist das einfach möglich. Entweder es geht, oder es geht nicht. Im Moment sieht es für mich so aus, als ob es nicht geht. Würde ich auf PC A Malware feststellen ist es völlig egal was da gelaufen ist, da wird ein sauberes Backup wiederhergestellt. Aber auf PC B ist nichts passiert. Ich werde einfach noch weiter testen/recherchieren, das Ergebnis, egal welcher Art, poste ich hier. Außerdem hilfst du mir trotzdem. Ich bin kürzlich über ein paar Videos von dir (CIM) gestolpert, die sehe ich mir demnächst an . Grüße

Hi, evtl. interessiert sich jemand dafür. Wie oben beschrieben signiert MS Dateien nicht konsequent. Dann kommt es vor, dass man einen PC mit z. B. Autoruns oder dem ProcessExplorer prüft. In letzter Zeit hatte ich es öfters, dass eine Systemdatei dann von 1 oder 2 Scanner bei Virustotal als Malware gemeldet wird. Derzeit ist es z. B. die winlogon.exe, diese wird von Cylance als Virus erkannt. Wer es hunderprozentig wissen will uns sich nicht auf AV-Scanner verlassen will, lädt sich vom Update-Katalog das letzte kumulative Update runter in dem diese Datei drin war (Datum beachten). Dieses Update kann man dann mit 7Zip entpacken. Darin ist eine XML in dem alle Dateien mit SHA256 Hash aufgelistet sind. Dann Hash vergleichen und sicher wissen, dass die winlogon.exe von Microsoft ist. Alternativ eine andere Installation, aber die ist manchmal nicht greifbar.

Guten Abend, ich wärme diesen Thread nochmals auf. Die Frage war, so dachte ich jedenfalls, konkret, aber evtl. kam das nicht richtig rüber. Wir brechen das ganz konkret runter. Keine Frage zu einem Konzept, nicht das große Ganze. Ich habe einen AD-User - AD0815 Diesem User gebe ich an allen Domänenrechner lokale Adminrechte Ich setze folgende Einstellungen für diesen AD-User auf allen Domänenrechner Option setzen: Account is sensitive and cannot be delegated Per GPO für den Account unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments Deny access to this computer from the network Deny log on as a batch job Deny log on as a service Deny log on through Remote Desktop Services Nach allem was ich bisher getestet habe, ist der User nur noch zum lokalen Anmelden (ich sitze davor) zu gebrauchen. Es kann nicht mehr auf Freigaben ohne weitere Eingabe vom Passwort zugegriffen werden, auch wenn diese für diesen User freigegeben sind. Der User kann nicht auf die $Freigaben zugreifen (remote). Der User kann nicht auf "normale" Freigaben zugreifen (remote). Der User kann z. B. keine WMI-Abfragen machen (remote). Der User kann sich nicht per RDP anmelden (remote). Der User kann keine Dienste starten (lokal). Der User kann keine Aufgaben ausführen (lokal). PsExec geht nicht mehr (remote) Wenn das so eingerichtet ist, kann ich mich bedenkenlos mit diesem User an einer beliebigen Arbeitsstation anmelden, ohne die Sorge haben zu müssen, dass eine evtl. laufende Malware irgendwas mit den Credentials dieses Users im Netzwerk anstellen kann. Das wäre auch das Ziel. Diese Frage ist aber, weiß ich was nicht, habe ich etwas falsch gemacht? Mit welcher Technik könnte ich jetzt noch immer von PC A auf PC B zugreifen um z. B. Prozesse zu starten, Daten abzugreifen? Vielen Dank

Guten Abend, beim Patchday von Januar und März hatte mein Exchange folgendes Verhalten: Die Updates wurden problemlos installiert. Der Nachfolgende Neustart dauerte ca. 35 Minuten. Nachdem der Exchange wieder bedienbar war, wurden Hardware-Änderungen gemeldet und ein erneuter Neustart angefordert. Dieser war dann gewohnt schnell und der Exchange läuft wieder völlig problemlos. Wenn ich die Logs richtig lese, wurde die Netzwerkkarte neu installiert. Bis zu diesem Zeitpunkt zeigte auch der Hyper-V Manager "keine Kommunikation" beim Netzwerk. Nun es ist mir bekannt, das der Exchange nicht starten mag, wenn keine Netzwerkverbindung vorhanden ist oder das AD nicht erreichbar ist. Auch beim Update der Integration Services ist das so. Aber bei "normalen" Updates ist mir das erst im Januar aufgefallen. Nun das ist kein großes Problem, es passiert ja nichts schlimmes und man kann es mit dem temporären Deaktivieren der Exchange-Dienste umgehen, aber lästig ist das schon. W2K12 R2, Exchange 2016 CU8, Hyper-V. Es wird auch an anderen Stellen berichtet: http://austintovey.blogspot.de/2018/02/virtual-exchange-server-become.html http://blog.scng.si/exchange-server-vm-becomes-unresponsive-while-updating-hyper-v-integration-services/ Kürzlich durfte ich lernen, dass hier auch Mitglieder der MS-Produktgruppen mitlesen . Da dürften sich die Exchange Entwickler mal drum kümmern. Wenn dann noch Zeit ist, evtl. bei den Exchange Cmdlets für die Powershell noch konsequent einen Präfix verwenden. Nun duck ich mich aber und bin weg .

Hi, ich würde gerne das Thema noch mal nach oben holen. Die grundsätzliche Empfehlung war ein 0815 Domänenuser und für Arbeiten die höhere Rechte auf den Clients erfordern ein lokaler Nutzer dessen PW mit LAPS verwaltet wird. Ich könnte aber auch den 0815 Domänenuser an allen Clients in der OU in die Gruppe der lokalen Administratoren schieben. Wie wir bereits diskutiert haben ist das schlecht, weil Prozesse die in dessen Kontext laufen allerhand Dinge auf allen zur OU gehörenden Clients tun können. Aber ist es auch noch schlecht, wenn ich zusätzlich folgendes mache: Option setzen: Account is sensitive and cannot be delegated Per GPO für den Account unter Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments Deny access to this computer from the network Deny log on as a batch job Deny log on as a service Deny log on through Remote Desktop Services Das sollte doch eine evtl. laufende Malware hindern sich auf weitere Rechner zu verbreiten? Evtl. Lücken mal ausgeschlossen.

Dann sage ich mal Danke für das schieben in die richtige Richtung.

Ein paar Stunden später ist mir eher klar was du mir sagen wolltest. Zusammengefasst sagst du: Melde dich einfach als 0815 Domänenuser ohne spezielle Rechte an. Poppt dann bei irgendeiner Arbeit z. B. die UAC auf, gibst du halt die per LAPS verwalteten lokalen Anmeldedaten ein. Alternativ die zur Verfügung stehenden Dinge wie ausführen als etc.. Das erfüllt meine Anforderungen, jedenfalls die die ich jetzt kenne . Bei irgendwelchen Bedenken wird das PW dieses einen 0815 Users geändert.

Ich glaube nicht, dass wir noch zusammenfinden, obwohl wir gar nicht so weit auseinander liegen. Ich habe genau das vor was geschrieben wurde, nichts vorgeschobenes. Auf Ressoucen wird natürlich nur lesend zugegriffen. Aber auch du siehst Domänenmitglieder nicht per se als vertrauenswürdig an. Warum sonst sollte man sich nicht mit besonders privilegierten User anmelden. Ich schließe aber nicht aus, dass ich am Ende zur Erkenntnis komme du hast Recht. Ich schreibe hier ja um zu lernen.

Da widerspreche ich dir nicht, technisch völlig klar. Da unterscheidet sich unsere Meinung nicht. Der Unterschied ist, du sagst es gibt nichts was man nicht mit einem lokalen Admin per LAPS verwaltet machen kann. Ich würde aber gerne auf Ablagen mit Tools, Files usw. zugreifen können deren Rechte per AD vergeben wurden. Ich würde gerne GPOs testen. Klar, kann ich immer noch beim Zugriff auf Ressourcen separat authentifizieren. Dann muss ich mir aber über diesen Account sorgen machen. Administrativer Aufwand, ja gibt es. Klappt das wie oben geschrieben über ein kleines Script oder Programm, ist der Nutzen höher als der Aufwand. Für mich . Klappt das nicht, erinnere ich mich an dich .

Da sind wir nicht einer Meinung. Nicht jeder auf irgendwelchen PC, sondern einer auf seinem PC. Es gibt Software wie Debugger, die läuft nicht auf zugenagelten Kisten. Auch solche PCs müssen gewartet und in ein Konzept eingebunden werden. Wir sind uns einig, das mit nicht besonders privilegierten Accounts zu machen. Wenn sich das Management dieser Accounts vereinfachen lässt, umso besser und warum nicht auf alle PCs einheitlich ausdehnen. Ich schätze deine Meinung, glaube aber auch, dass du mit „scheinbarer Sicherheit“ falsch liegst. Scheinbare Sicherheit wäre in diesem Fall, ich glaube nur dass ein AD-User ohne spezielle Rechte größeren Schaden anrichten kann. Das aber ist nicht der Fall und darauf arbeite ich hin. Es geht hier nicht um die Absicherung der Clients. Im Ernstfall wird ein Client neu aufgesetzt oder ein Image eingespielt.

Nein, das will ich nicht. Deswegen frage ich hier nach Erfahrungen. Ich habe das bestehende Rad noch nicht gefunden / kenne es nicht. Finde ich eines, drehe ich es nur . Ich finde es falsch, mit besonders privilegierten Accounts sich einfach überall anzumelden. Mir sind gegensätzliche Meinungen aber wohl bekannt. Mir ist dabei das Szenario von letztem Jahr im Kopf, als Ransomware sich z. B. über psexec verbreitete. Ohne ausreichend Rechte wäre das nicht gegangen. Ich werde noch etwas recherchieren, im Moment tendiere ich dazu ein Powershell Script oder C# Programm zu erstellen, dass die Computerkonten ausliest und passende Konten erstellt. Evtl. Ist es möglich das im AD gespeicherte PW von LAPS auszulesen und zu verwenden. Das idealerweise nur wenn ein Computerkonto generiert wird. Klappt das, wäre ich zufrieden.

Ja, du hast recht. Es ist missverständlich geschrieben. Muss heißen: Einen Wartungsaccount je Domänenmitglied. Es gibt keinen tiefergehenden Grund als bereits geschrieben. Ich betrachte die „normalen“ PCs als nicht vertrauenswürdig genug um mich als Domänenadmin oder mit einem sonstigen privilegierten Account anzumelden. Viele, nicht alle, User haben lokale Adminrechte und benötigen diese auch. Deswegen der Vertrauensentzug. Andererseits will ich ohne weitere Authentifizierung auf Ablagen die über das AD gesichert sind zugreifen, Nutzer GPOs prüfen usw..

Es muss nicht unbedingt kostenlos sein. Wenn LAPS aber gut funktioniert würde ich nicht extra Geld ausgeben wollen. Die Sache mit den nicht verschlüsselten Passwörtern ist nicht erste Sahne, aber ich kann es ja mit Zugriffsrechten schützen. Was wäre die kostenpflichtige Alternative. Es sind mehr als 25 Clients. Zu 2. Was will ich erreichen Ich will mich als Domänenuser an allen Mitglieder (PC) anmelden können und lokale Adminrechte haben. Dazu will ich aber weder den Domänenadmin nehmen noch einen einzigen User. Das ist sozusagen die ausgedachte Lösung. Ich will einen Wartungsaccount für alle Domänenmitglieder. Sollte dieser Wartungsaccount kompromittiert werden soll der Schaden in engen Grenzen gehalten werden. Der Wartungsaccount von PC1 soll nichts auf PC2 anrichten können. Manuell ist das alles möglich, automatisiert wäre mir lieber.

Ich hatte überhaupt nicht daran gedacht, dass hier irgendjemand etwas tun kann. Das war gar keine Absicht. Ich schreibe hier grundsätzlich um zu bitten, nicht um zu fordern. Was du mit PG oder dem Feedback Button meinst, ist mir gerade nicht klar. Eine Beschwerde bei MS, eher nicht. Das lohnt sich nicht.

Hallo, ich erarbeite mir gerade ein Konzept, dass die lokalen Passwörter nicht mehr organisatorisch verwaltet werden, sodern über das AD. Außerdem wäre es mir recht, wenn ich einen Domänenuser mit lokalen Adminrechten auf jedem Client hätte. Lokale Passwörter Eine Lösung die sich gut anhört ist "Local Administrator Password Solution (LAPS)". Hier: https://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/ ist es beschrieben. Ist LAPS noch immer die Standardlösung, auch mit Windows 10 1709? Es hört sich jedenfalls gut an. Domänenuser mit lokalen Adminrechten Ich kann einfach einem Domänenuser über GPO lokale Adminrechte geben. Das funktioniert, wäre aber so eine Art Superuser. Lieber wäre mir so etwas wie LAPS, aber in der Domäne. Ich will mich mit normalen Nutzerrechten in der Domäne aber Adminrechte lokal anmelden, das aber nicht an jedem Rechner mit dem gleichen Passwort / User. Da ich mich im AD bewege, klappt ein User mit verschiedenen Passwörter nicht. Ich stelle mir einen automatisiert angelegten User mit dem Namen des Clients vor und einem eingenen Passwort. Evtl. denke ich aber hier etwas quer, wenn ja, schiebt mich in die richtige Richtung. Ich will verhindern, dass an Clients für "normale" Wartungsarbeiten eine Anmeldung nötig wird, mit der im Netzwerk nennenswerter Schaden angerichtet werden kann.

Das ist aber kein guter Grund, sondern Bequemlichkeit. Aktuelle Patches verteilen nicht signierte *.dll und *.exe. Wir müssen eben damit leben.

Dann bleibt mir nur noch ein Danke.

Von einem separaten Treiber für die M.2 SSD habe ich zwar gelesen, aber W10 1703 + 1709 kann auch ohne extra Treiber damit umgehen.

Ich glaube das verwirrt den TE. Du meinst die Sache mit OUI der MAC-Adresse? Man kann einen Switch so konfigurieren, dass die Ports automatisch in ein VLAN fallen wenn ein bestimmtes Gerät angeschlossen wird. Bei IP-Telefonie zum Beispiel.

Hi, evtl. ist das Security-Forum hier falsch. Aber weiß jemand warum Microsoft nicht konsequent alle Dateien die zum OS gehören digital signiert? Je nach dem welche Partner-Kompetenz man hat bzw. will, muss man eigene Software doch auch signieren. Es gibt auf einem frisch installierten Windows 10 unzählig viele *.exe und *.dll die von Microsoft sind und nicht signiert sind. Das sollte im Jahr 2018 Standard sein. Mit fällt kein guter Grund ein. Kennt ihr einen? Danke

Hi, wenn ich zwei DCs habe und das Passwort des Build-in Administrators der Domäne ändern will. Muss da etwas spezielles beachtet werden? Bei einem DC oder normalen Nutzern oder zusätzlich angelegten Nutzern mit Administrationsrechten, gibt es ja nichts zu beachten. Die Beste Methode ist soweit ich weiß: anmelden, STRG + ALT + ENTF, Passwort ändern, altes und neues Passwort eingeben fertig. Ist der Build-in etwas spezielles im Bezug auf Passwortänderung mit zwei DCs oder auch "nur" ein normaler Nutzer? Die Lockout-Regeln für Passwörter gelten z. B. bei dem Build-in ja nicht und die UAC ist standardmäßig aus. Mehr Spezialitäten sind mir nicht bekannt. Schönen Abend noch...

Hi, vielen Dank für die Antworten. Schnellstart war bereits deaktiviert, aber über die UI. Memtest muss ich noch machen, ein G:\Windows gibt es mit bcdedit /v nicht. Was mir allerdings gerade erst einfällt. Ich habe die Samsung Software der SSD M.2 960 gar nicht installiert. Das muss ich machen, evtl. gibt es ein Firmwareupdate.

Guten Morgen, ich versuche das kurz zu schildern. Ein PC W10 1703 Enterprise installierte KB4088782/4088785 (Die März Updates). Beim Herunterfahren die übliche Meldung Bitte warten... Meldung. Beim Hochfahren auch wie üblich. PC funktioniert einwandfrei. Beim nächsten Herunterfahren wieder eine Bitte warten... Meldung. Beim nächsten Start erscheint dann "Automatische Reparatur", nach kurzer Zeit die Meldung, dass der PC nicht repariert werden konnte, näheres in der srttrail.txt. Den PC über die erweiterten Optionen heruntergefahren und neu gestartet. PC startet problemlos und funktioniert wieder einwandfrei, installiert nach dem Login die Tastatur- und Maustreiber neu. Lt. srttrail.txt ist die Datei ntfs.sys unter g:\Windows\system32\drivers\ntfs.sys beschädigt (corrupt), Fehlercode: 0x490. Klar, unter G:\ gibt es das auch nicht. PC läuft völlig problemlos, keine BlueScreens. Analyse: srttrail.txt verweist auf g:\Windows..., könnte aber auch mit der Reparaturumgebung zu tun haben. Lt. Eventlog ID20 unter System (Kernel-Boot) war einmal ein Herunterfahren FALSE. Ist mir aber nicht bekannt, bzw. habe ich nicht bemerkt. ntfs.sys ist da und die MS-Signatur stimmt. Checkdisk meldet keine Fehler. Sicherheitshalber mal ein Check mit Desinfect. Keine Funde. Auf dem PC wurde nichts installiert (außer Windows Updates), es wird nicht gesurft und Mails werden erst mal nur als Text gelesen. Malware also eher unwahrscheinlich. Ich habe nur das hier: https://superuser.com/questions/1258387/automatic-repair-couldn-t-repair-pc-looking-for-ntfs-sys-on-wrong-drive gefunden. Der User beschreibt exakt das gleiche Problem. Ich habe sogar auch eine Samsung 960 M.2 SSD installiert. Der User kommt zum Schluss: Schluckauf. Ich habe keine Erklärung für dieses Verhalten, hätte aber gerne eine um das zu verstehen. Kennt ihr das Problem bzw. habt ihr eine Idee was das sein könnte? Müssen in der srttrail.txt die korrekten Pfade stehen oder können diese schon mal umgebogen sein. Die srttrail.txt lag ja tatsächlich unter c:\Windows\system32\logfiles. Vielen Dank und Grüße PS Solltet ihr auch Desinfect nutzen. F-Secure scannt seit einiger Zeit gar nicht mehr. Es erscheint aber eine Erfolgsmeldung. Nur so zur Info.

Bis vor 2 Wochen hätte ich gesagt, dass ist mir in 19 Jahren noch nicht vorgekommen :) . Mit IBM / Lenovo habe ich ja nun auch nicht wirklich eine kleine Klitsche als Hersteller. Wahrscheinlich ist eine 10 GB Infrastruktur noch nicht so gängig. Nicht wirklich schlimm, läuft jetzt halt über 1 GB, aber immer verfügbar, auf jeden Fall, geht nicht gibt's nicht, ist halt auch nicht zu 100% richtig. Hängt vielleicht von der Wichtigkeit der Ersatzteile ab. Läuft nun über 1 GB statt über 10 GB ist halt weniger schlimm wie die Kiste steht. Ist ja tatsächlich auch so.