Доверието на домейна се счупи след месец офлайн? Проверете първо

Лаптоп остава шест седмици извън VPN, връща се и потребителят не може да влезе с домейн акаунт. Грешката споменава отношение на доверие, затова някой нулира компютърния акаунт или принуждава потребителя на пълно тунелиране, и проблемът сякаш изчезва. Нито едно от двете действия не доказа какво е било счупено. Член на Windows може да остане офлайн значително след обичайния интервал за парола на машината, без автоматично да загуби доверие, така че първата задача е да се раздели отказ на достъпност от истинско несъответствие на тайна.

Грешката изглежда като доверие, но три състояния си приличат

Потребителят може да влезе с кеширана домейн информация, работната станция може да не намери контролер на домейн или членът и домейнът наистина да не са съгласни за компютърния акаунт. Само третото е нарушено отношение на доверие в строгия смисъл.

Състоянието на репликацията на AD е четвърто наблюдение и то изобщо не е за тази работна станция. То описва съгласие между контролерите на домейн и здраво табло за репликация не доказва, че локалната тайна на тази машина съвпада с компютърния ѝ акаунт.

Познатият подразбиращ се срок от 30 дни е политика за смяна, а не краен срок за изтичане офлайн. Обяснението на Microsoft за паролата на компютърния акаунт описва координиран процес на смяна и организацията може да настрои различен интервал.

Иконата на VPN не доказва нищо за защитения канал

Свързаността трябва да е достатъчно добра, за да достигне домейн услугите, преди който и да е тест да значи нещо. Това означава предвиденият DNS резолвер на домейна, откриваем контролер, достъпни услуги за удостоверяване и часовник, достатъчно близък за Kerberos.

Пълното тунелиране може да е напълно валиден дизайн тук. Преминаването към разделено тунелиране не е предпоставка за здрава домейн връзка и третирането му като такава превръща диагнозата в промяна на архитектурата. Проверете кой контролер всъщност избира работната станция и запазете това име заедно с грешката.

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

Запишете DNS сървъра, разрешения контролер и точния текст на грешката. VPN клиент, който съобщава, че е свързан, ви казва, че тунелът съществува, а не че домейн пътят работи. Контролер, който отговаря на порта на Kerberos, но не на порта на директорията, е находка за защитна стена, а не находка за доверие.

Тествайте члена, преди да го поправите

На оторизиран член на домейн Windows Test-ComputerSecureChannel -Verbose е проверка само за четене на канала между машината и домейна. Изпълнете я в контекста на машината, която изследвате, а не от контролер на домейн, който има друга роля и други правила за възстановяване. Запишете изхода и кода за изход, а не думата успех или неуспех. Ако командлетът липсва в тази сборка, модулът е отделен проблем.

Резултатът все още се нуждае от контекст. Ако машината не може да достигне или да се удостовери пред избрания контролер, неуспешният тест не е независимо доказателство, че офлайн парола е изтекла. Запазете действителната грешка и използвания контролер и повторете теста, след като пътят е известен като добър.

Корелирайте събитията на Netlogon на члена и на съответния контролер около инцидента. Запазете името на машината, адреса на източника, времето и всякакви доказателства за промяна на акаунта. Успешният вход на друг потребител или здраво табло на контролера не могат да заменят обмена на тази машина.

Поправете само връзката, която доказахте

След като свързаността е стабилна и администратор е потвърдил, че поправка е уместна, режимът -Repair на командлета с оторизирани идентификационни данни е една поддържана операция за работна станция член. Той променя връзката и не е още един тест само за четене.

Преди промяната дръжте на разположение одобрен локален акаунт за възстановяване и път за управление. Контролерите на домейн имат различна роля за възстановяване и не трябва да се третират като обикновени работни станции от тази процедура. Използвайте работния процес за възстановяване на организацията, вместо да пускате няколко инструмента за нулиране последователно и да се надявате, че един от тях е правилният.

След поправката проверете нов тест на защитения канал и първоначалната домейн операция. Запазете потребителските профили и състоянието на приложенията и не правете премахване и повторно присъединяване първото необяснено действие.

Какво да проверите, когато отказът се върне

Ако отказът се върне, погледнете връщането назад, дублираната идентичност и времето на промените на акаунта, вместо да нулирате същия акаунт отново. Възстановено изображение, моментна снимка, клонирана идентичност на машина или нулиране на компютърен акаунт, извършено другаде, всички заслужават разследване.

Временно успешно нулиране е полезно доказателство за възстановяване, но не е доказателство, че прекъсващ VPN е причинил първоначалното несъответствие. Следващият случай е този, който ще ви каже дали причината някога е била отстранена.

Запишете контролера, DNS сървъра и изхода от теста в тикета. Този запис е това, което различава истински отказ на доверие от лаптоп, който просто не е успял да намери домейна.