wznutzer

Wie bereits mehrfach erwähnt, ist das keine gute Idee. Nachfolgend die Erklärung warum: https://www.hasslinger.com/index.php/de/blog/das-missverstaendniss-mit-besitz-uebernehmen-und-den-ntfs-sowie-freigaberechten Evtl. möchtest Du auch noch das AGDLP-Prinzip anwenden, wenn es Dir was bringt. Ich habe z. B. da das "DL" weggelassen, weil keinen Nutzen. https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/

Gute Liste. Ich habe mich z. B. gegen das ständige Wechseln der Passwörter entschieden und wo möglich gMSA-Konten verwendet (ich hoffe korrekt konfiguriert ). Dafür lange, komplexe Passwörter per Richtlinie und Account-Lockout. Gerade das Auswerten von Logs hat mich auch schon beschäftigt, also das Erkennen wenn etwas passiert ist. Security Onion finde ich gut, werde ich wahrscheinlich demnächst produktiv einsetzen. Dauerhaft darf es aber nicht zu oft Alarm geben, wenn nichts ist. Wenn man Veeam einsetzt, kann man z. B. mit Sure-Backup die Backups automatisiert offline scannen, wenn der Scanner per Kommandozeile gesteuert werden kann. Wer mag kann den Scanner von Nextron probieren, macht mir aber zu viele Fehlalarme. Jetzt sind wir zwar etwas von "Security für Admin-Accounts weg", aber trotzdem interessant.

Ein Adminrechner bzw. Jumphost, Credential Guard ist aktiv. Das ist auch tatsächlich ein Schwachpunkt, der evtl. die anderen Maßnahmen einstürzen lassen kann. Überlegungen Über eine ausgehende RDP-Verbindung (Sicherheitslücke) kann auf dem Adminrechner Code ausgeführt werden. Möglich, aber das Risiko einer Sicherheitslücke die alle Maßnahmen außer Kraft setzt, kann es immer geben. Der Adminrechner nimmt kaum Verbindungen über das Netzwerk an oder nur von bestimmten Endpunkten aus ==> Windows-Firewall. Muss der Adminrechner in der Domäne sein? Ich habe mich für ja entschieden, weil wenn der Adminrechner von der Domäne aus "übernommen" wird, ist es sowieso schon vorbei. Ich will ja den Adminrechner nicht vor der Domäne beschützen. Kann jemand unberechtigter physischen Zugriff auf den Adminrechner haben, wenn nein, würde auch Bitlocker nichts bringen. Applocker, hoffentlich so konfiguriert, dass die meisten Schwachstellen geschlossen sind. Wie noch könnte Code ausgeführt werden? PsExec (Sysinternals) nutzt Pipes über Port 139, 445. Braucht aber Credentials vom Rechner. Auch hier gilt, der lokale Admin geht nicht, aber natürlich der reguläre Adminuser (der natürlich keine Adminrechte hat). Also dürfen diese Credentials auf keinem anderen Gerät landen. Derzeit ist das organisatorisch. Die werden einfach nirgendwo anders eingegeben.

Ich kann Dir nicht sagen was alles richtig ist, da gibt es hier viel bessere Experten als mich. Ich kann nur erzählen was ich gemacht habe, mit knapp 100 MA. Aufteilung der Server in Tier 0 - 2. Zusätzlich habe ich innerhalb eines Tiers noch teilweise nach Funktionen getrennt. Aus dieser Aufteilung ergeben sich dann die einzelnen Identitäten. Domänenadmin wird ausschließlich zur Verwaltung der Domäne verwendet und darf sich auch sonst nirgendwo einloggen. Per GPO wird dieser automatisch von allen Workstations und Server entfernt. Natürlich auch nicht um einen Client in die Domäne aufzunehmen, entfernen, umzubenennen. Der Domänenadmin und auch alle anderen Identitäten die besondere Berechtigungen haben ist es per GPO verboten sich per Netzwerk zu verbinden. Das gilt natürlich nur für die Geräte, VMs denen die Identität nicht zugewiesen wurde. Den lokalen Adminaccounts ist es auch verboten sich per Netzwerk zu verbinden. RDP, WinRM usw. ist per Windows-Firewall auf bestimmte Endpunkte beschränkt. Schwachpunkt ist der Adminrechner, aber auf diesem gibt es kein Internet und auch keine Emails. Telefon, Alarm, Feuer, Zugangssysteme usw. alles in separaten VLANs Backup (geprüft und Wiederherstellung geübt) mehrfach online und offline. Doku für den schlimmsten aller Notfälle. Das Hantieren mit den unterschiedlichen Logins finde ich gar nicht schlimm. Es hilft aber ungemein, wenn man die Passwörter auswendig kennt. Sonst steht Du irgendwann im Keller und kannst nichts machen, weil dein bevorzugter Passwortsafe da nicht läuft. Grüße und schönes Wochenende

Das habe ich tatsächlich gemacht. Bei mir scheint alles OK. Auch der Selektor2 bei DKIM funktioniert, der ja bei der Einrichtung manchmal erst nach dem Rotieren der Keys funktioniert. Ab und zu nutze ich mail-tester.com, der sagt mir zwar ab und zu, dass die IP von der Emails gesendet werden auf irgendeiner Blacklist steht, aber da das eine Microsoft-IP ist, kann ich da auch nichts machen. Ich bekomme gar kein NDR. Sein Spamfilter fischt die Email einfach weg. Also er nimmt Sie aus meiner Sicht an, stellt die Mail aber nicht zu. Ich muss mal schauen, ob ich jemand ans Telefon bekomme, der da nicht nur "Stille-Post-Antworten" weitergibt. Vielen Dank an euch.

Vielen Dank für die Bemerkungen. Alles klar, ich werde empfehlen das zu lassen und den Rest ordentlich zu machen. Aber auch der Hostname lässt sich im Microsoft-Universum, meine ich, so nicht prüfen. Die Email wird z. B. von einer IP: X.X.X.X und dem Hostnamen EURXX-DBX-obe.outbound.protection.outlook.com gesendet. Die rDNS sagt dann aber die IP: X.X.X.X gehört zu mail-dbXeurXXonXXXX.outbound.protection.outlook.com. Darauf habe ich ja keinen Einfluss. Grüße und einen schönen Abend

Guten Tag, ein Kunde lehnt Mails von mir ab. Sein Spamfilter prüft per Reverse-DNS, ob die IP zur Domäne passt. Interessanterweise macht er das, obwohl SPF, DKIM, DMARC korrekt konfiguriert ist. Er will halt auch einen gültigen Reverse-DNS. Ich kann aber bei Exchange-Online gar keinen rDNS setzen. Lt. meinen Tests ändert sich das ja ständig. Wenn SPF, DKIM, DMARC alles simmt, ist es doch Unsinn eine Email wegen fehlendem rDNS abzulehnen, oder? Grüße

Guten Tag, ich habe die Anforderung für ein Partnerunternehmen eine Applikation zur Verfügung zu stellen. Da ich die IT des Partnerunternehmens als nicht vertrauenswürdig einstufe, soll das komplett getrennt von *meinem* Netz stattfinden. Das Partnerunternehmen hat ein AD und würde auch gerne die Benutzer aus diesem AD verwenden. Da ich die IT des Unternehmens als "Kraut und Rüben" einstufe, will ich alle Eventualitäten absichern. Lokal bei mir ein separates VLAN, von diesem VLAN gibt es keinerlei erlaubte eingehende Verbindungen in die anderen Netze ==> VLAN 90 Die VMs laufen auf einem separaten Host, der ebenfalls in einem separaten VLAN ist ==> VLAN 91 VPN vom Partnerunternehmen in das lokale VLAN 90 Lokal gibt es ein SQL-Server, RDSH und ein RDSH-Gateway Die Applikation wird auf dem RDSH installiert. Auf dem RDSH ist Applocker aktiv und natürlich korrekt konfiguriert. Zugriff auf die Applikation / RDSH nur via HTML5-Client oder RDP-Client, Port 443 (über das Gateway) Direkte RDP-Verbindungen würden vom Partnerunternehmen aus nicht erlaubt, ebenso die Anmeldung mit lokalen Usern. Bis auf den Host würde ich alle VMs in das AD des Partnerunternehmens aufnehmen, so können die Nutzer ihre gewohnten Zugangsdaten verwenden. Firewallkonfiguration vom Partnerunternehmen in das VLAN, HTTPS und alles was die Domäne braucht: https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts Nun stelle ich mir die Frage, ob es irgendeinen denkbaren Weg gibt, wie Malware aus dieser Umgebung ausbrechen und auf mein lokales Netzwerk übergreifen könnte. Zugangsdaten aus dem lokalen Netzwerk landen niemals im VLAN 90/91. Es gibt keine erlaubten eingehenden Verbindungen aus dem VLAN 90/91 in *mein* Netz. Auch die Firewall ist nicht aus diesem VLAN erreichbar (Konsole, Konfigurationswebseite), ebenso natürlich nicht die Switche, einfach nichts. Aber Es wird per RDP / HTML5 vom lokalen Netzwerk auf die Applikation im VLAN zugegriffen ==> Sicherheitslücke im RDP-Client die sich irgendwie ausnützen lässt. Ein Backup (SQL-Server *.bak) der Applikation ist notwendig und soll in das lokale Backup integriert werden. Dazu würde aber das Backup aus dem lokalen Netzwerk abgeholt. Also eine ausgehende Verbindung vom lokalen Netzwerk per SMB in das VLAN 90/91. Solles es jemand schaffen die Domäne des Partnerunternehmens zu übernehmen, könnte dieser jemand z. B. per GPO (Anmeldeskripte usw.) versuchen Malware auf dem RDSH zu installieren. Fazit: Es ist nicht auszuschließen, dass die VMs kompromittiert werden, weil diese eben Mitglied der unsicheren Domäne sind. Der einzig denkbare Weg wie die Malware (lateral Movement) in *meinem* Netzwerk aktiv werden könnte, wäre der Weg über den RDP-Client. Liege ich hier richtig oder habe ich an etwas nicht gedacht? Grüße und noch einen schönen Tag.

Was lange währt… Ich musste immer wieder drüber nachdenken, warum ich ausgestellte EFS-Zertifikate habe, obwohl das ganz sicher nicht genutzt wurde. Die Lösung ist KeePass. Speichert man da Anlagen und schaut man sich diese an und nutzt einen externen Viewer, verschlüsselt KeePass das ausgelagerte File und schwups hat man ein Zertifikat und weiß nichts davon.

Mein Fehler, falsche Abkürzung . Nicht viel. Ich dachte nur ich schaffe es "aufgeräumter", weil ich sowieso schon diverse USB-Geräte aller Art im Netzwerk verfügbar habe, nur halt nichts mit 10 Gbit-Anbindung.

Habe ich auch schon gemacht, aber mein Client ist mit 1 GB Ethernet (ca. 110 MB/s) angebunden. Das "gesuche Gerät" würde im Keller mit 10 GB angebunden werden. Wenn es dann mal > 3 TB sind reicht ein Arbeitstag nicht aus. Da sind so knapp 200-250 MB/s angenehmer. Aber klar, vielleicht ist das spezielle Gerät eine einfache Workstation mit Windows 11 und 10 GB NIC.

Guten Tag, evtl. passt die Rubrik nicht, ich wusste aber auch keine bessere. Ich muss hin und wieder sehr große Dateien von USB-Festplatten auf ein Storage (SAN) kopieren. Dafür gibt es einen speziellen Host. Dieser Host hat aber Probleme USB-Festplatten zu erkennen. Manchmal geht es, manchmal nicht. Neuinstallation und auch alle Updates helfen nicht. Evtl. irgendeine Inkompatibilität. Auch der Lenovo-Support kennt keine Lösung. Ich suche nach einer Lösung USB-Festplatten im Netzwerk anzuhängen und möglichst schnell deren Inhalt zu kopieren. Für andere Dinge nutze ich die Geräte von Silex. Funktionieren sehr gut, aber halt maximal so 80 MB/s. 10 GB Netzwerk haben die auch nicht. Kennt jemand von euch eine Lösung USB-Festplatten im Netzwerk (10GB) möglichst schnell anzubinden. Wenn mein Host dann mal geht, kopiert der mit 200-250 MB/s. Wenn es nichts in der Art gibt, bleibt wohl "nur" ein PC mit 10 GB NIC. Aber vielleicht gibt es eine andere Lösung. Viele Grüße

Wenn Du die Quarantäne nutzt: Admin-Center, Sicherheit, überprüfen. Da kannst Du Mails freigeben und bei der Freigabe zur Prüfung an MS senden.

Für den Fall, dass das hier jemand, so wie ich, das mit klick und bunt macht. Ich habe das jetzt einige Male probiert, mann muss diese Reihenfolge einhalten, sonst kann man sich nicht mehr an /ecp anmelden. Dann muss es mit Powershell repariert werden. Windows-Authentifizierung einschalten: zuerst OWA und dann ECP Windows-Authentifizierung abschalten (z. B. FBA): zuerst ECP und dann OWA. Hoffentlich ist das jetzt nicht auch schon seit Exchange 2007 so *duckundweg*.

Nein, danke.

Aber besser spät als nie .

Nein, das hatte ich in einem anderen Thread:

So, nun klappt das. Mal wieder ein klarer Fall von: "Kaum macht man es richtig, geht es." Ich habe die Einstellungen direkt im IIS geändert, das mag der Exchange wohl nicht. Man muss es im Exchange machen. Merker: Fummel nicht am IIS rum, wenn es dafür eine Option im Exchange selber gibt!

Genaugenommen gibt es kein Problem, außer das mit dem Anmelden, da forsche ich noch. Ich will nur verstehen was, warum, wie und wieso genau so und nicht anders.

Vielen Dank. Ich habe noch ein lokales Relay das nach O365 sendet, weil es noch ein paar alte Drucker/Scanner/Gerätschaften gibt die Mails versenden sollen, aber teilweise noch nicht einmal eine Authentifizierung oder nur TLS 1.0 können. Schönen Abend noch...

Guten Abend, um einen Exchange 2016 der noch auf W2K12R2 läuft wegzukriegen, soll ein Exchange 2016 nach 2019 migriert werden. Wobei migrieren falsch ist, der Exchange hat ja keine Postfächer mehr, liegen alle bei O365. Der Exchange 2019 soll nur zur Verwaltung der AD-Attribute verwendet werden. Der Exchange 2016 soll nicht einfach abgeschaltet, sondern ordentlich deinstalliert werden. Nun gibt es da aber noch die Systempostfächer in der DB des Exchange 2016. Ist es richtig, dass die Systempostfächer in die DB des neu installierten Exchange 2019 verschoben werden müssen. So lange die noch da sind, kann der Exchange 2016 nicht deinstalliert werden. Im Prinzip also wie eine "normale" Migration, nur dass es nur die Systempostfächer gibt. Liege ich hier richtig? Grüße und ein schönes Wochenende

Ja, da bin ich jetzt in die völlig falsche Richtung abgebogen. Aber bei Default (ist ja an 443 gebunden) ist Windows-Authentifizierung per default nicht aktiv, aber wenn ich das aktiviere, geht es auch nicht. Das Zertifikat ist es auch nicht, das war auf dem anderen Server auch nur Remote ein Problem. Default bei einen frisch installierten Exchange sieht das so aus: Default Web Site/ecp | Anonyme Authentifizierung aktiviert Default Web Site/ecp | Standardauthentifizierung aktiviert (alles andere deaktiviert) Default Web Site/owa | Standardauthentifizierung aktiviert (alles andere deaktiviert) /ecp leitet bei einem Exchange 2019 nach /owa um. Ich dachte Windows-Authentifizierung aktivieren bringt mir den Erfolg, dass ich mich auf dem Exchange selber nicht nochmals einloggen muss, aber da fehlt mir noch was. Ich muss weiter schauen. Für den Fall, dass ich da falsch denke. Um den Exchange zu verwalten ruft Ihr auch https://exchange/ecp auf, oder?

Im IIS heißt das Exchange Back End Ich habe noch weitere IIS, da funktioniert das so. In einem anderen Forum schreibt einer ohne nähere Angabe man müsse Delegierungen für das Computerobjekt einrichten. Aber das gibt es auch beim alten Exchange nicht. Ich verwalte da den Exchange, lege User an usw. die dann zu Azure sychronisiert werden. Die Powershell ist mir da etwas unbequem. Machst Du alles per Powershell? Oh nein, Kopf wie Sieb. Da hat es auch nicht mit einem selbstsignierten Zertifikat funktioniert, sondern erst nach dem ich mir ein Zertifikat von der lokalen CA ausgestellt und zugewiesen habe. Muss ich probieren.

Ich stehe auf der Leitung. Für "Exchange Back End/ecp" ist die Formularauthentifizierung deaktivert Für "Exchange Back End/ecp" ist die Windows-Authentifizierung aktiviert (HTTP 401 - Abfrage) Windows-Authentifizierung Anbieter sind Negotiate, NTLM (in dieser Reihenfolge) Die Webseite https://exchange ist in "Lokales Intranet" zugeordnet Die verstärkte Sicherheitskonfiguration ist deaktiviert (sonst lässt sich HCW nicht ausführen) Habe ich was falsch verstanden?

Guten Abend, wie kann ich erreichen, dass ich bei einem Exchange 2019 beim Aufruf des EAC auf dem Server selber mich nicht nochmals authentifizieren muss. Der angemeldete User hat bereits die notwendigen Rechte. Ich meine beim Exchange 2016 irgendwas separat gemacht zu haben, aber leider war die Doku damals so eher mittelgut . Für einen kleinen Schubs in die richtige Richtung wäre ich dankbar.