Neuer E-Mail-Alias für alle Exchange Benutzer

Es gab die Anforderung, eine neue Domain für den E-Mail-Empfang zu Exchange hinzuzufügen und entsprechend alle Benutzer und Verteilergruppen mit der neuen Domain auszustatten.

Dazu habe ich dieses Script gebaut (für Exchange 2010), um alle ~500 Objekte entsprechend zu ergänzen. Es bearbeitet zuerst die Benutzer (es ignoriert deaktivierte Benutzer), dann die normalen Verteilergruppen und zuletzt die dynamischen Verteilergruppen. Die Alias-Adressen werden entsprechend dem Mailbox-Alias angelegt.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

$ADSearchBase = "ou=Firmenname,dc=domain,dc=tld"
$domain = "domain.tld"

#Users
$targets = get-aduser -filter {Enabled -eq $true} -searchbase $ADSearchBase
foreach ($user in $targets) 
{ 
  $mbxalias = (get-mailbox -identity $user.SamAccountName).Alias
     Set-ADUser $user -add @{proxyaddresses="$mbxalias@$domain"}
}

#Distribution Groups
$grouptargets = get-adgroup -filter "groupcategory -eq 'distribution'" -searchbase $ADSearchBase
foreach ($group in $grouptargets) 
{ 
  $mbxalias = (get-distributiongroup -identity $group.SamAccountName).Alias
     Set-ADGroup $group -add @{proxyaddresses="$mbxalias@$domain"}
}

#Dynamic Distribution Groups
$dyngrouptargets = get-adobject -filter "objectclass -eq 'msExchDynamicDistributionList'" -searchbase $ADSearchBase
foreach ($dyngroup in $dyngrouptargets) 
{ 
  $mbxalias = (get-dynamicdistributiongroup -identity $dyngroup.Name).Alias
     Set-ADObject $dyngroup -add @{proxyaddresses="$mbxalias@$domain"}
}

Apple Mail mit Exchange 2016 auf Windows Server 2016

Bei einem Projekt wurde aus Gründen in einer reinen Mac-Client-Umgebung (macOS 10.13 Sierra) ein Exchange-Server installiert. Hier haben wir den Exchange 2016 CU5 auch direkt auf dem Windows Server 2016 installiert. Die Clients können problemlos auf OWA zugreifen, eine Exchange-Verbindung via Apple Mail kommt jedoch nicht zustande. Angeblich sollen Benutzername und Passwort falsch sein. Die /EWS/Exchange.asmx kann ebenfalls mit dem Safari nicht aufgerufen werden (Authentifizierung scheint fehlzuschlagen).

Nach einiger Recherche habe ich die Lösung gefunden. Man muss auf dem Exchange Server die Nutzung von HTTP/2 deaktivieren, da es offenbar Schwierigkeiten mit NTLM-Authentifizierung und HTTP/2 unter Mac OS X gibt. Durch den Fallback auf HTTP/1.1 klappt auch NTLM wieder richtig und Apple Mail (und die anderen Apps) können Exchange nutzen.

Dazu einfach in der Registry unter HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters folgende Einträge erstellen:

REG_DWORD EnableHttp2Tls 0
REG_DWORD EnableHttp2Cleartext 0

Der erste Eintrag sollte eigentlich schon ausreichern, der zweite ist nur als Fallback gedacht.

Das Problem betrifft meiner Kenntnis nach nur Mac OS X, iOS-Geräte sind davon nicht betroffen (die nutzen ja auch mit ActiveSync eine andere Verbindungsmethode).

Quelle: https://social.technet.microsoft.com/Forums/en-US/dab47b34-84a0-43fa-b1fa-2c0999aac165/exchange-2016-ews-401-unauthorized-apple-mail-and-safari-only?forum=Exch2016CM


OS X möchte Änderungen vornehmen

Nachdem der Mail-Account bei einem Kollegen in Apple Mail neu eingerichtet wurde, erhielt er jedesmal beim Versuch, eine E-Mail zu versenden, den Hinweis „OS X möchte Änderungen vornehmen. Geben Sie Name und Passwort eines Administrators ein, um dies zu erlauben.“ mit dem weiteren Hinweis „OS X möchte den Schlüsselbund System verwenden.“. Die üblichen Schritte zur Fehlerbeseitigung, also Neustart des MacBooks, Prüfung/Reparatur des Schlüsselbundes, die Zugriffsrechte-Prüfung/Reparatur mit dem Festplattendienstprogramm sowie die Holzhammermethode, das Löschen des Anmeldeschlüssels unter ~/Library/Keychains, brachten nicht den gewünschten Erfolg. Ein Blick in die Kosole sagte zumindest, dass die Rules-Datei nicht geöffnet werden konnte und dass die Sandbox verhindert, dass Mail.app auf den Schlüsselbund zugreifen kann.

Mit Hilfe eines in Apple-Fragen versierteren Kollegen ließ sich dann feststellen, dass Apple Mail beim Versand von E-Mails diese mit dem Zertifikat, welches eigentlich für das VPN gedacht ist, verschlüsseln möchte. Nachdem wir den Haken für die S/MIME-Verschlüsselung in Apple Mail entfernt hatten, ging der Versand von E-Mails wieder Problemlos. Na ja, E-Mails werden jetzt mit dem Zertifikat signiert, aber das ist ja nicht weiter schlimm und verursacht keine Probleme. Apple Mail merkt sich zum Glück die zuletzt verwendete Einstellung und würde erst wieder verschlüsseln wollen, wenn man das Häkchen wieder aktiv setzt.

Wie konnte es nun dazu kommen? Initial wurde der Mac nur mit dem Mail-Konto eingerichtet. VPN kam erst einige Zeit später hinzu. Mail hat also die ganze Zeit sowieso nicht auf das Zertifikat zugegriffen. Erst nachdem es aufgrund eines Fehlers im Mail-Konto nötig war, das Mail-Konto neu einzurichten, hat Apple Mail nachgeschaut, ob es ein Zertifikat im System findet, welches die Identität des angemeldeten Nutzers nachweist, mit dem es E-Mails verschlüsseln kann. Da es fündig wurde, hat es also als Standardeinstellung dieses eigentlich für VPN gedachte Zertifikat genommen. Und da das Zertifikat im System-Speicher liegt, ist dafür ein administrativer Zugriff nötig.


Kerio Connect und fail2ban

Wer einen Mailserver betreibt, kennt das Problem, dass man neben den normalen E-Mails auch irgendwann höhere Mengen an Spam erhält. Bei dem von mir verwalteten Webserver mit Kerio Connect sind es so ungefähr 98% aller SMTP-Anfragen, die mit Spam zu tun haben.

Natürlich bietet Kerio Connect hier schon eine Auswahl an Antispam-Mechanismen an. So greift ein Spamassassin ein sowie verschiedene individuell zu gestaltende Spamfilter und Blacklist-Abfragen. Diese Möglichkeiten sollte man auf jeden Fall auch nutzen.

Das ändert aber nichts daran, dass der Mailserver immer wieder die gleichen Anfragen von den denselben Spam-Servern annehmen und verarbeiten muss. Hinzu kommen noch Script-Kiddies, die irgendwann auf den Webmailer aufmerksam werden und dort mit Exploit-Scripts versuchen, irgendwie Zugriff zu erlangen.

An dieser Stelle kommt dann das Tool fail2ban ins Spiel. Jedenfalls wenn man den Kerio Connect Server nicht unter Windows, sondern unter einem Linux laufen lässt.

Weiterlesen


Die Zahlen sprechen dagegen

Unsere Forensoftware versendet E-Mails von einer individuell generierten E-Mail-Adresse. Das Format ist re-xxxxxxx-xxxxxxx-xxxxxxx@service.domain.tld. Die „x“ sind alle Zeichen von [a-z] und [0-9]. Weil immer mal wieder einzelne Nutzer ihr Adressbuch mit Sozialen Netzwerken wie LinkedIn, Xing oder Facebook synchronisieren und alle gefundenen Kontakte einladen, werden auch diese Adressen eingeladen. Reagiert man nicht auf die Einladung, kommt kurze Zeit später eine Erinnerung.

Jetzt kann ich natürlich in jede Mail, die hier im Sammelbecken ankommt, auf den Unsubscribe-Link klicken. Wenn dann aber irgendwann jeder der 2,4 Millionen Nutzer auf die Idee kommt, die Adressen zu LinkedIn etc. zu importieren, hätte ich ne ganze Menge zu tun. Und eine Blockade allein für die Service-Domain am Mailserver einzurichten kann ich leider nicht, sondern nur global für alle vom Mailserver verwaltete Domains.

Also habe ich erstmal LinkedIn darum gebeten, unsere Service-Domain generell zu blockieren. Als Antwort kam, dass man keine Domains blockieren könne, sondern nur einzelne E-Mail-Adressen. Aber ich könnte ja eine Liste der zu blockierenden E-Mail-Adressen zuschicken, man würde die dann einzeln in die Blockliste eintragen.

An der Stelle bin ich ins Rechnen gekommen. [a-z] + [0-9] sind 36 mögliche Zeichen. Der individuelle Teil der E-Mail-Adressen besteht aus drei Blöcken á sieben Zeichen. Daraus ergibt sich eine Anzahl aus 36^21 möglichen Kombinationen. Das ist eine Zahl mit 33 Stellen. Namentlich 481,2… Quintillionen. Das ist wahnsinnig viel.

Aber davon mal abgesehen: eine Adresse besteht insgesamt aus 50 Zeichen (statischer und individueller Teil inkl. Domain), was 50 Bytes in einer simplen Textdatei entspricht. Bei (36^21)*50 Bytes wäre ich sehr sehr lange Zeit damit beschäftigt, bei voller Ausnutzung unserer 100MBit-Leitung, die Adress-Liste an LinkedIn zu übertragen. Nämlich ca. 60 Trilliarden Jahre. Da könnte ich den Urknall rund 4,4 Millionen Mal erleben.

Die Frage ist nun, LinkedIn grundsätzlich am Mailserver zu blockieren (vermutlich keine gute Option) oder eine Filterregel einzurichten, die alle LinkedIn-Einladungsmails an die Service-Domain direkt zur Support-Adresse von LinkedIn weiterleitet (verführerisch!). Ich muss da nochmal drüber nachdenken.