GRP2CAS

Diese Skript ist das Gegenstück zu Grp2ExInet, um anhand von Gruppenmitgliedschaften bestimmte Funktionen und Berechtigungen indirekt zu steuern. Exchange erlaubt es leider nicht, über Gruppen direkt bestimmte Funktionen zu steuern, sondern ein Administrator kann diese nur auf dem Server global abschalten oder eben pro Postfach. Und darüber kann man schon mal den Überblick verlieren. Zudem gibt es immer wieder Lücken, wenn jemand einen neuen Benutzer anlegt und dieser dann mehr darf als die Allgemeinheit, weil die entsprechenden Einstellungen nicht in der GUI direkt abgefragt wurden.

Daher ist eine Steuerung per Gruppen natürlich eine interessante Option, besonders wenn die noch mit einem Automatismus gepaart wird, der so ein Skript regelmäßig oder bei Änderungen im Active Directory anstößt.

Funktionsweise

Das Skript sucht zuerst die Gruppe über das Commandlet "Get-Group" und überträgt die Mitglieder der Gruppe in eine Hashtable.

Achtung: Es werden nur die direkten Mitglieder ausgewertet.

In einem zweiten Schritt werden dann alles CAS-Mailboxen mit "GET-CASMAILBOX" ausgelesen, um je Mailbox dann über die Hashtable zu prüfen, ob das Postfach Mitglied der Gruppe ist. Dieser Weg ist erforderlich, da es zum einen keine direkt Möglichkeit eines Zugriffs auf "MemberOf" über diese Commandlets gibt. Zum anderen ist es aber erforderlich, dass eine Einstellung wieder rückgängig gemacht wird, wenn ein Benutzer aus der Gruppe entfernt wird. Daher kann das Skript nicht einfach die Mitglieder der Gruppe abarbeiten, sondern muss alle potentiellen Mailboxen durchlaufen und die Einstellung vornehmen.

Die Exchange PowerShell Shell ist erforderlich, da das Skript auf "GET-CASMAILBOX" und "SET-CASMAILBOX" zugreift.

SMTP Beschränken

Über die Steuerung mittels Set-CASMailbox kann gesteuert werden, welcher Anwender über welches Protokoll auf das Postfach zugreifen darf. Sie können damit aber nicht beschränken, ob der Anwender auch per SMTP senden darf. Per Default hat Exchange zwei SMTP Receive Connectoren, Einer nimmt auf Port 25 die Verbindungen der anderen Server an und ein eigener Connector für Clients auf Port 587. Der Client Connector auf Port 587 nimm erst mal nur Mails nach vorheriger Anmeldung an. Das kann aber jeder Anwender nutzen, der ein Postfach hat und weiß, wie er sich per SMTP anmeldet.

Wenn Sie aber nun schon den Zugriff per POP3 und IMAP43 unterbinden, dann kommt bei dem ein oder anderen auch der Wunsch auf, dass die Anwender auch bitteschön nicht mehr über SMTP senden. Dies ist so erst mal nicht in Exchange vorgesehen.

Wollen Sie wirklich verhindern, dass Absender mit erfolgreicher Anmeldung per SMTP Mails einliefern? Sie können über das Messagtracking so eine "unerwünschte" Verwendung problemlos nachverfolgen und dann aktiv dagegen vorgehen. Es zu blockieren stellt bekannte interne Absender sogar schlechter als "das Internet", welches per Definition von extern ohne Authentifizierung Briefe einwerfen kann. Zugegeben wird es dort natürlich Spamfilter geben, aber

Sie können so eine Konfiguration aber durchaus einrichten. Allerdings nicht per GUI und per PowerShell ist es auch etwas kniffliger. Wer über einen SMTP-Receive Connector Mails einliefern darf, ist über Berechtigungen (ACLs) geregelt, die auf "Receive connector permissions" (https://technet.microsoft.com/en-us/library/jj673053(v=exchg.150).aspx) beschrieben sind. Relevant ist hier das Recht "ms-Exch-SMTP-Submit", welches per Default natürlich alle Exchange Absender haben. Hier ein Auszug der Powershell-Abfrage

Get-ReceiveConnector "HUB\Client HUB" |Get-ADPermission | select User,ExtendedRights,deny,IsInherited
  User                              ExtendedRights                          Deny    IsInherited
----                              --------------                          ----    -----------
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}     False   False
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}        False   False
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}              False   False
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}                   False   False

Sie sehen hier aber auch die Option "Deny". Also können Sie natürlich auch z.B. eine Windows Gruppe anlegen, die hier dann mit einem DENY addiert wird. Sie könnten auch den "Authenticated Users" das Recht wieder zu nehmen. Das ist aber viel weitreichender und könnte z.B. auch Überwachungslösungen und anderen Dinge stören. Wenn Sie schon Zugänge verbieten wollen, dann sollten sie die auf eine Gruppe anwenden, die sicher nicht von System könnten genutzt wird.

Vorarbeiten

Ehe Sie das Skript einsetzen können, müssen Sie natürlich eine Vorarbeit leisten: Sie müssen die erforderlichen Gruppen für die Anwendung der Richtlinien anlegen und die Mitglieder pflegen. Die Gruppe muss weder eine Sicherheitsgruppe noch muss diese Exchange Enabled sein. Eine einfache AD-Gruppe oder ein AD-Verteiler reicht schon aus. Hier ein Beispiel.

Je nach ihrem OU-Konzept und Administrationskonzept sollten Sie diese Konfigurationsgruppen in eine separate OU legen und steuern, wer die Mitglieder davon pflegen darf. Beachten Sie auch, dass sehr viele Gruppenmitgliedschaften bei Benutzern zu anderen Problemen führen können (z.B. Ticketsize)

Pflegen Sie dann in den Mitgliedern die Benutzer mit Postfach, die z.B. die entsprechende Funktion nutzen dürfen.

Einsatz

Wenn Sie dann die Benutzer in die jeweiligen Gruppen aufgenommen haben, können Sie das Skript aus einer Exchange PowerShell Shell einfach aufrufen. Der folgende Aufruf aktiviert den "OWA-Zugriff" für alle Mitglieder der Gruppe "grp2cas-owa" und deaktiviert OWA natürlich für alle anderen Konten.

# Aufruf ohne benannte Parameter
.\grp2cas.ps1 cn=grp2cas-owa,ou=grp2cas,ou=msxfaq,dc=e2007,dc=msxfaq,dc=de '-owaenabled $true' '-owaenabled $false'

# Aufruf mit benannten Parametern
.\grp2cas.ps1
   -groupname cn=grp2cas-owa,ou=grp2cas,ou=msxfaq,dc=e2007,dc=msxfaq,dc=de
   -memberparameter '-owaenabled $true'
   -nomemberparameter '-owaenabled $false'

Beachten Sie, dass die Parameter mit Werten wie "$true" hier in einfache Anführungszeichen verpackt werden müssen, damit dies als String übergeben wird und nicht ersetzt wird. Die Parameter haben dabei folgende Bedeutung. Ab der PowerShell 2 können Sie die Parameter auch benennen, ansonsten ist die Reihenfolge einzuhalten.

  • -groupname
    Der erste Parameter ist der DN der Gruppe. Wenn sie nur eine Domain haben und
  • -memberparameter
    Diese Parameter werden 1:1 so an den Befehl SET-CASMAILBOX übergeben, wenn die Mailbox "Mitglied" in der Gruppe ist
  • -nomemberparameter
    Diese Parameter werden 1:1 so an den Befehl SET-CASMAILBOX übergeben, wenn die Mailbox nicht Mitglied der Gruppe ist

Danach müssen Sie nur noch sicherstellen, dass das Skript eben regelmäßig oder zumindest nach Änderungen an den Gruppenzugehörigkeiten aufgerufen wird.

ACHTUNG: Das Skript ist „scharf !!!!
Wer erst mal sehen möchte, was passiert, möge die Zeile am Ende mit dem "Invoke-Expression" auskommentieren und die Logausgaben kontrollieren.

Logging

Über die Funktion "Start-Transcript" wird jede Aktion in eine Textdatei im gleichen Verzeichnis protokolliert.

 Sorgen Sie bitte dafür, dass Sie diese Logs später archivieren oder löschen, damit die Festplatte nicht voll läuft.

MultiDomain-Einsatz

Das Skript ist darauf ausgelegt, alle Objekte in einem Forest zu bearbeiten. Dazu wird die Option "IgnoreDefaultScope" und "Resultsize unlimited" verwendet, was drei Dinge zur Folge hat:

  • Angabe der Gruppe über den DN
    In der Zeile "Get-Group" muss beim Einsatz von "IgnoreDefaultScope" die Gruppe als DN angegeben werden. Der kurze Namen reicht nicht aus. Wen das stört und eh nur eine Domain hat, der kann das "-IgnoreDefaultScope" gerne entfernen und mit kurzen Gruppennamen arbeiten.
  • Lange Laufzeit in großen Umgebungen
    Ein sehr großen Umgebungen dauert ein "GET-CASMailbox sehr lange. Das ist in Ordnung, wenn wirklich alle Objekte bearbeitet werden müssen.
  • Globaler Fokus
    Vielleicht ist es auch gar nicht gewollt, dass diese Logik "alle" Konten verarbeitet. Dann können sie in der aktuellen Version dies noch nicht per Parameter angeben. Aber sie können das Skript natürlich selbst "ändern" und z.B.: einen Scope mit angeben.

Download

So nun habe ich sie lange genug mit Vorarbeiten, Beschreibungen und dem Einsatz samt Warnungen aufgehalten. Hier das Skript.

grp2cas.1.2.ps1

Offen

Kein Skript ist vollkommen, folgende Verbesserungen stehen noch auf meiner Wunschliste

  • ReadOnly-Mode / WhatIf
    Vielleicht wollen Sie ja nicht sofort die Änderungen eintragen sondern erst mal sehen, was passieren würde.
  • Einschränken des Scope
    Man muss nicht immer gleich ALLE Mailboxen bearbeiten. Eine Scope-Funktion wäre wünschenswert, um die Zielgruppe einzuschränken.
  • Warnung bei Gruppen
    Speziell bei mehreren Domain sollten Sie immer universelle Gruppen für die Steuerung verwenden. Eine falsche Gruppe sollte zumindest eine Warnung generieren.

Sie sehen also, dass die Arbeit nie ausgeht.

Weitere Links