wznutzer

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.

Herzlichen Dank für die Infos. So hatte ich das bisher. Dann kann man den HCW nach der Stelle an der man die kostenlose Lizenz abholen kann abbrechen.

Hallo, wenn ich einen Exchange lokal nur noch zur Verwaltung der AD-Attribute nutze, weil alle Postfächer in der Cloud sind (für alte Drucker noch ein Relay), muss man bei der Installation trotzdem den Hybrid Wizard ausführen, aber warum? Was macht der? Ich benötige ja keinerlei Routing (Minimal Hybrid, Modern Topologie) und die AD-Attribute werden durch den Azure-Sync übertragen. Auch die Migration ist schon länger her. Evtl. hat mir jemand von euch einen Link zum Nachlesen?

Bezüglich des Problems des Hängenbleibens: Nachdem ich die Vorlage und das Register Kryptografie einmalig ohne Netzwerkverbindung angewählt habe, ist das Problem verschwunden. Seltsam, aber der Rest scheint zu funktionieren. Aber bei Gelegenheit komplett neu machen um dann ganz sicher nie wieder dran denken zu müssen ist bestimmt besser.

Ich weiß . Das seltsame ist ja, dass fast alle Zertifikate munter erneuert werden, aber niemandem bewusst ist, dass das verwendet wird. Ich bin selber dabei und ich weiß ganz genau, dass ich das nicht verwende .

Das wird wohl das Beste sein. Die DCs holen sich ja automatisch Zertifikate. Lassen sich die EFS-Zertifikate der Nutzer übernehmen, wobei alle mit denen ich gesprochen habe, ist nicht bewusst, dass sie jemals eine Verschlüsselung verwendet haben.

Oh shit... Ich habe mich darauf verlassen und das eher als Empfehlung gesehen https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/move-certification-authority-to-another-server

Die CA heißt noch gleich, aber der Server auf dem die CA läuft hat einen anderen Namen. Weil Microsoft das so beschrieben hat, dachte ich, das sei kein Problem Das ist Plan B um den IIS schnell zum Laufen zu bringen. Aber eine kaputte CA will ich auch nicht dauerhaft haben. Es sind halt EFS-Zertifikate ausgestellt, deswegen habe ich die migriert und nicht einfach weggeworfen.