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.

Kapcsolódó cikkek