Přejít k obsahu webu
17.12.2018 / kaldy123

Přihlášení k W10 v doméně pomocí Windows Hello

Bez nastavení v Group Policy to nejde – protože (zřejmě asi) jde o firemní politiku: zda Windows Hello nebo Windows Hello for Business (což je jiný kalibr, kde se řeší i připojení na Azure Active Directory, SSO, PIN recovery a podobné „lahůdky“ – do kterých adminům není moc radno kecat).

Pro adminy jednoduchá kuchařka pro Windows Hello (nikoliv for Business!):

Computer ->Administrative Templates -> System -> Logon -> Turn on convenience PIN sign-in : Enabled

V komentáři, který vám vypisuje GP editor se dočtete, že „is valid for“ W8, W8.1 a servery W2012 a W2012R2. No, já to dělal pro W10 (1803) a ty admx-y jsem vytahal z těch W10!

Protože Administrative Templates, doporučuji centrální úložiště (Policy Definitions na SYSVOL) a ty templates najdete na lokálu W10 na cestě C:\windows\Policy Definitions…

Reklamy
9.12.2018 / kaldy123

Vytvoření důvěryhodného certifikátu pro RDP

Ten podstatný trik jsem vybrowsil na
https://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo
https://www.derekseaman.com/2013/01/creating-custom-remote-desktop-services.html
https://www.derekseaman.com/2018/12/trusted-remote-desktop-services-ssl-certs-for-win10-2019.html

V čem tkví problém:
Při navázání spojení přes RDP si cílový počítač vytvoří selfsigned certifikát – se všemi důsledky. Pokud vytvoříte certifikát přes certifikační autoritu – obyčejný „computer“ certifikát nevyhovuje, a šablonu „certificate template“ pro Remote Desktop Connection – alespoň ve Windows (10, 2016) budete hledat marně. Nezbývá, než si ji vytvořit.
Článek předpokládá znalosti práce s Active Directory Certificate Services. Pro odvážné – nechte si někým nainstalovat „Enterprise CA“ – a zkuste si to „naklikat“ dle návodu…

Krok 1 – vytvoříme kopii Computer šablony.
Samozřejmě, jsme v konzoli enterprise certifikační autority, kde si přes Certificate Templates -> Management vyvoláme editor šablon:
a vytvoříme kopii „computer“ šablony:
Šablonu upravíme následně:

Pro novou šablonu autor výšeuvedeného pramene výslovně doporučuje stejné Template name i Template display name – nevím, nezkoušel jsem. Validity period a renewal period nastavte dle svých bezpečnostních zásad – pro účely článku nejsou podstatné.
Dále autor doporučuje ponechat kompatibilitu Windows XP/2003:

Krok 2 -vytvoření nové zásady aplikace
Hlavní fór při vytváření nové šablony je vytvoření „new application policy“ – a je to trochu alchymie, protože identifikátor objektu – Object indentifier – podle mne nejdůležitejší část procesu – je Pischweitzova konstanta, kterou autor vyhrabal bůhví kde.

Ještě jednou: Object identifier je: 1.3.6.1.4.1.311.54.1.2
Šablonu uložíme.

Krok 3 – šablonu vypublikujeme pro použití v rámci CA:

Krok 4 – pomocí Group Policy změníme implicitní způsob tvoření certifikátu (vytvoření selfsigned certifikátu nechceme!)

Computer Policy -> Administrative templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security:


kde nastavíme Server Authentication Certificate Template:
a když jsem v tom, tak i Require use of specific security layer for …..
Politiku si naaplikujte na počítače dle svých bezpečnostních pravidel a zásad.

Závěr:
Po tomto nastavení jsem provedl jak na RDP host (hostiteli!!!) tak na RDP client gpupdate, vyzkoušel – a hláška o nedůvěryhodném serveru zůstává! Sice certifikát je správně vydaný CA, ale RDP jej identifikuje jako nedůvěryhodný!

Až na druhý den: Já byl zvyklý zadávat do RDP klienta pouze název serveru. A v certifikátu je FQDN…. Bože – to zabolí :-)))

(Ale dokud blbnu, jsem alespoň na živu.)

16.11.2018 / kaldy123

SSL a TSL 1.0 nejsou akceptovatelné pro secure web

V dubnu 2016 publikovala Rada PCI dokument Data Security Standards (DSS) verze 3.0 .
Rada rozhodla, že SSL and TLS 1.0 nelze používat po 30. červnu 2016.

Toto rozhodnutí má za důsledek, že řada stránek (které dodržují pravidla dle DSS 3.0) odmítá přístup IE (11.0).

Počteníčko medle:
https://www.varonis.com/blog/ssl-and-tls-1-0-no-longer-acceptable-for-pci-compliance/
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Keyword:
SSL protocol is no longer considered secure

16.11.2018 / kaldy123

Správa Wireless Profiles ve Windows10

Ve snaze o co uživatelsky nejpřívětivější uživatelský zážitek (user experience) dochází ke zjednodušení celé řady nastavení, ale též, želbohu v takhle zjednodušené správě chybí celá řada nastavení, na které jsme byli nejenom zvyklí, ale jsou navíc docela potřebná.
Známé bezdrátové sítě sice v „desítkách“ vypíšete, ale řadu parametrů a třeba heslo ne. Zde platí známé BABO, RAĎ!

Radu neposkytne baba, ale net shell:

Net shell nám poskytuje řadu výpisů:

takže i profily:


a jejich detaily:


takže např:


Máme k dispozici i export a import profilu:



Tož tak.

15.11.2018 / kaldy123

Vytvoření SelfSigned certifikátu

původní článek: 11.02.17  Byron Calisto
https://www.oshyn.com/blogs/2017/november/how-to-create-self-signed-certificates-in-windows-10

by powershell

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "mysite.local" -FriendlyName "MySiteCert" -NotAfter (Get-Date).AddYears(10)


You can also create „star“ self-signed certificates. Suppose you have several sites named „app1.example.local“, „app2.example.local“, etc. It is easier to create a single certificate with the common name …………………………………………………………………………………………………………………………………….local“. To achieve this, enter the following command:

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "*.example.local" -DnsName "example.local", "*.example.local" -FriendlyName "LocalStarCert" -NotAfter (Get-Date).AddYears(10)

9.10.2018 / kaldy123

Virtual Machine Move on W2016

…aneb Live Migration na Hyper-V 2016. Taky jste dostali hlášku

Virtual machine migration operation failed at migration source?

Jasně – již z minulého příspěvku víme, že musíme nastavit delegování účtu – a nejlépe s nějakými omezeními (qůlivá bezpečnosti), zkrátka constrained delegation na zdrojové mašině (at migration source).
Ale na Windows Server 2016 to nefunguje. Proč? Moc pěkně to popsal a medicínu navrhnul John Slack, Hyper-V Team PM, ve svém blog-postu „Live Migration via Constrained Delegation with Kerberos in Windows Server 2016„.

Popisuje následující situaci:
MGMT1 je server (workstation), na které máme spuštěn Hyper-V monitor a na Hyper-V monitoru máme připojeny servery R420-HST1 a R420-HST2. Chceme migrovat (operace move) virtuální server VM1 z R420-HST1 na R420-HST2. Musíme tedy v Active Directory povolit delegaci credentials na účtu serveru R420-HST1pro servisy cifs/R420-HST2 a Microsoft Virtual System Migration Service/R420-HST2. Rodíl na W2016 je v tom, že musíme povolit delegaci pro všechny protokoly, nikoliv jen Kerberos….
Zmiňovaný dokument Johna Slacka detailně popisuje proč došlo k této změně (není to tedy úlet nějakého kodéra) a jaké to má důsledky pro bezpečnost (tvrdí, že minimální).

Zajímavá je též diskuse k blog-postu, kde se probírá užití v prostředí PowerShell,  MS Hyper-V Serveru, Workgroups – a další….