cj_berlin

vor 6 Stunden schrieb Dayworker:

Nein, wir gehen auf einen nicht DC, öffnen dort die Ereignisanzeige, dann öffnen Protokoll eines anderen Computers. Dann öffnet er die Logs zum Anklicken, aber auf as Systemlog z.B. kommt dann Zugriff verweigert. 

Das hat in meiner Erfahrung mit "Event Log Readers" zu 100% funktioniert. Firewall?

Geht es um den Zugriff per PowerShell? Da gibt es zusätzliche Problemfelder.

vor 3 Stunden schrieb NorbertFe:

 

Hallo,

 

MS hat gerade mal ein Update der Roadmap veröffentlicht:

Und so sieht diese Roadmap grafisch aus:

Moin,

Tip #1: Die Verwendung von RODC noch einmal überlegen. Ist es *wirklich* ein Standort mit schlechter physischer Sicherheit, wo der DC physikalisch entwendet werden könnte? Falls nicht, ist RODC dort falsch.

Tip #2: DNS auf einem Member-Server installieren, wenn es schon nicht in AD integriert sein soll. Oder halt sogar auf einem Workgroup-Server.

Redest Du von diesem Thread oder von dem Zustand der Welt?

imap.something ist mit Sicherheit kein Posteingangsserver, auch wenn es in Outlook so heißt  Da müsste der Server hin, auf den der MX zeigte, bevor Du ihn auf Exchange umgestellt hast.

vor 3 Minuten schrieb Cryer:

Das ich damit keine Verbindung ins Geschäft aufbauen oder von unterwegs auf meine private NAS zugreifen kann.

VPN outbound zu einer IPv4-Adresse: Kann ich nicht bestätigen. Ich habe einen 1&1-Anschluss mit einer DSLite-IPv4 und bisher keine Probleme gehabt. Meine Kunden und Arbeitgeber hatten sowohl SSL-VPN als auch IKEv2, beides ging.

vor 25 Minuten schrieb RalphT:

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

Kommt darauf an, was für Dich die "eigentliche" Replikation ist. Das hat mit der AD-Replikation vielleicht nichts zu tun, dafür aber mit der DFS-Replikation, denn die SYSVOL-Inhalte kommen nicht "mit der Macht" auf die anderen Domain Controller.

Mit welchem DC Dein GP Editor verbunden ist, kannst Du direkt im Editor sehen:

Möglich ist es schon, schön ist anders. Meinst Du nicht, dass Du 60 Postfächer auch übers Wochenende umgestellt bekommst?

Um das ursprünglich Gewünschte umzusetzen, muss die Empfangsdomäne auf nicht authoritativ gesetzt werden und ein Sendeconnector für diese Domain angelegt werden, der auf Strato zeigt.

Moin,

kannst Du bitte den Link am Ende des letzten Posts entfernen?

Checkt mit den Herstellern euerer SQL-Anwendungen, ob sie eine Azure SQL-Datenbank supporten würden. Kommt vermutlich billiger als einen dedizierten Server anzumieten, und es ist zumindest ein bisschen mehr Security vorgeschaltet als bei einem nackten SQL-Listener.

Checkt mit den Herstellern, ob ein "Offline-Replikat" mit SQL Express o.Ä. möglich ist. Das wäre vermutlich die beste Lösung, aber vermutlich werden nicht alle drei Anwendungen das können. 

Ansonsten, wenn es so gar nicht anders geht: TLS am SQL-Listener erzwingen wäre ein guter erster Schritt, um die Credentials und die Daten wenigstens vor dem Abhören in Transit zu schützen.

Idealerweise findet ihr eine Firewall, wo ein Mitarbeiter seine IP "on demand" freischalten kann (ich gehe jetzt davon aus, dass wenigstens einige der Quell-IPs dynamisch sind).

Einen Port irgendwo im oberen Bereich für den Listener verwenden, um zumindest die "dummen" Angriffe auf Port 1433 nicht abwehren zu müssen.

Lange Passwörter. Sehr lange Passwörter. Auch hier könnte die Anwendung euch einen Strich durch die Rechnung machen.

Eigentlich bin ich bei @testperson - VDI, welcher Art auch immer, ist immer a. sicherer und b. robuster als Remote-Zugriff auf SQL. Und CAD über WAN haben wir mit Citrix HDX 3D Pro schon vor 13 Jahren gemacht. Und auch das kann man inzwischen mieten und muss nicht eine eigene Farm für 11 Leute bauen.

Moin,

mit "SBS" meinst Du hoffentlich "SMB"?  

SMB ist für WAN nicht ausgelegt, hat aber in den neueren Dialekten einige Optimierungen, die automatisch greifen. Bevor Du dich also beim Troubleshooting auf VPN konzentrierst: Ist es Dir möglich, ein wirklichen Netzwerk-Geschwindigkeitstest, z.B. mit iPerf, zu machen? Wenn Du auch da diese Unterschiede feststellst, dann kann man schauen, wo man bei VPN ansetzen kann. Gibt es da die Unterschiede nicht, dann ist es Dein SMB-Protokoll, das für die stark variable Performance sorgt. Auch da gibt es Stellschrauben, die würde ich aber ohne Not nicht bemühen.

Stimmt, da war was. Dann muss man, wenn es aus irgendeinem Grund nicht möglich ist, das Default-Verhalten auf Block zu setzen, alle unerwünschten Ranges explizit blockieren. Viel Spaß damit - aber mit viel Aufwand ist auch das machbar. Ob's sinnvoll ist, ist eine andere Frage.

Je nachdem, wie das Netz segmentiert ist, würde ich als Konzept-Vorschlag noch den RD Gateway einwerfen, aber das hat wieder Abhängigkeiten, die man bedenken muss.

Moin,

wenn die Default-Regel in beiden Fällen auf "verweigern" steht, dann musst Du für den Zugriff auf den Server die zulässigen Quell-IPs angeben und für den Zugriff von diesem Server aus die zulässigen Ziel-IPs. Ports sind in beiden Fällen 3389 TCP + UDP.

Wenn die Default-Regel auf "zulassen" steht, gehört das ganze Konzept auf den Prüfstand und nicht nur RDP, Aber für RDP müsstest Du dann zwei Regeln haben: eine wie oben und eine, die RDP zumacht, aber tiefer in der Reihenfolge steht.

Ich habe auf diesen Kommentar gewartet @daabm  

Doch, kann ich. Aber bis dahin, nutzt man einfach Schattendomänen und Kontakte.

vor 11 Stunden schrieb NorbertFe:

Ich dachte, das wäre sowieso das Ziel. Deswegen schrieb ich ja von „während der  Migration“. Je kürzer der Migrationszeitraum, umso besser.

deswegen schrieb ich ja "schnell" - im Sinne von, so schnell, dass man sich mit kruden Workarounds gar nicht erst aufhalten muss

Moin,

ich werfe mal ein anderes Konzept ins Rennen: Ihr migriert die zwei Umgebungen schnell zu euch rüber und betreibt nur eine Exchange-Organisation. Die anderen Sites können gern wieder einen lokalen Exchange kriegen, falls die WAN-Performance ein Problem ist.

Die AD-Forests der neuen Häuser können ja bis zur endgültigen Migration da bleiben, ihr betreibt euren Exchange also für die anderen beiden Häuser als Ressourcen-Forest.

Mit dem im OP skizzierten Konzept werdet ihr des Lebens nicht froh. Und auch mit dem Gateway ist es so eine Sache - die wenigsten von ihnen können den Recipient Type sauber auswerten. Spätestens wenn das Thema MailUser auf den Tisch kommt, wird es wieder spannend.

Farbtiefe von 32-Bit absenken deaktiviert RemoteFX und somit alle WAN-Optimierungen von RDP --> das würde ich im Einzelfall *richtig* prüfen, bevor ich das als generelle Handlungsempfehlung rausgebe.

UDP deaktivieren über VPN ist natürlich Pflicht, denn sonst kapselt man UDP in TCP, was alle Vorteile von UDP sowieso zunichte macht  

Nur mal als schnelle 2 ct.

Ich meine den Server, der laut Autodiscover für den Zugriff auf die öffentlichen Ordner verwendet werden soll.

Ich würde sagen, Autodiscover. Mach mal einen Autodiscover-Test im Outlook und schau, welchen Server Du zurückgegeben wird.

Moin,

in diesem Thread wurde NICHT bestätigt, dass man Intune verwenden muss, nur dass Du Entra ID Premium brauchst, aus welchem Paket auch immer das kommt. Allerdings ist Deine Einschätzung generell zutreffend, dass Cloud-Dienste für den jeweiligen Betreiber eine Gelddruckmaschine darstellen.

Als Versuch, dies in Relation zu setzen, könnte man natürlich erwähnen, dass die Initiale Bereitstellung dieser Dienste einen Aufwand darstellte, der für uns Normalsterbliche auch schwer zu begreifen ist. Aber das hilft dem einzelnen Betroffenen natürlich wenig.

Moin,

das, was Du suchst, nennt sich "Conditional Access Policies" und wird als Teil von "Entra ID Premium" angeboten. Je nachdem, was ihr gebucht habt, könnte es bereits drin sein (M365 E3/E5/Business Premium) oder auch nicht (Business Basic/Standard). Intune musst Du nicht zwingend nutzen, aber wenn Du Endgeräte in die Cloud statt ins AD joinen willst, hilft es schon enorm. Generell spielt die Geräteverwaltung in den Conditional Access erst hinein, wenn Du Policies definieren willst, die "Firmengeräten" anderen Zugriff gewähren als "privat verwalteten Geräten"-

Moin,

in diesem Fall kannst Du den Exchange nach Anleitung deinstallieren. Allerdings wird dabei der Installer auch das mail-Attribut bei den Usern löschen, so dass Outlook-Autokonfiguration nicht mehr funktioniert. Daher am besten das mail-Attribut bei allen Usern vor der Deinstallation exportieren und danach wieder auf den vorherigen Wert setzen.

Ich habe das bei Microsoft eingekippt, jemand untersucht das Thema, aber ohne irgendwelche Zusagen. Sie sind doch wirklich jedes mal überrascht, dass Leute den Kram, den sie sich ausgedacht haben, wirklich benutzen  

https://developers.redhat.com/blog/2020/11/19/transitioning-from-docker-to-podman#about_podman