Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: brk 22. 03. 2020, 08:51:48
-
Za současného stavu výrazně přibývá požadavků na home office a s humornou nadsázkou tu jsou požadavky, aby ho měla skoro i uklízečka.
Kde to bylo technicky možné a šlo o zodpovědné lidi, tak si vzali počítače domů a jsou připojeni VPN. Kde to nebylo technicky možné, tak mají zapnuté počítače v kancelářích a domu si odnesli staré firemní notebooky, které mám stále plně pod kontrolou a z těch se připojují na své počítače přes RDP skrze vytočenou VPN.
Bohužel staré firemní notebooky došly a požadavky jsou tu další. Úvaha je použít soukromé stanice zaměstnanců. VPN, v ní povolen přístup pouze na konkrétní stanici ve firmě a to ještě jen na RDP, všechny ostatní služby opět zakázané.
Jak moc velké je to riziko? Musel by se teoretický útočník opravdu připojit skrze soukromou stanici zaměstnance na koncovou stanici terminálově a něco tam udělat ručně, případně si pomocí něčím typu makro kamera ve starých Windows, nebo tam je ještě nějaké další bezpečnostní úskalí? Kdybych dané stanice ještě odpojil od internetu, tak bych jim asi teoreticky odřízl i možnost vytvoření dalšího méně okatého kanálu, kdyby k téhle za mě spíš nepravděpodobné situaci došlo.
Můžu poprosit o názor, případně postup, jak to řešíte vy?
-
Připojení RDP přes VPN pokládám za vyhovující, pokud omezíte dostupnot pouze na daný koncový bod a na něm bude mít přihlášený uživatel pouze nutná práva tak bych to pokládal za ok.
-
Jde o to, co chcete chránit a před čím.
VPN do sítě přináší riziko rozšíření nějaké hrozby (viru) po souborech v síti.
Pokud jde o vzdálenou plochu, je bezpečnější variantou RDP přes RDP gateway (součást windows serveru) a bez VPN. Na RDP pak můžete zakázat připojení lokálních disků z PC uživatele.
Obecně bych víc preferoval RDP bez VPN, ale přes gateway. VPN pouze v případech, kdy uživatel potřebuje do celé sítě, ne jen na RDP. Alternativně můžete vytvořit VPN, do oddělené sítě, na které budou pouze RDP služby, ale ostatní služby sítě budou vypnuté. To je ale komplikovanější řešení, náchylné na chybu konfigurace.
-
VPN do sítě přináší riziko rozšíření nějaké hrozby (viru) po souborech v síti.
Vy máte dost.
Normální administrátor umí omezit VPN přístup jen na prostředky, které uživatel potřebuje k práci (tj. třeba jen ten RDP server/port 3389).
Obecně vystavovat jakoukoliv Microsoft službu do internetu (snad kromě ASP.NET) považuji za bezpečnostní riziko a snažím se tomu vyhnout. A to nemluvím o spravovatelnosti VPN vs Windows server.
Tady máte čerstvou várku:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RD+Gateway
-
Normální administrátor umí omezit VPN přístup jen na prostředky, které uživatel potřebuje k práci (tj. třeba jen ten RDP server/port 3389).
Znalý administrátor by nepokládal dotaz, jaký byl položen. VPN mají taky své slabniny + existentní riziko miskonfigurace. U RDP (RDS) máte k dispozici aspoň rychlé aktualizace.
Pokud se chcete bavit o bezpečném řešení, tak je to extra VPN pro RDS, chráněná certifikátem a tokenem a to samé pro přihlášení na RDP.
Jde o to, že v praxi to vypádává jinak. Starý server, mnohdy už mimo životní cyklus, k tomu VPN na MS Serveru (2008R2 apod.) nebo nějakém Mikrotiku a oboustranně povolený NAT-T. To Vám přijde bezpečnější, než jeden podporovaný a aktualizovaný produkt?
-
Pro soukromé stanice používáme výhradně přístup přes RD Gateway. Pouštět je do VPN, byť jen do izolované DMZ, je hovadina jak z hlediska náročnosti správné konfigurace,tak z hlediska bezpečnosti.
V každém případě doporučím tuhle variantu, před RDG ideálně posadit nějaký slušný IPS
-
Dík za podměty.
RD Gateway není aktuální, nemají Windows Server.
VPN pro tyto uživatlé se nebojím, ta je celkem rozumná. Žádná PPTP na něčem neaktualizovaném a podobně. Uživatelů nebude moc, takže i ta firewallová pravidla budou v rozumných přehledných mezích.
Přes politiky omezím ukládání hesel, mapování lokálních jednotek, schránky, ... .
-
RD Gateway není aktuální, nemají Windows Server.
Ptal jste se na bezpečné řešení. Možná toto je právě doba, kdy by měl klient zvážit pořízení WS. Zcela správně totiž identifikujete to, že při četnějším využívání RDP ve VPN rostou rizika. Pochopitelně, žádný klient nevydá peníze, když existuje srovnatelné řešení levněji. Na vás by mohlo být právě umět vysvětlit, v čem se řešení liší.
Při výběru VPN si dejte pozor, aby nezvyšovala výrazně latenci. PPtP není bezpečné. OpenVPN je tragedie (nejen) na výkon. L2TP je fajn, pokud ani na jedné straně (ani po cestě) není NAT. Pokud jsou oba konce na MS technologiích, zaměřil bych se na SSTP.
-
trochu to odbocuje od tematu, nicmene "objevil" jsem moznosti Windows+SSH serveru jak velmi narychlo udelat sifrovany tunel pro homeoffice. Windows jdou nastavit tak, aby umely pres klasickou cestu '\\server\share' projit tunelem skrze Putty na nejaky SSH server, ktery jde navic nastavit tak, ze povoli portfw jen na dany port (445 pro CIFS, 3389 pro RDP).
Win CIFS over SSH: https://www.nikhef.nl/~janjust/CifsOverSSH/Howto_Loopback.html (port je 445 pro novejsi systemy a ne 139!)
-
RD Gateway není aktuální, nemají Windows Server.
VPN pro tyto uživatlé se nebojím, ta je celkem rozumná. Žádná PPTP na něčem neaktualizovaném a podobně. Uživatelů nebude moc, takže i ta firewallová pravidla budou v rozumných přehledných mezích.
Přes politiky omezím ukládání hesel, mapování lokálních jednotek, schránky, ... .
Windows Server nemají...
Přes politiky omezím...
No tak moment. Tady něco nesedí, můžete popsat topologii?
- windows server stojí pár korun, CALy jsou teda o něco horší...
- windows server můžete začít používat ihned, 180d trial je víc než dobrá nabídka
-
- windows server stojí pár korun, CALy jsou teda o něco horší...
Ony ani CALY nejsou tak drahé, když si vezmete, že pokryjí několik let práce a poměříte je ke mzdě pracovníků.
Jak už jsem psal, myslím si, že IT odborník by měl umět zákazníkovi vysvětlit, že pokud se mění situace a je nový požadavek na práci z domova, že je to čas na změnu v koncepci. Samozřejmě mě hned napadají i vedlejší linie, co z dotazu vyplývají - např. že pokud pan kolega chce z VPN pouštět RDP až na stanice, musí mít stanice statické IP adresy. To je další věc, která se dávno dělá jinak a taky by zasloužila změnu.
-
Já to říkám taky, kdo si za pět let nevydělá 1200,- na CAL, toho je lepší nezaměstnávat vůbec.
Horší je to s cashflow když jich máte koupit 100, k tomu 100 RDS CAL a OLP Office na terminal. To už je raketa když se to spočte. Spoustu zákazníků to dovede k vědomému porušování licenčních podmínek, které potom horko těžko rovnáme. Přístup na stanici vyjde samozřejmě levněji, akorát se maličko hůř spravuje.
A stanice a statické IP? Fuj. Navrhoval bych funkční DNS, potom to fakt řešit nemusíte. Přes RDG se dá uživatel tunelovat přímo na stanici, na základě access pravidel klidně i kamkoli jinam.
-
Horší je to s cashflow když jich máte koupit 100, k tomu 100 RDS CAL a OLP Office na terminal. To už je raketa když se to spočte. Spoustu zákazníků to dovede k vědomému porušování licenčních podmínek, které potom horko těžko rovnáme. Přístup na stanici vyjde samozřejmě levněji, akorát se maličko hůř spravuje.
Pokud máte 100 zaměstnanců, obvykle je cash flow takové, že to unese.
Pokud ne, tak lze licence získat přes Office 365 plány E a rozložit si to v čase. Může to být i pro firmu výhodnější, protože pořízení licencí se daňově odpisuje 36 měsíců, zatímco pronájem (O365) jde do daňových nákladů rovnou.
Navrhoval bych funkční DNS, potom to fakt řešit nemusíte. Přes RDG se dá uživatel tunelovat přímo na stanici (...)
Přesně tak. Ale to jsem jen tak namátkou vybral jednu oblast, která by patrně potřebovala zlepšení.
-
Omezení ukládání hesel bych se vyhnul - je to možné třeba přes program rdp.exe obejít. Navíc to bude nutit zaměstnance nechat session otevřenou celý den.
Jak zde doporučovali - na 180 dní testovací verze Windows Serveru je to nejjednodušší a nejlepší co můžete udělat - RDS je v tom také zahrnuté, nijak to neobtěžuje.
Z VPN dobře a jednoduše funguje Softether - konfigurace je jednoduchá, pravidelné aktulizace, výkonné.
-
Omezení ukládání hesel bych se vyhnul - je to možné třeba přes program rdp.exe obejít. Navíc to bude nutit zaměstnance nechat session otevřenou celý den.
Na to je jednoduchá obrana. RDP se nastaví tak, že po půlhodině nečinnosti vzdálenou plochu odpojí. Dalším připojením se uživatel připojí do stavu, ve kterém byl odpojen.
Na terminálovém serveru se ještě přidává i automatické odhlášení, např. po další hodině. Pak to funguje tak, že odpojení je jakési "varování" před odhlášením. Odhlašováním po určité době se šetří prostředky serveru.
-
Za současného stavu výrazně přibývá požadavků na home office a s humornou nadsázkou tu jsou požadavky, aby ho měla skoro i uklízečka.
Kde to bylo technicky možné a šlo o zodpovědné lidi, tak si vzali počítače domů a jsou připojeni VPN. Kde to nebylo technicky možné, tak mají zapnuté počítače v kancelářích a domu si odnesli staré firemní notebooky, které mám stále plně pod kontrolou a z těch se připojují na své počítače přes RDP skrze vytočenou VPN.
Bohužel staré firemní notebooky došly a požadavky jsou tu další. Úvaha je použít soukromé stanice zaměstnanců. VPN, v ní povolen přístup pouze na konkrétní stanici ve firmě a to ještě jen na RDP, všechny ostatní služby opět zakázané.
Jak moc velké je to riziko? Musel by se teoretický útočník opravdu připojit skrze soukromou stanici zaměstnance na koncovou stanici terminálově a něco tam udělat ručně, případně si pomocí něčím typu makro kamera ve starých Windows, nebo tam je ještě nějaké další bezpečnostní úskalí? Kdybych dané stanice ještě odpojil od internetu, tak bych jim asi teoreticky odřízl i možnost vytvoření dalšího méně okatého kanálu, kdyby k téhle za mě spíš nepravděpodobné situaci došlo.
Můžu poprosit o názor, případně postup, jak to řešíte vy?
Vím, že z toho teď všichni šílí, týden intenzívně řeším vzdálené přístupy. Připojení RDP k pracovnímu PC notabene z domácího kompu je hodně špatně a s trochou cynismu, větší riziko než nějaká karanténní opatření na pracovišti. Preferuji VPN na potřebné aplikace, ale to chce samozřejmě mít vyřešeno předem, ne až hrom uhodí. A pořádnou analýzu potřeb a taky trochu odvahy říci ne. Držím palce.
-
Jde o to, co chcete chránit a před čím.
VPN do sítě přináší riziko rozšíření nějaké hrozby (viru) po souborech v síti.
Pokud jde o vzdálenou plochu, je bezpečnější variantou RDP přes RDP gateway (součást windows serveru) a bez VPN. Na RDP pak můžete zakázat připojení lokálních disků z PC uživatele.
Obecně bych víc preferoval RDP bez VPN, ale přes gateway. VPN pouze v případech, kdy uživatel potřebuje do celé sítě, ne jen na RDP. Alternativně můžete vytvořit VPN, do oddělené sítě, na které budou pouze RDP služby, ale ostatní služby sítě budou vypnuté. To je ale komplikovanější řešení, náchylné na chybu konfigurace.
RDP gateway, proč ne, ale proč bez VPN? Jaké riziko rozšíření viru a souborů po síti a riziko špatné konfigurace přináší VPN přístup na firemní poštovní , kolaborativní a ekonomické servery ?
-
VPN do sítě přináší riziko rozšíření nějaké hrozby (viru) po souborech v síti.
Vy máte dost.
Normální administrátor umí omezit VPN přístup jen na prostředky, které uživatel potřebuje k práci (tj. třeba jen ten RDP server/port 3389).
Obecně vystavovat jakoukoliv Microsoft službu do internetu (snad kromě ASP.NET) považuji za bezpečnostní riziko a snažím se tomu vyhnout. A to nemluvím o spravovatelnosti VPN vs Windows server.
Tady máte čerstvou várku:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RD+Gateway
+1
-
Za současného stavu výrazně přibývá požadavků na home office a s humornou nadsázkou tu jsou požadavky, aby ho měla skoro i uklízečka.
Kde to bylo technicky možné a šlo o zodpovědné lidi, tak si vzali počítače domů a jsou připojeni VPN. Kde to nebylo technicky možné, tak mají zapnuté počítače v kancelářích a domu si odnesli staré firemní notebooky, které mám stále plně pod kontrolou a z těch se připojují na své počítače přes RDP skrze vytočenou VPN.
Bohužel staré firemní notebooky došly a požadavky jsou tu další. Úvaha je použít soukromé stanice zaměstnanců. VPN, v ní povolen přístup pouze na konkrétní stanici ve firmě a to ještě jen na RDP, všechny ostatní služby opět zakázané.
Jak moc velké je to riziko? Musel by se teoretický útočník opravdu připojit skrze soukromou stanici zaměstnance na koncovou stanici terminálově a něco tam udělat ručně, případně si pomocí něčím typu makro kamera ve starých Windows, nebo tam je ještě nějaké další bezpečnostní úskalí? Kdybych dané stanice ještě odpojil od internetu, tak bych jim asi teoreticky odřízl i možnost vytvoření dalšího méně okatého kanálu, kdyby k téhle za mě spíš nepravděpodobné situaci došlo.
Můžu poprosit o názor, případně postup, jak to řešíte vy?
Apropos, jsou ty staré firemní notebooky s podporovaným a aktualizovaným OS a SW a antivirem?
Za druhé, co takhle rozdělit ty soukromé PC na ty výše uvedené a na ty “mazej do kanclu” ?
Třeba zkontrolovat je přes teamviewer ?
-
RDP gateway, proč ne, ale proč bez VPN? Jaké riziko rozšíření viru a souborů po síti a riziko špatné konfigurace přináší VPN přístup na firemní poštovní , kolaborativní a ekonomické servery ?
Fatalni. Chyba v konfiguraci nebo zabezpeceni muze mit lavinovy efekt. Jedna neopatchovana zranitelnost muze zpusobit prunik k centralnim prvkum, eskalaci opravneni a - pruser. Prikladem za vsechny budiz cca dva roky stare chyby v SMB protokolu, kdy i skrz nepouzivanou sluzbu slo ovladnout celou sit. A ruku na srdce, kdo z nas ma opatchovano opravdu 100%?
Proto je nejlepsi vystavit na odiv co nejmin moznych dopadovych ploch a potencionalne nakazene stroje drzet od site co nejdal. A RDG vystavovat az za VPN - teoreticky ok, prakticky neohrabane + pribude starost s izolaci VPN klientu + starost o tu VPN + konfiguraci VPN na klientech - je to trochu uchylne.
-
RDP gateway, proč ne, ale proč bez VPN? Jaké riziko rozšíření viru a souborů po síti a riziko špatné konfigurace přináší VPN přístup na firemní poštovní , kolaborativní a ekonomické servery ?
Fatalni. Chyba v konfiguraci nebo zabezpeceni muze mit lavinovy efekt. Jedna neopatchovana zranitelnost muze zpusobit prunik k centralnim prvkum, eskalaci opravneni a - pruser. Prikladem za vsechny budiz cca dva roky stare chyby v SMB protokolu, kdy i skrz nepouzivanou sluzbu slo ovladnout celou sit. A ruku na srdce, kdo z nas ma opatchovano opravdu 100%?
Proto je nejlepsi vystavit na odiv co nejmin moznych dopadovych ploch a potencionalne nakazene stroje drzet od site co nejdal. A RDG vystavovat az za VPN - teoreticky ok, prakticky neohrabane + pribude starost s izolaci VPN klientu + starost o tu VPN + konfiguraci VPN na klientech - je to trochu uchylne.
Patche samozrejme a na zranitelnosti IPS na firewallu ? Jo a nedělat chyby v konfiguraci...
RDP je jenom jedna ze služeb a IMHO je atraktivnější pro hackery než jiné a má víc zranitelností. YMMW
-
Jako jestli souhlasim s otazkou? Nic jineho v citovanem postu nebylo nezli otazky :-)
S pripojovanim soukr notebooku do jakekoli VPN nesouhlasim kategoricky. Aby clovek dovedl opravdu dobre ochranit interni sit pred hrozbami z VPN, musi sakra dobre vede co dela, mit velmi dobry prehled o provozu a potrebach site a mit nejaky rozumny cas na implementaci.
-
Jako jestli souhlasim s otazkou? Nic jineho v citovanem postu nebylo nezli otazky :-)
S pripojovanim soukr notebooku do jakekoli VPN nesouhlasim kategoricky. Aby clovek dovedl opravdu dobre ochranit interni sit pred hrozbami z VPN, musi sakra dobre vede co dela, mit velmi dobry prehled o provozu a potrebach site a mit nejaky rozumny cas na implementaci.
V tom se naprosto shodneme. Připadá vám to nereálné? Mně ne, tomu se říká odbornost :-)
Kromě toho to taky chce kvalitní technologie.
-
No mě taky ne, ale připadá mi to nereálné ve scopu původního tazatele, který na takovou systematickou akci při vší úctě není připraven. Natlačili ho do ne zrovna ideálního rohu, odkud se teď snaží operovat.
-
No mě taky ne, ale připadá mi to nereálné ve scopu původního tazatele, který na takovou systematickou akci při vší úctě není připraven. Natlačili ho do ne zrovna ideálního rohu, odkud se teď snaží operovat.
S tím taky souhlasím. Blbý je, že za úspěch ho nikdo nepochválí, ale průšvih odsere. Jako my všichni tady.
Mějte se hezky, dobrou noc
-
uffff.....
1. řešení je hodně pravidel na routeru(izolce IP, porty, etc)
2. řešení je na kliošské stanice nainstalovat Aplikační firewall a tam vytvořit zónu která směruje do VPN, povolit vybrané aplikace a vše ostatní zakázat
3. řešení je na kliošších filtrovat outgoing provoz
-
V tom se naprosto shodneme. Připadá vám to nereálné? Mně ne, tomu se říká odbornost :-)
Kromě toho to taky chce kvalitní technologie.
Nereálné ne, drahé ano. Dražší, než RDG. Lze spočítat.
No mě taky ne, ale připadá mi to nereálné ve scopu původního tazatele, který na takovou systematickou akci při vší úctě není připraven. Natlačili ho do ne zrovna ideálního rohu, odkud se teď snaží operovat.
Taky se mi zdá, a taky zjistil, že je v rohu, proto se ptá. Na něm je, jestli v rohu zvolí špatné řešení (a ponese si za něj odpovědnost), nebo dokáže prosadit rozumné řešení.
uffff.....
1. řešení je hodně pravidel na routeru(izolce IP, porty, etc)
2. řešení je na kliošské stanice nainstalovat Aplikační firewall a tam vytvořit zónu která směruje do VPN, povolit vybrané aplikace a vše ostatní zakázat
3. řešení je na kliošších filtrovat outgoing provoz
ad 1) vyžaduje statické IP => tím pádem se IP stane součástí bezpečnostního řešení => IP nelze 100% zaručit, že se nezmění => bezpečnost jde vniveč; proto je potřeba se dostat z L2 na L7
ad 2 a 3) nikdo Vám nezaručí, že to neselže nebo že si někdo nevytvoří jinou instalaci bez něj => klientský firewall je určitý typ hardeningu, ale ne bezpečnostní řešení pro server
-
Dobrý den,
můžu doporučit RDP a stunnel (s parametrem verify 3). Uživatel se tak dostane pouze na RDP a na nic dalšího. Používám právě tam, kde uživatel nemá firemní ntb/pc, který nemám pod svou zprávou. Celý to mám, jako portable balíček, kde je cmd, které spusti stunnel a pak rdp. Jde samozřejmě o množství uživatelů, kterým by to člověk poskytoval. Protože pro každého uivatele je nutný extra NATovaný port. Je nutné mít samozřejmě pro každého certifikát. Stunnel server je možné buď rozjet v nějaké virtuálce a pak distribuovat po síťi, jak je nutné. Na klientských stranách je pak ideální mít aplikační FW - klidně ten od MS a s GUI nadstavbou Windows Firewall Control (a RDP pak povolit pouze ze serveru, kde běží stunnel).
Pokud je nutné mít stunnel server přímo na klientské stanici (protože jiná cesta prostě není), tak je akorát nutné, aby služba stunnel server se spouštěla se zpožděním (zařízení, kde jsou SSDčka nabíhají příliš rychle a stunnel se pak nesprávně nabinduje).
Možnost VPN je také možnost (openvpn, wireguard - ten zatím vyžaduje na win admin práva) a na straně serveru zaříznout vše, kromě RDP.
Pokud bude zájem, poskytnu klidně nastavení stunnel, jak server, tak klient.
-
Já to vyřešil přímo na NGFW (Fortigate).
SSL VPN a web portál -> uživatel se pomocí www prohlížeče připojí na SSL VPN web portál, kde na něj čeká možnost RDP na svojí stanici. Uživatel má pouze obraz v okně prohlížeče, pokud chce něco kopírovat tak pouze text.
Jakékoliv tunelování je zakázané a uživatel se dostane pouze na svoje PC.
edit: taková varianta Apache Guacamole
-
Fortigate od verze 5.2 nebo 5.4 a novější používá přímo v sobě quacamole, takže přímo přesně taková varianta, jen bez obsáhlého nastavovaní a konfigurace :)
-
Těch možností řešení je mnoho, my používáme NoMachine ( https://www.nomachine.com/terminal-server ), protože jsme primárně řešili vzdálený přístup k linuxům na X-Win plochy (a to tám máme šílence, co vzdáleně motají OpenGL modely celé elektrárny v nějakém CAD/CAM/CFD a jsou spokojeni). Že sekundárně to umí být i brána k RDP, VNC je příjemné plus. :-)
Jinde se používá Cytrix virtuální desktopy, často s integrovaným CiscoVPN a napojením na další infrastrukturu (zrovna se ale jedno takové řešní jednomu velkému korporátu v Česku složilo, inu pár tisíc uživatelů online udělá své).
Souhlasím, že na cizí počítač max nějaký remote desktop s rozumnou konfigurovatleností, co člověk ne/může. VPNko na to, co nemám pod kontrolou není ideál. Samozřejmě pak mix VPN do DMZ a tam nějaká bráno k desktopu je plus navíc, ale v nouzové situaci nemusí být čas to oživovat (třeba včetně jednorázových/SMS hesel a podobných blbostí).
Ale sešli se tu evidentně znalci RDP: Otázka - umí v rámci připojení udělat už RDP klient ve woknech nějaký backgroud check a report serveru stavu klienta a na základě stavu server dovolí ne/připojit? Jak to umí nativní VPN klient ve Win10 (a asi i stsrších), když si to VPN server vyžádá? Zkrátka krom ověření klienta to pošle background check, co je nainstalováno, patche, běžící procesy, antivir, ..., takže když něco není dle představ serveru, tak odmítne spojení. Sice z toho zpět nedojde obvkyle inteligentní hláška, ale člověk už ví, že má pustit update OS/apliací, pustit plný scan systému a v dalším pokusu se už připojí. Nekonfiguroval jsem, jen jsem obětí takového řešení a má to něco do sebe (pokud ten update zrovna nerozjebe něco potřebného k životu :-) ).
-
Ne. RDP to vůbec neřeší.
Funkce NAP je deprecated od 2012R2, od 2016 removed.
-
Ne. RDP to vůbec neřeší.
Funkce NAP je deprecated od 2012R2, od 2016 removed.
Dík, jasně, NAP je asi ta zkratka. :-)
Předpokládám, že na novějším se očekává použití Always On VPN (či jak se to jmenuje) a klientské PC je tak "trvale" součástí firmení LAN a trvalého dohledu. Ale tady něco takového bude na dlouho, když vidím ten zástup serverů, kde jsou stále i Windows NT4.0 servery v provozním portfoliu. :-)