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

Denne artikkelen gir en detaljert oversikt over hvordan du konfigurerer en Active Directory (AD)-server gjennom en L2TP VPN-tunnel ved hjelp av USG FLEX/ATP VPN-godkjenningsmetoden. I tillegg gjelder veiledningen som presenteres her, for IPsec IKEv2- og IKEv1 VPN-konfigurasjoner.

VPN-tunneler er en kritisk komponent når man etablerer nettverk som i seg selv er ekspansive, for eksempel globale bedriftsnettverk eller hovedkontorer som er sammenkoblet med datterselskaper.

Et grunnleggende kjennetegn ved bedriftsnettverk er prosessen med å autentisere brukere til en server, og dermed demonstrere pålitelighet og få tilgang til interne ressurser. Denne veiledningen har som mål å utstyre deg med de nødvendige verktøyene for å konfigurere autentisering til en autentiseringsserver via en VPN-tunnel.

To brannmurer er koblet sammen via Site-to-Site VPN, og på hovednettstedet A finnes det en RADIUS-server i LAN. På Site B kan det være flere klienter som ønsker å autentisere seg mot RADIUS-serveren på Site A. På Site B finner vi enten lokale klienter som trenger tilkobling mot RADIUS-serveren på Site A, eller L2TP VPN-klienter som krever autentisering mot Site A's RADIUS.

Her må vi gjøre et viktig skille mellom VPN-klienten og LAN-klienten på Site B - mens det er svært sannsynlig at klienten fra Site B kan autentisere seg uten problemer mot RADIUS på Site A, vil L2TP VPN-klientene sannsynligvis ikke kunne gjøre det. Hvorfor er det slik?

Site-to-Site VPN-er er satt opp med en lokal policy og en ekstern policy. Disse policyene bestemmer hvilke nettverksruter som opprettes når en tunnel opprettes, det vil si hvilke nettverk som får lov til å "snakke med hverandre". I dette tilfellet antar vi at ruting mellom 192.168.10.0/24 og 192.168.20.0/24 er i orden. L2TP VPN, som i seg selv må være et annet undernett enn de lokale undernettene på Site B, har ikke lov til å kommunisere mot Site A fordi det ikke er inkludert i Local eller Remote Policy.

Det vil si, hvis vi ikke legger til flere policyruter. Ved hjelp av denne typen ruter kan vi tvinge alle autentiseringsforsøk som kommer fra L2TP VPN mot en destinasjon på Site A. Først må vi definere at autentiseringer på Site B skal sendes til Site A's RADIUS.

Konfigurer AAA-serveren

Konfigurasjon > Objekt > AAA-server

og sette opp et autentiseringsobjekt mot IP 192.168.10.100:

Test AD-autentiseringen din

Konfigurasjon -> Objekt -> AAA-server

Sørg for å lagre konfigurasjonen før du tester konfigurasjonsvalideringen.

Godt resultat	Dårlig resultat

Konfigurer Auth. Method

Dette AAA-serverobjektet må nå kombineres med en autentiseringsmetode, som i sin tur er angitt som hovedautentisering for VPN-et vårt. Først navigerer du til menyen

Konfigurasjon > Objekt > Auth. Metode

og legg til den nyopprettede AAA-serveren i standard Auth. Method:

Få brannmuren til å bli med i AD-serveren

Deretter må USG-enheten bli med i AD-domenet med domenenavnet til AD-serveren

Naviger til Konfigurasjon -> System -> Vertsnavn

Realm er domenenavnet til annonseserveren, og NetBIOS-navnet er domenet.

For å peke brannmuren mot AD-serveren må vi opprette en DNS-post for å finne AD-serveren via AD-serverens IP-adresse:

Konfigurere VPN

Via IKEv2

Konfigurasjon -> VPN -> IPSec VPN -> VPN-gateway - Legg til/rediger

Klikk på "Vis avanserte innstillinger" og aktiver "Utvidet autentiseringsprotokoll" og velg servermodus.

Velg deretter AAA-metoden (Auth. Method) og Tillatt bruker

Via L2TP

Deretter velger vi denne Auth. Metoden som skal brukes via L2TP VPN via

Konfigurasjon > VPN > L2TP over IPSec VPN

(Vær oppmerksom på at IP-adressepoolen ikke samsvarer med topologien som er tegnet ovenfor, siden dette bare er et eksempel på hvordan du setter opp L2TP-tunnelen)

Nå som L2TP VPN er satt opp med en autentisering som skal videresendes mot RADIUS på Site A, må vi opprette policyruter:

Den første policyruten vil skyve alt som kommer fra en hvilken som helst kilde, som ønsker å bevege seg mot 192.168.10.100 IP, inn i tunnelen til Site A - noe som også betyr autentiseringsforsøket fra L2TP-VPN-et vårt. Den andre policyruten vil skyve alt som er ment for L2TP VPN-undernettet tilbake til L2TP VPN.

På det andre nettstedet må vi nå ganske enkelt utfylle dette gjennom en tilsvarende regel, som vil skyve alt fra undernett som er forskjellig fra Site B LAN (som L2TP VPN-delnettets forsøk) tilbake i tunnelen mot Site B, noe som utløser policyruten vår som vi har angitt på det nettstedet.

Ved å følge denne enkle veiledningen bør du nå kunne autentisere klientene dine mot en RADIUS på en annen ekstern VPN-lokasjon.

Konfigurer DNS-videresending for AD-domenet (anbefalt)

For å sikre riktig AD-navnoppløsning må du konfigurere DNS-videresending i tillegg til den lokale DNS-oppføringen:

• Gå til Konfigurasjon → System → DNS → Domain Zone Forwarder, legg til AD-domenet ditt (f.eks. company.local) og angi AD DNS-serveren som videresender.

• I VPN-tilkobling → Klientinnstillinger tilordner du AD DNS-serveren (eller brannmurens LAN-IP hvis videresending er aktivert) som første DNS-server.

• (Valgfritt ) Legg til en policyrute hvis DNS-spørringer må tvinges gjennom VPN-et.

Verifiser med: nslookup dc1.company.local.

Feilsøking og test resultatet ditt

Naviger til

Monitor -> Network Status -> Login Users

Naviger til

Overvåk -> VPN-overvåking -> IPSec

Feilsøking

Naviger til webkonsollen til brannmuren eller koble til brannmuren via SSH og kjør denne kommandoen

debug domain-auth test profile-name [annonseprofilnavn] brukernavn [brukernavn] passord [passord]

Erstatt ad profile name med Active Directory "AD Server Summary"-navnet, og bruk brukernavnet og passordet for domenegodkjenning via MSCHAP.

Flere artikler finner du her:

AD (Active Directory) brukerautentiseringskontroll

Hvordan bli med i et Active Directory-domene med USG/ATP/VPN

Slik gjør du tofaktorautentisering med Active Directory-brukere