cj_berlin

Wenn der Empfänger die Mails nicht vorfiltert, kann der Absender *den Maschinen des Empfängers* grundsätzlich nicht helfen. Eine Signatur ist wenigstens etwas, was man den *Mitarbeitern* des Empfängers an die Hand geben kann...

GPO Analyzer aus dem SCT.

Soweit ich es als Nicht-Exchange-MVP überblicke, in den hier angesprochenen Punkten noch nicht.

Ja, extrem! Das EOL von Server 2019 steht ja quasi vor der Tür... Welche bahnbrechenden AD-Features, die ein 2022er DC einem 2019er voraus hat, werden durch die fehlende Unterstützung gebremst? SCNR

...oder auch nicht - kommt auf den Inhalt des Reports an

Nö, am sendenden Ende könnt ihr nur für den korrekten SPF Record sorgen. Auswerten muss ihn dann der Empfänger. Könnt ja anfangen, alle Mails zu signieren und euren Kunden mitteilen, dass Mails ohne Signatur definitiv nicht von euch sind...

Moin, Du musst unterscheiden: den NDR bekommt ihr, weil es den Empfänger c.muellerk@euredoma.in bei euch nicht gibt das wird aber erst dadurch möglich, dass euer Server die Mail von Absender o,maier@euredoma.in vom Server smtprelay04.b.hostedemail.com akzeptiert Am ersten Sachverhalt kannst Du nichts ändern, dem zweiten müsst ihr mit dem SPF Record begegnen UND einem Mail-Gateway, der den Record prüft und Mails, die von falschen Servern kommen, bereits im SMTP-Dialog (nach dem MAIL FROM:) ablehnt.

Wie gesagt, wenn euer Mail-Gateway den SPF Record prüft und die Mails von falschen Servern auch wirklich verwirft, dürfte es die Mails in Exchange gar nicht geben.

OK, wenn die SMTP-Domain wirklich eure ist, dann müsstet ihr euren SPF Record mal auf Vordermann bringen

Wie meinst Du "genauso aussehen" genau? Falsche SMTP-Adresse aber "richtiger" Anzeigename?

Moin, PowerShell starten Install-Module ExchangeOnlineManagement -Scope CurrentUser Import-Module ExchangeOnlineManagement dann die Admin-Zugangsdaten bereithalten und Connect-ExchangeOnline (es kommt ein Pop-Up, an der Cloud anmelden) und anschließend Get-EXOMailbox | Get-EXOMailboxStatistics | Sort-Object TotalItemSize -Descending | ft DisplayName, TotalItemSize

Moin, "Wenn Server zustimmt" greift nur bei SMB1, was bei Dir hoffentlich deaktiviert ist. Bei SMB2 und 3 wird die Signierung ausgehandelt, sobald mindestens einer der Partner sie fordert. Das heißt, theoretisch kannst Du sogar nur 1 oder 3 aktivieren. Ist bei Dir SMB1 noch in Verwendung, hast Du größere Probleme. Dort funktionieren die Einstellungen aber so wie intuitiv erwartet. Referenz: https://techcommunity.microsoft.com/t5/storage-at-microsoft/configure-smb-signing-with-confidence/ba-p/2418102 Mit der Performance ist es so eine Sache. Wenn Du von Deiner 10G-Leitung derzeit nur die Hälfte auslastest, würde Dir ein Verlust von 20% nicht wirklich weh tun. Mehr als das sollte es nicht werden. Signierung und RDMA zusammen kann zu Problemen führen. Auf Hyper-V-Clustern würde ich eher nach Wegen suchen, SMB-Signierung innerhalb des Clusters nicht zu erzwingen. Du kannst ja SMB Inboud per Firewall nur auf die Clusterknoten begrenzen und Outbound wird dann signiert, weil die Server außerhalb des Clusters das fordern.

Da der Host noch nicht lange an ist, wird der Neustart des Dienstes vermutlich nichts bringen. Aber er schadet auch nicht (sofern der Dienst wieder hoch kommt ) Kannst Du mal probieren, ob der Zugriff auf die VM-Konsolen von einer anderen Maschine aus geht? Gibt es einen Unterschied, ob Basic oder Enhanced Session Mode verwendet wird?

Ich habe mich schon länger nicht mehr mit kommerziellen AccessPoints beschäftigen müssen, aber vor 10 Jahren hatte jedes Gerät die Client Isolation als Teil der Gästenetz-Funktion. Bei manchen ließ sich das gar nicht wegkonfigurieren. Meine Erwartung gilt daher nicht den Errichtern und Betreibern der Netze, sondern den Herstellern der Hardware. Offenbar sind die Gepflogenheiten jetzt anders. Muss ich mal untersuchen, wenn ich mal wieder in einem Hotel bin oder fliege.

...wobei die Sache mit dem WLAN im Flieger natürlich sehr ungewöhnlich ist - von einem Gäste-WLAN erwarte ich in erster Linie Client Isolation und in zweiter Linie das Unterbinden von PNRP und NBT. Bereits eine dieser Maßnahmen hätte das Experiment ins Leere laufen lassen müssen.

Noch mal zur Sicherheit: MIt "Proxyabfragefenster" meinst Du die Aufforderung, Dich am Proxy mit Benutzernamen und Kennwort zu authentifizieren, richtig?

Ja, mehr macht WebAccess auch nicht - außer mit IE und dem ActiveX-Control. Wenn Du die HTML5-Unterstützung installierst, würde im Browser die Terminalsitzung angezeigt werden - aber das ist ja dann ein völlig anderes Portal. Es gibt seitens Microsoft nichts, was Dir erlauben würde, die RDP-Clients auf allen möglichen Plattformen zu steuern. Etwas besser sieht es auf dem Mac aus, aber nur insofern, als dass da die .RDP-Dateien per Doppelklick aufgehen.

Moin, was liefert denn auf einem betroffenen Server netsh http show proxy zurück?

Dann ist es bei Dir so. Wenn Du sowohl eine heterogene Client-Umgebung als auch eine etwas komplexere Remote-Landschaft mit mehreren Collections als auch den Bedarf an Echtzeit-Anwendungen in dieser Remote-Landschaft hast, ist Microsoft RDS vermutlich nicht das richtige Produkt für Deinen Use Case, und Du solltest Dir Citrix oder VMware anschauen. Ansonsten, das normale Web Access funktioniert auf allen Plattformen gleichermaßen, solange Du nicht vorhast, WebSSO zu verwenden. Das geht nur mit IE, denn da kommt ein ActiveX-Control zum Einsatz. Du könntest aber Deinen Web Access mit dem HTML5-Client erweitern. Der funktioniert mit jedem HTML5-fähigen Browser, hat aber nicht den gleichen Leistungsumfang wie ein lokal installierter Rich Client, vor allem was den Zugriff auf die lokalen Ressourcen am Client angeht.

Wenn es mehrere Sammlungen gibt (auf die der jeweilige User berechtigt ist), musst Du RDP Files verwenden oder RDP-Clients, die diese Sonderkonfigurationen als Parameter akzeptieren. Das, was Du im letzten Satz beschreibst, würde ich nur erwarten, wenn der User auf dem Connection Broker Adminrechte oder zumindest RDP-Rechte hat.

Microsoft meint, man soll das mit Intune managen, nicht mit Windows-Bordmitteln.

Wie gesagt, Hello for Business. Nur ist "Azure MFA" kein unterstützter Unlock Signal dort: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock Aber vielleicht reicht ja einer der anderen Faktoren

Moin, eine Alternative für on-prem wäre SmartCard oder Windows Hello mit einem Security Key. Das sind auch die einzigen Provider, die out of the box dabei sind. Eine andere Alternative für on-prem wäre zwar für die lokale Anmeldung am Endgerät nicht geeignet, aber wenn auf Terminalserver oder VDI zugegriffen wird, um sensible Daten zu verarbeiten, kann man dort (z.B. am RDG, NetScaler oder UAG, je nach verwendeter Technologie) MFA mit beliebigen Mitteln fordern - RADIUS mit RSA oder LinOTP, Azure MFA, you name it... Ansonsten gibt es 3rd party-Lösungen. Fortinet bringt den FortiAuthenticator mit, mit dem man einen zusätzlichen Provider installiert und eine beliebige Windows-Anmeldung mit MFA versehen kann. Es gibt auch viele andere.

Moin, das, was Du beschreibst, trifft nur zu, wenn Du RemoteApps bereitstellen willst. Bei einem vollen Desktop kannst Du die Verbindung gern gegen den Connection Broker richten.

Nö, nix wissen "wir beide". Ich habe in UserVoice bereits Dinge sowohl selbst eingestellt als auch durch meine Stimme unterstützt, die später umgesetzt worden sind. Ich weiß also anscheinend etwas anderes als Du.