Archiv des Autors: weed

Postfix: ausgehende E-Mail via TLS pro Domain erzwingen

Veröffentlicht am von — Keine Kommentare ↓

Problem

Es gibt eine (Management-)Richtlinie, die vorschreibt mit einem bestimmten Partner ausschliesslich über (TLS) verschlüsselte Verbindungen zu kommunizieren. Der ausgehende Mailserver ist ein Postfix (z.B. ein Smarthost). TLS mit den entsprechenden Zertifikaten ist hier schon korrekt eingerichtet. Es sollen nur sichere TLS-Verbindungen zu bestimmten Domain erzwungen werden.

Lösung

Standardmäßig verschlüsselt Postfix ausgehende E-Mails nicht. Sofern die Zertifikate richtig konfiguriert sind (Stichwort smtpd_tls_cert_file) lässt sich die ausgehende Verschlüsselung IMMER erzwingen:

Zum erzwingen von TLS In der Datei /etc/postfix/main.cf eintragen:

smtp_tls_security_level = encrypt

Viele Mail-Server akzeptieren aber auch heute noch keine TLS-Verbindungen. E-Mails an solche Mailserver werden daher nicht versendet. Als sinnvolle Alternativebietet sich daher an:

 smtp_tls_security_level = may

Bei dieser Einstellung wird die TLS-Verschlüsselung nur verwendet, wenn der Empfängerserver ebefalls TLS-Verbindungen akzeptiert. Verschlüsselt geht hier von iunverschlüsselt.

Nur für bestimmte Domains erzwingen

Es soll TLS für alle E-Mails erzwungen sein, die an *@denic.de gesendet werden. Der MX von denic.de zeigt auf mx1.denic.de und mx2.denic.de.

    • Mapping-Datei erstellen, z.B. „/etc/postfix/tls_policy“ mit diesem Inhalt: 
      denic.de       encrypt
    • Mapping übernehmen 
      root@posty:/etc/postfix# postmap /etc/postfix/tls_policy
    • Tabelle in der main.cf in der TLS-Policy referenzieren 
      # TLS erzwingen
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
    • Postfix reloaden 
      root@posty:/etc/postfix# /etc/init.d/postfix reload

Im Log lässt sich der Erfolg direkt danach prüfen, indem man nach dem Servernamen (oder der Adresse) und „STARTTLS“ grept:

postfix/smtp[61070]: > mx1.denic.de[2a02:568:102:211::1:1]:25: STARTTLS

Exchange 2013/2016 Ordner „ETLTraces“ mit ETL-Dateien wird riesig (läuft voll)

Veröffentlicht am von — Keine Kommentare ↓

Problem

Exchange Ordner ETLTraces läuft mit ETL Dateien voll

Nach dem Update auf Exchange 2013 CU6 (oder neuer) gibt es plötzlich einen neuen Ordner in

%ProgramFiles%\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces

der riesig wird. Dort sammeln sich DocumentProcessingTrace*.etl Dateien, die auf gut 50Mbyte pro Stück anwachsen können. In einem Fall hatten sich dort etwas mehr als sieben Gbyte an Daten angesammelt, die nicht so wirklich jemandem helfen.

Das sind die Diagnose-Dateien der Exchange Volltextsuche. Man kann diese auch mit Eventviewertools öffnen und Exchange entfernt diese auch irgendwann, aber ob diese in der Zwischenzeit so viel Platz belegen müssen bleibt dem Admin überlassen.

Lösung

Glücklicherweise lässt sich das Diagnostische Tracking der Suche Konfigurieren. Sowohl der Pfad zu den Dateien, die Größe als auch die Anzahl sind in der Registry einstellbar:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing]
"TracingPath"="C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Bin\\Search\\Ceres\\Diagnostics\\ETLTraces"
"MaxTraceFileSize"=dword:00000028
"MaxTraceFileCount"=dword:0000000a

Die Werte für „MaxTraceFileSize“ und „MaxTraceFileCount“ sind hier hexadezimal anzugeben.

Nach einer Änderung müssen die Dienste „Microsoft Exchange-Diagnose“ und „Microsoft Exchange-Suche“ einmal neu gestartet werden und schon ist man die Plage los.

Windows 7: Anmeldeinformationen speichern für RDS-Server zulassen

Veröffentlicht am von — Keine Kommentare ↓

Unter Windows Vista und Windows 7 ist es aus magischen Sicherheitsgründen nicht möglich, Anmeldedaten für einen RDS-Server eine Domäne zu speichern, deren Mitglied der betroffene Computer nicht ist. Möchte man aber nun Anmeldedaten für einen RDS (Remotedesktopverbindung) speichern, funktioniert das nicht. Man hat diese vielleicht auch bereits gespeichert, aber die Anmeldung kommt trotzdem immer wieder

Dieses Verhalten lässt sich via GPO anpassen:

Computerkonfiguration > Administrative Vorlagen > System >
  Delegierung von Anmeldeinformationen >
  Delegierung von gespeicherten Anmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen

Die Richtlinie muss „Aktiviert“ werden und entweder der betroffene Terminalserver („TERMSRV/<HOSTNAME>“) oder eine das Wildcard-Label („TERMSRV/*“) konfiguriert werden.

Windows Server 2016 (oder Windows 10) Windows Update 0x8024001e

Veröffentlicht am von — 2 Kommentare ↓

Tritt bei einem Windows  10 und Windows Server 2016 bei der Aktualisierung der Update Fehler 0x8024001E auf, hilft in der Regel diese Vorgehensweise:

  1. Server neu starten. Wichtig.
  2. Die Dienste „Windows Update“ und „Intelligenter Hintergrundübertragungsdienst“ beenden
  3. Das Verzeichnis „%windir%\Software Distribition“ vollständig (!) löschen
  4. Die Dienste „Windows Update“ und „Intelligenter Hintergrundübertragungsdienst“ wieder starten
  5. Den Update-Vorgang erneu starten

Nun sollte es nicht mehr zu dem Updatefehler 0x8024001e kommen. Ursache war bisher praktisch immer ein defektes Update-Paket; ob das die Vollversion oder das Delta-Paket war, ist unerheblich. Schuld können Virescanner, Firewalls, Paketfilter, UTMs, Deepsecurity-Kram, unterbrochene Netzwerkverbindungen, kaputte Platten oder ähnliches sein. Auf jeden Fall ist der Download defekt.

Besonders fiese Geschichte: Ein (physikalischer) Server hatte einen defekten 10G Netzwerkkartentreiber und ein „heiler“ Download war darüber nicht möglich. Wir haben stundenlang gesucht …

Exchange 2013/2016 zeigt in einer Ressource den Betreff einer Buchung nicht (mehr) an, sondern nur den Namen des Organisators

Veröffentlicht am von — 1 Kommentar ↓

Problem

Ein Ressourcenpostfach ist via „AutoAccept“ auf die automatisch Annahme einer Buchung konfiguriert Wenn man diese Ressource (Eine Raum oder ähnliches) nun bucht, bekommt man die Besprechung im eigenen Kalender auch korrekt angezeigt, im Kalender der Ressource allerdings nicht. Dort sieht man nur den Namen des Organisators im Betreff (anstelle des Betreffs).

Lösung

Dieses Verhalten ist das Standardverhalten für neue Ressourcenobjekte. Aber die Einstellung lässt sich jederzeit ändern:

Set-MailboxCalendarSettings -Identity <NAME> -AutomateProcessing AutoAccept -AddOrganizerToSubject $False -DeleteSubject $False