Как программно взаимодействовать с Winlogon?

Просто при прохождении ... Но разве среди примеров Microsoft нет поставщика учетных данных, который принимает асинхронный ввод? Я определенно написал такую, которая регистрирует пользователя, который сканирует приемлемый отпечаток пальца, независимо от того, какая плитка отображается. Для меня это означает, что взаимодействие с LogonUI должно быть не более чем неявным, но, возможно, я что-то упускаю.

Но, возможно, нет. Хотя я не сомневаюсь, что намерение состоит в том, что асинхронный ввод будет исходить от пользователя, действующего на оборудовании, как при сканировании пальца, я обычно не вспоминаю об этом. Если это не так, тогда у вас может быть свой программный вариант в виде представления учетных данных, как если бы они были собраны асинхронно - не с устройства, которое явно подключено к компьютеру, а с вашего побочного канала HTTP, неизвестно что.

Итак, можете ли вы сделать так, чтобы провайдер учетных данных прослушивал RPC от вашей службы для уведомления об учетных данных, которые ваша служба собрала через свой побочный канал? Или пусть ваша служба прослушивает RPC от вашего поставщика учетных данных, чтобы узнать, какие учетные данные еще доступны? Возможно, я не удивлюсь, если одно направление будет закрыто - даже из соображений безопасности - но я подумал, что одно или другое можно заставить работать.

Стоит ли вам хотеть что-то из этого, я не хочу вдаваться в подробности.

Не то чтобы я потворствовал этому, но просто предлагаю вам решение проблемы. И он не взаимодействует программно с процессом WinLogon. Он программно работает над этим.

Используйте свойство Windows Autologin. И перезагрузитесь, чтобы перейти к этому пользователю. Обратите внимание, что это требует сохранения пароля в реестре в виде открытого текста.

Специально установите эти regkeys

HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ AutoAdminLogin HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ DefaultUserName HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon \ DefaultPassword

* Изменить *

Помогает с 4. Не помогает с 4.1. Если вы не хотите перезагрузиться, чтобы разблокировать, в чем я сомневаюсь.

Другая альтернатива, которая звучит многообещающе \ заслуживает изучения, упоминается в более старом вопросе https://stackoverflow.com/a/35173886/4640588

Я написал для этого коммерческое решение под названием SasLibEx. SasLibEx - это библиотека, предназначенная для разработчиков, изначально поддерживающая c / c ++ и delphi.

SasLibEx умеет:

• Имитация Ctrl Alt Del (последовательность безопасного внимания)
• Отмена Ctrl Alt Del
• Заблокировать рабочую станцию
• Разблокировать рабочую станцию ​​(без учетных данных)
• Отключить Ctrl Alt Del
• Снова включить Ctrl Alt Del
• Отменить ожидающий запрос UAC
• Рабочий стол заблокирован

См. https://www.remkoweijnen.nl/blog/tag/saslibex/.

У меня были почти те же требования к фреймворку на основе селена, который я создаю. Короче говоря, мне нужно было запустить приложение на станции Windows пользователя (WinSTA0), а это означало, что пользователь должен был войти в виртуальную машину.

Я уже создал проект с менеджером учетных данных и использовал его для достижения следующего рабочего процесса:

• Запустите виртуальную машину, скопируйте компоненты с помощью Powershell
• Установите CredManager, перезагрузите виртуальную машину.
• Cred Manager создает случайного пользователя, сохраняет его в базе данных
• Авторизоваться с этим пользователем
• Пользователь имеет автозапуск в реестре приложения, и приложение запускает веб-сервер, с которым можно связаться для запуска сеансов селена.

Если я правильно понимаю ваши требования, вам нужно будет создать диспетчер учетных данных, который будет предоставлять сервер (http, именованные каналы и т. Д.) Для связи с учетными данными для автоматического входа - здесь нет необходимости тратить время на пользовательский интерфейс. Используйте метод Advice в вашей ITestWindowsCredentialProvider реализации, чтобы запустить сервер, и UnAdvice, чтобы остановить его.

Я бы посоветовал вам в этом помочь:

• Используйте внешнюю службу ведения журнала (например, app-insights), чтобы получать отзывы о вашей службе и упрощать отладку.
• Используйте виртуальную машину в качестве хорошей практики, поскольку критический сбой в Winlogon сделает компьютер бесполезным.
• Используйте try catch на более высоком уровне для всех ваших методов в реализации COM-компонента, чтобы проглотить исключение, чтобы сохранить сбои Winlogon

Кроме того, для большей картины вы должны иметь в виду, что все эти процессы имеют разный доступ (и время жизни для компонентов COM) к станциям Windows, рабочим столам и запускаются от имени разных пользователей. Однако я не думаю, что это будет иметь большое значение для вас.

Вы можете найти базовый код диспетчера учетных данных здесь: https://github.com/phaetto/windows-credentials-provider

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

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

Мой собственный провайдер учетных данных также имеет функцию автоматического входа в систему / разблокировки в некоторых случаях использования.

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

Я не уверен, что вы пытаетесь сделать, но почему бы вместо этого не развернуть задачу запуска для выполнения работы с использованием учетной записи службы на компьютере?

Вы можете настроить его для запуска, даже если пользователь не вошел в систему в указанное время / событие. Если это не сработает, не могли бы вы немного подробнее описать свой сценарий?