Jak sporządzić log audytowy z Configuration Manager-a?

Administrator Configuration Manager-a, który cząstkę swej „władzy nad produktem” musi oddać w inne ręce, często spotyka się ze skutkami nieprzemyślanych działań. A to ktoś skasował kolekcję, a to ktoś inny utworzył obiekt niezgodnie z konwencją nazewniczą…

Nawet nie chodzi o to by „ścigać sprawcę”, lecz aby dotrzeć do właściwych osób z koniecznymi wskazówkami, jak powinny postępować. Oczywiście są też firmy i instytucje, gdzie rozliczalność jest na tyle istotna, że działania administratorskie muszą być rejestrowane.

Sam z siebie, Configuration Manager rejestruje informacje o działaniach administratorów w systemie komunikatów statusowych, wyróżniając je typem „Audit”. Wystarczy więc utworzyć filtr wyłapujący takie komunikaty, kierując je do odpowiednio przygotowanego logu. Log Application, choć najłatwiejszy do wykorzystania nie jest dobrym miejscem, gdyż wiele aplikacji do niego zapisuje rozmaite informacje. Zatem plan działań jest następujący:

1. Utworzyć log audytowy dla potrzeb Configuration Manager-a.
2. Utworzyć źródło danych.
3. Utworzyć skrypt zapisujący informacje do wskazanego logu na podstawie zmiennych.
4. Utworzyć filtr Configuration Manager-a (albo zmienić istniejący filtr 12 dodając uruchomienie programu) odnoszący się do typu Audit powodujący wykonanie skryptu ze wskazanymi parametrami. Należy pamiętać, że utworzony takim poleceniem log zacznie swój „żywot” od następnego restartu systemu, nie należy próbować zapisu do niego wcześniej.powershell.exe -ExecutionPolicy Bypass -Command „&{Write-EventLog -LogName ConfigMgrSecurity -Source 'Configuration Manager security auditing’ -eventID %2 -EntryType %3 -message '%4′ }”Filtr statusowy Configuration Manager-a powinien mieć przykładową postać (zakładając, że w katalogu C:\SCRIPTS umieszczono skrypt o nazwie FILTR.BAT
5. C:\SCRIPTS\FILTR.BAT „Configuration Manager security auditing” %msgid SuccessAudit „%msgdesc”
7. Skrypt (tu przykładowo FILTR.BAT umieszczony w katalogu C:\SCRIPTS) może zawierać jedną linię, wywołującą polecenie PowerShell-a:
8. New-EventLog -LogName ConfigMgrSecurity -Source „Configuration Manager security auditing”
9. Zakładając, że log będzie miał nazwę „ConfigMgrSecurity”, a źródło danych „Configuration Manager security auditing”, należy zacząć od polecenia PowerShell:powershell.exe -ExecutionPolicy Bypass -Command „&{Write-EventLog -LogName ConfigMgrSecurity -Source 'Configuration Manager security auditing’ -eventID %2 -EntryType %3 -message '%4′ }” 

   Filtr statusowy Configuration Manager-a powinien mieć przykładową postać (zakładając, że w katalogu C:\SCRIPTS umieszczono skrypt o nazwie FILTR.BAT

   C:\SCRIPTS\FILTR.BAT „Configuration Manager security auditing” %msgid SuccessAudit „%msgdesc”

    

   Rezultaty:

   Utworzenie kolekcji powoduje wystąpienie komunikatu statusowego, zapisywanego w logu o zadanej nazwie w postaci:

   

    

   Uwagi końcowe.

   1. Chociaż nazwa logu może być dłuższa od 8 znaków, jednak znaczenie identyfikacyjne logu ma jedynie pierwsze 8 znaków nazwy!
   2. Jest cały zbiór parametrów, które można przekazywać w filtrach (nie tylko %msgid i %msgdesc). Warto spojrzeć na zestawienie w Technecie (https://technet.microsoft.com/en-us/library/bb693758.aspx)
   3. Dlaczego w skrypcie znajduje się polecenie PowerShell, a nie wywołanie wbudowanego programu EventCreate? EventCreate zmusza do korzystania z EventID do 1000, zaś większość zdarzeń Configuration Manager-a ma czterocyfrowe kody zdarzenia… Na szczęście Write-Eventlog nie ma tego ograniczenia.