Posted in: Windows 10, Windows 11, Windows server

Odinstalace programů PowerShellem

Nainstalovat program příkazovou řádkou, nebo pomocí PwerShellu, klidně i vzdáleně, není nic až tak těžkého. Pro msi balíčky máme msiexec a pro balíčky z MS Store máme rovněž integrované jednotné nástroje, horší je to s exe soubory, tam potřebujeme pokyny od vydavatele aplikace. Otázkou pak zůstává, jak vzdáleně takové programy odinstalovat.

Vzdálený přístup na systém nám může zajistit vzdálená relace, nebo v případě software distribuovaného jako msi také parametr ComputerName. Pokud chceme odebrat program, který byl instalován jako MSI, pak potřebujeme identifikační číslo dané instalace programu. Identifikační číslo nejsnáze zjistíme příakzem:

Get-WmiObject Win32_Product | select Name, Version, IdentifyingNumber | FL
#pro vzdálený počítač
Get-WmiObject Win32_Product -ComputerName pc2 | select Name, Version, IdentifyingNumber | FL

Následuje již příklad se samotnou odinstalací programu:

(Get-WmiObject Win32_Product | where IdentifyingNumber -eq "{C17F6DEF-D34C-4B75-97E1-D81062408B4A}").Uninstall()
#pro vzdálený počítač
(Get-WmiObject Win32_Product -ComputerName pc2 | where IdentifyingNumber -eq "{C17F6DEF-D34C-4B75-97E1-D81062408B4A}").Uninstall()

Pokud budu chtít odebrat programy, které jsou instalované pomocí exe souborů, pak potřebuji malinko jiný příkaz, ale i to se dá zvládnout vzdáleně, tentokrát již s pomocí vzdálené relace (Enter-PSSession).

Get-Package -ProviderName Programs -IncludeWindowsInstaller | select Name, Version, Source, ProviderName | FL
#příklad odinstalace 7zipu
Get-Package -Name "7-zip*" | Uninstall-Package
Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Kontrola konektivity pomocí PowerShellu

Všichni ověřujeme možnost přístupu někam po síti pomocí příkazu ping, kterému rozumí příkazová řádka i PowerShell včetně všech jeho parametrů. PowerShell ovšem ukrývá dvojici cmdletů, která nám dává lepší možnosti zjištění síťové dostupnosti služby či zařízení. Tím hlavním je Test-NetConnection, který je vylepšenou obdobou pingu, využívá WMI třídu Win32_PingStatus.

Nejjednodušší podobu udává příklad s obecným dotazem na bing.com:

Test-NetConnection bing.com                                                                                                                                                                                                                                                                                                                          ComputerName           : bing.com
RemoteAddress          : 204.79.197.200
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.0.21
PingSucceeded          : True
PingReplyDetails (RTT) : 15 ms

Výhodou proti pingu je možnost doptat se na více počítačů najednou, jako v následujícím příkladu, kde jsou počítače rozděleny do skupin dostupných (true) a nedostupných (false)

$computers = "chi-dc01","chi-dc02","chi-dc04","chi-app01","chi-core01"
$computers | group {test-connection -count 1 -ComputerName $_ -quiet}

Další výhodou je možnost ptát se na konkrétní služby, tedy ne jen na to, zda je daný systém online, ale zda je na něm aktivní webserver (http protokol).

Test-NetConnection bing.com -CommonTCPPort HTTP


ComputerName     : bing.com
RemoteAddress    : 204.79.197.200
RemotePort       : 80
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.0.21
TcpTestSucceeded : True

Podporované jsou následující protokoly:

  • SMB
  • HTTP
  • RDP

Druhým příkazem je Test-WSMan, který slouží k detekování možnosti vzdálené správy pomocí PowerShellu.

Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Správa automatického spouštění aplikací PowerShellem

Všichni čas od času řešíme, co se nám spouští spolu s přihlášením, no startem systému. Často jsou to chtěné funkcionality, jako třeba OneDrive, ale např. Teams již chtěné být nemusí a spousta dalších aplikací zrovna tak. Běžně se tyto problémy dají řešit pomocí Autoruns od Sysinternals, správcem úloh, nebo složitěji přes registry, služby a specifické složky. Ale jak to řešit na vzdáleném počítači? Když vynecháme RDP, AnyDesk a další, které připojí pracovní plochu jiného PC, zbyde nám PowerShell a editor registru (pokud je povolná vzdálená správa registru). A právě o možnostech PowerShellu to dnes bude.

PowerShllem máme 2 možnosti řešení, tu komplexnější, kdy využijeme vzdáleného připojení pomocí Enter-PSSession -ComputerName <název počítače>, nebo budeme využívat parametr ComputerName. Níže budu popisovat řešení přímé připojení se k danému stroji pomocí Enter-PSSession.

Automaticky spouštěné položky vypíšeme následujícím příkazem:

Get-CimInstance Win32_StartupCommand | Select-Object Name, command, Location, User | Format-List

Bližší informace k příkazu Get-CimInstance jsou v dokumentaci. Příkaz Get-CimInstance podporuje parametr ComputerName. Pokud ve výstupu bude uvedeno jako Location: common startup location, jde o cestu: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Většina položek ovšem povede do registrů. Pro práci s registry se nám budou hodit následující příkazy:

  • Get-ItemProperty -Path <doplň>
  • Remove-ItemProperty -Path <doplň> -Name <doplň>

Pokud naopak budeme chtít něco do autoranu přidat, např. Outlook, tak do registrového klíče doplníme záznam příkazem: New-ItemProperty -Path <doplň> -Name <doplň> -PropertyType <doplň> -Value <doplň>

Posted in: Windows server

Přihlašovací hodiny

Dnes se chci podělit o to, jak pomocí PwerShellu hromadně přenastavit, nebo vypnout přihlašovací hodny, tedy omezení, kdy se daný uživatel může v síti hlásit. Tato nastavení není v AD žádnou novinkou a důvody nastavení mohou být buď politické (požadavek vedení), nebo bezpečnostní, protože v době, kdy se uživatel nemůže hlásit, nemůže ani spouštět plánované akce a nelze jeho účet zablokovat pomocí chybného zadávání hesla. Toto nastavení by se nemělo za žádných okolností zadávat administrátorským účtům a BFÚ (obyčejným) účtům administrátorů, aby bylo možné kdykoliv reagovat na jakoukoliv situaci.

Pokud je firma s jednosměnným provozem, tak dává smysl, aby všechny zaměstnanecké (nikoliv adminské a servisní) účty byly uzamčené přes noc a pokud firma běžně pracuje od pondělí do pátku, tak také přes víkend. Toto nastavení pomůže snížit riziko kybernetického útoku, protože útočníci se snaží firmy napadat v době, kdy na ně interní IT nebude reagovat. Ve školním prostředí pak dává smysl omezit všem žákům možnost přihlášení na dobu od 7 do 16 hodin (možná 17 hodin), čímž nemusím jako admin řešit, kdo má nultou hodinu a kdo odpoledku.

Jak na to hromadně?

Začneme tím nejjednodušším a to je návrat k výchozímu stavu, tedy přihlášení povolení 24/7 všem uživatelům. Na to nám stačí jednoduchý příkaz:

#Nastavíme proměnou hours na 25/7
[byte[]]$hours = @(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255)
Get-ADUser -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Jak vyresetovat jen konkrétní OU ukáže následující příklad na OU žáci:

#Nastavíme proměnou hours na 25/7
[byte[]]$hours = @(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255)
Get-ADUser -SearchBase "OU=Zaci,OU=Uzivatele,OU=Skola,DC=skola,DC=local" -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Jak nastavit pro všechny žáky povolení přihlášení jen v pracovní dny od 7 do 16?

[byte[]]$hours = @(000,000,000,192,127,000,192,127,000,192,127,000,192,127,000,192,127,000,000,000,000)
Get-ADUser -SearchBase "OU=Zaci,OU=Uzivatele,OU=Skola,DC=skola,DC=local" -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Kde vzít ono bytové pole? To je dobrá otázka, která má ve skutečnosti jednoduchou odpověď. Otevřeme si libovolného uživatele a v GUI mu nastavíme přihlašovací hodiny dle libosti, např. takto:

Když vše potvrdíme a uložíme, otevřeme znovu uživatele a podíváme do editoru atributů na atribut logonhours, který dvojklikem otevřeme a necháme si jej zobrazit dekadicky, binární příklad přidávám níže:

Tento výpis, v dekadické podobě, zkopírujeme do proměnné $hours v příkazech výše, čímž dojedeme k tomu, že dle tohoto uživatele můžeme nastavit celé OU nebo celou doménu. A proč jsem vložil binární příklad? Protože si vysvětlíme, jak to funguje.

  • 1 bit = 1 hodina
  • 3 byty (3x 8 bit) = 1 den
  • 168 bit = jeden týden

První 3 byty jsou neděle, druhé 3 byty pondělí atd. Nyní je rovněž jasné, jak vše spočítat a do příakzů výše zadávat rovnou vypočtené hodnoty 😉

Posted in: Windows server

Výpis obnovovacího klíče Bitlocker z AD

Dnešní krátký kód vypíše z AD obnovovací klíč Bitlockeru, pokud je uložen v AD bez toho, aby na daném řadiči byly instalovány nástroje pro práci s Bitlockerem.

Import-module ActiveDirectory
$ADComputer = Read-Host -Prompt "Zadej jméno počítače"
$DN = Get-ADComputer $ADComputer | Select-Object -ExpandProperty DistinguishedName
$ADobj = get-adobject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} -SearchBase $DN -Properties 'msFVE-RecoveryPassword' | Select-Object Name,msFVE-RecoveryPassword
[Ordered]@{
    Computer = $ADComputer
    RecoveryPassword = $ADobj.'msFVE-RecoveryPassword'
    Date = Get-Date -Date ($ADobj.Name ).Split('{')[0]
    BitlocerKeyID = (($ADobj.Name ).Split('{')[1]).TrimEnd('}')
} 
Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Odebrání zbytkového ovladače

Na odebrání ovladačů, které systém již nepotřebuje je spousta cest. Nejlepší je samozřejmě odebrat ovladač při odinstalaci zařízení ve Správci zařízení.

Někdy se může stát, že zařízení obsahuje mnoho ovladačů, které nikdy nevyužilo (např.: jednotný image pro mnoho typů počítačů s integrovanými ovladači). V takovém případě je možné nepotřebné ovladače odebrat pomocí cleanmager.exe (vyčištění disku), který spustíme jako správce, pak máme na výběr odebrání ovladačů.

Vše výše popsáno je zcela bezpečné a stabilní, takto provedená operace je bez rizika. Problém je v tom, že i některý SW implementuje ovladače (typicky bezpečnostní produkty) a může se stát, že i po odinstalaci takového produktu zůstanou v systému fragmenty, třeba i ovladače. V takovém případě doporučuji na webu vydavatele najít odinstalační nástroj a pokyny k jeho užití, pomocí jehož je možné tyto fragmenty odebrat. Systém sám obsahuje nástroje k nalezení a odebrání ovladačů. Doporučení je, tyto akce provádět v Safe modu systému.

Nalezení a odebrání ovladače z běžícího systému

Zde nám v první řadě pomůže nástroj DISM, který nám vypíše ovladače jež nejsou z dílen Microsoftu. Stačí následující příkaz.

dism /online /get-drivers /format:table

Výstup je vidět na obrázku níže.

Na výpisu výše je vidět, že v systému je takovým fragmentem ovladač Esetu edevmon, který je provozován stejnojmennou službou. Další postup si ukážeme právě na příkladu tohoto ovladače. V tomto bodě si potřebujeme bokem uložit original file name, bude potřeba později. K odebrání ovladače použijeme vestavěný nástroj pnputil pomocí následujícího příkazu (v PowerShellu):

#pnputil /delete-driver < Published Name>  /force
#příklad Esetu:
pnputil /delete-driver oem10.inf  /force

Pokud se příkaz zdaří, je ovladač odebrán ze systému. Zde bych doporučil restartovat systém, aby se projevila změna. Pokud vše proběhne v pořádku, ověříme si výpisem DISM (první bod), že systém neprováděl opravu spuštěním s poslední funkční konfigurací. Nyní můžeme odebrat vlastní binární soubor ovladače pomocí PowerShellu.

#Remove-Item -Path C:\Windows\System32\drivers \<original file name>.sys -Force
#Příklad s Esetem
Remove-Item -Path C:\Windows\System32\drivers edevmon.sys -Force

Pokud příkaz skončí chybou, znamená to, že systém soubor odstranil sám, pokud ne, odstranění provedl příkaz.

Offline odebrání ovladače

Zde jsou 2 důvody, potřebujeme upravit soubor install.wim, nebo po instalaci ovladače systém nenastartoval. V obou případech použijeme nástroj DISM, v prvním pomocí něj vybalíme instalační obraz do složky, v druhém budeme tento nástroj spouštět z příkazové řádky ve WinRE, či instalačním médiu.

Načtení seznamu ovladačů je obdobné jako u běžícího systému:

#Instalační obraz máme ve vybalený ve složce C:\test\offline
Dism /Image:C:\test\offline /Get-Drivers

Nyní můžeme odebírat ovladače

Dism /Image:C:\test\offline /Remove-Driver /Driver:OEM10.inf

Po úspěšném dokončení operace v případě úpravy instalačního obrazu vše uložíme příkazem:

Dism /Unmount-Image /MountDir:C:\test\offline /Commit

V případě opravy systému, kterou provádíme z prostředí WinRE nebo instalačního média počítač restartujeme do plnohodnotného systému.

Posted in: Windows 10, Windows 11, Windows server

Stažení databáze hesel Have i been pwned

Správci systémů někdy potřebují databáze uniklých přihlašovacích údajů k tomu, aby zjistili, zda někdo z jejich uživatelů nepoužívá kompromitované přístupové údaje. Krom různých fór útočníků a pentesterů je jedním z dobrých zdrojů služba Have i been pwned. Dříve se přímo ze stránek této služby nechala stáhnout databáze s uniklými hesly ve formátu NTLM pro kontrolu těchto údajů v AD. Jedním z nástrojů, které umí tyto údaje kontrolovat je DSInternals. Nově web Have i been pwned má aplikaci pro stahování databáze hesel a o tom je tento příspěvek.

Stažená

Pro stažení a samotnou práci s aplikací je potřeba mít .NET6, jak jej instalovat jsem již psal. Pro instalaci downloaderu pak může sloužit např. příkaz:

dotnet tool install haveibeenpwned-downloader --tool-path "C:\Program Files\NET6\Tools"

Stažení databáze hesel ve formátu NTLM

Vlastní stažení databáze do složky aplikace je pak v PowerShellu velice jednoduché, jak ukazuje příklad níže.

#Přepneme se do adresáře aplikace
cd C:\Program Files\NET6\Tools
#Stáhneme hesla
.\haveibeenpwned-downloader.exe -n pwnedpasswords_ntlm
Posted in: Windows server

Nastavení DHCP pro PXE Boot Windows Deployment Services na BIOS i UEFI

Dnes to bude o tom, jak nastavit DHCP na Windows serveru tak, aby poskytlo v DHCP možnosti 67 validně pro BIOS i UEFI. Ve výchozím stavu se v návodech na konfiguraci WDS dočtete, že DHCP možnosti 67 má být uvedeno „boot\x64\wdsnbp.com“, což je možnost pro BIOS a legacy boot. Jak ale nastavit podmíněně možnost 67? Odpovědí je použít DHCP politiky, ale nejdříve musíme detekovat, zda má zařízení UEFI, nebo BIOS.

Detekce UEFI a BIOS

Řešením je rozšířit Vendor Classes z výchozích Windows 98 option, Windows 2000 option a Microsoft option o detekci architektury. Nejsnazší to bude pomocí PowerShellu:

Add-DhcpServerv4Class -Name "PXEClient (UEFI x64)" -Type Vendor -Data "PXEClient:Arch:00007"
Add-DhcpServerv4Class -Name "PXEClient (UEFI x86)" -Type Vendor -Data "PXEClient:Arch:00006"
Add-DhcpServerv4Class -Name "PXEClient (BIOS x86 & x64)" -Type Vendor -Data "PXEClient:Arch:00000"

Alternativně můžeme využít postup zachycený na snímcích níže.

Do dat v ASCII zapíšete postupně hodnoty z PowerShellových příkazů výše (co příkaz, to jedna hodnota Vendo Classes). Tím jsme dosáhli toho, že DHCP ví, zda o IP žádá BIOS nebo UEFI.

Konfigurace DHCP možnosti 67

Nyní již k tvorbě politiky, která nastaví spouštěcí soubor PXE boot. Nejprve všechno v PowerShellu (V příkazech je nutné nastavit ScopeId dle IP rozsahu, který obsluhuje naše DHCP):

Add-DhcpServerv4Policy -Name "PXEClient (UEFI x64)" -ScopeId 10.10.10.0 -Condition OR -VendorClass EQ,"PXEClient (UEFI x64)*"
Add-DhcpServerv4Policy -Name "PXEClient (UEFI x86)" -ScopeId 10.10.10.0 -Condition OR -VendorClass EQ,"PXEClient (UEFI x86)*"
Add-DhcpServerv4Policy -Name "PXEClient (BIOS x86 & x64)" -ScopeId 10.10.10.0 -Condition OR -VendorClass EQ,"PXEClient (BIOS x86 & x64)*"

Set-DhcpServerv4OptionValue -ScopeId 10.10.10.0 -PolicyName "PXEClient (UEFI x64)" -OptionId 067 -Value "boot\x64\wdsmgfw.efi"
Set-DhcpServerv4OptionValue -ScopeId 10.10.10.0 -PolicyName "PXEClient (UEFI x86)" -OptionId 067 -Value "boot\x86\wdsmgfw.efi"
Set-DhcpServerv4OptionValue -ScopeId 10.10.10.0 -PolicyName "PXEClient (BIOS x86 & x64)" -OptionId 067 -Value "boot\x64\wdsnbp.com"

Tentokát nebudu přidávat textový popis a snímky obrazovky, místo toho jsem našel pěkné video i s vysvětlením a angličtině, takže vkládám níže.

Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Výpis oprávnění ke všem SMB share na serveru

Dnes si ukážeme malý kus PowerShellu, který velice usnadní auditování oprávnění na sdílených složkách. Jako první si uvedeme příklad kódu, který vypíše všechny složky, kde je nějak nastaveno oprávnění pro úroveň Everyone:

$SMB = (Get-SMBShare).Name
foreach($n in $SMB)
{
    Get-SmbShareAccess -Name "$n" | where AccountName -EQ Everyone
    
} 

Kompletní výpis pak poskytne odlehčená verze kódu:

$SMB = (Get-SMBShare).Name
foreach($n in $SMB)
{
   Get-SmbShare -Name "$n"   
   Get-SmbShareAccess -Name "$n"   
} 

Bližší informace, jako je cesta a server vkládá do výpisu s oprávněními právě příkaz Get-SmbShare, který lze volat i samostatně k vypsání informací o všech sdílených složkách (bez parametrů) krom oprávnění.

Posted in: Windows 10, Windows 11

Instalace .NET 6 pomocí PowerShellu

V rámci automatizace správy se může hodit instalovat SW pomocí PowerShellu dávkově jedním skriptem. Ani moderní .NET 6 není výjimkou. Instalační skript je možné stáhnout přímo z webu Microsoftu. https://dot.net/v1/dotnet-install.ps1

Ve výchozím stavu je bohužel tímto skriptem instalován .NET do adresáře AppData daného uživatele, který skript sopustí, což není ve firemním prostředí vhodné a není to dobré ani z pohledu bezpečnosti. Osobně mohu doporučit instalovat pomocí následujícího příkazu z PowerShellu spuštěného jako správce:

.\dotnet-install.ps1 -Channel LTS -InstallDir "C:\Program Files\NET6"

Pokud bude instalace provedena takto, bude .NET instalován normálně v Program Files a bude dostupný všem. Podadresář NET6 se vytvoří voláním příkazu automaticky.

Podrobnosti je možné nalézt v dokumentaci MS: dotnet-install scripts – .NET CLI | Microsoft Learn

Back to Top