Dukel

Schau mal:

https://www.heise.de/select/ix/archiv/2019/8

Marktübersicht Privileged-Identity-Management-Software

Wieso das ganze auf Root Servern? Wenn man das nicht im eigenen RZ haben möchte, dann kann man sich ja auf einen Exchange Provider einlassen. Exchange Online z.B.

Allgemein oder wegen der aktuellen Lücken?

Ich zietiere einmal https://www.msxfaq.de/exchange/update/hafnium-exploit.htm#was_tun_bei_erkanntem_einbruch_

Quote

Stellen Sie sich vor, sie haben eine PowerShell auf einem Server mit "LocalSystem" und "ExchangeTrustedSubsystem" in einem fremden Netzwerk und sie haben kriminelle Energie. Was könnten sie alles anstellen? Ziemlich viel und auf ziemlich vielen Servern.

 

Eigentlich hat das Gesamtsystem als kompromittiert zu gelten. Es kann keine allgemein gültige Empfehlung geben, den Sie wissen ja nicht, wie tief der Angriff war und welche "Hinterlassenschaften" in ihrem System zu finden sind.

Wann man das mit dem Kunden abstimmt ist ja egal. Am besten, wie bei euch, vorher.

Was ist das denn für ein Server wenn es nur ein Netzteil gibt und kein ECC RAM?

Vielleicht abschließend zu dem Thema. Man trägt die Verantwortung ja nicht selbst, wenn man nicht der GF ist.

Wenn man Dienstleister ist, stimmt man das Thema mit dem Kunden ab. Dieser muss ja eine Risiko Analyse tätigen und eine Entscheidung fällen. Als Angestellter Admin, stimmt man das mit seinem Vorgesetzen ab.

Bei 1-3 User wirst du, wenn kein HPC damit gemacht wird, keine Performance Probleme merken, egal welche SSD du dort einbaust.

12 minutes ago, cj_berlin said:

...oder Du legst für die Freigabe einen Benutzer dort an, wo die Freigabe liegt, und teilst die Credentials demjenigen Benutzer mit, der sie nutzen soll. Dann musst Du beim Kennwortwechsel (des zugreifenden Benutzers) nicht herumrennen und es überall zeit- und inhaltsgleich wechseln...

Dann kann man gleich auf Berechtigungen verzichten.

Ich würde aber mir keine Gedanken über irgendwelche Workarounds suchen. Entweder werden Berechtigungen benötigt, dann macht man es richtig oder es werden keine benötigt, dann lässt man es sein.

Man kann Lokale Benutzer erstellen (auf jedem Rechner) und die Kennwörter die selben nutzen.

Dann muss man aber bei einem Kennwort Wechsel, dies auf jedem Rechner durchführen.

Entweder keine Zugriffsberechtigungen oder eine Zentrale Benutzerverwaltung. Alles andere macht kein Spaß.

Ist das ganze für zu Hause oder zum basteln oder Produktiv?

Backup/Restore sollte man sich auch vorher Gedanken machen.

Für OWA habe ich folgenden Link gefunden

https://www.alitajran.com/remove-old-exchange-owa-files-to-free-up-disk-space/

Ich denke für ECP gilt das selbe.

2 hours ago, Alman2 said:

 

Ich weiß, VPN wäre hier die richtige Vorgehensweise, allerdings kann ich nicht immer von jedem Rechner, von dem ich gerne per RDP nach Hause will, den entsprechenden VPN Zugang einstellen oder irgendwelche VPN Tools installieren.

Wenn du der einzige sein willst, der auf deinen Rechner zu hause zugreift, dann kannst du das schon machen.

Alternativ ein RDS Gateway, was aber mehr Infrastruktur bedeutet.

Dann finde heraus, warum das nicht geht.

Sind Snapshots vorhanden?

Evtl. geht das mittels vmkfstools.

Wie willst du die Disk dann erweitern, wenn du Sie nicht vorher vergrößerst?

Eine Partition mit einer weiteren Disk will man nicht erweitern.

Man kann das ganze auch ohne Dynamische Disk vergrößern.

Was läuft auf dem Server? Evtl. kann man Temporäre Daten berenigen.

Was _genau_ möchest du haben?

Willst du den Service User des SQL Dienstes ändern oder einen User haben, der diese Dienste starten und stoppen kann?

Wenn es mehr als zwei Stufen sind ist das eher eine größere Organisation, in der entsprechendes Know-How und Prozesse vorhanden sind.

Wenn du noch kein CU23 hast, dann installiere CU23 (und entsprechendes .Net Framework) und danach den Security Fix.

Die schon gepostetete Seite https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b verlinkt auf den Download unter https://www.microsoft.com/en-us/download/details.aspx?id=102775

Wenn Supportetes CU (2013: 23, 2016: 18 oder 19, 2019: 7 oder 8) vorhanden, dann optional Upgrade auf aktuelles CU _und_ dann Installation des Fix (KB5000871).

Wenn älteres CU als oben genannt, dann Upgrade auf aktuellstes CU und Installation des Fix.

Ganz einfach eigentlich.

Ich würde auch eher nach einem vorhandenen Tool schauen.

Man bekommt als Neuling schnell etwas hin, aber das ist dann nicht wirklich wartbar oder man beauftragt jemanden, das ist aber dann nicht günstig.

Es sind zwei unaabhängige Dinge!

Auch wenn der interne DNS Server genutzt wird heisst das ja nicht, dass der Internet Traffik nach extern geht.

Höchstens die DNS anfragen, die aber kein Problem sein sollten.

Das nennt sich Split Tunneling.

Wie du das in deiner Konstellation einrichtest kann ich dir nicht sagen. Du willst aber keinen Workaround bauen!

Btw. Es heisst FQDN (Fully Qualified Domain Name)

Das Problem mit dem Hyper-V Server ist im Troubleshooting.

Der Tägliche Betrieb ist kein Problem, geht alles Remote. Wenn es zu Problemen kommt, fehlt halt einiges an Tools auf dem Host selber.

Was für ein Windows Connector und was für ein LDAP Server?

Ist ein Active Directory im Einsatz?