Direct Access introduksjon #2

Oppfølger til forrige post om emnet, Direct Access introduksjon #1. Denne gangen litt dypere.

Tilkobling

Direct Access bruker IPv6 til å kommunisere med Server 2008 R2 serveren som er Direct Access server.  Siden dette ikker støttet på alle nett man kobler til via benytter Direct Access ulike tunneleringsmetoder. Det er tjenesten IP Helper som velger og setter opp disse i henhold til tabellen under:

Selvsagt så sant du har konfigurert opp disse. Den siste protokollen er laget av oss, de andre er i henhold til standard og støttet av klientene våre utenom Direct Access også. IP-HTTPS gjør også at du kan kommunisere gjennom firewaller eller proxier der alt annet enn http er blokkert. Sånn kan du også med DA få en fjernaksessløsning med bedre tilkoblingsmuligheter enn tradisjonelle VPN løsninger. (Er jo i stor grad derfor SSL vpn ble populært)

Over Internett brukes også IPsec til å beskytte og autentisere trafikken som går mot datasenteret.

Dersom du har ressurser i datasenteret som ikke støtter IPv6 kan du bruke en såkalt Nat-PT device som oversetter mellom IPv6 og IPv4.

I ekstern firewall må følgende trafikk slippe gjennom til DA server:

ICMPv6 og IPv6 Protokoll 50  (ipsec) trengs kun dersom DA klientene skal kunne koble til direkte med native IPv6. dvs uten tunnelering.

Prosessen

Når en Direct Access maskin er startet vil den forsøke å koble til Direct Access serveren til firma, gitt at den detekterer at den ikke er tilkoblet firmanettet direkte. Hvis dette går oppretter den en tunnel og autentiserer seg. Slik vil den alltid være tilgjengelig og “pålogget” domenet.

Deteksjon av om klienten er på innsiden eller utsiden gjøres ved å sjekke tilgjengeligheten på en ressurs uten DA i gang. Ressursen definerer man selv i oppsettet. Bør jo være en med høy tilgjengelighet. Klienten vil også sjekke IPv6 adressen den får og sammenligne den med scopet som i DA konfigurasjon er definert som innsiden.

Når en bruker så logger på blir det opprettet de nødvendige tunnelene for å koble til mot interne ressurser via Direct Access serveren. Det er da brukeren som blir autentisert i tillegg.

Når en DA klient forsøker å slå opp et navn, f.eks Sharepoint07, vil TCP/IP stacken først legge til DNS suffix som er konfigurert for maskinen, og deretter sammenligne med dataene i NRPT, Name resolution policy table. Denne inneholder oversikt over DNS namespaces og tilhørende interne DNS tjenere. NRPT kan inneholde data for mange ulike suffixes.

Hvis det ikke er en match i policy tabellen vil ordinær DNS server konfigurert for NIC’et bli brukt og trafikken vil gå direkte ut på nettet der maskinen er tilkoblet. Så kalt split-tunnelling, ikke all trafikk går via Direct Access serveren, noe som er tilfellet i enkelte vpn oppsett. Såkalt enforcement av tunnelering kan settes opp med DA også, men er ikke standard.

Eksempel på NRPT:

Tilgangsmodell

Direct Access kan settes opp med tre ulike modeller for tilgang:

• Full Intranet Access. Dette er en end-to-edge modellen, der klient IPsec tilkobling termineres i gatewayen. Dette er en separat DA rolle. (IPsec-gateway) Brukerne får her tilgang til alle servere internt.
• Selected Server access. Modifisert utgave av den forrige. Her oppretter man en IPsec tunnel til med kun autentisering som ikke termineres i IPSec gateway, men går helt fram til den aktuelle ressursen. Da kan man sette IPsec-regler på de enkelte serverne om hvem som har tilgang.
• End to End. I dette oppsettet sender DA serveren kun trafikken videre, IPsec tunnelene går hele veien til den aktuelle ressursen internt, også kryptert. Sikrer kommunikasjonen hele veien og åpner for IPsec tilgangsregler på interne servere.

DA kan settes opp til å kreve Smart Card, enten alltid på maskinen, eller kun for å få DA tilkobling. I vårt oppsett logger vi bare på med passord til vanlig, men på “utsiden” må vi bruke Smart card for å få Direct Access tilgang til interne ressurser.