V aplikácii Microsoft Sentinel prejdeme do časti Automation – Playbook templates, nájdeme si šablónu “Send email with formatted incident report” a vytvoríme.
Teraz nám pribudla v strednej časti – Active Playbooks len si ju musíme prispôsobiť. Klepneme na názov a poďme do Logic app designer. Zmeniť musíme prvú položku – konektivita a poslednú, konto pod ktorým sa posiela email
Predtým než spravíme automatizované pravidlo si Playbook otestujme. Najsamprv ale skontrolujeme oprávnenia v Settings – Playbook permissions a tu vyberieme konkrétnu resource group. Aktívne povolenia skontrolujeme v časti Current Permissions.
Test spravíme v časti incidenty, kde jeden vyberieme – Akcie – Spustiť playbook
To s nami ešte trochu komunikuje – Run.
Keď tu klepenem na názov Playbooku, alebo to pozrieme cez Active Playbooks, vieme skontrolovať log ako nám úloha zbieha. Ak je všetko OK, vidíme v záložke Runs history – Succeeded
Keď nám všetko funguje konečne môžeme spraviť automatizovanú úlohu v Automation – Automation rules.Ponastavujeme si podmienky, pravidlá a dáme Enable.
Poďme si ukázať riešenie, ako pripojiť servery na Microsoft Defender 365 zo sietí bez prístupu na internet, dokonca bez prístupu na štandardnú webovú bránu. Teda cez nejaký dedikovaný proxy server určený len pre komunikáciu na Defender jedným smerom a do internej siete druhým smerom.
Použijeme na to OMS Gateway. Inštalácia je jednoduchá. V podstate zadefinujme iba port a prípadne webovú proxy, cez ktorú má komunikovať.
OMS Gateway sa nainštaluje do C:\Program Files\OMS Gateway a reaguje na powershell príkazy s OMS v názve napr. Get-OMSGatewayConfig apod.
Logy pozrieme z časti Applications and Services Logs – OMS Gatewey Log
Tento LOG je dôležitý aj z toho dôvodu, že tu zistíme ak nám OMS Gateway nekomunikuje na nejakú adresu. Je potrebné ich cez príkaz Add-OMSGatewayAllowedHost -Host adresa/názov servera -Force pridať medzi povolené hosty. Zatiaľ som cez chybu v LOG-u našiel nasledujúce hosty, ktoré musia byť v Allow hosts. Nikde som kedysi videl na stránkach MS aj kompletný. Keď nájdem doplním. Nižšie je zoznam s ktorým mi to bez chyby funguje už niekoľko mesiacov:
Medzi Allowed hosts si pridajme aj interné servery ktoré nám na OMS gateway komunikujú (teda napr. Add-OMSGatewayAllowedHost -Host interný server.domena.com -Force). Nezabudneme bránu po pridaní hostov reštartovať.
Pokračujeme nastavením nasledujúcich registrov na klientovi, ktorý má komunikovať na Defender, resp. na OMS Gateway:
No a už potom len onboardingom Defendra. Ciest ako to spraviť je viacero, či už cez Arc, alebo priamo skriptom z portálu security.microsoft.com – Settings – Endpoints – Device management – Onboarding. V prípade, že nám niečo nefunguje pomôžeme si utilitkou MDEClientAnalyzer.
Ak používate eDiscovery Export Tool na ukladanie exportov z eDiscovery môže sa Vám stať, že sa odmietne spustiť. Pre jeho beh je potrebné mať povolenú funkcionalitu tzv. Clickonce.
Support CLickOnce povolíme cez edge://flags/
Aktuálny stav skontrolujeme cez edge://policy
Alebo ľahšie nastavíme cez registre pre konkrétneho používateľa
V zariadeniach na portáli security.microsoft.com klikneme na tri bodky – Turn on troubleshoot mode
Po stlačení Submit, sa používateľovi počítača ktorý ideme riešiť zjaví nasledujúce hláška
Zavítame do poweshell-u a tam si príkazom Set-MpPreference vieme zapínať a vypínať moduly Defendra, podľa toho aký problém práve riešime. Príklad: Set-MpPreference -DisableEmailScanning $True, po skončení zase zapneme cez $False. Zoznam možností nám vylistuje príkaz Get-MpPreference.
Ak používame Mobile Aplication Management v Intune, vieme že zoznam preddefinovaných aplikácií na ktoré vieme tieto politiky viazať je pomerne obmedzený a obsahuje najmä aplikácie Microsoft. Iste je tu možnosť pohrať sa s tým a pridať custom aplikáciu, ale tak zas, načo si komplikovať život? Ten nám dostatočne skomplikujú používatelia, keď im zapneme obmedzenie nižšie:-)
Úvaha je nasledujúca. Načo vytvárať a vynucovať protection politiky cez Intune, keď sa nám ľudia vedia prihlasovať cez aplikácie, na ktoré sa tieto politiky nevzťahujú.
Jednou z možností je vytvorenie conditional access politiky pre povolenie prístupu do O365 len cez povolené aplikácie. Zoznam týchto aplikácií spravuje Microsoft a priebežne sa obmieňa.
Politika by potom mohla vyzerať nejako takto. Zapneme si na akú aplikáciu/službu to chceme aplikovať. Ja som vybral iba Exchange, keďže chcem obmedziť používanie iba na Outlook
V Conditions vyberieme Device Platforms a do Include dáme Android a iOS. Pozor na Exclude, aby sme tam mali zaškrtnutý iba doplnok k Include, teda Windows, macOS a Linux.
V časti Grant zvolíme Grant access – Require approved client app, prípadne ak máme použité tak vyberieme aj voľbu pod tým – Require app protection policy.
Keďže sme odvážny, rovno zapneme.
Výsledok je potom taký že v sign-in logoch vidíme, že ak používateľ nepoužije na prístup k pošte Outlook, conditional access politika ho zablokuje
Úloha je jasná. Zmazať z používateľských schránok mail, ktorý nemali dostať. Hromadne to spravíme rýchlo a efektívne cez powershell. Začneme inštaláciou a pripojením sa k príslušnej službe:
Teraz použijeme portál pre Compliance – https://compliance.microsoft.com/. Po novom mu nadávame Microsoft Pureview, kde si vieme vyhľadávaciu úlohu vyklikať cez GUI, alebo spravíme cez powershell. Mažeme mail u konkrétneho používateľa so Subjectom “Test_Delete”.
$Search=New-ComplianceSearch -Name "Vymaz_mailu" -ExchangeLocation mailová_adresa -ContentMatchQuery 'Subject:"Test_Delete"'
iný príklad (všetky schránky)
$Search=New-ComplianceSearch -Name "Vymaz_mailu" -ExchangeLocation All -ContentMatchQuery 'Subject:"Test_Delete"'
Úlohu naštartujeme cez príkaz “Start-ComplianceSearch -Identity $Search.Identity” alebo cez GUI.
Kontrolu či dobehla spravíme rovnako cez GUI, alebo cez príkaz “Get-ComplianceSearch“
No a teraz tá zábavnejšia časť. Ideme mazať. Najprv si skontrolujeme čo nám vlastne našlo cez príkaz “Get-ComplianceSearch-Identity “Vymaz_mailu” | fl“. Výsledok si skontrolujeme v poli SuccessResults. Teraz vyrobíme novú akciu na mazanie cez príkaz:
New-ComplianceSearchAction -SearchName "Vymaz_mailu/názov vyhľadávacej úlohy vyššie" -Purge -PurgeType HardDelete
Potvrdíme - Yes/All a počkáme kým skončí. Priebežne kontrolujeme cez príkaz Get-ComplianceSearchAction. Keď skončí všimneme si že nám vytvorilo nový objekt, ktorý má koncovku _purge. Po skončení si mazaciu úlohu pozrieme cez príkaz:
get-ComplianceSearchAction -Identity "Vymaz_mailu/názov úlohy_Purge" | fl
Tu si už len pozrieme úspešnosť úlohy.
Budeme potrebovať utilitku “MDEClientAnalyzer“, ktorý si stiahneme z odkazu https://aka.ms/MDEAnalyzer. Rozpakujeme si na príslušnom serveri/klientovi, kde riešime problém a z príkazového riadka spustíme ako admin – MDEClientAnalyzer.cmd. Akceptujeme EULA a počkáme pár (a viac) minút. Výstupom bude pekný html report informujúci o stave Defendra aj s chybami a radami ako ich vyriešiť.
Export príslušných logov bude uložený do adresára v ktorom je rozbalená utilitka:
Stav Arc agenta skontrolujeme napr. príkazom azcmagent show
Logy a konfiguračné súbory nájdeme v adresári – C:\ProgramData\AzureConnectedMachineAgent
No a onboardovacie logy, resp. errory zase v adresáry kde máme umiestnený onboardovací skript (adresár AzureArcDeploy). Tam pribudne nový adresár AzureArcLogging s podadresárom NotConnected obsahujúcim xml súbory s chybami.
Jedným z rozumnejších spôsobov ako naimportovať a následne spravovať onpremise servery v Azure je využitie služby Azure Arc. Prístupná je cez hlavný portál Azure
Predtým než začneme s onboardingom serverov do Arc skontrolujeme si či na subskripcii máme registrované “Resource providers” – Microsoft.HybridConnectivity. Ak nie, klepneme na Register.
V portále Arc budú pre nás pre onboarding serverov zaujímavé dve, resp. tri položky a to “Service principals”, ktorú použijeme z dôvodu abstrakcie prihlasovania sa do Azure, tj. aby sme nemuseli používať konto administrátora. Je to nevyhnutné z dôvodu hromadného onboardingu cez GPO.
Ďalšou položkou je “Private link scopes”, kde zavítame keď budeme chcieť meniť prístup onpremise prostredia do Azure z Public alebo proxy na privátnu VPN no a poslednou časťou je “Machines”, kde s onboardingom začneme.
ťukneme teda na “Add/Create” a vyberieme “Add a machine”
Tu máme možnosť onboardovať server po jednom, hromadne alebo s využitím Update Management. Zameriame sa na hromadné pridanie serverov, nakoľko pridanie jedného servera je z pohľadu nastavenia len podmnožinou tejto možnosti.
Klepneme na Add multiple servers – Generate script. Čaká nás základné nastavenie:
subscription – vyberieme subskripciu z ktorej sa bude Arc účtovať
Rersource group – rovnako ako vyššie. Ak nemáme, cez Create new vytvoríme novú
Region – vyberáme west Germany, že? 🙂
Operating system – možnosť vybrať Linux, alebo Windows
Connectivity method – možnosti public, proxy alebo private endpoint (musíme ho mať vytvorený). Pre začiatok nie je naškodu ísť cestou Public. Priškrtiť to môžeme vždy. Najmä treba myslieť na príslušné sieťové prestupy z onpremise do Azure.
Authentication – budeme potrebovať vytvoriť service principal
Vytvorenie service pricipal nie je žiadna veda. Je možné spraviť to z tohto okienka, alebo z hlavného menu Arc viď obrázok vyššie. Vyberáme si či Service principal použijeme na Resource Group, alebo na Subscripciu, platnosť kľúča a hlavne nezabudneme zaškrtnúť rolu Azure Connected Machine Onboarding. A úplne najdôležitejšia vec – stiahneme si pricipal ID and Secret, lebo už sa k nemu nikdy nedostaneme! Jedine teda že si vygenerujeme nový, k čomu sa tiež dostaneme, keďže platnosť kľúča nie je neobmedzená.
Keď máme vyklikané, prejdeme na ďalšiu obrazovku, kde zvolíme Group policy:
Ako prvé si z linku “Download Installer package” stiahneme inštalátor “AzureConnectedMachineAgent .msi”. Ten si uložíme niekde na filesystém, budeme ho odtiaľ inštalovať na servery. Zložku do ktorej inštalátor uložíme nazdieľame a nezabudneme na rozumné oprávnenia. Teda Domain Servers, Admins, Computers prípadne iné, ktoré používame. Určite nechceme v produkcii nechať Everyone.
V ďalšom kroku si stiahneme z Githubu zip súbor s pomocnými skriptami a šablónou pre group policy. Toto si rozbalíme niekde na doménový radič napríklad. Nižšie v kroku 4 si parametrizujeme spúšťanie práve týchto stiahnutých skriptov ktoré obsahuje balíček “ArcEnabledServersGroupPolicy_v1.0.6.zip”.
No a parametre. Domain name je jasný a z nasledujúcich dvoch vyskladáme cestu k share kde sme si uložili inštalátor z kroku 2. Teda vyzerať to môže tak, že ReportServerFQDN bude server. domena.com a ArcRemoteShare bude napr. MSI\GPO\Arc. Nebojte keď tam zadáte blbosť pri spustení skriptu si vo výpise rýchlo všimnete ako a akú cestu skript vyskladáva, kde ste dali navyše lomítko a podobne, takže to ľahko napravíme priamo v parametroch skriptu. Nezabúdame samozrejme serviceprincipal-Enter secret here:-)
No a už sa stačí len nalistovať do adresára s rozbaleným “ArcEnabledServersGroupPolicy_v1.0.6.zip” a spustiť skript z kroku 4. Ak všetko prebehne v poriadku, pribudne nám nová politika s názvom [MSFT] Azure Arc Servers Onboarding a časovou značkou. Tú stačí nalinkovať na OU a pridať computer objecty serverov. Tie sa vo väčšine prípadov do Arc-u pochytajú automaticky.
No a čo vlastne robí tá politika? pridáva dva registrové záznamy:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\AzureArc\RegistrationInfo, Value type REG_SZ, Value data RegistrationInfoTOSET
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\AzureArc\RegistrationKey, Value type REG_SZ,
Value data RegistrationKeyTOSET
a dva naplánované úlohy na inštaláciu Arc agenta parametrizované podľa toho čo sme zadali vyššie. V zdieľanom adresári to potom vyzerá nejako takto:
Manažment Service principals robíme v portály Azure Arc – Service principals
Tu si potom v časti Certificates & secrets vygenerujeme nový kľúč. Nezabudneme uložiť “Value”, keďže sa k nej už nikdy nedostaneme!
No a teraz tá zaujívamá časť. Pri generovaní GPO pre munltimachines onboarding cez Azure sa nám kľúč pre Service principal skriptom “AzureArcDeployment.psm1” (čo nájdeme v skripte DeployGPO.ps1, od riadku 221) zašifroval a uložil v tejto podobe na share, ktorý sme si definovali pre súbory politiky do súboru “encryptedServicePrincipalSecret”.
Keď zmeníme kľúč, samozrejme sa nám nechce vyrábať celú politiku a všetko okolo nanovo. Na internete je veľa dobrých ľudí, a našiel som nasledovnú drobnú modifikáciu časti skriptu DeployGPO.ps1:
$ServicePrincipalSecret = 'TU NAHRAME VLASTNY KLUC'
$DomainComputersSID = "SID=" + (Get-ADDomain).DomainSID.Value + '-515'
$DomainControllersSID = "SID=" + (Get-ADDomain).DomainSID.Value + '-516'
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
$descriptor = @($DomainComputersSID, $DomainControllersSID) -join " OR "
Import-Module .\AzureArcDeployment.psm1
$encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSecret)
$encryptedSecret | Out-File -FilePath .\encryptedServicePrincipalSecret -Force
Tú stačí pustiť v umiestnení kde máme uložený “AzureArcDeployment.psm1” a nový súbor “encryptedServicePrincipalSecret” je na svete. potom ho stačí nakopírovať na share kde máme uložený starý a onboarding funguje s novým kľúčom.
IT tipy rady návody 