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

У меня есть служба Windows, которую я хочу использовать для программной разблокировки рабочей станции, используя имя пользователя и пароль.

В этой статье https://technet.microsoft.com/en-us/library/dn751047(v=ws.11).aspx объясняется рабочий процесс аутентификации входа в Windows на следующем изображении: authentication workflow

Как видно выше, на шаге 5 пользователь вводит учетные данные в пользовательский интерфейс входа в систему. Я хочу добиться того, чтобы Windows Service вводила учетные данные и имела winlogon для входа в систему.

Для этого нет API-интерфейса winlogon. Как видно из других вопросов, функция winapi LogonUser успешно выполняет аутентификацию и возвращает токен, но не переключается на рабочий стол приложения, и пользовательский интерфейс входа в систему остается на экране.

Большинство статей и SO-ответы указывают на поставщиков учетных данных, но все образцы сертификатов учетных данных требуют взаимодействия с пользовательским интерфейсом входа в систему.

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

  1. Служба Windows начинается с загрузки Windows (выполняется).
  2. Одна и та же служба Windows имеет веб-службу и принимает HTTP-запросы через API (сделано).
  3. Пользователь предоставляет учетные данные для службы через API с другого устройства (сделано).
  4. Предоставляемые учетные данные используются для входа в рабочую станцию.
    4.1. Предоставляемые учетные данные используются для разблокировки рабочей станции в случае блокировки (WinKey + L).
  5. (Необязательно) Услуга предоставляет учетные записи Windows через API.
  6. (Дополнительно) Пользователь может указать службе, какую учетную запись хочет использовать для входа.

На данный момент я заинтересован в выполнении шагов 4 и 4.1.

ОТВЕТЫ

Ответ 1

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

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

В частности, установите эти ключи

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. Если вы не хотите перезагружаться, чтобы разблокировать, что я сомневаюсь.

Другая альтернатива, которая звучит многообещающе, стоит упомянуть по старому вопросу fooobar.com/questions/322166/...

Ответ 2

Я написал коммерческое решение для этого, называемое 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/

Ответ 3

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

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

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

Если вы хотите сделать что-либо из этого, я не хочу вникать.

Ответ 4

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

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

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

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

Я предлагаю следующее, чтобы помочь вам добраться:

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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