testperson

Hi, das sollte machbar sein, sofern du die T-Mobile Netze in Erfahrung bringst. Ich gehe aber davon aus, dass es sicherlich eine Reihe an Bot-Netz-Membern gibt, die ebenfalls T-Mobile nutzen und dich dann eben aus einer erlaubten Range attackieren. Neben "klassischem VPN" könnte ein MPLS / Provider Routing auch für Mobilfunk ein Ansatz sein, damit der Exchange nicht von extern erreichbar ist. Ansonsten eben noch der Ansatz "Reverse Proxy" / "Web Application Firewall" samt Pre-Authentication. Eine weitere Alternative - im Bereich Security - könnte durchaus Exchange online sein. Gruß Jan

Hi, meine Meinung dazu: W2K19 Storage Migration Services - Windows Server Forum - MCSEboard.de Hilft dir hoffentlich zumindest "indirekt". ;) Gruß Jan

Microsoft stellt jetzt für ältere / unsupportete CUs auch einen entsprechenden Fix bereit: March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server - Microsoft Tech Community Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: March 2, 2021 (KB5000871): Auf GitHub (CSS-Exchange/Security at main · microsoft/CSS-Exchange · GitHub) gibt es noch ein weiteres Script (CompareExchangeHashes.ps1), um die Installation auf infizierte Dateien zu durchsuchen.

Ich würde definitiv die hier genannten Pfade auf verdächtigen Inhalt prüfen (HAFNIUM targeting Exchange Servers with 0-day exploits - Microsoft Security): Bzw. eben den Microsoft Safety Scanner dafür nutzen: Microsoft Safety Scanner Download - Windows security | Microsoft Docs

Im Exchange Blog schreibt "Microsoft" in den Kommentaren dazu (https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/bc-p/2188076/highlight/true#M29753):

Hi, finde den Fehler: Gruß Jan

Hi, ggfs. könntest du noch überlegen, einen der DCs auf ein anderes Blech zu legen. Damit das mit den Lizenzen weiterhin aufgeht, wäre dann die Überlegung, ob du einen DC + Exchange auf einem "schwächeren" Blech betreibst und den weiteren DC samt Terminalserver auf dem anderen. Falls die Hardware noch nicht da ist, könntest du noch prüfen, ob du nicht mit einer (max.) 16 Core CPU oder zwei (max.) 8 Core CPUs (pro Host) zurecht kommst. Ansonsten: +1 für Standard / Datacenter inkl. GUI. Gruß Jan

Der Microsoft Security Scanner (MSERT.EXE) kann die bekannten Muster jetzt auffinden (Microsoft Exchange Server Vulnerabilities Mitigations – updated March 6, 2021 – Microsoft Security Response Center)

Hi, wenn USB in eine VM soll, dann würde ich immer auf USB Server setzen, die das USB Device dann über Netzwerk in die VM bringen. Ganz gute Erfahrungen haben wir mit den USB / Dongle Servern von SEH und WuT gemacht. Gruß Jan

Hi, der schnellste und einfachste Weg wäre vermutlich: Neue VM aufsetzen, durchpatchen, Exchange Vorbereitungen installieren, Exchange 2016 CU19 + Security Fixes installieren, Exchange / "Rest" konfigurieren, testen, "migrieren", alten Exchange deinstallieren und Server aus dem AD entfernen. Gruß Jan

Dann nimm doch einfach die passende SearchBase: # -SearchBase "CN=Computers,DC=manowi,DC=local -SearchBase $("CN=Computers,{0}" -f $curDomain.DistinguishedName) # OU Firma1 OU Lager OU Rechner -SearchBase $("OU=Rechner,OU=Lager,OU=Firma1,{0}" -f $curDomain.DistinguishedName)

Der Inhalt (HAFNIUM targeting Exchange Servers with 0-day exploits - Microsoft Security) wurde ergänzt: Hier findet sich das PowerShell Script zum Testen: CSS-Exchange/Security at main · microsoft/CSS-Exchange · GitHub Habe es grade mal auf knapp zehn Systemen getestet und auf einem System gibt es den Ordner "%exchangeinstallpath%\OABGeneratorLog" nicht. Ist das jetzt verdächtig oder durchaus normal?

Hi, $curDomain = Get-ADDomain -Current LocalComputer Get-ADComputer -Filter "Operatingsystem -like '*Server*'" ` -SearchBase $curDomain.DistinguishedName ` -Properties IPv4Address, OperatingSystem, OperatingSystemVersion, DNSHostName | Select-Object IPv4Address, OperatingSystem, OperatingSystemVersion, DNSHostName | Format-Table funktioniert doch prima. Anstatt "Format-Table" am Ende kannst du dann natürlich auch per "Export-Csv" alles in eine CSV schieben. Gruß Jan

OT: Ich werde definitiv mit einem Lächeln ins Wochenende gehen. :)

Hi, sollte es tatsächlich um einen LDAP Abgleich mit AD Connect halten, dann zitiere ich nochmal einen Teil meines Zitates: Ansonsten wirf mal hier (Teams für Schulen (msxfaq.de)) einen Blick drauf. Auf der Seite finden sich - meiner Meinung nach - halt schon genug Besonderheiten und ggfs. auch ein ortsfremder Dienstleister, der scheinbar bereits Erfahrung in diesem Bereich hat. Gruß Jan

Hi, habe den Storage Migration Services noch nie genutzt. Sieht für mich ganz "nett" aus. Bei einem reinen Fileserver wäre je nach Ausgangsituation durchaus ein In-Place 2012 R2 und weiter In-Place auf 2019 denkbar. Alternativ neuen Server aufsetzen und vorbereiten, vom alten Server die Freigaben aus der Registry exportieren. Danach den alten runterfahren, die virtuelle Disk umhängen, dem neuen Server alte IP/Namen geben und Freigaben importieren. (Der Storage Migration Service macht das letztlich nicht viel anders. Da werden die Daten kopiert / gesynced und nicht die virtuelle Disk umgehangen.) Solltest du nicht virtuell unterwegs sein, dann kann ich beim Storage Migration Service nicht helfen. Aber auch hier würde ich das eher händisch machen und bis zum Stichtag immer wieder mit Robocopy syncen und dann , wie oben, switchen. Sofern noch nicht im Einsatz, könnte man jetzt auch über DFS-N nachdenken, um es in Zukunft "noch entspannter" zu haben. Gruß Jan

AD Connect kann AFAIK auch "LDAP". Allerdings mit folgendem Hinweis: (LDAP synchronization with Azure Active Directory | Microsoft Docs)

Luxusproblem.. Wenn ich da so an die Hoster/Agenturen denke, die keine DNS Anpassungen erlauben oder diese dann durchaus hochpreisig umsetzen. ;)

Du musst _vermutlich_ den MX Record für die Domain und nicht die Subdomain setzen. Oder eben den MX der Subdomain checken.

Hast du denn im externen DNS beim Provider(?) den passenden Record für mail. der auf deine öffentliche IP zeigt?

Hi, was sagt denn ein nslookup -q=MX <deine Domain>.<tld> Gruß Jan

Hi, hast du mal die NTFS Rechte der Icons / des Ordners gechecked? Gruß Jan

Hi, ich bin mir bei Chrome nicht sicher und finde auf die Schnelle nichts Muss Chrome nicht noch "beigebracht" werden den "Enterprise Roots", also dem Windows Zertifikatsspeicher zu vertrauen, oder muss zumindest die RootCA in den Trust Store vom Chrome? Gruß Jan

Microsoft: Solarwinds-Hacker sahen Code für Azure, Exchange und Intune | heise online Microsoft: Solorigate attackers grabbed Azure, Intune, Exchange component source code - Help Net Security Microsoft Affirms Solorigate Attackers Saw Azure, Intune and Exchange Source Code -- Redmondmag.com

BTW.: Ist das jetzt die erste "Überraschung" aus dem Solarwinds Hack (Sunburst / Solorigate), wo - laut Berichten - bei Microsoft Teile vom Exchange Source Code abhanden gekommen sind?