Dneska se koná v Praze v Akvárku můj další WUG na téma Direct Access, tedy pokračování předchozí akce, která se zabývala VPN a RDP Gateway. Budeme se tedy zabývat průzkumem té strašlivé infrastruktury, která souvisí s DA (DirectAccess). Speciálně při použití Windows 2012, které už konečně obsahují DNS64 a NAT64 překladače, takže si DirectAccess můžete rozjet vcelku bez bolestně.
Samozřejmě krom jedné malé bolístky. Pořád potřebujete klienta Windows 7 a novější v edici Enterprise nebo Ultimate. Óóó bože. A pak musíte mít stěstí, že to opravdu rozjedete. Přednáška je tu k tomu, abyste alespoň porozuměli tomu peklu a co se uvnitř ve skutečnosti děje.
Tak se těším večer!
Pro dnešek nějaké poznámečky i zde na mém webu - nejspíš nebudu mít moc slajdů:
- Jak správně zkontrolovat platnost certifikátů? Použijte CERTUTIL -url a CERTUTIL -verify -urlfetch. Upozorňuju, že parametr -url ve skutečnosti neověřuje, jestli je sám certifikát platný, zkusí jeho CRL jenom stáhnout. Takže pro kontrolu platnosti certifikátu samotného musíte použít ten druhý parametr -verify. Detailní návod je k dispozici v anglické části mého blogu.
- Nějaké informace o IPv6 protokolu je možné si přečíst česky v mém úvodním IPv6 a pokročilejším IPv6 článku.
- Certifikáty potřebujete pro VPN DA server, pro web server, který prokazuje přítomnost uvnitř sítě, a pro klientskou stanici. VPN DA server potřebuje IPSec certifikát a TLS/SSL web serverový certifikát. Pro vnitřní web server potřebujete TLS/SSL web serverový certifikát a pro stanici už jenom IPSec certifikát.
Minimální parametry certifikátů pro IPSec (IPSec certificate template for IPSec transport mode peers, podpora AuthIP with TLS authentication):
| Subject |
not mandatory if SAN present |
| SAN |
DNS (checks against what the other side claims as its Peer ID) |
| Exportable key |
no |
| Archive key |
no, transport authentication/encryption only |
| Key type |
Signature and Encryption |
| Key usage |
Digital Signature, Key Encipherment |
| CSP |
Microsoft Enhanced RSA and AES Provider |
| EKU |
a) IPSec IKE Intermediate (IPSec Protection) (1.3.6.1.5.5.8.2.2) + Server Authentication + Client Authentication
b) IPSec IKE Intermediate + Client Authentication (1.3.6.1.5.5.7.3.2)
c) Client Authentication |
| Autoenrollment |
yes, domain computer DNS name |
| Publish in AD |
no |
Minimální parametry TLS/SSL serverovských certifikátů pro vnitřní web server a VPN DA IPHTTPS server:
| Subject |
not mandatory if SAN present |
| SAN |
DNS (checks against what the client uses as the HTTP host header) |
| Exportable key |
no if enrolling from an internal CA
yes if enrolling from a public CA and will copy the certificate (NLB, reverse proxies) |
| Archive key |
no, transport encryption only |
| Key type |
Encryption (we are doing RSA key exchange) |
| Key usage |
Key Encipherment |
| CSP/CNG |
all Strong, Enhanced, RSA Schannel, AES providers support TLS 1.2 with SHA256 on Windows 2008
IIS can use Microsoft Software Key Storage Provider on Windows 2008
only RSA Schannel on Windows 2003 |
| EKU |
Server Authentication (1.3.6.1.5.5.7.3.1) |
| Autoenrollment |
no, custom DNS name |
| Publish in AD |
no |
Pokud chcete vypnout IPv6 v registrech, ale jen tak, abyste si ponechali IPv6 pro Direct Access a tedy i IPHTTPS - musíte vypnout ISATAP, Teredo a 6to4 - tak to nejde (vypínat v registrech se dají pouze celkově všechna tunelová rozhraní - tunnel interfaces) a musíte místo toho použít příkazovou řádku:
netsh interface isatap set state disabled
netsh interface teredo set state disabled
netsh interface 6to4 set state disabled
Vyresetovat IPHTTPS do výchozího nastavení se provádí pomocí:
netsh interface httpstunnel reset
Vypsání HTTPS binding které zpravuje HTTP.SYS se provádí pomocí (AppId pro IP-HTTPS{5d8e2743-ef20-4d38-8751-7e400f200e65} viz. můj článeček zde):
Vypsání vůbec registrovaných URI, která zpravuje HTTP.SYS:
NETSH http show servicestate
Výslednou sadu zásad (Group Policy) na stanici, včetně kontroly úspěšnosti WMI filtrů, a kontroly členství počítače ve skupinách, můžete provést pomocí GPRESULT (upozorňuju, že WHOAMI nefunguje korektně pro počítačový účet, protože access token služeb běžících pod účtem SYSTEM, které se startují obecně dříve, než je nahozena síť, doménové skupiny obvykle neobsahuje):
GPRESULT /h report.htm
report.htm
Informace o IPv6 konfiguraci, rozhraních (interfaces), IP-HTTPS tunelu a opdovídajících směrovacích tabulkách (routing table) a ARP tabulce, zjisíte pomocí NETSH:
ipconfig /all
NETSH interface httpstunnel show mode
NETSH interface httpstunnel show interfaces
NETSH interface httpstunnel show alias
NETSH interface httpstunnel show statistics
NETSH interface ipv6 show route
NETSH interface ipv6 show address IPHTTPSInterface
NETSH interface ipv6 show neighbors
Pro DirectAccess zajímavé IPv6 adresy jsou následující:
| FF00:: / 8 |
multicast |
224.x.x.x /4 |
| FE80:: / 10 |
link-local, automatically generated
includes also FE8, FE9, FEA, FEB, FEC, FED prefixes |
APIPA 169.254.x.x /16 |
| :: / 128 |
noting |
0.0.0.0 /32 |
| ::1 / 128 |
loopback |
127.x.x.x /8 |
| FD00:: / 7 |
unique local address
includes also FC, FD, FE prefixes |
10.x.x.x /8
172.16.x.x.x - 172.31.x.x /16
192.168.x.x /24 |
| FD...:1:: /64 |
ISATAP tunnel interface from client to DA server |
|
| FD...:1:0:5EFE:IP.IP.IP.IP |
static ISATAP address of the DA server itself |
|
| FD...:1000:: /64 |
IP-HTTPS tunnel interface from client to DA server |
|
| FD...:3333::1 |
static DA server internal interface IPv6 address |
|
| FD...:7777:: /96 |
NAT64 and DNS64 running on the DA server |
|
Veškeré chybové kódy se dají obvykle přeložit pomocí Err nástroje viz. můj dřívější článeček.
A to je všechno. Zbytek bude na videu později. Video záznam předchozího WUGu na téma VPN je k nalezení zde.
Testování HTTPS spojení se dá provést buď rovnou pomocí Internet Explorer, kde sice nic z HTTP neuvidíte, ale aspoň se můžete podívat na IPHTTPS certifikát, protože TLS/SSL se ustavuje jako první. Nebo se dá použít můj PowerShell script na testování TLS, co jsem zveřňoval zrovna v pondělí myslím.
Díky a zase někdy na WUGu naschledanou.