Зашто је преносном рачунару са Protected Users потребан VPN пре пријаве

Преносни рачунар, радни налог и хотелска мрежа заједно дају петљу пријаве коју ниједно поновно покушавање не прекида. Налог је у Protected Users, што спречава Windows да сачува верификатор који би му требао за проверу корисника без везе. Сваки план облика „прво се пријавите, па затим повежите тунел“ има обрнут редослед, а заштита ради управо оно што обећава. Оно што следи претпоставља традиционални Active Directory налог на подржаном Windows домаћину.

Шта заштита заправо уклања

Windows обично кешира верификатор како би се налог домена могао пријавити док је контролер домена недоступан. Protected Users то блокира за налог, чиме уклања пријаву у домен без везе као могућност, уместо да је учини непоузданом.

Ово није уобичајени проблем са застарелим кешом и уобичајена средства се не примењују. Поновна мрежна пријава, још једна промена лозинке или повећање броја кешираних пријава неће вратити способност, јер ниједна од тих радњи не ствара верификатор који политика одбија да сачува. Налог се понаша како је дизајниран, а дизајн претпоставља да је мрежа присутна кад Windows пита. Третирање симптома као квара кеша је начин на који тимови обнављају профил који никада није био покварен.

Зашто тунел мора да постоји пре радне површине

Уређај мора да дође до аутентификације домена у тренутку кад Windows то затражи, а то је пре него што постоји икаква корисничка сесија. VPN клијент који се покреће тек након што се појави радна површина оставља нову пријаву да чека пут који никада не долази. Зависност припада машини, не кориснику који се још није пријавио.

Користите подржани аранжман пријаве пре пријаве договорен са власницима крајњих тачака и идентитета. Тунел уређаја Always On VPN аутентификован сертификатом рачунара задовољава услов када управљани уређај испуњава предуслове тог распоређивања. Подржана интеграција добављача са екраном за пријаву је друга опција. Обичан кориснички профил са аутоматским окидачем није ни једно ни друго, колико год слично изгледало у сучељу клијента.

Том путу треба разрешавање имена за домен, доступан контролер домена и протоколи аутентификације које налог сме да користи, а ништа од тога не пружа индикатор „повезано“. Његове руте и филтери треба да носе услуге идентитета и ништа друго што није потребно, јер је та листа префикса површина коју украдени преносни рачунар добија пре него што се ико пријави. Одлуке о подељеном тунелу донете за кориснички тунел не преносе се на тунел уређаја, па их прегледајте одвојено.

Доступност није компатибилност аутентификације

Тунел може беспрекорно да преноси пакете док аутентификација домена не успева, јер је механизам који се покушава онај који налог не сме да користи. У домену који спроводи ограничења групе, NTLM није доступан члановима, а Kerberos захтева налог и конфигурацију компатибилне са AES-ом. Пут пакета не може да поправи ни једно од тога. Зато чист ping до контролера домена није доказ да ће пријава радити.

Могу бити у игри и два система акредитива. VPN може да се аутентификује код пружаоца идентитета док Windows одвојено треба пријаву у домен, а прихватање првог не говори ништа о другом. „VPN се повезао“ и „корисник је пријављен“ су одвојена запажања, и поправка једног не подразумева друго.

Прочитајте доказе аутентификације

Прикупљајте догађаје са клијента и са контролера домена за исти покушај, а не само са једне стране. Записи Protected Users налазе се под Applications and Services Logs\Microsoft\Windows\Authentication, а администратор можда мора да укључи запис пре него што он ишта забележи. Повежите временске ознаке са сопственим записом везе тунела, јер грешка у редоследу изгледа као квар акредитива са обе стране.

Прва наредба испод наводи сваки запис аутентификације који уређај излаже, па читате онај који постоји, а не онај који је навео неки блог пост. Друга чита недавне уносе кад знате име. Тражите пакет аутентификације, налог и услов неуспеха, јер недостајући мрежни пут и одбијени механизам остављају различите доказе и само је један од њих VPN проблем. Ако се тунел подигао након покушаја, редослед је био погрешан ма шта ти уноси говорили.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Докажите границу из хладног подизања

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

1. Потврдите да уређај може да нађе контролер домена пре него што се ико пријави, помоћу nltest /dsgetdc:corp.example.com.
2. Покушајте пријаву у домен, па питајте да ли је уопште добијена карта, помоћу klist.
3. Прочитајте запис аутентификације који уређај бележи, двема наредбама изнад, и забележите пакет и услов неуспеха.
4. Потврдите да одобрени резервни акредитив још ради са екрана за пријаву, јер је то једини пут назад ако тест границе не успе.

Отварање мрежног дела са достављеним акредитивима такође не ствара интерактивну пријаву без везе, па не замењује ниједан корак изнад. Ако организацији заиста треба пријава без везе, одговор је компатибилан дизајн налога и крајње тачке одабран намерно. Уклањање налога из групе или држање једне неограничене хитне пријаве на сваком преносном рачунару одлука је политике идентитета коју промена VPN-а не може да донесе уместо вас.

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