Exchange 2019: Client Access Rules

Eines der neuen Exchange 2019 Features sind die “Client Access Rules”. Client Access Rules können verwendetet werden um den Zugriff auf Exchange Server anhand von gewissen Kriterien einzuschränken. Ein Anwendungsfall wäre zum Beispiel, den Zugriff auf das EAC nur aus einem Management Netzwerk zu erlauben.

Leider sind die Client Access Rules in der Exchange 2019 RTM Version noch nicht vollständig implementiert, derzeit lassen sich nur RemotePowerShell und ExchangeAdminCenter mit Client Access Rules verwalten. POP3, IMAP, ActiveSync, OWA usw. lassen sich derzeit noch nicht mit Client Access Rules einschränken. Ich hoffe, dass mit den nächsten CUs für Exchange 2019 die Client Access Rules noch erweitert werden, damit sich auch andere Protokolle verwalten lassen und der Zugriff granularer gesteuert werden kann.

Übersicht der Befehle

Die Client Access Rules lassen sich nicht via EAC verwalten, sondern ausschließlich via PowerShell. Für die Verwaltung der Client Access Rules gibt es 5 CMDLets:

• Get-ClientAccessRule (Anzeigen der Regeln)
• New-ClientAccessRule (Neue Client Access Rule hinzufügen)
• Remove-ClientAccessRule (Regel löschen)
• Set-ClientAccessRule (Anpassen einer vorhandenen Regel)
• Test-ClientAccessRule (Test einer Client Access Rule)

Wie bereits erwähnt lassen sich derzeit nur RemotePowerShell und ExchangeAdminCenter mit Client Access Rules verwalten. Der Versuch andere Protokolle bzw. Schnittstellen zu verwalten schlägt mit Exchange 2019 RTM fehl:

Eine detaillierte Beschreibung der Befehle findet sich hier:

• Get-ClientAccessRule
• New-ClientAccessRule
• Remove-ClientAccessRule
• Set-ClientAccessRule
• Test-ClientAccessRule

Allerdings sind nicht alle der in den Artikeln beschriebenen Einstellungen in Exchange 2019 RTM verfügbar.

Wie funktionieren Client Access Rules

Client Access Rules funktionieren ähnlich wie Exchange Transport Regeln bzw. Firewall Regeln. Die Regel mit der höchsten Priorität (niedrigste Zahl) wird zuerst angewendet, nachdem eine zutreffende Regel angewendet wurde, werden keine weiteren Regeln mehr verarbeitet.

Die Priorität gibt also Reihenfolge vor, in der die Regeln abgearbeitet werden, die Priorität beginnt immer mit 1, alle weiteren Regeln folgen darauf (2, 3, 4, etc.). Es ist nicht möglich eine Regel mit Prio 1 und eine Regel mit Prio 5 zu erstellen. In diesem Fall wird die zweite Regel automatisch die Prio 2 bekommen. Ähnlich verhält es sich wenn eine Regel gelöscht wird. Wenn die Regel mit Prio 1 gelöscht wird, rücken die restlichen Regeln auf, die Regel mit Prio 2 wird also zur Prio 1 Regel.

Client Access Rules kennen nur zwei Aktionen: AllowAccess (Zulassen) oder DenyAccess (Verweigern). Die Aktion AllowAccess wird nicht oft zum Einsatz kommen, denn alle Aktionen die nicht per Regel verweigert werden, sind im Standard erlaubt. Da sich Regeln auch nicht auf einander aufbauen lassen (Subnetz X verweigern, aber IP auf Subnetz X erlauben), kommt AllowAccess meistens nur in der Prio 1 Regel vor (siehe Anmerkung).

Ein paar wichtige Punkte:

1. Die Exchange Management Shell nutzt RemotePowerShell für die Verbindung. Hier muss man also aufpassen, dass man sich nicht selbst aussperrt.
2. Aus Geschwindigkeitsgründen nutzen Client Access Rules einen Cache. Es kann daher bis zu 24 Stunden dauern bis die erste erstellte Regel wirkt. Änderungen an bereits bestehenden Regeln, oder das weitere hinzufügen von Regeln, können bis zu einer Stunde dauern.
3. Middle-Tier Applications wie zum Beispiel “Outlook für iOS und Android” verbinden sich nicht direkt vom Endgerät (Android Smartphone, iPhone) zum Exchange Server, sondern nutzen eine Middleware. Der Zugriff vom Client auf Exchange durchläuft also eine weitere Applikation. Dies trifft auch auf diverse Web Applikation Firewalls (WAF) zu, die im Proxy Modus arbeiten. Wenn also die IP-Adresse des Proxy/WAF/Middleware mit einer Regel blockiert wird, können ggf. viele Benutzer nicht mehr auf Exchange zugreifen. Dies gilt allerdings nicht für “Microsoft Apps” wie zum Beispiel “Outlook für iOS und Android”, hier wird zwar ebenfalls eine Middleware genutzt, diese ist aber von den Client Access Rules ausgeschlossen und können daher nicht blockiert werden (zumindest nicht mit Client Access Rules, mit Active Sync Regeln ist dieses möglich).

Beispiele für Client Access Rules

Leider gibt es an dieser Stelle nicht viele Beispiele für Client Access Rules, da es einfach derzeit nicht viele Möglichkeiten gibt. Sinnvoll sind Client Access Rules derzeit nur für das Blocken von Admin Verbindungen aus dem Internet oder anderen problematischen Netzen (ggf. Gäste WLAN oder Produktionsnetze).

Die folgende Regel blockiert die Zugriffe auf RemotePowerShell und ExchangeAdminCenter für alle Netze außer 192.168.200.0/24:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24

Die folgende Regel blockiert RemotePowerShell und ExchangeAdminCenter nur für das Netz 192.168.200.0/24, lässt aber alle anderen Netze zu:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -AnyOfClientIPAddressesOrRanges 192.168.200.0/24

Der folgende Befehl ändert die Netzwerke einer bestehenden Regel:

Get-ClientAccessRule "Block EAC and RPS" | Set-ClientAccessRule -AnyOfClientIPAddressesOrRanges 192.168.100.0/24, 192.168.200.0/24

Der folgende Befehl zeigt alle Regeln inkl. aller Details an:

Get-ClientAccessRule | fl *

Bestehende Regeln lassen sich mit folgendem Befehl testen, dabei wird eine Verbindung des Benutzers Administrator von der IP 192.168.100.10 zum ExchangeAdminCenter simuliert:

Test-ClientAccessRule -User administrator@frankysweblab.de -AuthenticationType Basic -RemotePort 443 -Protocol ExchangeAdminCenter -RemoteAddress 192.168.100.10

Der folgende Befehl löscht alle Regeln:

Get-ClientAccessRule | Remove-ClientAccessRule

Sobald die Client Access Regeln vollständig implementiert sind, werde ich diesen Artikel überarbeiten und weitere Beispiele einfügen.

Anmerkungen

Beim Erstellen der Regeln muss man im Hinterkopf behalten, dass immer die erste zutreffende Regel verarbeitet wird, danach aber keine weiteren Regeln angewendet werden. Hier mal ein Beispiel mit zwei Regeln, die erste verbietet den Zugriff auf EAC für das Subnetz 192.168.200.0/24, die zweite Regel erlaubt den Zugriff auf EAC von der IP 192.168.200.16:

Der Test mittel des CMDLets “Test-ClientAccessRule” liefert nun beide Regeln als Ergebnis für den Zugriff von der IP 192.168.200.16:

Hier greift aber nur die Regel mit Prio 1, auch wenn die Regel mit Prio 2 spezifischer ist:

Hier muss man also etwas aufpassen welche Regeln wie angeordnet werden, man kann sich sonst recht schnell selbst aussperren. Die Prio 1 Regel sollte daher besser nicht eine “DenyAccess” Regel sein, sondern eine “AllowAccess” Regel die den Zugriff von einem Management Netz oder Admin PC immer erlaubt.

In diesem Beispiel kann man also die Reihenfolge der Regeln verändern, damit der PC mit der IP 192.168.200.16 immer Zugriff auf EAC hat:

Viel wichtiger wäre hier natürlich der Zugriff via RemotePowerShell, da sich im Fehlerfall die Regeln nicht via EAC bearbeiten lassen, sondern nur via RemotePowerShell.

Desaster… Hilfe…!!!

Nun kann es ja doch einmal vorkommen, dass es zu einem kleinen Ausrutscher beim anlegen oder ändern von Client Access Regeln kommt. In der Exchange RTM Version lassen sich ja aktuell nur die Zugriffe auf EAC und RemotePowerShell einschränken, daher sperrt man sich als Admin also höchstens selbst aus. Benutzer sind also nicht direkt betroffen, daher erst einmal Ruhe bewahren.

Falls man sich also selbst ausgesperrt hat: Kein Problem, die Regeln werden im Active Directory gespeichert und lassen sich dort auch verändern oder löschen.

Um Regeln direkt im AD zu bearbeiteten kann der ADSI-Editor verwendet werden. Die Regeln werden in der Konfigurationspartition des AD gespeichert:

Ändert man nun die IP im Wert für “msExchTransportRuleXml” wird hier auch direkt die Regel geändert. Die Client Access Rule wird hier im XML Format gespeichert. Ich habe dazu einfach einmal die IP von 192.168.200.16 auf 192.168.200.17 geändert, dies wirkt sich auch direkt auf die Client Access Rule aus:

Falls man sich komplett verzettelt hat, lassen sich auch alle Regeln löschen, dazu können einfach die Einträge entfernt werden:

Die Exchange Shell meldet direkt das aktuelle Ergebnis, die Regeln sind gelöscht:

Hier muss dann allerdings wieder der Cache beachtet werden. Wie bereits erwähnt kann es hier bis zu einer Stunde dauern, bis der Zugriff wieder möglich ist (Alternativ Neustart der Exchange Server).