Exchange: Admin Audit Log konfigurieren und durchsuchen

Besonders wenn mehrere Administratoren in einer Umgebung aktiv sind, kann es sinnvoll sein, einen Blick aufs Admin Audit Log zu werfen. Im Exchange Admin Audit Log werden alle Befehle mit detaillierten Informationen gespeichert. Somit lässt sich im Nachhinein einfach feststellen, wer welche Änderung mit welchem Benutzer vollzogen hat. Aufgrund der Tatsache, dass das Exchange Control Panel (ECP) im Hintergrund auch nur mit Powershell-Befehlen arbeitet, werden selbst diese Änderungen ins Log aufgenommen.

Admin Audit Log konfigurieren

Gleich vorab die gute Nachricht: Das Exchange Admin Audit Log ist standardmäßig aktiviert. Trotzdem sollte man bereits bei der Konfiguration des Exchanges ein Auge darauf werfen. Besonders folgenden zwei Parametern sollte man seine Aufmerksamkeit schenken:

• AdminAuditLogAgeLimit: Gibt an, bis zu welchem Zeitraum Logs gespeichert werden. Der voreingestellte Wert liegt bei 90 Tagen. Alle Befehle, die vor 90 Tagen ausgeführt wurden, fallen aus dem Log raus.
• LogLevel: Gibt an, ob die geänderte Einstellung ebenfalls im Log gespeichert werden sollen. Standardmäßig wird nur das ausgeführte Cmdlet geloggt, nicht aber jene Attribute, die der Befehl geändert hat.

Meine Empfehlung lautet ganz klar: Das AgeLimit auf 365 Tage ausweiten, sowie das Loglevel auf „Verbose“ stellen. Somit hat man die optimalen Einstellungen getroffen, um in Zukunft alle Änderungen retroperspektiv betrachten zu können. Mit folgendem Befehl werden die angesprochenen Parameter gesetzt:

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 365 -LogLevel Verbose

Admin Audit Log durchsuchen

So manch findiger Administrator wird sich nun unter anderem die Frage stellen, wo das Log eigentlich gespeichert wird. Alle möglichen Exchange Logs, wie jene vom IIS, MAPI und EWS werden direkt am Filesystem gespeichert. Das ist beim Admin Audit Log nicht der Fall. Dieses wird in einer sogenannten Systemmailbox gespeichert. Zum Durchsuchen wird der Powershell-Befehl „Search-AdminAuditLog“ verwendet.

RunspaceId         : 6ac12cb7-50d4-409f-988a-db75b052e5bb
ObjectModified     : /schweigers.at/Users/Kevin
CmdletName         : Set-Mailbox
CmdletParameters   : {Identity, DisplayName}
ModifiedProperties : {DisplayName}
Caller             : api@schweigers.local
ExternalAccess     : False
Succeeded          : True
Error              :
RunDate            : 01.06.2020 20:07:22
OriginatingServer  : EX01 (15.01.1979.002)
Identity           : AAMkAGZhYTY4ZTJhLTkyNjctNDc5Ny1hMjYyLWRmZWE5Yjk1YWFmOABGAAAAAACuoKglPoqYSYE1e/HZITnnBwADdTJFuJn4Rb
                     j9jGDdbjGxAAAAAAEbAAADdTJFuJn4Rbj9jGDdbjGxAADhP9DGAAA=
IsValid            : True
ObjectState        : New

An diesem Beispiel sieht man recht gut, wie das Log funktioniert. Trotzdem noch eine kleine Erklärung zu den wichtigsten Parametern:

• ObjectModified: Welches Active Directory Objekt verändert wurde.
• CmdletName: Welcher Powershell Befehl wurde ausgeführt.
• CmdletParameters: Welche Parameter beim ausgeführten Powershell Befehl angegeben wurden.
• ModifiedProperties: Zeigt an, welches Attribute durch den Powershell Befehl verändert wurde. Hätte man das Logging nicht auf „Verbose“ gestellt, würde dieses Feld leer bleiben
• Caller: Jener Benutzer, der den Befehl ausgeführt hat

Fazit

Da wir nun wissen, wie wir Änderungen von anderen Personen nachvollziehen können, können wir auch im nächsten Schritt beispielsweise Service Desk Mitarbeitern Zugriff auf einzelne Funktionen der Exchange Infrastruktur geben. Wie das gemacht wird, kannst du in folgendem Artikel nachlesen: Exchange: ServiceDesk Berechtigungsgruppe erstellen
Alle Organisationen die einen globalen Administratoren Account für alle Mitarbeiter haben, sollten ihr Konzept noch einmal überdenken. Gibt man jedem IT-Angestellten seinen eigenen Admin-User, kann man ihn nicht nur einfacher sperren, sondern es kann auch einfach nachvollzogen werden, wer welche Änderung eingekippt hat.