wznutzer

Danke. Nicht an den SMTP binden als Alternative, das ist dann wohl ein Fall für die Sache mit dem Wald und den Bäumen.

Guten Tag, bitte beantwortet mir folgende Frage. Mein Exchange arbeitet derzeit noch mit dem bei der Installation selbst ausgestellten Zertifikat. Mit iOS 12 können aber selbst signierte Zertifikate nicht mehr akzeptiert werden. Die ganzen "Tricks" wie Neustart, Zugangsdaten erst falsch dann richtig eingeben usw. funktionierten nur bis iOS 11. Da es aber sowieso nicht schön ist selbst signierte Zertifikate öffentlich zu verwenden bekommt der Exchange jetzt ein eigenes Zertifikat. Die Konfiguration an sich ist gut dokumentiert und sollte keine Probleme bereiten. Hier https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/mt595782(v=exchg.150) heißt es: "We recommend that your certificate's common name match the primary SMTP domain for your organization." Was will mir das sagen? Hier: https://www.frankysweb.de/exchange-2016-smtp-connector-und-wildcard-san-zertifikate/ werden die Probleme beschrieben die auftreten wenn das nicht so ist. Meine Domäne heißt intern leider anders als extern. Der Exchange hört intern auf den Namen exchange.firma.local extern auf exchange.firma.de. Den DNS konfiguriere ich intern so, dass der externe Name auf die interne IP aufgelöst wird. Mein Zertifikat wird ein SAN-Zertifikat mit CN=exchange.firma.de und als weiteres Attribut autodiscover.firma.de. Es sollte doch völlig egal sein wie der interne Name des Exchange ist, so lange die Verbindung über den externen Namen auch intern verwendet wird. Der Exchange kann blabla.xyz.local heißen wenn das Zertifikat auf exchange.firma.de lautet und die Verbindung auch so aufgebaut wird. Konkret denke ich darüber nach ob es mir Probleme bereitet, wenn der Exchange exchange.firma.local heißt das Zertifikat auf exchange.firma.de lautet und meine Standard SMPT Domain nicht die *.de sondern die *.local ist. Wird das Probleme machen? Danke

Das ist nicht richtig. "Veeam Agent for Windows" unterstützt die konsistente Sicherung von SQL-Instanzen, egal in welcher Version. Eigentlich sogar zwangsläufig, weil Schattenkopien genutzt werden. Was in der "Free" Version nicht unterstützt wird, ist das was bei Veeam "Application-Aware-Processing" genannt wird. D. h. du hast in der "Free" Version keinen Einfluss auf das "Wie" der Sicherung. Voraussetzung dafür ist ein installierter und funktionierender "SQL Server VSS Writer", der ist aber bei einer Standardinstallation sowieso vorhanden. Das aber trotzdem prüfen! "Veeam Agent for Windows FREE" macht eine Kopiesicherung, d. h. eine parallel laufende SQL-Sicherung mit Bordmittel wird nicht beeinflusst. Du kannst das alles anhand der Events und der Einträge in [msdb..backupset] nachvollziehen. Das hier auch genannte/verlinkte "Veeam Backup Free Edition" ist nicht geeignet, du schreibst nichts von Virtualisierung. Der größte Nachteil des "Veeam Agent for Windows" ist eine fehlende Prüfung ob das gemachte Backup auch korrekt gemacht wurde. Das soll aber in einer der nächsten Versionen eingebaut werden. Wenn du "Veeam Agent for Windows" nutzt, solltest du dir das Recovery anschauen: Funktioniert ein erstellter Wiederherstellungsstick? Recovery auf leere HDDs, die Partitionierung / Mapping muss da manuell gemacht werden. Du solltest dich mit dem SQL-Server in folgenden Punkten beschäftigen: Wiederherstellungsmodell, Backupvarianten. Dann kannst du schnell beurteilen ob das Backup mit "Veeam Agent for Windows" in dein Konzept passt. Ich sichere den SQL-Server immer mit Bordmittel, je nach Aufgabe des Servers noch zusätzlich mit Veeam (VAW, VBR). Schönen 1. Mai wünsche ich.

Guten Morgen, ich fasse nochmals kurz zusammen um was es hier ging. Ich meine man sollte Threads nicht einfach im Nichts enden lassen. Zu Anfangs ging es um die Verwaltung der lokalen Accounts: Empfehlung LAPS Die Diskussion ging dann über wie ein Wartungsaccount für Domänenmitglieder aussehen könnte: Empfehlung Domänenuser ohne lokale Adminrechte + lokaler Account mit dem PW aus LAPS. Weiter ging es dann mit der Frage ob ein Domänenuser mit lokalen Adminrechten und den genannten Einstellungen nicht genauso gut wäre: Keine Empfehlung bzw. unterschiedliche Meinungen. Meine Überlegungen dazu waren: Es ist so schlicht einfacher/bequemer und dem Domänenuser ohne lokale Adminrechte müsste ich das Recht geben die per LAPS vergebenen Passwörter aus dem AD auszulesen. Das kann dann aber auch Malware. Das schmeckt mir wiederum nicht. Hat der User nicht das Recht das PW zu ermitteln muss das ein anderer User, schreibe ich dann das PW auf einen Zettel um es bei der UAC-Abfrage einzugeben? Alle einzelnen Maßnahmen eines Sicherheitskonzeptes sind auf unterster Ebene immer irgendwie akademischer Natur. Wie lang muss das Passwort sein, macht das Scannen mit dem verbundenen Aufbrechen verschlüsselter Verbindungen Sinn, filtere ich Email-Anhänge, betreibe ich Geo-Blocking usw.. Ich habe hier im Forum einfach mal nach Malware gesucht. Erstaunt haben mich die teilweise unwidersprochenen Kommentare, dass bei Malware auf einem einzelnen Rechner das komplette Netzwerk neu installiert werden soll. Sollte eine durchdachte Rechtevergabe nicht genau das verhindern können? In diese Richtung gehen meine Überlegungen. Microsoft denkt auch darüber nach: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory. Da habe ich auch die Empfehlungen entnommen. Ich schätze alle weiteren Kommentare, ansonsten können wir das auch beenden.

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.