Forgassa át a helyi VPN-fiókot anélkül, hogy elveszítené az engedélyeit
A helyi VPN-fiókok olyan jogosultságot hordoznak, amelyet a törlés és újralétrehozás kitöröl. Hasonlítsa össze a helyben forgatást az újraépítéssel, majd ellenőrizze, mit tud a CHAP valójában hashelni.
Egy működő VPN-jelszó cseréje két soros változásnak tűnik, amíg az újraépített fiók nem tér vissza alapértelmezett engedélyekkel, és az egyetlen felügyeleti munkamenet el nem tűnt. A biztonságos eljárás attól függ, hol van tárolva a hitelesítő adat és melyik protokoll használja, nem attól, melyik parancs a legrövidebb. Hasonlítsa össze a két megközelítést, mielőtt hozzányúl az eszközhöz. A helyben forgatás megőrzi a fiókobjektumot; a törlés és újralétrehozás lecseréli, és minden, ami rá mutatott, vele megy.
Derítse ki, melyik tároló hitelesíti valójában a munkamenetet
Az alagút- vagy kapcsolatprofilnál kezdje, ne a felhasználói adatbázisnál. A profil megnevez egy hitelesítési módszert és gyakran egy kiszolgálócsoportot, és ha ez a csoport RADIUS-ra vagy TACACS+-ra mutat, az eszközön lévő helyi felhasználónév csupán díszítés. Olvassa el a profil hitelesítési listáját és a hivatkozott AAA-csoportot, mielőtt bármit tervezne. Csak akkor számít az eszközön lévő fiók, ha a profil helyit mond. Ha ezt elhibázza, olyan hitelesítő adatot forgat át, amelyet senki sem használ, miközben a valódi címtárbejegyzés pontosan úgy marad, ahogy volt.
Ugyanaz az eszköz általában két populációt tart: a beléje bejelentkező adminisztrátorokat és az alagutat lezáró VPN-felhasználókat. Megoszthatnak egy tárolót, és nem kell feltételezni, hogy megteszik.
Helyben frissítés szemben a törléssel és újralétrehozással
A helyben forgatás egy meglévő objektum egyetlen attribútumát változtatja meg. A jogosultsági szint, a csoporttagság, az engedélyezési attribútumok és minden házirend, amely a fiókra hivatkozik, túléli, mert semmit sem távolítottak el. A törlés és újralétrehozás parancssorból építi újra az objektumot, így minden mező, amelyet nem ismételt meg, visszatér az alapértékére. Azon az eszközön, ahol a felhasználónkénti attribútumok osztott alagút- vagy címkészlet-hozzárendeléseket hordoznak, ez a különbség a teljes kockázat.
Az újraépítésnek egyetlen jogos indoka van: amikor magát a tárolt formátumot kell megváltoztatni, és a platform nem kínál átalakítást. Még akkor is először rögzítse a meglévő bejegyzést, mert a futó konfiguráció az egyetlen pontos leltár arról, mit hordozott a fiók. A változás előtt készített másolat erről a konfigurációról jobb, mint az emlékezetből írt visszaállítási terv.
Miért lehet, hogy a rendelkezésére álló hash nem az a titok, amelyre szüksége van
A tárolási formátumok olyan módon különböznek, amely eldönti a választ. Az egyirányú hash ellenőrizni tud egy jelszót, amikor a kiszolgáló tisztán kapja meg az alagúton belül, de a kihívás-válasz módszernek magára a közös titokra van szüksége az összefoglaló kiszámításához. Ezért ha minden fiókot a legerősebb egyirányú formátumra alakítanak, az éppen azoknak a felhasználóknak törheti el a CHAP-ot vagy az MS-CHAP-ot, akik függnek tőle.
Protokoll szerint döntsön, ne szlogen szerint. Ahol a módszer visszanyerhető titkot igényel, az a követelmény a tervezés korlátja, és nem tisztogatandó mulasztás.
A hitelesítő adatot túlélő munkamenetek
Egy hitelesítő adat megváltoztatása nem szünteti meg a már hitelesített munkameneteket. A felépített alagúttal rendelkező partner a kulcsfrissítésig, az újrahitelesítésig vagy a kifejezett bontásig tovább működik.
Ezt a részt külön tervezze meg, és a változás előtt tervezze meg. Ha a hitelesítő adat kiszivárgott, az élő munkamenetek meghagyása meghiúsítja a forgatást. Ha csak elévült, minden partner offline kényszerítése olyan kiesés, amelyre nem volt szüksége. Tartson nyitva egy második felügyeleti útvonalat a munka közben, lehetőleg olyat, amely nem a szerkesztett fióktól függ, mert az itteni hibaállapot pontosan akkor veszi el a hozzáférését, amikor szüksége van rá. Utána ellenőrizze az új bejelentkezést és az elérhető erőforrásokat.
Bizonyítsa, hogy az engedélyek túlélték
Jelentkezzen be az átforgatott felhasználóként, és ellenőrizze, mit ad a munkamenet, ne csak azt, hogy megnyílt. Érjen el egy erőforrást, amely megköveteli a fióknak hordoznia kellő jogosultságot, és próbáljon meg egyet, amelyet nem lenne szabad elérnie. A sikeres bejelentkezés szűkített vagy kiterjesztett hozzáféréssel sikertelen változás.
Hasonlítsa össze a futó konfiguráció engedélyezési attribútumait az elején vett másolattal. Nézze meg a csoporttagságot, a címkészletet, a DNS- és osztott alagút beállításait, és minden olyan házirend-objektumot, amely megnevezte a fiókot. Ezután frissítse annak nyilvántartását, hol él ez a hitelesítő adat, mert a következő forgatás abból a feljegyzésből indul. Az a forgatás, amelyet senki sem tud a dokumentációból megismételni, csak egyszer élte túl.