2015-02-26 2 views
4

Мы разрабатываем приложение с внутренней системой учетных записей пользователей, но хотели бы иметь возможность использовать учетные данные из учетных записей Active Directory и/или Windows. С этой целью мы сохраняем SID пользователя в поле в таблице пользователей приложения. Наш механизм Войти функции, как это:Использование LogonUser() только для проверки учетных данных

  • Запрашивать домен, логин, пароль
  • Вызов LogonUser(logon, domain, password, logon_type, logon_provider, &hToken)
  • В случае успеха, получить SID пользователя из hToken
  • Закрыть hToken
  • Поиск базы данных нашего приложения для пользователь с данным SID; если они найдены, мы считаемся зарегистрированными в этой учетной записи.

Проблема, что придумал это: мы используем LOGON32_LOGON_NETWORK для logon_type, но теперь мы столкнулись с некоторыми конфигурациями безопасности, где «Доступ к компьютеру из сети» будет отказано, то есть тип сетевого входа в систему запрещено.

Мой вопрос: какой тип входа следует использовать для этой ситуации? Интерактивный? На самом деле мы не используем токен входа для чего-либо другого, кроме как извлечь SID пользователя. Наше приложение имеет собственные внутренние группы и разрешения; мы вообще не используем группы Windows или разрешения. С точки зрения Windows и контроллера домена все, что мы делаем, это вход в систему и быстрый выход из системы.

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

Благодаря

+0

Это настольное приложение или веб-приложение? Почему не следует использовать Kerberos для аутентификации пользователя против AD? – MvdD

+0

Рабочий стол. Мы уже записали материал для входа, и мы надеемся просто изменить этот параметр. Также мы хотим иметь возможность использовать локальные учетные записи Windows в дополнение к AD. – smead

+0

Рабочий стол? Итак, пользователь уже вошел в систему? Почему ваше приложение нуждается в повторном входе в систему, почему бы просто не использовать существующий SID? (Что еще более важно, вы понимаете, что пользователь сможет легко обойти свой механизм входа в систему и войти в ваше приложение как любой другой пользователь?) –

ответ

1

Я также был удивлен, обнаружив, что LogonUser() с LOGON32_LOGON_NETWORK типа терпит неудачу, когда пользователь щелкает правой «Доступ к компьютеру из сети» не предоставляется для всех на локальном компьютере.

Я использую следующий обходной путь:

  • Сначала попробуйте LogonUser() с LOGON32_LOGON_NETWORK типа.
  • Если сбой ошибки ERROR_LOGON_TYPE_NOT_GRANTED, позвоните по номеру LogonUser() с помощью типа LOGON32_LOGON_NEW_CREDENTIALS и поставщика услуг для входа в систему LOGON32_PROVIDER_WINNT50.
+0

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

+0

Сохранение флага - хорошая идея. Я полагаю, что ошибка входа ERROR_LOGON_TYPE_NOT_GRANTED не должна учитываться системой с ошибкой. – Jusid

0

Вы можете общаться с ССПИ услуг для проверки учетных данных пользователя и получить маркер, не требуя особых привилегий. Для этого требуется много неясного кода и

См. Например, http://support.microsoft.com/kb/180548; функция SSPLogonUser - это то, где используется токен.

+0

На самом деле, перечитывая, я не уверен, что это сработает для вас. В любом случае, я оставлю ответ. –

0

Конвенция является использование LOGON32_LOGON_BATCH, как описано:

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

(выделено мной).

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

+0

К сожалению, этого не произойдет, поскольку это право не предоставляется на большинстве систем. Я думаю, что, скорее всего, просто придерживаюсь Interactive. – smead

+0

Большинство системных администраторов не захотят разрешать конечным пользователям входить в систему на сервере в интерактивном режиме. –

Смежные вопросы