Довербата на доменот падна по еден месец офлајн? Прво проверете

Лаптоп останува шест недели надвор од VPN, се враќа, и корисникот не може да се најави со доменска сметка. Грешката споменува довербен однос, па некој ја ресетира сметката на компјутерот или го принудува корисникот на целосно тунелирање, и проблемот навидум исчезнува. Ниту едно од двете дејства не докажа што било расипано. Член на Windows може да остане офлајн многу подолго од вообичаениот интервал на лозинката на машината без автоматски да ја изгуби довербата, па првата задача е да се оддели неуспехот на достапност од вистинско несовпаѓање на тајната.

Грешката изгледа како доверба, но три состојби личат

Корисникот може да се најави со кеширани доменски информации, работната станица може да не најде контролер на доменот, или членот и доменот навистина да не се согласуваат за сметката на компјутерот. Само третата е скршен однос на доверба во строга смисла.

Здравјето на AD репликацијата е четврто набљудување и воопшто не се однесува на оваа работна станица. То го опишува договорот меѓу контролерите на доменот, а здрава табла за репликација не докажува дека локалната тајна на оваа машина се совпаѓа со нејзината сметка на компјутер.

Познатиот стандард од 30 дена е политика на промена, не рок за истек офлајн. Објаснувањето на Microsoft за лозинката на сметката на машината опишува координиран процес на промена, и организацијата може да конфигурира различен интервал.

Иконата за VPN не докажува ништо за безбедниот канал

Поврзаноста мора да биде доволно добра за да стигне до доменските услуги пред било кој тест да значи нешто. Тоа значи предвидениот DNS резолвер на доменот, контролер што може да се најде, достапни услуги за автентикација и часовник доволно близу за Kerberos.

Целосното тунелирање може да биде сосема валиден дизајн овде. Преминот кон поделено тунелирање не е предуслов за здрав однос со доменот, и неговото третирање како таков ја претвора дијагнозата во промена на архитектурата. Проверете кој контролер работната станица навистина го избира, и зачувајте го тоа име со грешката.

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

Запишете го DNS серверот, резолвираниот контролер и точниот текст на грешката. VPN клиент што пријавува поврзаност ви кажува дека тунелот постои, не дека патеката до доменот работи. Контролер што одговара на портата Kerberos, но не на портата за директориум, е наод за огнен ѕид, не наод за доверба.

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

На авторизиран член на Windows домен, Test-ComputerSecureChannel -Verbose е проверка само за читање на каналот меѓу машината и доменот. Извршете ја во контекстот на машината што ја истражувате, не од контролер на доменот, кој има друга улога и други правила за опоравување. Забележете го излезот и излезниот статус наместо зборот помина или падна. Ако cmdlet недостасува во тој build, модулот е одделен проблем.

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

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

Поправете го само односот што сте го докажале

Кога поврзаноста е стабилна и администраторот потврдил дека поправката е соодветна, режимот -Repair на cmdlet со авторизирани акредитиви е една поддржана операција за работна станица член. Тој го менува односот, и не е уште еден тест само за читање.

Пред промената држете достапна одобрена локална сметка за опоравување и патека за управување. Контролерите на доменот имаат друга улога за опоравување и оваа постапка не смее да ги третира како обични работни станици. Користете го работниот тек за опоравување на организацијата наместо да извршите неколку алатки за ресетирање по ред и да се надевате дека една од нив е вистинската.

По поправката, потврдете нов тест на безбедниот канал и првобитната доменска операција. Зачувајте ги корисничките профили и состојбата на апликациите, и не правете отстранување-и-повторно-придружување прво необјаснето дејство.

Што да проверите кога неуспехот ќе се врати

Ако неуспехот се врати, погледнете го враќањето назад, дупликат идентитетот и времето на промените на сметката наместо повторно да ја ресетирате истата сметка. Обновена слика, снимка, клониран идентитет на машина или ресетирање на сметка на компјутер извршено на друго место — сите заслужуваат истрага.

Привремено успешно ресетирање е корисен доказ за опоравување, но не е доказ дека повремениот VPN ја предизвикал првобитната неусогласеност. Следната појава е таа што ќе ви каже дали причината некогаш била отстранета.

Запишете ги контролерот, DNS серверот и излезот од тестот во тикетот. Токму тој запис разликува вистински неуспех на довербата од лаптоп што едноставно не можел да го најде доменот.