Egy hónap offline után megszakadt a tartományi bizalom? Először ezt ellenőrizze

Egy laptop hat hétig a VPN-en kívül van, visszatér, és a felhasználó nem tud bejelentkezni tartományi fiókkal. A hiba bizalmi kapcsolatot említ, ezért valaki visszaállítja a számítógépfiókot, vagy teljes alagútra kényszeríti a felhasználót, és a probléma látszólag megszűnik. Egyik művelet sem bizonyította, mi tört el. Egy Windows-tag jóval a szokásos gépi jelszóintervallumon túl is offline maradhat anélkül, hogy automatikusan elveszítené a bizalmat, ezért az első feladat az elérhetőségi hiba és a titok valódi eltérése szétválasztása.

A hiba bizalomnak látszik, de három állapot hasonlít

A felhasználó gyorsítótárazott tartományi adatokkal jelentkezhet be, a munkaállomás nem találhat tartományvezérlőt, vagy a tag és a tartomány valóban egyet nem érthet a számítógépfiókról. Csak a harmadik szakadt bizalmi kapcsolat szigorú értelemben.

Az AD-replikáció állapota negyedik megfigyelés, és egyáltalán nem erről a munkaállomásról szól. A tartományvezérlők közötti egyetértést írja le, és egy egészséges replikációs műszerfal nem bizonyítja, hogy ennek a gépnek a helyi titka megegyezik a számítógépfiókjával.

A jól ismert 30 napos alapértelmezés változtatási szabályzat, nem offline lejárati határidő. A Microsoft magyarázata a gépi fiók jelszaváról összehangolt változtatási folyamatot ír le, és a szervezet más intervallumot állíthat be.

Egy VPN-ikon semmit nem bizonyít a biztonságos csatornáról

A kapcsolatnak elég jónak kell lennie a tartományi szolgáltatások eléréséhez, mielőtt bármely teszt bármit jelent. Ez a szándékolt tartományi DNS-feloldót, megtalálható vezérlőt, elérhető hitelesítési szolgáltatásokat és a Kerberoshoz elég közeli órát jelenti.

A teljes alagút itt teljesen érvényes kialakítás lehet. Az osztott alagútra váltás nem előfeltétele az egészséges tartományi kapcsolatnak, és annak tekintése a diagnózist architektúraváltássá alakítja. Ellenőrizze, melyik vezérlőt választja a munkaállomás valójában, és őrizze meg ezt a nevet a hibánál.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Jegyezze fel a DNS-kiszolgálót, a feloldott vezérlőt és a hiba pontos szövegét. Egy kapcsolódott állapotot jelentő VPN-kliens azt mondja, hogy az alagút létezik, nem azt, hogy a tartományi útvonal működik. Az a vezérlő, amely a Kerberos-porton válaszol, de a címtárporton nem, tűzfal-megállapítás, nem bizalmi megállapítás.

Tesztelje a tagot, mielőtt javítja

Egy engedélyezett Windows-tartományi tagon a Test-ComputerSecureChannel -Verbose a gép és a tartomány közötti csatorna csak olvasható ellenőrzése. Abban a gépkörnyezetben futtassa, amelyet vizsgál, ne tartományvezérlőről, amelynek más a szerepe és mások a helyreállítási szabályai. Rögzítse a kimenetet és a kilépési állapotot a sikeres vagy sikertelen szó helyett. Ha a parancsmag hiányzik abból a buildből, a modul külön probléma.

Az eredménynek még mindig kell a környezet. Ha a gép nem éri el vagy nem tud hitelesíteni a kiválasztott vezérlőnél, a sikertelen teszt nem független bizonyítéka annak, hogy egy offline jelszó lejárt. Őrizze meg a tényleges hibát és a használt vezérlőt, és ismételje meg a tesztet, ha az útvonal ismerten jó.

Korrelálja a Netlogon-eseményeket a tagon és az érintett vezérlőn az incidens körül. Őrizze meg a gép nevét, a forrás címet, az időpontot és a fiókváltozás bármely bizonyítékát. Egy másik felhasználó sikeres bejelentkezése vagy egy egészséges vezérlő-műszerfal nem helyettesítheti ennek a gépnek a cseréjét.

Csak azt a kapcsolatot javítsa, amelyet bizonyított

Amint a kapcsolat stabil, és egy rendszergazda megerősítette, hogy a javítás megfelelő, a parancsmag -Repair módja engedélyezett hitelesítő adatokkal egy támogatott művelet tag-munkaállomáson. Megváltoztatja a kapcsolatot, és nem egy újabb csak olvasható teszt.

A változtatás előtt tartson elérhetően egy jóváhagyott helyi helyreállítási fiókot és egy felügyeleti útvonalat. A tartományvezérlőknek más a helyreállítási szerepe, és ez az eljárás nem kezelheti őket közönséges munkaállomásként. Használja a szervezet helyreállítási munkafolyamatát, ahelyett hogy több visszaállító eszközt futtatna egymás után, abban a reményben, hogy az egyik a megfelelő.

A javítás után ellenőrizzen egy friss biztonságos csatorna tesztet és az eredeti tartományi műveletet. Őrizze meg a felhasználói profilokat és az alkalmazások állapotát, és ne tegye az eltávolítás-és-újracsatlakozás az első megmagyarázatlan műveletté.

Mit kell ellenőrizni, amikor a hiba visszatér

Ha a hiba visszatér, nézze a visszaállítást, a kettős identitást és a fiókváltozások időzítését, ahelyett hogy újra visszaállítaná ugyanazt a fiókot. Egy helyreállított lemezkép, egy pillanatkép, egy klónozott gépidentitás vagy egy máshol végrehajtott számítógépfiók-visszaállítás mind vizsgálatot érdemel.

Az átmenetileg sikeres visszaállítás hasznos helyreállítási bizonyíték, de nem bizonyítja, hogy a szakaszos VPN okozta az eredeti eltérést. A következő előfordulás mondja meg, hogy az okot egyáltalán megszüntették-e.

Írja a jegybe a vezérlőt, a DNS-kiszolgálót és a teszt kimenetét. Ez a feljegyzés különbözteti meg a valódi bizalmi hibát attól a laptoptól, amely egyszerűen nem találta a tartományt.