Jak se přihlášení k VPN dostane do RADIUS a k vašemu poskytovateli identity

Minulý týden se uživatel mohl přihlásit k VPN a přesto skončil v síti, kde se nic neresolvovalo. Klient hlásil připojeno, log brány hlásil Access-Accept a tým identity říkal, že účet je v pořádku. Přihlášení fungovalo; autorizace za ním ne. Když přihlášení k VPN selže, jdu cestou, kterou požadavek skutečně prochází — klient, brána, RADIUS server, poskytovatel identity — a zastavím se u prvního skoku, jehož odpověď nesouhlasí s následujícím.

Klient nikdy nemluví RADIUS

Ať aplikace na notebooku ukazuje cokoli, jejím prvním skokem je VPN protokol: IKEv2, OpenVPN, WireGuard nebo klient založený na TLS. RADIUS se v této výměně neobjevuje. Klient se autentizuje vůči bráně certifikátem, uživatelským jménem a heslem nebo metodou EAP nesenou v nastavení tunelu.

To je důležité při čtení logů, protože obecnou chybu autentizace, kterou uživatel vidí, vytváří brána poté, co už mluvila s něčím jiným. Pokud se klient k bráně vůbec nedostane, neexistuje žádný RADIUS požadavek k ladění a hodina strávená na RADIUS serveru je ztracená. Než se dotknete backendu, potvrďte, že tunel vůbec vznikl.

Brána je RADIUS klient

Jakmile nastavení tunelu dospěje do bodu, kdy je třeba ověřit přihlašovací údaje, brána se stane serverem síťového přístupu. Sestaví Access-Request: User-Name, heslo nebo EAP payload, NAS-IP-Address nebo NAS-Identifier a Message-Authenticator, když to metoda vyžaduje. Požadavek jde ve výchozím nastavení na UDP 1812 a účtování na 1813. Starší nasazení stále používají 1645 a 1646, takže pravidlo firewallu napsané pro jednu dvojici vysvětluje mnoho tichých selhání.

Obě strany sdílejí tajemství a to není uživatelský údaj. Podepisuje výměnu a každá odpověď se proti němu ověřuje. Nastavte tajemství na obou stranách různě a server neodpoví špatné tajemství — požadavek zahodí nebo odpověď neprojde ověřením, takže brána hlásí vypršení časového limitu. Špatné tajemství a mrtvý server vypadají z brány stejně, proto skok testuji klientským nástrojem, než obviním adresář.

Protokol je malý a starý — RFC 2865 definuje autentizační výměnu — ale atributy, které nese, jsou to, na čem je postavena většina VPN zásad.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

RADIUS server může být jen přední částí poskytovatele identity

Lidé mluví o RADIUS a poskytovateli identity, jako by to byla stejná krabice. Často nejsou. RADIUS server přijme Access-Request a poté se před odpovědí zeptá něčeho jiného — Active Directory přes LDAP nebo Kerberos, místní soubor uživatelů nebo externí službu. FreeRADIUS s modulem LDAP nebo krb5, Windows NPS a Cisco ISE stojí všechny na této pozici.

Rozdíl rozhoduje o tom, kam se dívat. Odmítnuté heslo je odpověď poskytovatele identity přeposlaná RADIUSem. Vypršení časového limitu je obvykle úsek RADIUS–adresář: prošlý účet pro svázání, nedostupný adresář nebo požadavek směrovaný na špatný backend. Pokud uživatelské jméno nese doménovou příponu, server podle ní může směrovat, a stejný účet odeslaný jako CORP\alice a [email protected] může skončit na různých místech. Ve Windows NPS zapisuje protokol Security 6272 při povolení a 6273 při odmítnutí, což vám řekne, zda rozhodnutí vůbec přišlo z NPS.

Čtěte selhání u skoku, který je způsobil

Jedna zpráva o nemožnosti připojení pokrývá čtyři různá selhání. Než cokoli změníte, přiřaďte symptom ke skoku, který ho způsobil.

Poslední řádek je ten, který posílá lidi ke špatnému týmu. Access-Accept znamená, že přihlašovací údaje byly přijaty; neznamená, že brána umístila uživatele do správného poolu nebo protlačila trasy. Atributy skupiny záleží jen tehdy, když je zásada brány čte. Viděl jsem správné přihlášení skončit v hostovském poolu, protože mapování skupin bylo na straně RADIUSu nastaveno pro jiný atribut, než který brána kontroluje.

Sledujte jedno přihlášení od začátku do konce

Vyberte jeden testovací účet a jednu bránu a pak sledujte stejný pokus ve všech čtyřech bodech. Spusťte ladění na straně RADIUSu — freeradius -X vypíše požadavek a každý modul, kterého se dotkne — sledujte autentizační log brány a spusťte tcpdump pro UDP výměnu. Připojte se jednou a přečtěte čtyři stopy v pořadí.

Chcete vidět souhlas: brána se ptala na uživatele, kterého jste očekávali, RADIUS server zvolil backend, který jste očekávali, tento backend vrátil rozhodnutí a atributy v odpovědi odpovídají zásadě, kterou brána uplatňuje. První místo, kde se stopy rozcházejí, je vaše linie poruchy. Pokud odpověď nenese atribut skupiny, problém je na straně RADIUSu, ne ve VPN profilu; pokud atribut existuje a brána ho ignoruje, problém je v zásadě brány.

Jedna bezpečnostní poznámka, dokud jste tam. Sdílené tajemství chrání výměnu, ale nešifruje většinu atributů. Pokud brána a RADIUS server leží v různých segmentech, dejte tento skok na RADIUS přes TLS nebo soukromou cestu. Šifrovaný uživatelský tunel nic neříká o propojení k backendu.

Než tiket zavřete, potvrďte čtyři věci. Brána dosáhne na RADIUS server na portu, pro který je skutečně nakonfigurována. Sdílené tajemství na obou stranách souhlasí. RADIUS server resolvuje přesný tvar uživatelského jména, který brána posílá. Přijetí nese atributy, které zásada brány potřebuje. Když platí všechny čtyři, přihlášení, které stále selhává, je problém zásady brány, ne autentizace.