cj_berlin

Hier zum Beispiel ein Snippet, das das Mail-Attribut eruiert, in der Annahme, dass es nur eine Domäne im Forest gibt: $ds = New-Object System.DirectoryServices.DirectorySearcher $ds.Filter = "(&(objectClass=user)(sAMAccountName=$($env:USERNAME)))" $null = $ds.PropertiesToLoad.Add("mail") $user = $ds.FindOne() $user.Properties["mail"][0]

Dafür benutzt man System.DirectoryServices, das ist in PowerShell unter Windows immer verfügbar.

Für diejenigen, die dort arbeiten, ist 1x doch durchaus eine praxisrelevante Zahl Aber klar, natürlich gibt es nur sehr wenige. Daher finde ich die Diskussion um jahrelang nicht gerollte Passwörter immer so spannend...

Moin, Users von Shared Mailboxes sind normalerweise deaktiviert Alle anderen: Least Privilege plus entweder Group Policy oder Authentication Policy.

Also habt ihr NTLM schon abgeschaltet, so dass Pass-the-Hash nicht mehr ohne weiteres funktioniert?

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.

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.

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.

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.

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.