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"}
}

Watchguard, Azure, VPN

Kleiner Tipp am Rande: wenn man eine virtuelle Watchguard bei Microsoft Azure betreibt und man dorthin ein L2TP-VPN von einem halbwegs modernen Windows aus aufbauen möchte (gilt für Windows Vista, Windows 7, Windows 8 und Windows 10), ist zu beachten, dass es sich um eine NAT-Verbindung handelt. Windows kann damit eigentlich nicht umgehen und der Tunnel-Aufbau wird somit fehlschlagen.

Es gibt einen Workaround dazu: erstelle einen Registry-Eintrag. Der Pfad lautet:
HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent

Der nötige Eintrag ist ein REG_DWORD mit dem Namen „AssumeUDPEncapsulationContextOnSendRule“ mit dem Wert „2“

Ach ja, noch eine Sache: Watchguard unterstützt offiziell kein Split Tunneling bei L2TP. Es funktioniert aber doch. Und nicht nur bei L2TP, sondern auch bei IKEv2. Dazu fügt man der VPN-Verbindung über den Powershell-Befehl „Add-VpnConnectionRoute“ einfach die nötige Route zu. Das schöne ist: die Route ist persistent, muss also nicht immer wieder neu eingegeben werden.
Bspw.:

Add-VpnConnectionRoute -ConnectionName "Mein VPN" -DestinationPrefix 10.0.0.0/16

Natürlich muss der VPN-Verbindung auch gesagt werden, dass Sie Split Tunneling nutzen soll. Bspw.:

Set-VpnConnection -Name "Mein VPN" -SplitTunneling $true

Für weitere Informationen schaut euch gerne die Dokumentation bei Microsoft an:
https://docs.microsoft.com/en-us/powershell/module/vpnclient/?view=win10-ps

Firewall und Spiegel Online

Dieser Artikel beschreibt ein Problem speziell mit Watchguard Firewalls und Spiegel Online (SPON). Vielleicht ist es aber auch bei anderen Firewall-Lösungen nützlich.

Wir hatten in den letzten Wochen bei einigen Kunden das Problem, dass sich bei SPON der Hinweis, dass man doch bitte den AdBlocker ausschalten solle, öffnete, obwohl kein AdBlocker installiert war. Die Ursache ließ sich relativ schnell auf den HTTP-Proxy-Dienst der eingesetzten Firewall (Watchguard) eingrenzen. Es hat aber dann tatsächlich noch etwas gedauert, bis klar wurde, was genau das Problem verursacht. Nachdem wir zunächst SPON in die Proxy-Ausnahmen eingetragen und auch testweise Virenscan und andere Dienste im Proxy deaktiviert hatten, war eine Analyse des Netzwerkverkehrs nötig, um festzustellen, dass bestimmte HTTP-Header-Informationen vom Proxy entfernt werden, die – wie sich herausstellte – für die Funktionalität des Anti-AdBlocker-Prüfscripts bei SPON nötig waren.

Letztendlich hat geholfen, das Pattern

Access-Control-Allow-Origin:*

bei den Response-Headern zu erlauben.

Interessanterweise hatten nicht alle Kunden mit Watchguard das Problem. Es ließ sich allerdings auf die Kunden eingrenzen, die schon vor dem Jahr 2016 auf Watchguard als Firewall-Lösung setzen. Möglicherweise hat Watchguard irgendwann mal in die Standard-Einstellungen für HTTP-Proxys den Header-Typ aufgenommen, weshalb bei neueren Watchguard-Kunden der Header bereits erlaubt wird. Wenn man aber bei alten Kunden die bestehende Konfiguration von alten Geräten auf neue Geräte importiert, wird die Standardeinstellung überschrieben und nur die veraltete Header-Typ-Liste wird verwendet.


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


Nagios Update 4.3.0 Probleme

Ups, nachdem ich mein Nagios 4.2.3 auf 4.3.0 aktualisiert hatte, war ich einigen kleinen Problemen ausgesetzt. Zunächst meldete Nagios, dass es den Prozess-Status nicht finden konnte:

Unable to get process status

Weiterhin konnte ich auf keinen Menüpunkt in Nagios zugreifen. Bspw. beim Aufruf von „Tactical Overview“ bekam ich die Meldung vom Apache Server

The requested URL /nagios/cgibin/tac.cgi was not found on this server.

Es stellte sich heraus, dass Nagios in der aktuellen Version nicht mehr unter /nagios/cgi-bin/ sondern unter /nagios/cgibin nach den CGIs sucht. Also habe ich in der Datei /etc/apache2/sites-enabled/nagios.cfg (kann abweichend sein) noch den zusätzlichen ScriptAlias /nagios/cgibin für/usr/local/nagios/sbin eingetragen. Nach einem Neustart des Apache Servers war zumindest das Problem schon mal gelöst.

Ein weiteres Problem waren die Map und die Trends. Im Legacy-Mode funktionierten sie, aber nicht mehr im „normalen“ Modus. Ich bekam hier lediglich die Meldung

Warning: Monitoring process may not be running! Click here for more info

Das „here“ verwies auf einen ungültigen Pfad (nämlich auf /{{cgiurl}}extinfo.cgi?type=0). Nach einigem Suchen fiel mir auf, dass irgendwie unter /usr/local/nagios/share/js die Datei config.js fehlte. Diese beinhaltet die Variable für cgiurl. Nachdem ich die Datei config.js.in aus dem Source-File angepasst (ich habe @cgiurl@ durch cgibin ersetzt und die Dateiendung .in entfernt) und in das genannte Verzeichnis gelegt hatte, funktionierte Nagios bei mir wieder ohne Probleme.

config.js:

var nagcfg = {};
nagcfg.cgidir = "cgibin/";