winmadness

Hallo, hast Du schon mal probiert, das bestehende "Problem-Benutzerprofil" komplett zu löschen und den Benutzer auf dem Rechner neu anzulegen?

@skipper02 Ich gehe davon aus, dass Du in der "Systemsteuerung -> E-Mail" alle Profile gelöscht hast. Du kannst in der Registry unter dem Schlüssel "Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles" prüfen, ob auch alle Profile gelöscht wurden. Evtl. wird der autodiscover über die Registry "umgebogen". Check mal den Schlüssel "Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" und "...\RedirectServers". Registry Einträge gelten für MS Outlook 2016, evtl. Versionsinfo im Pfad anpassen.

Hallo Peter, mit der Problematik hatte ich mich auch schon beschäftigt. Unser Lizenzberater hat damals ausgeführt, dass auch für Replikationsserver alle VMs vollständig lizenziert sein müssen - egal ob diese laufen oder nicht. Also in Deinem Fall würdest Du 4x Windows 2019 benötigen. Und natürlich auf die Mindest-Core-Anzahl achten. Bitte beachte, diese ist keine rechtsverbindliche Aussage. Immer mit MS bzw. Deinem Lizenzhändler abklären.

Hallo Dukel, habe ich getan. Da ich ein eigenes Zertifikat erstellt habe und diese sowohl der Default Web Site als auch dem Back End zugewiesen habe, habe ich natürlich ein anderes Zertifikat mit Get-ExhangeCertificate als mit Geth-Authconfig (hier kommt das originale MS Auth Exchange Certificate). Auch mit "netsh http show ssl" wird für den Port 444 (Back End) das eigene Zertifikat angezeigt. Natürlich wird Dir bei beiden Befehlen das gleiche Zertifikat angezeigt, wenn Du die Default Exchange Installation nicht veränderst.

@Dukel Bist Du sicher? Noch meiner Kenntnis ist das "Get-AuthConfig" Zertifikat notwendig für die OAuth Authentication und in Hybrid-Umgebungen - entsprechender Artikel hier und hier.

@cj_berlin Sehe ich nicht so. Es hindert Dich schließlich niemand daran, Deine Gedanken zur Absicherung im LAN hier zu posten. Bisher waren es nur ein paar Stichworte ohne weitere Erläuterungen / Links. Und auf die Nachfrage von @magicpeter hast Du auch nicht reagiert. Ansonsten gebe ich Dir Recht, das auch im LAN die Möglichkeiten zur Absicherung genutzt werden müssen. Es gehört zum Gesamtkonzept. Also wie verhindere ich, dass überhaupt Angreifer ins Netz gelangen und wenn doch, wie hindere ich die Angreifer daran sich im Netz auszubreiten. Ein weiterer Aspekt der LAN-Sicherheit besteht sicherlich in der Möglichkeit, dass "kriminelle oder neugierige" Mitarbeiter das Netz von innen angreifen.

Alles klar, jetzt habe ich es verstanden. Nur für mein Verständnis. Ich gehe davon aus, dass der eigentliche Exchange Admin das Standard Exchange Auth Zertifikat explizit gelöscht hat, da es mit Get-ExchangeCertificate nicht aufgeführt wird. In diesem Fall wären ja schon früher Fehler (Eventlog) aufgetreten, wenn der nicht gleichzeitig über Set-AuthConfig das Zertifikat neu gesetzt hätte. Oder übersehe ich hier etwas? Sorry, will Dich nicht nevern - ich will es nur verstehen und lerne gerne dazu.

Habe ich verstanden. Deswegen wundert mich Deine Aussage (Zitat) nach der negativen Überprüfung der Bindungen mit netsh und "Get-ExchangeCertificate". Was habe ich übersehen?

Verstehe ich nicht so ganz. Er hat doch geprüft, ob das eigene Zertifikat im System oder an Exchange gebunden ist - nach seiner Aussage nein. Ausserdem ist in dem Link die Erstellung eines Zertifikates mit "New-ExchangeCertificate " beschrieben. Ich z.B. verwende zwei Zertifiakte - ein offizielles Wildcard-Zertifikat für SMTP und mein virtuelles ActiveSync Directory und ein mit Windows Zertifizierungsstelle erstelltes für die Default Web Site / Exchange Back End.

Hier noch einige Ideen: Mit "Get-MessageTrackingLog" mal das Nachrichtenprotokoll prüfen, evtl. findest Du hier eine Spur Hast Du einen MTA (z.B. Exchange Edge) im Einsatz - diesem mal überprüfen wie @tessoschon geschrieben hat, mal mit "Get-MailboxDatabase <database> | fl JournalRecipient" die DB prüfen Zwar abwegig, aber mal die Exchange Regeln im "Nachrichtenfluss" prüfen

Hallo Michael, das sieht nach einer Journalregel zur Mail Archivierung aus. Schaue mal im ECP unter "Verwaltung der Compilance -> Journalregeln" ob dort eine Regel mit Deinem Postfach als Empfänger eingetragen ist. Alternativ auch mit dem Exchange Powershell Befehl "Get-JournalRule"

Ist nur eine Idee zur Lösung Deines Problems. Ich hatte bisher immer eine Standard-Tags mit Ordner-Tags gemischt und nie Probleme, deswegen der Vorschlag.

Richtig, aber Du benötigst nach meinen Wissen eine Standard-Regel. In dieser setzt Du den "Aufbewahrungszeit" auf "Nie", sodass diese nicht greift. Dann weist Du diese Deiner Aufbewahrugnsrichtlinie zu und damit sollte es funktionieren.

In diesem Fall benötigst Du Beeftext nicht. Es geht einfach, wenn Du ein Powershellskript erstellst, welche alle benötigten Informationen in einer EMail sendet. Ich würde hier ohne Parameter arbeiten und in der EMail alle benötigten Informationen einstellen. Z.B. $User = ([System.Environment]::UserName) $bios = (Get-CimInstance Win32_bios).SerialNumber $newline = "`n" $body = "User: $user${newline}SN: $bios" Send-MailMessage -to support@firma.de -from $user@mail.de -subject "Systeminformationen" -body $body -SmtpServer mail.firma.de Absenderadresse bewußt mit "mail.de", da bei "firma.de" es Probleme mit dem Recht zu senden geben kann - ja nach euerer Exchange Konfiguration.

Ich meinte eine allgemeingültigen Tag, also neben Deinen Tags für spezielle Ordner. Im ECP in der Spalte "Typ" sollte also "STandard" stehen.

Hast Du der Aufbewahrungsrichtlinie auch einen allgemein gültigen Aufbewahrungstag ("Standard" oder "Persönlich") zugewiesen? Es könnte daran liegen, dass Du nur Tags für spezielle Ordner erstellt hast.

Welche Regel, werden wo angezeigt? Prüfe mal auf dem Exchanger Sever mit Powershell die Zuweisung: Get-Mailbox <mailboxname> | Select RetentionPolicy Get-RetentionPolicy -Identity <regelname> | fl

Hallo, damit ist die Sache klar und Du benötigst nur das Wildcardzertifikat. Überprüfe aber zur Sicherheit, ob das eigene Zertifikat wirklich nicht aktiviert ist. netsh http show sslcert Zertifikathash entspricht Fingerabdruck des Zertifikates Powershell Exchange Get-ExchangeCertificate | fl

Überprüfe mal auf dem IIS die unter "Bindungen" zugewiesene Zertifikate für die Defauft Site und Exchange Back End. Wenn dort das eigene Zertifikat zugewiesen ist, musst Du dieses erneuen. Habt Ihr unterschiedliche Domänen für intern und extern - auf welchen Domänen ist das Wildcard bzw. eigene Zertifikat ausgestellt?

Kannst Du in Outlook bei den entsprechenden Ordnern die Aufbewahrungsrichtlinie sehen (Ordner Eigenschaften / Tab "Richtlinie")? Ist diese zugewiesen bzw. kannst Du diese zuweisen?

IDS/IPS ist ein anderes Konzept als Geo IP. Wie beschrieben, kann es unter anderem bekannte Bedrohungen blockieren, also vergleichbar mit dem Konzept eines Virenscanner. IPS hätte den ProxyLogon Angriff in der ersten Welle wahrscheinlich nicht entdeckt / blockiert. Erst wenn der Hersteller / Admin die entsprechende Regel erstellt hat würde der Angriff blockiert. Geo IP hingegen hätte alle Angriffe, welche über Server aus den blockierten Ländern erfolgt wären, geblock. Natürlich hast Du mit Geo IP auch ein Problem wenn der Angriff aus "freigegebenen" Ländern erfolgt. Ich sehe IDS/IPS und Geo IP als Baustein einer umfangreichen Sicherheitsstrategie. Also die beiden Ansätze ergänzen sich und bilden mit VPN, Reverse Proxy Firewall Regel etc. ein Gesamtkonzept. Hier noch eine interessante Diskussion bgzl. ProxyLogin und IDS/IPS und Reverse Proxy von betroffenen Admins.

Wow, auf die einfachste Lösung bin ich nicht gekommen. Das wars - Danke.

Hallo, ich habe ein faszinierendes Problem auf einem Windows 10 Client mit Outlook 2016. Wenn ich das Fenster miniere wird es automatisch „ausgeblendet / geschlossen“. D.h. Outlook läuft noch, nur das Fenster wird geschlossen. Dies passiert auch bei mehreren offenen Outlook Fenster. Dieses Verhalten betrifft aber nur Explorer-Fenster. D.h. wenn z.B. eine E-Mail im Inspector geöffnet und dieses Fenster miniert wird, bleibt das Fenster erhalten. Alle anderen MS Office Programme (Word, Excel etc.) zeigen dieses Verhalten nicht. Ich habe MS Office bereits repariert. Ohne Erfolg.

Hallo Peter, ich verwende OPNSense. Das GEO Blocking ist dort direkt integriert. Im Grunde liefert MaxMind eine Liste mit IP Adressen und Länderbezug. OPNSense importiert diese Liste und stellt diese in sog. Alias zur Verfügung. Somit kann man z.B. einen Alias anlegen, in dem nur Deutschland aktiviert ist. Dieses Alias wird in der Firewall als "Source IP" eingetragen und als "Invert" gekennzeichnet. Diese Regel blockt dann alle Anfragen, ausser aus Deutschland. Oder man verwendet das Alias für einen bestimmten Port (z.B. EAS) und erlaubt mit der Firewall Regel Zugriffe nur aus Deutschland.

Hallo Peter, als Admin würde ich immer kompromittierte Systeme neu installieren / aufbauen. Aber wie Du schon richtig schreibst liegt die Entscheidung (leider) bei der Geschäftsleitung – Kosten gegen Sicherheit.