Вход и выход, когда другой пользователь разблокирует ранее заблокированный компьютер - как это работает?

Я наблюдал довольно любопытное поведение Windows 7 на некоторых наших офисных ПК:

Пользователь А входит в свою учетную запись как обычно.
Пользователь A блокирует ПК (через Win + L или аналогичный).
Пользователь B (не имеет значения, кто, это просто кто-то с другой учетной записью пользователя) затем регистрируется на том же ПК со своими учетными данными (либо непосредственно на ПК, либо на удаленном компьютере).
Пользователь B снова выходит из системы.
Сразу после отображения экрана «выход из системы» сеанс пользователя А разблокируется, не требуя пароля пользователя А.

Этот точный шаблон работает, как представлено на всех затронутых ПК с произвольными комбинациями учетных записей пользователей. Я слышал, как наш администратор упоминал, что он даже работает, чтобы разблокировать учетные записи администраторов, если они когда-нибудь останутся подключенными к нужному ПК. Однако он не работает на серии новых компьютеров, которые мы недавно приобрели для нашей команды.

Известно ли это «явление»? Я не смог найти отчеты о похожем поведении через Google, поэтому я предполагаю, что это должно быть что-то специфическое для нашей офисной среды. Какой недостаток в конфигурации Windows 7 может привести к такому поведению?

Немного предыстории:

Наши ПК работают под управлением Windows 7 Professional, 64bit. SP1 установлен. Обновления безопасности, кажется, применяются регулярно.
Все учетные записи пользователей являются учетными записями домена.
Я проинформировал одного из наших администраторов об этой особенности несколько месяцев назад, но, поскольку поведение сохраняется, я постараюсь представить проблему более неотложным образом (и на этот раз обязательно включу ответственного за ИТ-безопасность).
Я знаю, что это имеет некоторые последствия в отношении информационной безопасности. (Это позволяет олицетворять себя, получать доступ к сетевым дискам с ограниченным доступом и т. Д.). Но, по крайней мере, на моем ПК это серьезно портит мои настройки окон, поэтому маловероятно, что кто-то воспользуется им без того, чтобы я потом не заметил. Я уверен, что единственная причина, по которой он еще не решен, заключается в том, что не было (известных) случаев злоупотреблений. Кроме того, он требует физического доступа к соответствующему ПК для использования.
Я просто пользователь без повышенных привилегий. Я постараюсь предоставить любую информацию, которая потребуется (если таковая имеется), но, скорее всего, рано или поздно достигнет какого-то ограничения.
Также я хотел бы извиниться, если моя терминология относительно системного администрирования выключена - я не профессионал. Пожалуйста, дайте мне знать, если я могу улучшить свою формулировку где-нибудь.

Вкладка входа в систему автозапуска (записи Microsoft скрыты): затемненный раздел представляет собой сценарий, который отображает сетевые диски в зависимости от того, кто входит в систему. Вкладка автозапуска Winlogon (есть только записи Windows):

windows-7

— Inarion
источник

Я действительно подозреваю, что это вызвано локальной модификацией, что ваша новая партия ПК еще не пострадала. (Я не помню никаких новостных статей, избивающих Microsoft за эту конкретную проблему ...)

— user1686

Это наиболее определенно вызвано сторонней программой. Это происходит с локальными учетными записями пользователей? В безопасном режиме? Используйте автозапуск, чтобы отключить все приложения автозагрузки не от Microsoft и проверить поведение (будьте осторожны с драйверами и службами, хотя, скорее всего, именно это может быть причиной).

— Я говорю Восстановить Монику

Также 1) в автозапуске, что на Winlogonвкладке? Пожалуйста, опубликуйте снимок экрана этой вкладки, если это возможно. 2) Каковы данные значения LastLoggedOnProvider в ключе после возникновения проблемыHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\# ? (Где #номер сеанса, который может быть больше, чем один.)

— Я говорю Восстановить Монику

@TwistyImpersonator Autoruns, похоже, я тоже захочу использовать это на своем персональном компьютере - довольно изящно! 1) На вкладке входа есть куча записей, ни одна из которых не выглядит мне подозрительно. Добавлю скриншот к моему вопросу. 2) Все ключи показывают одинаковое значение для LastLoggedOnProvider , однако только первый ключ показывает мое имя пользователя в LoggedOnUsername, тогда как все остальные имеют имя моего коллеги (того, с кем я проводил тесты).

— Инарион

@TwistyImpersonator Относительно локальных учетных записей: мне все еще нужно проверить это. Я не могу ничего отключить, кроме записей в HKCU, так как мне не хватает прав для этого. Придется заставить наших айтишников сделать это.

— Инарион

Ответы:

Это разработано.

Обратитесь к Интерактивный вход в систему: Требовать проверки подлинности контроллера домена, чтобы разблокировать рабочую станцию

Это параметр безопасности, который, по сути, если он не включен, позволяет пользователю входить в систему без проверки на контроллере домена.

В вашем случае пользователь A был проверен и был кэширован. Пользователь B был проверен, и когда пользователь A вернулся, он использовал кэшированный. Если этот параметр установлен, он должен потребовать повторной аутентификации на контроллере домена, поэтому есть недостаток. Если у вас есть, скажем, ноутбук и вы потеряли сетевое соединение, как вы подключаетесь к контроллеру домена для разблокировки. Следовательно, это может быть «опасный» параметр.

— todd_placher
источник

Спасибо, ссылка была полезна для моего общего понимания. Однако ни ваша ссылка, ни связанные результаты Google не указывают на то, что кэшированные учетные данные будут использоваться для автоматической аутентификации пользователя (ввод пароля не требуется). Насколько я понимаю, даже локально кэшированные учетные данные служат только для сравнения того, что пользователь вводит при входе в систему. Поэтому теоретически не должно существовать сценария, когда пользователь B может войти в систему как пользователь A, независимо от того, были ли у пользователя A его учетные данные. кэшируются. Все же это все еще происходит.

— Инарион,

Достаточно интересно, что ваш комментарий вызвал удивление о том, что отличается в различных методологиях входа в систему, используемых в Windows: для Windows 10 он был заменен интеграцией провайдера учетных данных Microsoft Windows, что делает более глубокое погружение, в котором вы найдете перечисление

— CREDENTIAL_PROVIDER_USAGE_SCENARIO

Примечания. Начиная с Windows 10, пользовательские сценарии CPUS_LOGON и CPUS_UNLOCK_WORKSTATION были объединены. Это позволяет системе поддерживать вход нескольких пользователей в машину без необходимости создавать и переключать сеансы. Любой пользователь на машине может войти в нее, как только она будет заблокирована, без необходимости выходить из текущего сеанса и создавать новый. Из-за этого CPUS_LOGON может использоваться как для входа в систему, так и когда рабочая станция разблокирована.

— todd_placher

Это не правильно. OP испытывает случай, когда ранее вошедшая в систему, но заблокированная учетная запись становится разблокированной без предоставления пользователем своих учетных данных . Ссылочный параметр GPO, на который вы ссылаетесь, управляет поведением Windows, когда предоставляются учетные данные ... но эти учетные данные должны быть предоставлены, чтобы сеанс входа в систему был разблокирован.

— Я говорю Восстановить Монику

Так что, похоже, наши ИТ-парни нашли проблему. На всех наших ПК, будь то Dell или HP, установлен HP Remote Graphics Sender (версия 6.0.3 для моего ПК). Отключение соответствующей службы немедленно останавливает оскорбительное поведение.

Что касается того, почему этот конкретный сервис включал такого рода неслыханное поведение в Windows: мы не знаем. Мы совершенно невежественны.
Скорее всего, мы не будем выделять больше ресурсов на эту проблему, поскольку нам не нужна служба Sender (только с использованием Receiver). Поэтому я могу только предположить, что проблема может быть вызвана какой-то несовместимостью программного обеспечения HP и наших компьютеров марки Dell. (Большинство затронутых ПК были от Dell, хотя пара - старше? - компьютеры HP тоже плохо себя вели, так что это не полная история.)

Все вещи, рассматриваемые в целом, остаются загадочно неудовлетворительно, но, к сожалению, я не в состоянии продолжить расследование этого вопроса - как с точки зрения финансирования, так и с точки зрения привилегий.

— Inarion
источник