VPN - konfigurace serveru Active Directory [AD] prostřednictvím tunelu VPN

Tento článek poskytuje podrobný přehled o tom, jak nakonfigurovat server Active Directory (AD) prostřednictvím tunelu L2TP VPN pomocí metody ověřování USG FLEX/ATP VPN. Kromě toho jsou zde uvedené pokyny použitelné pro konfigurace IPsec IKEv2 a IKEv1 VPN.

Tunely VPN jsou důležitou součástí při vytváření sítí, které jsou ze své podstaty rozsáhlé, jako jsou globální podnikové sítě nebo hlavní lokality propojené s pobočkami.

Základní charakteristikou podnikových sítí je proces ověřování uživatelů na serveru, čímž se prokazuje důvěryhodnost a získává přístup k interním zdrojům. Cílem tohoto výukového kurzu je vybavit vás potřebnými nástroji pro konfiguraci ověřování na ověřovacím serveru prostřednictvím tunelu VPN.

Dva firewally jsou propojeny prostřednictvím Site-to-Site VPN a na hlavním serveru A je v rámci sítě LAN umístěn server RADIUS. V lokalitě B může být několik klientů, kteří se chtějí ověřit vůči serveru RADIUS v lokalitě A. V lokalitě B najdeme buď místní klienty, kteří se potřebují připojit k serveru RADIUS v lokalitě A, nebo klienty L2TP VPN, kteří vyžadují ověření vůči serveru RADIUS v lokalitě A.

Zde je třeba rozlišovat mezi klientem VPN a klientem LAN v lokalitě B - zatímco je velmi pravděpodobné, že klient z lokality B se může bez problémů ověřit vůči serveru RADIUS lokality A, klienti L2TP VPN toho s největší pravděpodobností nebudou schopni. Proč tomu tak je?

Sítě VPN Site-to-Site se nastavují pomocí místních zásad a vzdálených zásad. Tyto zásady určují, které síťové trasy se vytvoří při vytvoření tunelu, tedy které sítě spolu mohou "komunikovat". V tomto případě předpokládáme, že směrování mezi 192.168.10.0/24 a 192.168.20.0/24 je v pořádku. VPN L2TP, která ze své podstaty musí být jinou podsítí než místní podsítě v lokalitě B, nesmí komunikovat směrem k lokalitě A, protože není zahrnuta do místních ani vzdálených zásad.

Tedy pokud nepřidáme další trasy zásad. Pomocí tohoto druhu tras můžeme vynutit jakýkoli pokus o ověření přicházející z L2TP VPN směrem k cíli v lokalitě A. Nejprve musíme definovat, že ověření v lokalitě B jsou směrována do RADIUS lokality A.

Konfigurace serveru AAA

Konfigurace > Objekt > Server AAA

a nastavte objekt ověřování směrem k IP 192.168.10.100:

Otestujte ověřování AD

Konfigurace -> Objekt -> Server AAA

Před testováním ověření konfigurace nezapomeňte konfiguraci uložit.

Dobrý výsledek	Špatný výsledek

Konfigurace Auth. Method

Tento objekt AAA Server-Object je nyní třeba zkombinovat s metodou ověřování, kterou následně nastavíme jako hlavní ověřování pro naši VPN. Nejprve přejděte do nabídky

Konfigurace > Objekt > Auth. Method .

a přidejte nově vytvořený AAA Server do výchozího Auth. Method:

Přimějte bránu firewall, aby se připojila k serveru AD

Poté je třeba, aby se zařízení USG připojilo k doméně AD s názvem domény serveru AD.

Přejděte do části Konfigurace -> Systém -> Název hostitele

Oblast je název domény serveru ad a název NetBIOS je doména.

Abychom mohli firewall nasměrovat na server AD, musíme vytvořit záznam DNS, který úspěšně vyhledá server AD prostřednictvím IP adresy serveru AD:

Konfigurace sítě VPN

Prostřednictvím protokolu IKEv2

Konfigurace -> VPN -> IPSec VPN -> Brána VPN - Přidat/upravit

Klikněte na "Zobrazit pokročilá nastavení" a povolte "Extended Authentication Protocol" a vyberte režim serveru.

Poté vyberte metodu AAA (Auth. Method) a Allowed user (Povolený uživatel).

Přes L2TP

Poté vybereme tento Auth. Method, která se má používat prostřednictvím L2TP VPN přes

Konfigurace > VPN > L2TP přes IPSec VPN.

(Upozorňujeme, že fond IP adres neodpovídá výše nakreslené topologii, protože se jedná pouze o příklad nastavení tunelu L2TP).

Nyní, když je L2TP VPN nastavena s ověřováním, které by mělo být předáno směrem k RADIUS v lokalitě A, musíme vytvořit trasy zásad:

První trasa zásad bude do tunelu na lokalitu A posílat cokoli, co přichází z jakéhokoli zdroje a chce se přesunout na IP adresu 192.168.10.100 - tedy i pokus o ověření z naší L2TP VPN. Druhá trasa zásad bude tlačit vše, co je určeno pro podsíť L2TP VPN, zpět do L2TP VPN.

Na druhé lokalitě to nyní musíme jednoduše doplnit prostřednictvím odpovídajícího pravidla, které bude cokoli z podsítí odlišných od lokální sítě lokality B (jako pokus naší podsítě L2TP VPN) tlačit zpět do tunelu směrem k lokalitě B, čímž se spustí naše trasa zásad, kterou jsme na této lokalitě nastavili.

Podle tohoto jednoduchého návodu byste nyní měli být schopni ověřovat své klienty směrem k RADIUS na jiném vzdáleném místě VPN.

Konfigurace předávání DNS pro doménu AD (doporučeno)

Chcete-li zajistit správné překládání názvů AD, nakonfigurujte kromě místního záznamu DNS také předávání DNS:

• Přejděte do Konfigurace → Systém → DNS → Domain Zone Forwarder, přidejte doménu AD (např. company.local) a nastavte server AD DNS jako forwarder.

• V části Připojení VPN → Nastavení klienta přiřaďte serveru AD DNS (nebo IP adrese LAN brány firewall, pokud je předávání povoleno) funkci Prvního serveru DNS.

• (Nepovinné) Přidejte trasu zásad, pokud je třeba dotazy DNS vynucovat přes síť VPN.

Ověřte pomocí: nslookup dc1.company.local.

Řešení problémů a testování výsledku

Přejděte do

Monitor -> Stav sítě -> Přihlášení uživatelé

Přejděte na

Monitor -> Monitor VPN -> IPSec

Řešení problémů

Přejděte na webovou konzolu brány firewall nebo se k ní připojte přes SSH a spusťte tento příkaz

debug domain-auth test profile-name [název reklamního profilu] username [uživatelské jméno] password [heslo]

Nahraďte název profilu ad názvem služby Active Directory "AD Server Summary" a použijte uživatelské jméno a heslo ověřování domény prostřednictvím MSCHAP.

Další články naleznete zde:

AD (active directory) ověření uživatele

Jak se připojit k doméně Active Directory pomocí USG/ATP/VPN

Jak provést dvoufaktorové ověřování uživatelů služby Active Directory