Админы говорят "у нас доверительные отношения настроены между доменами значит должно!"... а я что-то сомневаюсь. Доверительные это что-то другое, ну типа группы из одного в другом видеть. Ну и в LogonUser явно домен указывается. Но уж больно настаивают, в общем "а вдруг?", дай думаю переспрошу у независимых экспертов. ;)

Хм. вопрос отпал, реально можно, сейчас они там чего-то под шаманили и LogonUser прошел... (до этого была ошибка "не удается преобразовать DSN имя сервера, не найден контроллер домена" ну и "гнали" соответственно на программу)

> sniknik ©

да, сие нормальная практика

> Ну и в LogonUser явно домен указывается.

нестрашно. домен соглашается на проверку юзверей в домене, которому доверяет.

> Игорь Шевченко ©   (01.08.16 13:20) [2]

Игорь, а причем здесь это? Вопрос вполне понятен. Сисадмину, по крайней мере.

> sniknik ©   (01.08.16 13:08) [1]
> не найден контроллер домена" ну и "гнали" соответственно на программу

В следующий раз предложить им запустить cmd.exe при помощи runas и искомого пользователя.
После чего послать в консерватории править )

> В следующий раз предложить им запустить cmd.exe при помощи runas и искомого пользователя.
Было, и не раз. Но "проблема" остается, чуть что - виновата программа, не разбираясь. Это такой прием просто, зачем что-то делать, пробовать, можно же просто обвинить кого то и пусть доказывает (сами втихую у себя поправят и "все в белом", а у тебя вроде выяснили проблем нет, "ложечки нашлись" но "осадочек остался"). Люди меняются (на других в смысле), приемы нет.

Кстати еще вопрос... не по теме, но вытекающий из нее.
Как делать авторизацию через Active Directory? Можно ли вообще, думал что нет, но вон раз уже ошибся.
А то тут с удивлением узнал, что LogonUser устарел, создание процесса/копии из программы неправильно, и вообще виндовые функции - отстой, нужно все делать через Active Directory... а я даже авторизовать юзера через него не могу.

Смысл (/логика при придумывании и написании казалась нормальной, с предыдущим технологом, но тут пришли новые хозяева... и админы чуть ли не сразу после школы), ну да ладно, в общем прога работает так - на сервер приходит логин пароль юзера, клиент авторизуется с "инета"(/из дома/с другого города) но заведен на сервере, там проверяется по LogonUser, есть ли он у нас или нет, и если есть то запускается процесс (копия самой проги) от его имени с которой и работает в последующим программа клиента. Зачем? Ну тогда показалось, что так проще, админы хотели сами права в системе давать на папки/базу и т.д. каждому юзеру (ИМХО просто не хотели в программе назначать, ее же тогда изучать пришлось бы). Ну и да, фактически не используется, так потестили, что возможно, а после всем стали давать "единое право", т.е. подключился значит все можешь. Но переделывать и что то менять ввиду этого смысла не вижу. Если не заставят конечно авторизацию переделать, через Active Directory.

У меня из краткой админской практики сложилось впечатление, что Active Directory - это и есть "хранилище пользователей в домене Windows". Т.е., вообще говоря, это одно и тоже и одно без другого - не существует. Если мы именно про доменых пользователей Windows говорим.
И в этом смысле любая функция LogonUser должна совершенно эквивалентно работать с использованием доменной авторизации (оно же Active Directory) или без ней. Просто в логине требуется указывать домен, если мы именно доменным пользователем хотим залогиниться.

Но на верности этого утверждения про единость "доменная аутентификация Windows" и "Active Directory" настраивать не стану, возможно я что-то упустил важное.

> что Active Directory - это и есть "хранилище пользователей в домене Windows".
Аналогичное ИМХО, база по пользователям и админская оснастка для управления. Административная "надстройка" в общем.
И как вообще использовать ее для логона, если для доступа к ней тоже нужны права которые без логона неизвестны... Прямо притча про курицу и яйцо.

> возможно я что-то упустил важное.
+1
Потому и вопрос. Уж больно уверенные эти "книжные академики, без понимания сути".

>  в этом смысле любая функция LogonUser должна совершенно
> эквивалентно работать с использованием доменной авторизации
> (оно же Active Directory) или без ней. Просто в логине требуется
> указывать домен, если мы именно доменным пользователем хотим
> залогиниться.
>

Насколько я понимаю и помню, теоретически можно логиниться не только в Active Directory.
Возможно, может быть какая-то сетевая служба, которая может проверить учетные данные (не эмулятор AD, а именно отдельная служба).

> sniknik ©   (02.08.16 16:03) [8]
> И как вообще использовать ее для логона,

Вот это не понимаю.
Ты (условный ты) просто логинишься стандартными средствами своей ОС.
Как на самом деле проверяются далее реквизиты логина (которые бывают и по отпечатку пальца, и по ключу физическому) - вообще не парит, особенно если идёт речь про "запустить процесс от имени такого-то пользователя".
ОС проверила и просто сказала "годится" или "нет".

Кстати, в изначальном описании меня несколко удивил момент, где расказывалось про "сначала поискать пользователя, потом если есть такой - то попробовать под ним залогиниться (запустить процесс)". Зачем этап проверки? какой в нём смысл?

Кстати, найдите вот такую книжку электро или печатную
http://forcoder.ru/web-other/programmirovanie-servernyh-prilozhenij-dlya-microsoft-windows-2000-164

На сколько помню, в ней был прям огромный раздел про логоны, логины, токены, наследование прав и токенов, и т.п. именно с точки зрения API и программиста, а не только админа.
Кстати, AD и появилась как раз в 2000 виндовс

> Кстати, AD и появилась как раз в 2000 виндовс
Смутно помню что и в WinNT с последним(?) сервис паком была уже... который вполне возможно после 2000го и вышел.

> Кстати, в изначальном описании меня несколко удивил момент, где расказывалось про "сначала поискать пользователя, потом если есть такой - то попробовать под ним залогиниться (запустить процесс)". Зачем этап проверки? какой в нём смысл?
А меня этот момент возмущает... т.к. мне нужно практически логинить программу под, а не самого юзера, то в большинстве случаев(локальный вариант, не через клиента) сам факт запуска проги от юзера и проверкой существования юзера, логина и его прав, нужно только данных процесса(/паспорте программы) посмотреть кто и от чего. А на доступ к AD у пользователя вполне может прав и не быть чтобы в нем смотреть. Т.е. мало того, что бессмысленная работа, так еще и с возможностью словить там глюки.

> ... от юзера и проверкой ...
... от юзера, является и проверкой...