locked
Úskalí implementace Direct Access

    Dotaz

  • Zdravím,

    zatím v teoretické rovině zvažujeme nasazení Direct Access. Před několika měsíci jsem k tomu četl nějaké manuály, nyní doufám, že mi někdo poradí, jak to funguje v praxi. Máme tu tři servery 2008 R2. Běží na nich vnitřní certifikační autorita, řadiče domény a NPS s NAP 802.1x. To vše je schované za firewallem a NAT dalšího výrobce. Vnitřně používáme IPv4, přechod na IPv6 zatím neplánujeme - pouze překlad zvenku (ten v tuto chvíli také nemáme). Včera jsem se dozvěděl, že pro implementaci Direct Access na serveru 2008 R2 je potřeba i vnitřní IPv6 protokol - a to i na všechny ostatní servery, kam chci přistupovat. To je pro naši síť docela problém. Server 2012 by to údajně měl řešit, ale nevím, jestli ho stačí připojit jenom jako člena, nebo na něm musím udělat řadič domény, případně povýšit funkční level domény? Mohl byste mi někdo svými slovy popsat, co je v našem případě zapotřebí?

    Děkuji, JŠ

    pátek 12. dubna 2013 13:58

Odpovědi

Všechny reakce

  • Co jsem slyšel na posledním WUGu v Praze (pokud se pamatuji dobře) nemusí být W2012 jako DC. Taky jsem si z toho odnesl, že až budu chtít nasadit DA, tak jedině s W2012.
    neděle 14. dubna 2013 20:58
  • 1. Zakladni info o DirectAccessu je v knize Windows_Server_2008_R2_e-book, ktera je volne dostupna na strankach MS. Zavislosti na IPv6 se u verze s WS2008 nezbavite

    http://searchmidmarketsecurity.techtarget.com/tip/Understand-the-pros-and-cons-of-Microsoft-Windows-7-DirectAccess

    2. U WS2012 je situace jednodussi

    http://searchwindowsserver.techtarget.com/tip/Easier-DirectAccess-setup-means-a-plausible-VPN-alternative-for-admins

    M.

    pondělí 15. dubna 2013 9:44
    Vlastník
  • provozovat DirectAccess přes NAT s tím, že je to vnitřní Windows 2012 DA server je v pohodě (na Windows 2008 R2 bych to nedělal, protože tam není NAT6to4 ani DNS6to4, IPv6 uvnitř nemáte). Mám to s Windows 2012 už u dvou zákazníků (což bych ani neřekl, že se to tak rozjede) a teďka zrovna řešíme třetího. Podle mě podstatný limit je hlavně fakt, že:

    a) musíte mít Enterprise edici stanic. Dá se to udělat ručně i pro Standard/Professional, ale je to nepodporované peklo

    b) vééélmi si ušetříte problémy, pokud koretně rozjedete napřed PKI, hlavně ověřování CRL cest z internetu.

    c) musíte počítat s tím, že to je potřeba vyzkoušet a hlavně na to zvyknout uživatele. Nesou z prvu citlivě, že si to nemohou jen tak sami odpojit (než se naučí vypnout IP Helper službu :-)).

    ondra.

    pondělí 15. dubna 2013 10:20
  • obecně bych se nejprve, před implementací nějakého vzdáleného přistupu zamyslel, jestli pro mě není dostatečná vzdálená ploch (Remote Desktop) za pomoci Remote Desktop Gateway (RD Gateway) a teprve potom nasazoval vůbec něco jiného.

    RDP je velmi bezpečné (pakliže dodržíte správnou implementaci přes TLS a případně s čipovými kartami) a druhak véélmi výkonově dobré i na velmi špatných sítích - což v případě VPN a DirectAccess neplatí. Například "normálně" pracuju s Word a Excel a Visio dokumenty dokonce i přes Edge pokud to je RDP. Přes VPN byste se ani nepohnul.

    o.

    pondělí 15. dubna 2013 10:23
  • provozovat DirectAccess přes NAT s tím, že je to vnitřní Windows 2012 DA server je v pohodě (na Windows 2008 R2 bych to nedělal, protože tam není NAT6to4 ani DNS6to4, IPv6 uvnitř nemáte). Mám to s Windows 2012 už u dvou zákazníků (což bych ani neřekl, že se to tak rozjede) a teďka zrovna řešíme třetího. Podle mě podstatný limit je hlavně fakt, že:

    a) musíte mít Enterprise edici stanic. Dá se to udělat ručně i pro Standard/Professional, ale je to nepodporované peklo

    b) vééélmi si ušetříte problémy, pokud koretně rozjedete napřed PKI, hlavně ověřování CRL cest z internetu.

    c) musíte počítat s tím, že to je potřeba vyzkoušet a hlavně na to zvyknout uživatele. Nesou z prvu citlivě, že si to nemohou jen tak sami odpojit (než se naučí vypnout IP Helper službu :-)).

    ondra.


    Máme tady multilicenci, kde nakupujeme jenom Windows 7/8 Pro. Nemáme ani jeden PC Windows 7/8 Enterprise. Proč nefunguje DA na počítačích s Win Pro? Považoval jsem to za samozřejmost.
    pondělí 15. dubna 2013 14:27
  • no prostě obchodní politika :-(

    o.

    úterý 16. dubna 2013 10:09
  • Zdravím, 

    u zákazníka momentálně implementuji DA na WS2012R2 s tím, že DC jsou 2008R2, na kterých není povolené IPv6, a já se ptám je pro fungování DA nutné mít na DC zaplé IPv6 ? 

    Pokud provedu příkaz Get-DAConnectionStatus, lokálně funguje v pořádku, pokud se připojím např. přes hotspot setkám se s hláškou "NameResolutionFailure" nemáte někdo zkušenost ? 

    Moc by mi to pomohlo. Díky

    středa 28. ledna 2015 18:52
  • na DC nemusíte mít IPv6. překlady dělá služba na DA serveru, která to prostě posílá normálně na IP adresu DNS serveru, které má nastavené na síťovkách DA server. Zkontroloval bych, jaké tam máte IP adresy DNS serverů a to včetně IPv6 protokolu, lidi se obvykle nedívají do vlastností IPv6 protokolu, protože to nenastavovali a přitom tam může být něco divného. Rozhodně byste tam měl mít jen IP adresu vnitřního DNS serveru. Pokud máte na více síťovkách různé IP adresy DNS serverů, jejich pořadí je obvykle značně nejasné, takže to raději nedělejte a dejte všude jen vnitřní DNS servery.

    předpokládám, že chcete, aby to chodilo přes IPHTTPS, takže bych se snažil na klientovi ověřit, že IPCONFIG zobrazuje ten IPHTTPS interface jako připojený (nebo tedy kterýkoliv jiný, pokud by byl).

    Potom na klientovi můžete vyzkoušet překlad jmen, jenom nemůžete používat NSLOOKUP. Ten nástroj generuje svoje vlastní DNS pakety a nepoužívá službu DNS Client. Na rozdíl od toho služba DNS Client je schopná používat tu Name Resolution Polciy, která jí diktuje, jak má ty dotazy odesílat. Tohle NSLOOKUP nedělá.

    Pokud chcete zkoušet překlad, dělejte to z klienta buď přímo přes PING například, nebo pomocí PowerShell [Net.Dns]::Resolve(), nebo Resolve-DnsName

    ondra.

    středa 28. ledna 2015 20:22