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

Den här artikeln ger en detaljerad översikt över hur du konfigurerar en Active Directory (AD)-server via en L2TP VPN-tunnel med hjälp av USG FLEX/ATP VPN-autentiseringsmetoden. Dessutom är den vägledning som presenteras här tillämplig på IPsec IKEv2 och IKEv1 VPN-konfigurationer.

VPN-tunnlar är en kritisk komponent när man upprättar nätverk som i sig är expansiva, t.ex. globala företagsnätverk eller huvudanläggningar som är sammankopplade med underordnade platser.

En grundläggande egenskap hos företagsnätverk är processen för att autentisera användare till en server, vilket visar pålitlighet och ger åtkomst till interna resurser. Denna handledning syftar till att förse dig med de verktyg som krävs för att konfigurera autentisering till en autentiseringsserver via en VPN-tunnel.

Två brandväggar är anslutna via Site-to-Site VPN, och på huvudsidan A finns det en RADIUS-server inom LAN. På Site B kan det finnas flera klienter som vill autentisera sig mot RADIUS-servern på Site A. På Site B hittar vi antingen lokala klienter som behöver anslutning till RADIUS-servern på Site A, eller L2TP VPN-klienter som behöver autentisering mot Site A:s RADIUS.

Här måste vi göra en viktig åtskillnad mellan VPN-klienten och LAN-klienten på Site B - även om det är mycket troligt att klienten från Site B kan autentisera utan några som helst problem mot RADIUS på Site A, kommer L2TP VPN-klienterna troligen inte att kunna göra det. Varför är det så?

Site-to-Site VPN: er är konfigurerade med en lokal policy och en fjärrpolicy. Dessa policyer avgör vilka nätverksvägar som skapas när en tunnel skapas, vilket innebär att vilka nätverk som tillåts "prata med varandra". I det här fallet antar vi att routning mellan 192.168.10.0/24 och 192.168.20.0/24 är bra. L2TP VPN, som i sig måste vara ett annat undernät än de lokala undernäten på Site B, får inte kommunicera mot Site A eftersom det inte ingår i Local or Remote Policy.

Det vill säga, om vi inte lägger till ytterligare policyvägar. Med hjälp av den här typen av rutter kan vi tvinga alla autentiseringsförsök som kommer från L2TP VPN till en destination på Site A. Först måste vi definiera att autentiseringar på Site B ska riktas till Site A:s RADIUS.

Konfigurera AAA-servern

Konfiguration > Objekt > AAA-server

och konfigurera ett autentiseringsobjekt mot IP 192.168.10.100:

Testa din AD-autentisering

Konfiguration -> Objekt -> AAA-server

Se till att spara din konfiguration innan du testar konfigurationsvalideringen.

Bra resultat	Dåligt resultat

Konfigurera Auth. Metod

Detta AAA Server-Object måste nu kombineras med en autentiseringsmetod, som i sin tur är inställd som huvudautentisering för vårt VPN. Navigera först till menyn

Konfiguration > Objekt > Auth. Metod

och lägg till den nyskapade AAA-servern i standard Auth. Method:

Få brandväggen att ansluta sig till AD-servern

Sedan måste USG ansluta sig till AD-domänen med domännamnet på AD-servern

Navigera till Konfiguration -> System -> Värdnamn

Realm är domännamnet på annonsservern och NetBIOS-namnet är domänen.

För att peka brandväggen till AD-servern måste vi skapa en DNS-post för att framgångsrikt hitta AD-servern via AD-serverns IP-adress:

Konfigurera VPN

Via IKEv2

Konfiguration -> VPN -> IPSec VPN -> VPN Gateway - Lägg till/redigera

Klicka på "Visa avancerade inställningar" och aktivera "Extended Authentication Protocol" och välj Serverläge.

Välj sedan AAA-metoden (Auth.-metod) och Tillåten användare

Via L2TP

Efter det väljer vi denna Auth. Method som ska användas via L2TP VPN via

Konfiguration > VPN > L2TP över IPSec VPN

(Observera att IP-adresspoolen inte motsvarar topologin ovan, eftersom det här bara är ett exempel på hur man ställer in L2TP-tunneln)

Nu när L2TP VPN är konfigurerat med en autentisering som ska vidarebefordras mot RADIUS på Site A måste vi skapa policyvägar:

Den första policyvägen kommer att trycka allt som kommer från vilken källa som helst, som vill röra sig mot 192.168.10.100 IP, in i tunneln till Site A - vilket också betyder autentiseringsförsöket från vårt L2TP VPN. Den andra policyvägen kommer att driva allt som är avsett för L2TP VPN-undernätet tillbaka till L2TP VPN.

På den andra webbplatsen måste vi nu helt enkelt komplettera detta genom en motsvarande regel, som kommer att driva allt från undernät som skiljer sig från Site B LAN (som vårt L2TP VPN Subnets försök) tillbaka in i tunneln mot Site B, vilket utlöser vår policyväg som vi har ställt in på den webbplatsen.

Om du följer den här enkla guiden bör du nu kunna autentisera dina klienter mot en RADIUS på en annan VPN-plats på distans.

Konfigurera DNS-vidarebefordran för AD-domänen (rekommenderas)

För att säkerställa korrekt AD-namnmatchning ska du konfigurera DNS-vidarebefordran utöver den lokala DNS-posten:

• Gå till Konfiguration → System → DNS → Domain Zone Forwarder, lägg till din AD-domän (t.ex. company.local) och ange AD DNS-servern som vidarebefordrare.

• I VPN-anslutning → Klientinställningar tilldelar du AD DNS-servern (eller brandväggens LAN-IP om vidarebefordran är aktiverad) som första DNS-server.

• (Valfritt ) Lägg till en principväg om DNS-förfrågningar måste tvingas genom VPN.

Verifiera med: nslookup dc1.company.local.

Felsökning & testa ditt resultat

Navigera till

Övervaka -> Nätverksstatus -> Inloggade användare

Navigera till

Övervaka -> VPN-övervakning -> IPSec

Felsökning

Navigera till brandväggens webbkonsol eller anslut till brandväggen via SSH och kör det här kommandot

debug domain-auth test profile-name [ad profile name] användarnamn [användarnamn] lösenord [lösenord]

Ersätt ad profile name med Active Directory-namnet "AD Server Summary" och använd användarnamnet och lösenordet för domänautentiseringen via MSCHAP.

Fler artiklar finns här:

AD (active directory) användare autentisera kontroll

Hur man ansluter till en Active Directory-domän med USG/ATP/VPN

Hur man gör tvåfaktorsautentisering med Active Directory-användare