Преносим компютър, работещ профил и хотелска мрежа се събират в цикъл на влизане, който никакво повторение не прекъсва. Профилът е в 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 описва както поведението на проверяващия низ, така и домейн ограниченията, от които зависи този дизайн. Планирайте процеса на възстановяване, преди някой да тръгне на път, защото тестът със студено стартиране е единственото място, където той се упражнява.

Подобни статии