Zeichenfläche 1UUPDATE

UPDATE

Exchange 2013 CU22
Zeichenfläche 1UUPDATE

UPDATE

Exchange 2016 CU12
Zeichenfläche 1SSICHERHEIT

SICHERHEIT

Schwachstelle Windows RDP
Zeichenfläche 1DDATENSCHUTZ

DATENSCHUTZ

Sicherer Umgang mit Passwörtern
Office 365, Exchange Online

Intra2Net Empfängerüberprüfung Office 365

  Kurzbeschreibung

In dieser Anleitung beschreibe ich Dir, wie Du die Abfrage der Empfängeradressen auch ohne Schmemaerweiterung durchführen kannst.

  Die Anleitung

Die Empfängerüberprüfung bei einem Spamproxy bzw. Spamfilter ist von seiner Funktion relativ wichtig, wenngleich oft unterschätzt. In der Regel wird eine solche Abfrage über eine LDAP Abfrage am #ActiveDirectory durchgeführt.

Office 365 lässt keine Abfrage über LDAP zu

Und das ist auch gut so, denn ansonsten wäre es möglich, jeden Tenant nach existierenden Adressen für seine Spamverteiler abzufragen. Das Azure AD ist in vielerlei Hinsicht nicht identisch mit einem lokalen AD.

Die Adressen werden bei einer LDAP Abfrage über das AD Attribut “proxyAddresses” abgefragt. Das Feld erlaubt mehrere Einträge.
In einer Domäne, in der kein Exchange installiert war und keine Schemaerweiterung durchgeführt wurde, ist dieses Feld per sé ohne Funktion. Es gibt auch keine “einfache” Möglichkeit, diese Einträge zu verwalten. Natürlich kann man es über die Powershell … oder manuell über das Bearbeiten des Attributs anpassen, jedoch wird das einpflegen der Adressen etc. so zu einer Qual mit enormem Verwaltungsaufwand.

Darum gibt es folgende Szenarien.

Office 365 mit erweitertem AD Schema OnPremise

Die LDAP Abfrage wird einfach (wie gewohnt) eingerichtet und die Empfängeradressen werden über LDAP abgefragt.

Dabei muss man entweder die Adressen manuell angleichen, AD-Sync einrichten, oder ein Powershell Script benutzen, um die Empfängeradressen einzutragen.

Nach dem Einrichten von AD Sync können die Benutzer nicht mehr über die Exchange Online Konsole verwaltet werden (bis zum „schließen“ des Sync).

Office 365 OHNE erweitertes AD Schema

Hier können im AD die Adressen beim Attribut „proxyaddresses“ eingetragen werden.
Der Abgleich muss dann aber anders eingestellt werden als üblicherweise.

Einstellungen LDAP Abfrage Intra2Net ohne erweitertes Schema

Zum Abgleich kann man in dem Fall das Powershell Script verwenden, welches alle smtp Adressen aus dem Exchange Online ausliest und diese in den „dummyuser“ schreibt.

Das Intra2net Security Gateway fragt dann, wie gewohnt, die Adressen über LDAP ab und trägt diese in seine Empfängerliste ein.

Das PowerShell Script

Vorab sollte die config.ini angepasst werden.
Beim ersten Start des Scripts sollte man es mit dem -newpw aufrufen.
Der Aufruf fragt dann nach dem Passwort des Office 365 Benutzers in der Config und schreibt diesen als sicheren String in die password.txt.
Das Speichern der Zugangsdaten erfolgt in dem Fall nur, damit man das Script auch als Task auf einem DC einrichten kann und somit eine Art autom. Abgleich hat.

Das Script muss zwingend auf einem DC ausgeführt werden.

Der dummyuser aus der config muss existieren (im Zweifelsfall angelegt werden).

Das Script löscht beim Eintragen der smtp-Adressen vorher alle Adressen aus dem dummyuser, so wird gewährleistet, dass gelöschte Benutzer nicht mehr auftauchen.

Es wird jeweils ein Logfile für die angelegten Adressen und eine für die nicht angelegten (das kann in der config eingestellt werden) erstellt.

In dem Logfile für nicht angelegte Benutzer tauchen dann zum Beispiel die SIP Adressen auf.

Das Script hat momentan noch eine relativ lange Laufzeit und eine Warnung als Output.

Das kommt daher, dass er alle msonline Module beim Verbinden lädt. Für die nächste Version werden nur noch die Module geladen, die auch benötigt werden. Wenn die Logdateien in einem anderen Pfad als das Script liegen sollen, müssen diese mit Pfad in der config angegeben werden.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.