Kterou adresu registrujete jako klienta RADIUS pro NPS?

Brána VPN, která předává ověřování Windows NPS, potřebuje na straně NPS jeden objekt, než může fungovat jakákoli uživatelská politika: záznam klienta RADIUS pro bránu. Většina neúspěšných pokusů registruje špatnou adresu, protože důležitá je adresa, kterou brána používá na své backendové cestě, ne název hostitele, který zaměstnanci zadávají do své aplikace VPN. Pokud tuto hodnotu zadáte špatně, NPS požadavek tiše zahodí, což na straně klienta vypadá jako špatné heslo. O tom, která adresa do pole patří, rozhodují tři podmínky, tak si je vyřešte dřív, než otevřete konzolu.

Registrujte bránu, ne notebooky ani fond

Objekt klienta RADIUS představuje zařízení pro síťový přístup, které odesílá žádosti o ověření. To je brána VPN, ne každý notebook, na kterém běží klient, a ne rozsah adres přidělovaných uvnitř tunelů.

Tyto adresy tunelů se nikdy neobjeví jako zdroj požadavku RADIUS, protože požadavek putuje vlastní síťovou cestou brány. Registrace záznamu fondu klientů vytvoří politiku, která nikdy nemůže odpovídat, zatímco skutečný požadavek přichází z adresy, o které NPS nikdy neslyšel. Stejný zmatek vede k tomu, že lidé přidávají domácí IP každého zaměstnance, což je zároveň neudržovatelné i špatné.

O adrese, kterou zadáváte, rozhodují tři podmínky

Nejprve najděte zdrojovou adresu, kterou brána skutečně používá směrem k NPS. Brána s více rozhraními často odesílá z řídicího nebo backendového rozhraní, ne ze svého veřejného VPN posluchače. Za druhé zkontrolujte, zda je mezi nimi NAT: pokud se požadavek překládá, NPS vidí přeloženou adresu a to je hodnota, kterou je třeba registrovat. Za třetí, pokud dvě brány sdílejí roli, každý zdroj požadavků potřebuje vlastní záznam klienta, protože jeden objekt s jednou adresou pokrývá jen jeden z nich.

Záznam se dvěma konci drží dvojici v pořádku. Tabulka níže používá soukromé adresy pro ilustraci, tak je nahraďte těmi, které vaše cesta skutečně používá.

Zdroj potvrďte, místo abyste ho hádali. Během jednoho pokusu sledujte protokol NPS nebo firewallu, nebo zachyťte na hostiteli NPS pomocí sudo tcpdump -ni any udp port 1812. Adresa v tomto zachycení je jediná obhajitelná odpověď pro záznam klienta. Pokud má brána několik možných zdrojů, zaregistrujte každý pod jeho vlastním přátelským názvem.

Sdílený klíč je hodnota mezi bránou a NPS

Sdílený klíč ověřuje vztah zařízení. Není to uživatelské heslo a nikdy se nerozdává zaměstnancům ani nevkládá do profilů klientů.

Zvolte jednu hodnotu, zadejte ji na obou místech a uložte ji tam, kde žije záloha konfigurace brány. Neshoda vytvoří požadavek, který NPS zahodí bez užitečné chyby, což v protokolu brány nelze odlišit od nedostupného serveru. Otáčejte ji v okně údržby a aktualizujte oba konce v téže změně.

Potvrďte jedním povoleným požadavkem

Použijte řízený účet a spojte jeden pokus na obou stranách. Na bráně potvrďte, že požadavek odešel zamýšlenému serveru; v NPS potvrďte, že dorazil z registrovaného klienta a odpovídal očekávané politice požadavků na připojení. Vypršení a odmítnutí znamenají různé věci a léčba obojího jako problému s přihlašovacími údaji ztrácí další hodinu. Potom otestujte platný, ale nezpůsobilý účet a špatné heslo, protože politika, která přijímá všechno, projde i prvním testem.

Nakonec zkontrolujte, co brána dělá s vráceným oprávněním. Registrace klienta RADIUS jen umožňuje zařízení účastnit se; nedává každé vzniklé relaci přístup do LAN.

Udržujte diagnostický výstup omezený: žádné sdílené klíče, žádná uživatelská hesla, žádné úplné obsahy paketů v tiketu podpory. Pokud návrh vyžaduje, aby server NPS četl atributy adresáře, je toto oprávnění samostatný administrativní úkol od registrace klienta a když chybí, selhává jinak.