VPN - Konfigurer en Active Directory [AD]-server via en VPN-tunnel

Denne artikel giver en detaljeret oversigt over, hvordan man konfigurerer en Active Directory (AD)-server via en L2TP VPN-tunnel ved hjælp af USG FLEX/ATP VPN-godkendelsesmetoden. Derudover kan vejledningen heri anvendes til IPsec IKEv2 og IKEv1 VPN-konfigurationer.

VPN-tunneler er en kritisk komponent, når man etablerer netværk, der i sagens natur er ekspansive, som f.eks. globale virksomhedsnetværk eller hovedsteder, der er forbundet med datterselskaber.

En grundlæggende egenskab ved virksomhedsnetværk er processen med at autentificere brugere til en server og derved demonstrere pålidelighed og få adgang til interne ressourcer. Denne vejledning har til formål at give dig de nødvendige værktøjer til at konfigurere autentificering til en autentificeringsserver via en VPN-tunnel.

To firewalls er forbundet via Site-to-Site VPN, og på hovedsite A er der en RADIUS-server i LAN'et. På Site B kan der være flere klienter, som ønsker at autentificere sig over for RADIUS-serveren på Site A. På Site B finder vi enten lokale klienter, som har brug for forbindelse til RADIUS-serveren på Site A, eller L2TP VPN-klienter, som kræver autentificering over for Site A's RADIUS.

Her er vi nødt til at gøre en vigtig forskel mellem VPN-klienten og LAN-klienten på Site B - mens det er meget sandsynligt, at klienten fra Site B uden problemer kan autentificere sig over for RADIUS på Site A, vil L2TP VPN-klienterne sandsynligvis ikke være i stand til at gøre det. Hvad er årsagen til det?

Site-to-Site VPN'er er sat op med en lokal politik og en ekstern politik. Disse politikker bestemmer, hvilke netværksruter der oprettes, når en tunnel oprettes, dvs. hvilke netværk der får lov til at "tale med hinanden". I dette tilfælde antager vi, at routing mellem 192.168.10.0/24 og 192.168.20.0/24 er i orden. L2TP VPN, som i sagens natur skal være et andet subnet end de lokale subnet på Site B, har ikke lov til at kommunikere mod Site A, fordi det ikke er inkluderet i den lokale eller eksterne politik.

Det vil sige, hvis vi ikke tilføjer yderligere policy-ruter. Ved hjælp af den slags ruter kan vi tvinge ethvert autentificeringsforsøg, der kommer fra L2TP VPN, til en destination på Site A. Først skal vi definere, at autentificeringer på Site B sendes til Site A's RADIUS.

Konfigurer AAA-serveren

Konfiguration > Objekt > AAA-server

og opsæt et godkendelsesobjekt mod IP 192.168.10.100:

Test din AD-godkendelse

Konfiguration -> Objekt -> AAA-server

Sørg for at gemme din konfiguration, før du tester konfigurationsvalideringen.

Godt resultat	Dårligt resultat

Konfigurer Auth. Metode

Dette AAA-serverobjekt skal nu kombineres med en godkendelsesmetode, som igen indstilles som hovedgodkendelse for vores VPN. Naviger først til menuen

Konfiguration > Objekt > Auth. Metode

og tilføj den nyoprettede AAA-server til standard Auth. Metode:

Få firewallen til at tilslutte sig AD-serveren

Derefter skal USG'en tilslutte sig AD-domænet med AD-serverens domænenavn

Naviger til Konfiguration -> System -> Værtsnavn

Realm er AD-serverens domænenavn, og NetBIOS-navnet er domænet.

For at pege firewallen mod AD-serveren skal vi oprette en DNS-post for at kunne finde AD-serveren via AD-serverens IP-adresse:

Konfigurer VPN'en

Via IKEv2

Konfiguration -> VPN -> IPSec VPN -> VPN Gateway - Tilføj/rediger

Klik på "Vis avancerede indstillinger", og aktiver "Extended Authentication Protocol", og vælg servertilstand.

Vælg derefter AAA-metoden (Auth. Method) og Allowed user (Tilladt bruger).

Via L2TP

Derefter vælger vi denne Auth. Metode, der skal bruges via L2TP VPN via

Konfiguration > VPN > L2TP over IPSec VPN

(Bemærk, at IP-adressepuljen ikke svarer til den topologi, der er tegnet ovenfor, da dette kun er et eksempel på, hvordan man opsætter L2TP-tunnelen)

Nu, hvor L2TP-VPN'en er sat op med en godkendelse, som skal videresendes til RADIUS på Site A, skal vi oprette policy-ruter:

Den første policy-rute vil skubbe alt, der kommer fra en hvilken som helst kilde, som ønsker at bevæge sig mod 192.168.10.100 IP, ind i tunnelen til Site A - hvilket også betyder autentificeringsforsøget fra vores L2TP VPN. Den anden policy-rute vil skubbe alt, der er beregnet til L2TP VPN-undernettet, tilbage i L2TP VPN.

På det andet site skal vi nu blot supplere dette med en tilsvarende regel, som vil skubbe alt fra undernet, der adskiller sig fra Site B LAN (som vores L2TP VPN-undernets forsøg), tilbage i tunnelen mod Site B, hvilket udløser vores politikrute, som vi har indstillet på det site.

Hvis du følger denne enkle vejledning, bør du nu være i stand til at autentificere dine klienter mod en RADIUS på en anden fjern VPN-placering.

Konfigurer DNS-videresendelse for AD-domæne (anbefales)

For at sikre korrekt AD-navneopløsning skal du konfigurere DNS-forwarding ud over den lokale DNS-post:

• Gå til Configuration → System → DNS → Domain Zone Forwarder, tilføj dit AD-domæne (f.eks. company.local), og indstil AD DNS-serveren som forwarder.

• I VPN-forbindelse → Klientindstillinger skal du tildele AD DNS-serveren (eller firewallens LAN-IP, hvis videresendelse er aktiveret) som første DNS-server.

• (Valgfrit) Tilføj en policy-rute, hvis DNS-forespørgsler skal tvinges gennem VPN'en.

Bekræft med: nslookup dc1.company.local.

Fejlfinding og test af dit resultat

Naviger til

Monitor -> Netværksstatus -> Login-brugere

Naviger til

Overvåg -> VPN-overvågning -> IPSec

Fejlfinding

Naviger til firewallens webkonsol, eller opret forbindelse til firewallen via SSH, og kør denne kommando

debug domain-auth test profile-name [ad profile name] username [username] password [password]

Erstat ad profile name med Active Directory-navnet "AD Server Summary", og brug brugernavnet og adgangskoden til domænegodkendelsen via MSCHAP.

Flere artikler findes her:

AD (active directory) brugergodkendelseskontrol

Sådan tilslutter du dig et Active Directory-domæne med USG/ATP/VPN

Sådan laver du to-faktor-autentificering med Active Directory-brugere