VPN certifikát na Macu: který účet brána vidí?

Profil zobrazuje vaše jméno, viditelný štítek certifikátu říká něco jiného a protokol brány zaznamenává třetí identifikátor. Žádný z nich nelže a právě v tom je problém: tři různá pole se čtou, jako by odpovídala na jednu otázku. Spojení předkládá pověření, identifikátor IKEv2 a účet a brána rozhoduje, které z nich co opravňuje.

Tři identity v jednom spojení

Viditelné jméno profilu je štítek pro lidi. Vybere spojení a nic víc. Certifikát je pověření a to, zda může něco prokázat, závisí na tom, zda klient drží odpovídající soukromý klíč. Pole účtu je tvrzení o principálovi a server je může namapovat na jinou místní identitu.

Když ověření selže, ptejte se, na které ze tří se chyba vztahuje. Odmítnuté pověření, neznámý identifikátor a deaktivovaný účet vytvářejí různé zprávy a jejich sloučení do jednoho „problému s certifikátem“ vás pošle do špatné konzole.

Čtěte nativní pole podle jejich úlohy

Ve spravované nativní konfiguraci IKEv2 odděluje reference datové zátěže od Apple hodnoty a metoda ověření určuje, která kombinace je nutná:

Certifikát a přihlášení EAP mohou mít v témže spojení různé role. Nenuťte každé pole držet stejný text jen proto, že to dělá jedno z nich, a nepředpokládejte, že změna jednoho přebije ostatní. VPN aplikace třetí strany může nabízet úplně jiný model; použijte její dokumentovaný výběr identity místo přenášení nativních názvů polí.

Certifikát serveru není identita klienta

Certifikát, který ověřuje bránu, je kotva důvěry. Dokazuje, že jste dosáhli serveru, který jste očekávali. Identita klienta je jiný objekt: zahrnuje přístup k soukromému klíči, který dokazuje, že připojující se strana je tím, za co se vydává. Přejmenování viditelného účtu nemůže jedno proměnit v druhé.

Tady se dobře míněná oprava pokazí. Import certifikátu CA brány do úložiště klienta nic neudělá pro ověření klienta a označení tohoto záznamu jménem uživatele z něj neudělá identitu uživatele. Oba objekty žijí v různých částech profilu a odpovídají na různé otázky.

Sledujte principála až k mapování na bráně

Potvrďte, k čemu bylo pověření vydáno: tomuto uživateli, tomuto zařízení, nebo sdílené roli. Přihlašovací účet Macu není automaticky oním principálem a certifikát zkopírovaný z jiného stroje si zachovává identitu stroje, pro který byl vydán.

Poté porovnejte skutečné pověření, ne štítek. Vydavatel, sériové číslo a otisk prstu vám i správci umožní potvrdit, že mluvíte o stejném objektu. Zobrazovaná jména lze upravovat a často se duplikují, což z nich dělá nejhorší možný identifikátor během incidentu.

Poslední krok je na bráně. Požádejte jejího vlastníka, aby spojil jedno připojení s předloženými identifikátory a s pravidlem mapování účtů, které je spotřebovalo. Štítek na straně klienta nemůže určit, co server rozhodl, a pravidlo, které mapuje certifikát na deaktivovaný účet, bude selhávat, i když všechna pole na straně klienta vypadají správně.

Opravte vrstvu, která nesoulad vlastní

Pokud profil ukazuje na špatné pověření, opravte jeho referenci nebo výběr. Pokud pověření patří jinému principálovi, projděte opětovnou registrací u vydavatele místo úprav štítků. Pokud brána sváže platné pověření se špatným účtem, její vlastník politiky musí opravit mapování. To jsou tři různé změny se třemi různými schvalovateli.

Obnova si zaslouží stejnou péči. Výměna certifikátu, přejmenování jeho viditelného štítku a přesun osoby mezi systémy účtů nemusí ovlivnit mapování stejným způsobem. Zaznamenejte, kterou ze tří věcí jste změnili, protože příští selhání bude z pohledu klienta vypadat stejně a v protokolu brány jinak.

Sdílejte jen minimální veřejné identifikátory, které podpora potřebuje. Soukromý klíč nebo celý balík identity nikdy není součástí této výměny, ať by to diagnózu jakkoli usnadnilo.