cj_berlin

vor 2 Stunden schrieb zahni:

Keine Exchange-Dienste außer SMTP ins Internet hängen. Für den mobilen Zugriff gibt es andere Lösungen, z.B. von Blackberry.

...und die sind definitiv und erwiesenermaßen unhackbar und frei von Fehlern, die eine Sicherheitslücke offen lassen 

vor 58 Minuten schrieb =BT=Viper:

Was wäre denn da der technische Hintergrund?

Exchange speichert nahezu seine gesamte Konfiguration im AD, inklusive Zeitstempel und Watermarks. Das ist einer der Gründe, warum das Anfertigen von Snapshots einer Exchange-VM unsupported ist und ein Backup vollständiger Exchange-Server so orchestriert werden muss, dass zum gleichen Zeitpunkt auch ein AD-Backup erzeugt wird.

Moin,

ich empfehle - meist vergebens - meinen Kunden den Split Permissions Mode fast so lange wie es das gibt.

Ich empfehle - mit noch geringeren Erfolgsraten - Exchange grundsätzlich in einem separaten Resource Forest zu betreiben. Und dort wieder mit Split Permissions. Und den Trust des Ressource Forest gegenüber dem User Forest zu filtern.

Ich empfehle, Active Directory weder als Identity Management noch als Configuration Management zu missverstehen und folglich zu missbrauchen.

Ich empfehle, Admins in die Protected User oder, besser, in ein Authentication Silo. Und das kombiniert mit Tiering.

Die ersten zwei hätten die Übernahme des User Forests im vorliegenden Fall verhindert. Der dritte Punkt hätte, wenn man ihn konsequent umsetzt, den Wiederaufbau nach einer möglichen Übernahme des User Forests zu einer planbaren Übung statt zu einem Disaster gemacht.

In der Realität? Die Admins wollen doch nur Bequemlichkeit. Lieber alle paar Jahre einen Breach und Stress und Nachtschichten, als irgendwas in den eigenen Abläufen zu ändern.

Anderen Port für die anderen Webdienste wie Dein NAS.

Oder mehrere FQDNs für die gleiche IP und einen Reverse Proxy, der anhand des aufgerufenen FQDN weiterleitet statt anhand vom Unterverzeichnis.

Wenn Du /RDWeb weiterleitest, bekommst Du eben nur RDWeb und alles darunter. RD Gateway sitzt nicht in einem Unterverzeichnis, sondern direkt am Anfang.

Moin,

für RDG kannst Du keinen Context-Switch verwenden, das braucht die Weiterleitung von /

In einem freien offenen Forum kann keine verbindliche Rechts- oder Lizenzberatung erteilt werden.

Aber nach diesem Hinweis: Ich würde jetzt vorsichtig sagen, dass Du keine CALs brauchst, sofern der AADConnect-Server die Kommunikation stets selbst initiiert. Das dürfte bei Dir aber der Fall sein.

Bei Server 2019 scheinen sich diese Eval-Umwandlungsprobleme wirklich zu häufen. Ich würde daher keine Zeit verschwenden, den Server "einfach" neu installieren und das ganze als teures Lehrgeld im Hinterkopf speichern.

Eine nicht aktivierte Vollversion läuft ja eine ganze Weile. Wenn man sich theoretisch vorstellen kann, den jeweiligen Server später produktiv einzusetzen, sollte man keine Eval, sondern von vorn herein eine Vollversion dafür nehmen.

Wenn ich mich recht erinnere, darf eine Eval sowieso keine produktiven Workloads ausführen...

...und ein Loadbalancer macht das automatisch sicherer?

Von den 50% der Unix-Linux-Webserver weltweit, die von HeartBleed betroffen waren, werden die meisten hinter Loadbalancern gestanden haben...

https://freeloadbalancer.com/

vor 1 Stunde schrieb Moschi76:

 

Hat jemand die Lösung?

Die Quotas noch einmal drüberbügeln?

vor 4 Stunden schrieb Dirk-HH-83:

 

Hallo, 

 

scheinbar gibt es für die Exchange Powershell keine History oder?

 

%AppData%\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

 

Hast Du evtl. Exchange 2010? Da nutzt die Exchange-Shell noch PowerShell 2.0.

...indem Du ihn neu installierst? 

Aus dem Inhalt der Mail-Datenbanken wird er sich vermutlich nicht wieder infizieren, alles andere machst Du platt.

Moin,

es gibt keine Event-ID für "ka**e ist am Dampfen". Alle IDs aus dem Auditing sind einzeln genommen harmlos und ergeben erst bei der Korrelation ein Bedrohungsbild.

Hier ein Beispiel für 4727-4730:  https://www.lepide.com/how-to/track-and-audit-active-directory-group-membership-changes.html Wenn Du sie z.B. in rascher Abfolge siehst, könnte es bedeuten, dass jemand sich irgendwo ein anderes Loch gebohrt hat. Und da muss man die anderen Events haben und sie damit korrelieren.

...aber was hat das mit Deinen Kunden und deren Netzen zu tun? Die privaten IP-Bereiche sind extra dafür geschaffen worden, damit zig Netze den gleichen IP-Bereich haben können...

Moin,

wenn Deine Notebooks nicht in das WLAN des Kunden kommen, ist es doch vollkommen egal, ob die IP-Bereiche kollidieren oder nicht. Wenn sie aber da reinkommen, hast Du eh nicht zu entscheiden, welche Adressen eure Notebooks kriegen...

Zusätzlich wäre anzumerken, dass, sofern der Server nicht Teil einer DAG ist, eine Recovery-Installation eher mit dem Ölwechsel zu vergleichen ist als mit dem Verschrotten. Oder, falls noch Thrid Party-Zeug auf dem Server läuft, vielleicht mit einem Auspufftausch.

Klar hat man Respekt davor, wenn man es noch nie gemacht hat. Aber tatsächlich ist bei einem Standalone-Server nix großes dabei.

vor 13 Minuten schrieb Oli72:

Also Domäne aufsetzen und gut oder eine Cloudlösung.

Nur aus Interesse: Wie würde eine Cloudlösung da helfen?

Gerade eben schrieb Ja_Nosch:

 

Wobei ich da anmerken möchte, dass die 240 GB-Version z.B. der Intel DC S4610 bei den sequenziellen Schreibzugriffen nur  320 MB/s ausweist, während es bei der 480 GB-Version 510 MB/s sind.

Do wolltest für den Zweck ne HDD einbauen. Was schafft die?

vor 43 Minuten schrieb Dukel:

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.

...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...

vor 14 Minuten schrieb Ja_Nosch:

Produktiv für 1-3 User. Ja, Backupkonzept (auch über 2 Standorte) mit Synology-NAS ist gegeben.

Wichtig ist allerdings eher das Restore-Konzept  

vor 15 Minuten schrieb Ja_Nosch:

Und ja, als letzte Variante käme natürlich noch in Betracht: 2 x 240 GB-Intel-SSDs zusätzlich kaufen, die dann nur den Hypervisor beherbergen ...

Na endlich. Wäre auch das, was ich machen würde.

...weil Hyper-V, anders als z.B. ESXi, nicht im RAM läuft, und die Performance der System-HDD deswegen durchaus für die Gesamt-Performance relevant ist.

Insofern, um Deine Frage exakt zu beantworten: schon immer.

Moin,

ich würde niemals SSD und HSS auf einem Storage-Controller mischen. Nennt mich altmodisch, aber in meiner Welt gibt es damit nur Ärger. Einzige Ausnahme: reiner Pass-Through-Betrieb ohne jegliches RAID oder Controller-Cache, wie z.B. in S2D-Szenarien.

Und warum sollte man ausgerechnet für das Betriebssystem langsame HDDs nehmen?

Moin,

das letzte Mal, dass der Hyper-V-Server echte Vorteile gegenüber Standard hatte, war bei 2008R2. Da konnte Standard noch maximal 32GB RAM und kein Clustering, der Hyper-V-Server aber schon.

Moin,

das Flag "Allow key to be exported" ist ein Merkmal des privaten Schlüssels, nicht des Zertifikats, das diesen Schlüssel beinhaltet. Somit ist das Flag bereits gesetzt (oder halt nicht), wenn der CSR erstellt wird. Und es gibt meines Wissens unter Windows keine Möglichkeit, das zu unterbinden.