Přejít k obsahu webu
2.11.2020 / kaldy123

Podepisování PowerShell skriptů

Bylo-nebylo. Organizace měla předepsanou bezpečnostní politiku.

a existoval skript, který byl pro byznys důležitý:
Jenže. Ten skript nefungoval:
A tak ho bylo treba podepsat:
é voilá:
Byznys firmy je zachráněn! Ale zase se ozvali bezpečáci, že je nutné dokladovat, jakým certifikátem je náš skript podepsaný.
Řešíme opět přes PowerShell:
Zdálo se že hotovo, ale volal kamarád, že nemá PKI a potřebuje „sámsivařímsámsiperu“ certifikát – „selfsigned certificate“. A jestli, prý, jestli na to nemám mast. Tak jsem zalovil na netu a zde je powershell commandlet:
Parametrů hafo, takže krátký mustr:
Nezapomeňte certifikáty distribuovat na potřebné počítače do úložiště Cert:\CurrentUser\TrustedPublisher! Takže export-import:

a jak říkal Pat Matovi:

A je to!

 

Klíčová slova: certifikát, certificate, code signing, powershell script signing, selfsigned certificate, create selfsigned certificate, report script certificate

13.8.2020 / kaldy123

Windows Update for Business

Jak najdete v popisech (kde ?), Windows Update for business není feature ani funkce Windows, je to jen soubor doporučení a postupů, jak řídit Windows Update v Enterprise prostředí, kde potřebujeme striktní politiky na fungování Windows, kde není místo na nějaké neočekávané aktualizace.

Microsoft uvádí celou řadu scénářů a příkladů, kde se tak děje, ale já zde uvádím konkrétní příklad.

Petr xxxx<petrb@xxx.cas.cz>
Wed 8/12/2020 10:09 AM
Dobrý den,
tentokrát si dovoluji otázat se na něco já. Mám takovou prosbu. Před cca měsícem jsem byl nucen vyměnit počítače, které mi ovládají mé přístroje (difraktometry) za nové. Nebylo už jiného zbytí. Samozřejmě, že už teď nebyla jiná možnost než použít počítače s OS Windows10. U běžných počítačů pro kancelářskou práci s W10 nemám žádný problém. Ale zde u těch „měřicích“ počítačů se mi jeden očekávaný problém vyskytl. A sice automatické aktualizace. Dnes v noci nastalo přesně to, co jsem očekával, a čeho jsem se obával. Počítače se restartovaly během probíhajícího měření, naprosto nezávisle na tom, že to měření běželo.
Naštěstí se difraktometry samy zastavily a nedošlo, kromě ztráty dat, k ničemu závažnějšímu. Alespoň toto vím, že se vlastní stroje zachovají v pořádku. Měl bych tedy v souvislosti s tím následující prosbu o radu.
Jak nastavit Windows 10 do režimu, který jsem měl u Windows XP. Tedy, aby mi systém nabídl aktualizace, ale ty se provedly až po mém zásahu. Protože v případě měřicích počítačů se „velká výhoda“, že se aktualizace provedou samy, stává ještě větší nevýhodou. V nastavení W10 si já jako uživatel dokážu aktualizace odložit, ale ne nakonfigurovat se své potřebě. Nerad bych samozřejmě vypínal, nebo odkládal aktualizace na neurčito, ale rád bych je udělal v nejbližším možném termínu tak, aby mi měření doběhlo v pořádku. Existuje taková možnost? Případně i nastavením přes msconfig nebo v registrech?

Řešení je, jak bylo v emajlu naznačeno, v politikách. Protože jsem v Krkonoších, kde hlídám vnuka, ukáži jej pro zjednodušení na lokálních politikách, ale samozřejmě doporučuji natáhnout na DC adminitrative templates pro Windows 10 a udělat to přes Group Policy – ušetří to HODNĚ práce!

Tedy Computer Configuration, Administrative Templates, Windows Components, Windows Update:

Zde jsem se nechal nachytat proklamacemi Microsoftu o Windows Update for Business, a zaměřil jsem se na tyto politiky. Ouvej!
Tyto politiky se opět nehodí, než k odložení updates o počet dní od vydání aktualizace. A jak víme, termíny nejsou v obecném povědomí a navíc je ani MS není schopen dodržovat… (1809?  !)

Zalovil jsem tedy mezi politikami Windows Update, a tam nalezl to pravé ořechové:

V této politice (Computer settings – Administrative templates – Windows Components – Windows Update – Configure Automatic Updates) si lze nastavit den a hodinu (popř. týden v měsíci), kdy se má začít s updaty.

V business critical prostředí lze tak nastavit updatovací okruhy: 1. týden testeři, 2. týden méně kritičtí uživatelé, 3. týden vysloveně kritické stroje (bankomaty), 4. týden lze vyhradit na jiné úpravy, popř. deinstalaci nevyhovujících updatů.  Spolu s touto konfigurací doporučuji nastavit:

  •  Allow Automatic Update Immediate Installation na Disabled
  •  Turn on recommended updates via Automatic Updates na Enabled
  •  No auto-restart with logged on users for scheduled automatic update installations na Disabled

Nevím, jak dlouho nám Nejvyšší tyto politiky v platnosti zachovati ráčí, ale takto lze nastavit update našich stroječků na definovaný čas. Navíc, není nutno ponechávat workstejšny zapnuté každou noc, ale lze vyhradit „maintenance day“ jednou týdně nebo jednou měsíčně a provést tolik nepopulární apdejty spolu s potřebnými restarty…..

25.6.2020 / kaldy123

Windows 2004

No jo, už máme jednu „univerzální“ verzi Windows, a to Windows 10, ale chlapci z Redmondu si poradili i s tímto omezujícím faktorem: 2x do roka vydávají nové buildy, které se od sebe už dost podstatně liší (pro odborníky: Semianual Channel).

Už jste dospěli k buildu 2004? U nás doma ano. Želbohu. První do toho zahučela moje lepší polovička. To jsme se se psem proháněli kolem Vltavy na kole, když mne zastihl telefonát:

„Ty jsi zase dělal něco na mém počítači?“ Tentokráte jsem se cítil celkem jistý v kramflekách, protože od jisté doby uživatelské stanice nechávám žít jejich životem, protože jejich uživatelé nepovažujíya optimální nastavení, které za ta léta považuji za optimální já.

„Byl porušen vztah důvěry mezi počítačem a ověřujícím serverem“ – (asi to neinterpretuji zcela přesně, doopravdy nemám rád lokalizované verze systému) deklamovala poslušně má drahá. Uklidnil jsem se. to obyčejně spraví jeden powershellový příkaz (Test-ComputerSecureChannel -Repair), jenomže vykládejte uživateli, že se má přihlásit jako lokální admin, spustit powershell, zadat onen příkaz a restartovat (to není nutné, ale pro jistotu, že máte všechny politiky)… Tkaže jsem slíbil, že jakmile dorazíme, podívám se na to…

Naštěstí. Když jsem se do toho pouštěl, byl jsem již u počítače sám. Suverénně jsem se pustil do úkolu a zrovna tak suverénně jsem pohořel. Abych se připojil jako lokální admin, potřebuji obrácené lomítko! ( .\ atd…)

První problém. Mám svůj systém nastavení jazyků, ve kterém nesmí chybět angličtina US s klávesnicí  US International (kdo se připojoval vzdálenou plochou z Androidu, ví proč). Jediný jazyk, který počítač po upgradu rozeznával, byla čeština s klávesnicí QERTZ. No jo – když máte malou klávesnici notebooku a nemáte angličtinu – zkuste zadat obrácené lomítko!!!

Nastavení jazyka a klávesnice bylo po upgradu nastaveno na implicitní (default) hodnoty. U všech účtů.

Takže.

1. odpojit počítač od sítě.

2. přihlásit se přes nakešované credentials.

3. změnit nastavení jazyků a klávesnic.

4. připojit se k síti.

5. přihlásit se jako lokální admin.

… a zkusil jsem ono powershellové zaklínadlo.

Účet vašeho počítač není v databázi ověřujícího počítače! Nějako v tom smyslu mě informoval Neomylný a Vševědoucí. Jen tak pro kontrolu jsem si ověřil stav AD na mém starouškovi: tam vše OK.

Že by?!
Název počítače byl po upgradu změněn na jméno generované při instalaci.

Ale pouze lokálně. Na AD si netroufl, sketa!
Scheisse!!! Takže:

  1. Odpojit počítač od sítě.
  2. Odpojit počítač z domény.
  3. Přejmenovat počítač (na jméno které měl před událostí – tak je uveden i v AD!)
  4. Připojit počítač do sítě.
  5. Připojit počítač do domény

Hladce to klaplo, původní účet počítač v AD konečně poznal svého majitele a došlo i ke spárování.

Tož tak.

 

Klíčová slova: Windows 10, build 2004, upgrade, semmianual channel, po upgradu se nelze připojit do domény, po upgradu ztraceno nastavení jazyků a klávesnic

11.6.2020 / kaldy123

Remote Desktop can’t connect to remote computer

Hlášku:

určitě znáte. Většinou jste si na vině sami, něco jste prostě opomenuli. Ale ouvej! 11.6.2020 (datum uvádím, aby bylo zřejmé, že je to záležitosti některého z posledních Windows updatů) jsem v tom byl opravdu dost nevinně. Situaci nastíním obrázkem:

Je to již mnoho let, co jste přes „vlastnosti počítače“ (remote settings) nastavovali povolení vzdálené plochy. Ať již pro terminal services nebo administrative remote desktop.

Ouups! Máme zde moderní a vysoce produktivní systém Windows 10. A nějaký chytrý softvér dizajnér vymyslel do „všeobecně oblíbené“ aplikace „settings“ (jo to je ta, co se snaží neuměle a humpolácky nahradit Control panel – česky Ovládací panely) nastavení Remote desktop.

A jestli si myslíte, že se tento frikulín nějak obtěžoval s nastavením přes Control panel – taxe šeredně mýlíte a dostanete výsledeček z obrázku 1.

Tož tak.  Settings -> System -> Remote desktop

Klíčová slova: Remote desktop, Vzdálená plocha, Remote Desktop can’t connect to remote computer, Control panel, Ovládací panely, jak povolit vzdálenou plochu, how to enable remote desktop, nelze připojit vzdálená plocha, cannot connect remote desktop

BTW: https://aio.cz/skoleni.asp

 

4.3.2020 / kaldy123

IIS Virtual Directory na core serveru.

Core IIS server sice lze pohodlně spravovat z remote IIS konzoly, nicméně, ale pokud máte virtuálních adresářů povícero a navíc, pokud máte farmu IIS serverů – je to k uklikání.
Dobře, máme powershell, ale ouha! Pokud se podíváte na parametry New-WebVirtualDirectory,  je zřejmé, že máme problém se zadáním pověření (credentials). A to může být docela problém, zejména, pokud máte virtuální adresáře na sdílených adresářích (shares).

New-WebVirtualDirectory [-Site <String>] [-Application <String>] [-Name] <String> [-PhysicalPath <String>] [-Force] [<CommonParameters>]

V tomto příspěvku uvádím tedy nástin PS příkazů, jak co nejvíce zautomatizovat řešení popsaného problému.

Zavedení modulu WebAdministration.

Abychom mohli s IIS dobře pracovat, zavedeme tento modul. Jeho nepřítomnost například zjistíme velmi rychle absencí PoverShell drive provideru IIS: .

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\WINDOWS\system32> Import-Module WebAdministration
PS C:\WINDOWS\system32>

Vytvoření virtuálních adresářů

Pro jednoduchost uvádím 3 servery, na kterých máme share szar. Virtuální adresář bude mít vždy jméno serveru a bude ukazovat do zmíněného share.

PS C:\>
PS C:\> $servery='server1','server2','server3'
PS C:\> $servery|% {New-WebVirtualDirectory -site status.domena.cz -Name $_ -PhysicalPath ('\\' + $_ +'.domena.cz\szar') -force}

Name    PhysicalPath
----    ------------
server1 \\server1.domena.cz\szar
server2 \\server2.domena.cz\szar
server3 \\server3.domena.cz\szar

Použití parametru -force je na tomto místě docela kruciální. Příkaz se snaží po zadání validovat zadanou cestu, nicméně pracuje v lokálním kontextu a jaxi se mu to nepovede. Zadání pověření (credentials) v tomto kroku není možné – takže je potřebné validaci parametru nějako obejít. Parametr -force vynutí založení adreáře, i kdzž cesta je neplatná.

Doplnění credentials.

Toto provedeme nastavením vlastností na Power Shell drivu IIS: . Protože nemáme specializované parametry pro položku virtuálního adresáře, řešíme toto konstruktem, kdy zadáváme dvojici jmého_vlastnosti – hodnota_vlastnosti. Protože virtuální adresáře mají v tomto příkladě jména shodná se servery, do kterých ukazují, jedním příkazem nastavíme pro všechny 3 adresáře uživatelské jméno a druhým pro všechny 3 adresáře heslo. Jméno: potřebujeme doménového uživatele, anžto lezeme na sdílené adresáře v síti. Heslo se zadává kupodivu v otevřeném textu, ale v systému se ukládá šifrovaně.
(Soubor ApplicationHost.config)

PS C:\> $servery|% {Set-ItemProperty -Path ('iis:\sites\status.domena.cz\' + $_) -Name userName -Value domena\bfu}
PS C:\> $servery|% {Set-ItemProperty -Path ('iis:\sites\status.domena.cz\' + $_) -Name password -Value Pa55w.rd}

Právě fakt, že hesla jsou v systému uložená šifrovaně, zcela znemožňuje replikaci definic virtuáních adresářů prostou editací souboru ApplicationHost.config. Za zkušenost zaplatíte restartem webového serveru, ve kterém musíte odstranit ony zkopírované řádky konfiguračného souboru. Pouhý restart nestačí: odpálí se tam nějaká služba, ale která – to jsem nezjistil.

Poznámka 1.

Celý tento postup byl laděn a zkoušen na Microsoft Windows Serveru 2019.

Poznámka 2.

Někdy mám pocit, že některé týmy vývojářů na Microsoftu – jako by byly z jiné planety. Nechodí vám příkazy Set-ItemProperty tak, jak je popsáno v příkladu? Jasně: Set-It…. …password je v cajku, ale Set-It… …username vám nechodí a nechodí! Zkuste tedy jako jméno property userName – kapišto? Fakt. Jsme u Microsoftu a ono je to Case-Sensitive ! To je podobné jako u zadání hesla v otevřeném textu: v celém zbytku PowerShellu (pokud je mi známo) se používá formát hesla jako Secure.String …..

 

2.3.2020 / kaldy123

Export and Import Windows features

Když potřebuju ještě jeden server, stejný jako ten předchozí.

Create your windows features xml or text file with the one of the following commands from a reference server:

Get-WindowsFeature | ? { $_.Installed } | Export-Clixml .\Features.xml

OR

Get-WindowsFeature | ? { $_.Installed } | Select Name | ForEach-Object { $_.Name } | Out-File .\Features.txt

To install these features:

$(Import-Clixml .\Features.xml) | Add-WindowsFeature

OR

$(Get-Content .\Features.txt) | Add-WindowsFeature

I prefer the TXT file and a Sort for an easy way to compare the files to easily compare of two servers. Therefore my final scripts:
Export:

Import-Module ServerManager
Get-WindowsFeature |
? { $_.Installed } |
Sort-Object Name |
Select Name |
ForEach-Object { $_.Name } |
Out-File .\Features.txt

Import:

Import-Module ServerManager
$(Get-Content .\Features.txt) |
Add-WindowsFeature

..and you should be all set.
http://jeffmurr.com/blog/?p=273

Poznámka: Když jsem popsaný způsob aplikoval, nedařila se mi ta textová varianta. Po delším pátrání (to už jsem byl dávno za vodou s xml formátem) mi došlo, že při získávání features mi vypadl příkaz

ForEach-Object {$_.name}

Jasně! Právě tento příkaz „vykotlá“ z objektu Feature právě Property Name a tu teprve zapisuje. A je jasné, proč mi to nechodilo, i když výpis Features.txt vypadal dobře (ale byly tam trailing mezery – a ty na výpisu vidět nejsou)!

26.1.2020 / kaldy123

SQL (Express) na Core serveru II.

Nastavení.
Podstatou úkolu je nastavit SQL server pro vzdálenou správu, nejlépe přes SQL system management studio – SSMS. K tomu je nutné povolit TCP komunikaci a v případě „named instance“ (pojmenované instance) – nastavit i pevný port.

Celý postup (v powershell) je trochu krkolomný. ale jde to:

  1. nastavení SQL Management Objektu
  2. vytvoření Windows Management Instrumentation objektu
  3. připojení (vytvoření) k objektu TCP pro danou instanci SQL serveru v rámci WMI objektu
  4. povolení TCP komunikace
  5. nastavení pevného portu pro komunikaci

Níže uvedené příkazy se zadávají v prostředí SQLPS – powershell pro SQL server. Zavoláte jednoduše z příkazové řádky příkazem sqlps. Jak na něj přes remoting – věru nevím, příklad byl vyzkoušen na lokální konzole.
V příkazech:

$smo='Microsoft.SqlServer.Management.Smo.'
$wmi=new-object ($smo + 'Wmi.ManagedComputer')
$uri="ManagedComputer[@Name='JMENO-SERVERU']/ServerInstance[@Name='SQLEXPRESS']/ServerProtocol[@Name='Tcp']"
$Tcp=$wmi.GetSmoObject($uri)
$Tcp.IsEnabled=$true
$Tcp.Alter()
$wmi.GetSmoObject($uri + "/IPAddress[@Name='IPAll']").IPAddressProperties[1].Value="1433"
$Tcp.Alter()

K tomu jen pár praxí získaných poznámek:

  1. JMENO-SERVERU je skutečně nutno psát verzálkama (velkými písmeny) – ta mrcha je case-sensitive!
  2. Parametry @Name jsou rovněž case-sensitivní.
  3. Parametr IPAll není IPA-jedenáct, ale IP-všechny!
  4. Tcp.Alter je tam 2x a záměrně. Totiž: nejdříve je třeba objekt Tcp vytvořit – a pak můžete nastavovat fixní (nebo jiný) port

Příklad je zpracován pro named instance SQLEXPRESS a port 1433.

Nedaří se?
Pokud běží na virtuálce, je dobré mrknout, zda všechny servisy, co mají běžet, běží. Malý powershelový mustr je:

Get-Service|? {($_.starttype -eq 'Automatic') -and ($_.status -ne 'Running')}|ft name,status,starttype
25.1.2020 / kaldy123

SQL (Express) na core serveru I.

Instalace.

Instalovat jde, ale není podporovaný wizzard, musí se instalovat z příkazové řádky v quiet módu. Je dobré si vypsat setup /? a projet si parametry. Osobně jsem svůj SQLEXPRESS instaloval takto:

C:\setup /ACTION=INSTALL /FEATURES=SQL /IACCEPTSQLSERVERLICENSETERMS /INSTANCENAME=SQLEXPRESS /SAPWD=<HESLO> /SECURITYMODE=SQL /SQLBACKUPDIR="C:\SQLBACKUP" /SQLCOLLATION=SQL_Czech_CP1250_CI_AS /TCPENABLED=1 /QS
22.1.2020 / kaldy123

OTEVŘENÉ DNSSEC VALIDUJÍCÍ RESOLVERY

JAK ZAPNOUT CZ.NIC RESOLVERY?
V konfiguraci síťového připojení nakonfigurujte resolvery s IP adresami

193.17.47.1

185.43.135.1

pokud vaše síťové připojení funguje i přes protokol IPv6 můžete použít i IPv6 adresy 2001:148f:ffff::1 a 2001:148f:fffe::1.

Zkopírováno z https://www.nic.cz/odvr/

13.1.2020 / kaldy123

CRL na IIS

Je dost důvodů, proč vystrčit CDP (CRL Distribution Point) na nějaký externí webový server. Má to drobný háček: Delta CRL má na konci názvu „+“ – a to se IIS pranic nelíbí. Pokud s tím nic neuděláte, dostanete 403 – not found.

Chce to povolit v Request filtering – Allow double escaping. Jinak, kompletní článek je na https://www.vkernel.ro/blog/how-to-publish-the-crl-and-aia-on-a-separate-web-server .

How to Publish the CRL and AIA on a Separate Web Server
In order to fix this and make it more flexible, we are going to publish the AIA and CRLs on a different server, a web server. And since we are in Microsofts world, we are going to use IIS as our new location or distribution point.
http://www.vkernel.ro

Zde publikuji pouze sručný tahák: