Nejprve musíme zajistit na doménových řadičích zapnutí Audit Policy: Directory Service Changes, nejlépe v Default Domain Controllers Policy (Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies)

Vytvoříme výstrahu (alert), reagující na událost v bezpečnostním logu 5136: A directory service object was modified, přičemž nás zajímá změna atributu gPLink. Událost 5136 a její parametry (%n) podle dokumentace Microsoftu (Windows 7 and Windows Server 2008 R2 Security Event Descriptions.xls) vypadá takto

A directory service object was modified.

Subject:
Security ID: %3
Account Name: %4
Account Domain: %5
Logon ID: %6

Directory Service:
Name: %7
Type: %8

Object:
DN: %9
GUID: %10
Class: %11

Attribute:
LDAP Display Name: %12   <--- gPLink
Syntax (OID): %13
Value: %14

Operation:
Type: %15                <--- (Value Added, Value Deleted) 
Correlation ID: %1
Application Correlation ID: %2

Podmínka tedy bude vypadat takto pro výstrahu při odebrání vazby GP na OU:

(Event ID Equals 5136) And (Parameter 15  Equals Value Deleted) And (Parameter 12 Equals gPLink)

nebo pro přidání vazby:

(Event ID Equals 5136) And (Parameter 15  Equals Value Added) And (Parameter 12 Equals gPLink)

SACL (system access control lists) jsou seznamy, které řídí audit na úrovni jednotlivých objektů. Pokud potřebujeme mít jistotu, že je audit nastaven, museli jsme postupně všechny (alespoň ty důležité) objekty kontrolovat, jeden po druhém.

V nejnovějších verzích Windows Server 2008 R2 a Windows 7 lze definovat globální politiku pro celý počítač (global object access auditing policy), pro celý souborový systém nebo registry. Zvolený SACL je pak automaticky přiřazen každému objektu vybraného typu. Ve výsledku je záznam generován, pokud vyhoví kombinaci globálního nastavení a lokálního nastavení SACL.

V konfiguraci (global object access auditing policy) lze uvést jednotlivý účet nebo skupinu, jejichž aktivitu sledujeme. Z toho je zřejmé použití v různých scénářích: sledování aktivity vybrané skupiny uživatelů nebo správců či diagnostika – když hledáme konkrétní objekty pro jednotlivého uživatele, ke kterým nemá přístup (hlášení “access denied“), což znemožňuje uživateli zamýšlenou činnost.

Technet: Global Object Access Auditing

Výsledkem je, že tyto stavy na straně agenta vůbec nemonitoruje!
Náprava je jednoduchá, vytvoříme si vlastní monitor, tentokrát správně konfigurovaný a původní monitor můžeme pomocí override úplně zakázat, protože je k ničemu.

Použijeme například následující (mírně modifikovaný původní) předpis:

1. Create a unit monitor – vybereme typ: Windows Events \ Simple Event Detection\ Windows Event Reset
2. Destination Management Pack - použijeme vlastní MP, buď už existující nebo nový (pojmenujeme třeba Forwarder) rozhodně NEPOUŽIJEME Default management pack!
3. Monitor pojmenujeme např. Audit Collection Forwarder – connection, jako cíl uvedeme v Monitor target: Microsoft Audit Collection Services Forwarder a rodičovský monitor musí být Availability.
4. V dalším kroku uvedeme správné jméno logu, ve kterém monitor vyhledává události, Event Log (Unhealthy Event) Log name: Operations Manager.
5. Event Expression (Unhealthy Event):  AND group (Event ID equals 4369, Event Source equals adtagent)
6. Stejně bude i pro Event Log (Healthy Event) Log name: Operations Manager.
7. Event Expression (Healthy Event):  AND group (Event ID equals 4368, Event Source equals adtagent)
   
8. Configure Health: Mapování monitoru na stavy – první událost vyvolá přepnutí do stavu Warning nebo Critical, vyberte co vám více vyhovuje.
9. Configure Alerts: podle potřeby zvolíme i generování alertu. Máme možnost volit jeho automatické uzavření, pokud monitor přejde do zdravého stavu. Kupodivu zde nelze použít Custom fields.

Verze Windows podle MinBuild pro Source Name = Security odpovídají:

2195 - Windows 2000
2600 - Windows XP
3790 - Windows 2003
3791 - Windows 2003 R2

Verze Windows podle MinBuild pro Source Name = Microsoft-Windows-Security-Auditing odpovídají:

5384 - Windows Vista / 2008
7000 - Windows 7 / 2008 R2

Sekce Source Name = CrossPlatformSecurity obsahuje události sbírané ze systémů Unix a Linux.

Způsob použití a popis transformačních funkcí uvedl Eric Fitzgerald před časem: ACS Event Transformation Demystified

Standardní implementace SCOM + ACS tuto oblast nepokrývá, ale je k dispozici placené řešení od SecureVantage Technologies (Archiver). Nic nám však nebrání, abychom si zpřístupnili historická data sami v paralelní databázi se stejnou strukturou, jakou má databáze se „živými daty“.

Výchozí modelová situace:

Aktuální data pokrývají období 100 dnů v provozní databázi ACS, historická data jsou k dispozici v archivních souborech a každý z nich pokrývá 100 dnů, se vzájemným přesahem 1-2 dny. Archivní soubory jsou vytvořené pomocí nástroje MS SQL Server Management Studio.  (Databases \ OperationsManagerAC | Tasks | Backup… | Backup type: Full | Back up to Disk: <jméno souboru>.bak)

Vytvoření prázdné databáze:

Databáze se bude jmenovat OperationsManagerACH, bude pro zjednodušení na stejném serveru SQL jako aktuální databáze – proto odlišné jméno. Na tomto serveru jsou také instalované SQL Reporting Services.

1. Získáme předpis pro vytvoření nové databáze: SQL Server Management Studio | označíme databázi OperationsManagerAC | Script Database as | CREATE To | New Query Editor Window
2. V editoru skript upravíme:
   jméno databáze, ctrl-H, Find what: OperationsManagerAC, Replace with: OperationsManagerACH
   jména souborů změníme, protože je ukládám do stejné složky:
   dbAuditData.mdf -> dbAuditDataH.mdf
   dbAuditLog.ldf -> dbAuditLogH.ldf
3. Skript provedeme (execute) a získáme tak novou prázdnou databázi OperationsManagerACH.

Zápis záznamů z archivu databáze:

Databázi OperationsManagerACH naplníme informacemi z archivního souboru, například v prostředí SQL Server Management Studio následujícím postupem.

Tasks | Restore | Database … | záložka (General)

• To database: OperationsManagerACH
• přepnout volbu na From device, vyhledáme [...] v dialogu Specify Backup: Backup media: File, Add : <jméno souboru.bak> OK,
• Označit Restore [x]

na druhé záložce (Options): označené jsou pouze dvě volby

• Restore options: Overwrite the existing database (WITH REPLACE) a
• Prompt before restoring each backup

Důležité je v tomto modelovém případě pozměnit pojmenování cílových souborů databáze historických dat:

• Restore the database files as (změnit pojmenování ve sloupci Restore As, [...]) <cesta>\dbAuditDataH.mdf a <cesta>\dbAuditLogH.ldf
• Dále zvolíme první položku Recovery state: Leave the database ready to use … (RESTORE WITH RECOVERY)

Jakmile akce Restore doběhne, jsou historická data plně k dispozici a lze je zpřístupnit pro reporty.

Reporty, Data Source:

Spustíme webový Report Manager a vytvoříme nový datový zdroj, který se připojuje k výše vytvořené databázi:

http://<reportserverMachine>/Reports

• akce Add new data source
• pojmenujeme – Name: DBH Audit
• povolíme – Enable this data source
• Definujeme způsob připojení databáze – Connection string: data source=<scom07serverName>;initial catalog=OperationsManagerACH;Integrated Security=SSPI
• Windows Integrated Security

Toť vše, protože je nová databáze vytvořena na serveru, kde je definována a korektně obsazena role db_datareader a jsou zde funkční SQL Reporting Services.

SELECT
'RDP' AS LogonType,
Logon.CreationTime AS LogOnTime,
LogOff.CreationTime AS LogOffTime,
Logon.String04 AS Computer,
Logon.String02 AS IP,
Logon.PrimaryDomain AS LogonDomain,
Logon.PrimaryUser AS LogonUser
FROM
(SELECT * FROM AdtServer.dvAll WHERE EventId=528) AS Logon LEFT OUTER JOIN
(SELECT * FROM AdtServer.dvAll WHERE EventId=538) AS LogOff ON
Logon.PrimaryLogonId = LogOff.ClientLogonId
WHERE
Logon.String01 = '10'
ORDER BY LogOnTime

Odpovídající události na serveru Windows 2008 jsou 4624 a 4634, a místo dvojice PrimaryLogonID = ClientLogonID použijeme String01. Také cílový počítač, informace o adrese IP a typ přihlášení jsou uvedené v jiných sloupcích tabulky v databázi. Uživatel je uveden v poli TargetUser:

SELECT
'RDP' AS LogonType,
Logon.CreationTime AS LogOnTime,
LogOff.CreationTime AS LogOffTime,
Logon.String05 AS Computer,
Logon.String03 AS IP,
Logon.PrimaryDomain AS LogonDomain,
Logon.TargetUser AS LogonUser
FROM
(SELECT * FROM AdtServer.dvAll5 WHERE EventId=4624) AS Logon LEFT OUTER JOIN
(SELECT * FROM AdtServer.dvAll5 WHERE EventId=4634) AS LogOff ON
Logon.String01 = LogOff.String01
WHERE
Logon.String02 = '10'
ORDER BY LogOnTime

Sloupec Computer označuje cílový počítač, IP je adresa, odkud došlo k přihlášení uživatele – Logon User. Pokud budeme chtít vyhledat další události vázané na stejné LogonID, budeme hledat shodu mezi zjištěným LogonID v poli String01 události 4624 a LogonID u dalších událostí. Bude to vyžadovat pátrání, protože LogonID se vyskytuje ve Windows 2008 u 163 událostí v různých parametrech. Pokud je při transformaci v databázi ACS (OperationManagersAC) LogonID zaznamenáno v poli PrimaryLogonID, je zde uvedeno v desítkovém tvaru. V poli String01 je však v šestnáctkovém, takže je musíme pro porovnání převést na shodný základ. Pro třetí řádku z předchozího výpisu jde o LoginID = 0×332321, v desítkovém zápisu ‘3351329‘. Toto číslo tedy hledáme v záznamech událostí v poli PrimaryLogonId:

SELECT EventId, Category, CreationTime, PrimaryUser as UserName, PrimaryDomain as Domain, PrimaryLogonId,String01, String02
FROM AdtServer.dvAll
WHERE PrimaryLogonId = '3351329'

Vybrané události skutečně následují časově po přihlášení uvedeném v předchozím výpisu na třetím řádku.

• z auditních záznamů událostí v bezpečnostním logu jsme schopni zjistit okamžik změny a původce, změnu verze, zápis do objektu nebo smazání objektu GP v AD (Directory Service Audit Access). Žádné detaily.
• z auditních záznamů přístupů k souborům (File Access Audit) jsme schopni odlišit změny nebo zápisy na úrovni souborů v \\domain\sysvol\fqdn.domain\policies\{policy-guid}\, tj. v souborech a složkách
  • GPT.INI (verze)
  • \Machine\Registry.pol (HKLM)
  • \Machine\Scripts (startup, shutdown)
  • \Machine\Applications (MS Installer)
  • \Machine\Microsoft\Windows NT\Secedit (Gpttmpl.inf – security)
  • \Machine\Adm (šablony pro editor)
  • \User\Applications (MS Installer)
  • \User\Documents and Settings (Fdeploy.ini – redirections)
  • \User\Microsoft\RemoteInstall (OSCfilter.ini)
  • \User\Microsoft\IEAK (Internet Explorer)
  • \User\Scripts (logon, logoff)

Detailní informace o změněných položkách takto ovšem nezískáme. (zdroj)
Existují produkty určené ke správě AD nebo přímo pro Group Policy které mohou tento úkol splnit. Nezkoušel jsem je, takže jen vyjmenuji, co jsem objevil:

• ADAudit Plus – Active Directory Auditing and Reporting (ManageEngine),
• Group Policy Change Reporter (NetWrix),
• a v neposlední řadě obsahuje sledování změn GPO také Advanced Group Policy Management (Microsoft), který řeší problematiku správy a nasazování politik ve firmě (technické detaily zde).

Pro každý profil, který přichází v úvahu a je v něm Firewall zapnutý (Domain, Private, Public) (3) upravíme co a kam se bude zaznamenávat, tlačítko Customize . . . (4)

Name: určuje umístění souboru, není problém změnit cestu i pojmenování, výchozí je – C:\Windows\system32\LogFiles\Firewall\pfirewall.log. Dále můžeme určit maximální velikost (Size limit (KB)) a vybrat, co se bude zaznamenávat:

• zahozené pakety (dropped packets)
• úspěšná připojení (successfull connections)

Ukončíme a uložíme zvolené nastavení – OK |OK.

Služba okamžitě začne soubor používat. Přesvědčíme se o tom – můžeme zobrazit obsah textového souboru se záznamy přímo z adresy, kterou jsme si zvolili: C:\Windows\system32\LogFiles\Firewall\pfirewall.log, nebo z prostředí výše uvedeného nástroje pro správu Firewalu, když ve stromové struktuře v levé části vybereme Monitoring:

Formát uložených informací a příklad záznamů:

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2010-10-06 18:19:02 ALLOW TCP 10.0.0.51 10.0.0.51 56247 1433 0 - 0 0 0 - - - SEND
2010-10-06 18:19:02 ALLOW TCP 10.0.0.51 10.0.0.51 56247 1433 0 - 0 0 0 - - - RECEIVE
. . .
2010-10-06 18:22:15 ALLOW TCP 10.0.0.51 10.0.0.50 56395 88 0 - 0 0 0 - - - SEND
. . .
2010-10-06 18:22:26 DROP UDP 10.0.0.1 10.0.0.255 137 137 78 - - - - - - - RECEIVE

Příkazem auditpol /set /subcategory:“Filtering Platform Connection“ /success:enable /failure:enable nastavení změníme. Názvy kategorií a podkategorií jsou závislé na jazyce lokalizace serveru, proto je možné používat místo jmen jazykově nezávislý  GUID: auditpol /set /subcategory:“{0CCE9226-69AE-11D9-BED3-505054503030}“ /success:enable /failure:enable

Kontrolní výpis pak potvrdí, že změna byla provedena:

V logu nás potom budou zajímat následující události:

Allowed and blocked connections:

• 5154—Listen permitted
• 5155—Listen blocked
• 5156—Connection permitted
• 5157—Connection blocked
• 5158—Bind permitted
• 5159—Bind blocked

Note Permitted connections do not always audit the ID of the associated filter. The FilterID for TCP will be 0 unless a subset of these filtering conditions are used: UserID, AppID, Protocol, Remote Port.

Čerpal jsem ze stránek MSDN: http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx, které uvádějí GUID pro další kategorie a podkategorie a seznam generovaných událostí, které přicházejí pro tyto účely v úvahu.

K zobrazení událostí používám filtry v bezpečnostním logu, viz zde.

Důležitá poznámka: zapnutí auditu firewallu může způsobit generování vysokého počtu záznamů, takže je důležité po změně nastavení sledovat provoz nebo povolit audit pouze na nezbytně dlouhou dobu, např. při vyšetřování problémů.