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 10, Windows 11, Windows 8 a 8.1, Windows server

Validace a oprava systémových souborů offline

Dostat se do situace, že počítač nestartuje a je potřeba systém opravit pomocí WinRE nebo instalačního média zase není nic vzácného. Opravu spouštěcích souborů už Microsoft předpřipravil jako jedno kliknutí, byť stále ji můžeme provést pomocí příkazové řádky, ale stavy jako je nestartující systém po BSOD z důvodu selhání NTFS.sys neřeší a určitě i v dalších scénářích nemusí postačovat.

Možnosti kontroly jako je chkdsk nebo diskpart nejsou nikomu cizí, ale jak zkontrolovat systémové soubory offline kopie Windows, nebo offline odebrat problémový ovladač, je předmětem tohoto článku. Pro kontrolu a opravu systémových souborů slouží 2 nástroje, SFC a DISM. SFC(system file chacker) je nástroj přímo určený na kontrolu systémových souborů, a pokud chci kontrolovat a opravit offline kopii systému, zapisuji příkaz takto:

sfc /scannow /offbootdir=c:\ /offwindir=c:\windows

Písmenu systémového disku offline kopie Windows, víše C, si zjistím pomocí nástroje diskpart příkazem list volume. Další systémové komponenty je potřeba kontrolovat pomocí DISM, kdy analýzu provedeme příkazem:

Dism /Image:C:\ /Cleanup-Image /scanhealth

Následnou opravu pak:

Dism /Image:C:\ /Cleanup-Image /RestoreHealth

Písmeno disku, víše C, opět pochází z výsledku diskpartu.

Pokud je příčinou pádu systému ovladač (a není to zrovna ntfs.sys, či jiný od MS, ty opraví příkazy výše), tak je možné jej offline odebrat, následně spustit systém a danému zařízení nainstalovat ovladač nový. K zobrazení přesného názvu ovladače využijeme příkaz:

Dism /Image:C:\ /Get-Drivers /format:table

Po nalezení odpovídajícího ovladače jej odebereme pomocí příkazu:

Dism /Image:C:\ /Remove-Driver /Driver:OEM1.inf

V příkladu výše pak OEM.inf je název problémového ovladače, který jsme si našli v tabulce z předešlého příkazu.

Poslední, co se nechá se systémem, krom modifikace registrů a souborů, dělat, je vrácení změn rolí a funkcí, případně aktualizací. Na odebrání posledních aktualizací MS opět nabízí GUI, ale to neřeší případ, že k pádu OS dojde při spouštění v rámci aktualizačního restartu. Stejně tak přidávání či odebírání komponent (jako např. Hyper-V). V těchto případech se pak pomocí DISM vrátí čekající změny příkazem:

DISM /image:C:\ /cleanup-image /revertpendingactions
Posted in: Windows server

Manuální odebrání certifikační autority v AD

Dnes se chci podělit o postup odebrání certifikační autority v existující doméně, když z nějakého důvodu zkolabuje a nelze obnovit (poškození OS a zálohy). Pokud je to jen trochu možné, odebírejte certifikační autoritu dle pokynů MS (viz dokumentace). Níže uvedený postup je opravdu riskantní, protože můžete poškodit jinou certifikační autoritu v doméně, doporučil bych jej ve chvíli, kdy zkolabovaná autorita byla jedinou autoritou provést dříve, nežli do domény nasadíte novou autoritu.

Praktický celý postup zvládneme v konzoli Active Directory Sites and Services, kde je potřeba mít zobrazené služby.

Pro práci budeme potřebovat větev Services\Public Key Services, kde se budeme pohybovat. S mazáním začneme ve větvi AIA uvnitř Public Key Services, kde najdeme objekt autority, kterou chceme smazat, klikneme na něj pravým tlačítkem a dáme Delete.

Nyní se přesuneme do větve CDP, kde najdeme kontejner odpovídající autority a celý jej smažeme.

Dále pokračujeme ve větvi Certification Authorities, kde smažeme objekt odpovídající autority. Pokud je odebíraná autorita podřízenou autoritou, je potřeba ověřit všechny vazby před smazáním objektu.

Dalším krokem je smazání objektu dané certifikační autority ve větvi KRA.

Posledním bodem práce v této konzoli je pak odebrání objektu autority v Enrollment Service.

Definitivní tečkou je pak odebrání autority v atributu domény, které již provedeme pomocí PowerShellu. Na tento příkaz již potřebujete oprávnění Enterprise admina.

$doma="<zadej název domény před tečkou>"
$top="<zadej název domény za tečkou>"
certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=$domena,DC=$top?cACertificate?base?objectclass=certificationAuthority"

V příkazu certutil výše přeci je doporučuji proměnné zaměnit za konkrétní hodnoty, kterých by nabývaly. Pokud Příkaz proběhne správně, zobrazí se seznam certifikátů všech certifikačních autorit v prostředí, vybereme požadovaný certifikát a potvrdíme OK.

Zdroj

Vlastní zkušenost s tímto úkonem a článek: Ruční odebrání starých odkazů na certifikační autority ve službě Active Directory | Řešení zabezpečení od Microsoftu (wordpress.com), ze kterého pochází obrázky, protože snímky z produkčního prostředí použít nemohu.

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

Oprava opakovaného vyžádání obnovovacího klíče Bitlocker

Dnes jen malá poznámka o problému, se kterým se setkávám a to je, když nástroj Bitlocker si vyžádá kód pro obnovení i po správně zadaném hesle. Nejčastěji je na vině aktualizace, BIOS bez pozastavené ochrany, ale někdy i ovladačů nebo pouze systému. Níže představím rychlé řešení, které lze aplikovat z běžícího systému, nebo z WinPE po odemčení jednotky, viz starší článek.

Začne řešením pro případ, že jednotka se odemyká automaticky pomocí TPM.

manage-bde -protectors -delete C: -Type TPM
manage-bde -protectors -add c: -tpm

Případ, kdy kombinujeme TPM a PIN je obdobný, příkazy níže:

manage-bde -protectors -delete C: -Type TPMAndPIN
manage-bde -protectors -add c: -TPMAndPIN

Byť to nemusí být nezbytné, doporučuji po této operaci znovu zálohovat klíč pro obnovu. Jak tomuto stavu předcházet? Na 100% to nelze, ale nejčastěji je na vině aktualizace BIOS, proto před jejím započetím doporučuji Bitlocker pozastavit a po jejím dokončení opět obnovit ochranu.

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

Řešení problému bootrec /fixboot access deny

Tento problém nastává v případě, že je potřeba opravit boot záznamy systému pro UEFI. Tento problém se týká oddílu EFI na disku využívající strukturu GPT. Podotýkám, že zde uvedený postup je až posledním řešením, často stačí příkaz chkdsk, ale pokud je potřeba provést bootre /fixboot a chybu nejde ignorovat, jde o opakovanou opravu bootu, jak jej můžete zkusit. V příkazové řádce WinRE prostředí postupujeme následovně:

  1. diskpart
  2. list vol
  3. sel vol <číslo jednotky UEFI>
  4. assign letter U
  5. exit
  6. cd /d U:\
  7. format U: /FS: FAT32
  8. bcdboot c:\windows /s U: /f UEFI
  9. cd /d u:\EFI\Microsoft\Boot\
  10. bootrec /fixboot

Často stačí skončit krokem 8, protože z adresáře systému Windows jsou do UEFI oddílu nahrány zcela nové Bootovací soubory. Když to nezabere, dokončíme všech 10 kroků.

Posted in: Windows server

Migrace FSMO rolí mezi servery

K „neřízené“ migraci FSMO rolí dochází naprosto přirozeně samo, ve chvíli, kdy je nedostupný (výpadek sítě, vypnutí a pod.) server, který má nějakou FSMO roli, dočasně tuto roli převezme jiný server. Po obnovení provozu serveru, který má danou roli si je přebere zpět, ale až po úplném dokončení synchronizace.

Dnešní příspěvek je určitým českým popisem stavu, kdy je nutné FSMO roli přesunou ručně a rozhodně nenahrazuje originální dokumentaci. Sám jsem se dostal do stavu, kterému se v licenční tématice říká Permanent hardware failure, kdy jsem musel vynutit „trvalé“ převzetí všech FSMO rolí jiným serverem. Bohužel, server který selhal provozoval 4 z 5 těchto rolí. Právě o tom, jak takovéto převzetí udělat, buď v výpadku, nebo plánovat před vyřazením z provozu je tento článek. K převzetí všech FSMO rolí slouží PowerShellový příkaz:

Move-ADDirectoryServerOperationMasterRole -Identity S3 -OperationMasterRole RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator,schemaMaster -Force

Tento příkaz je potřeba spustit na serveru, který má role převzít. Parameter Identity slouží k určení cílového serveru (je povinný), ale i tak doporučuji spouštět přímo na daném serveru. Pokud chci převádět jen některé role, stačí uvést jejich výčet v parametru OperationMasterRole.

Pokud server vyřazuje z provozu plánovaně, odebírám roli DC pomocí DCpromo, respektive příkazem:

Uninstall-ADDSDomainController

V takovém případě zůstávají role automaticky „rozebrány“ dalšími kontrolery, ale je dobré se o tom ujisti.

Posted in: Windows 10, Windows 11, Windows server

Odebrání serverů ze Server management konzole

Tento článek se týká Windows Serverů (verze 2012 a novější) instalované s GUI a klientských systémů Windows s instalovaným RSAT.

Konzole sama obsahuje možnost přidat servery a vytvořit skupiny serverů, do nichž je možné servery přidávat. Bohužel zde chybí možnost z této praktické konzole servery odebrat, což se ve spoustě případů může hodit. Postup odebrání je tedy následovný:

  1. příkaz: cd %userprofile%\AppData\Roaming\Microsoft\Windows\ServerManager
  2. Otevřít (k editaci, třeba Notapadem): ServerList.xml
  3. Smazat XML záznam pro server, který chceme odstranit
  4. Uložit
Back to Top