Собственно в этом и вопрос.

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

а собственно какой в этом смысл?

токен одной машины на другой не действителен... ну, вроде, есть еще что то вроде делегирования прав, но это из другой оперы, не передачей токена делается... ИМХО. не помню точно.

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

> удалось запустить значит от правильного юзера...

Права на запуск есть у всех, вот и надо определить, кто запустил, а пароль второй раз нельзя спрашивать.


> а узнать от какого, передавай его SID

Теоретически клиент может передать чужой SID, насколько я понимаю узнать SID другого пользователя вообще проблем не составляет. Поэтому клиенту надо как-то доказать, что это его SID.

P.S.
NetBios как то же это делает.

> Права на запуск есть у всех
админы негодуют...

> вот и надо определить, кто запустил
программа твоя? когда винда запускает прогу она ей передает инфу по правам с которыми ее запустила. и юзером от которого запущена.

> Теоретически клиент может передать чужой SID
программа твоя? что значит "теоретически"? ты что его в едит вставлять будешь с напутствием "откорректируйте под другого юзера, если узнаете, счас я его передавать буду..."?

> NetBios как то же это делает.
чудом, не иначе.

> программа твоя? что значит "теоретически"? ты что его в
> едит вставлять будешь с напутствием "откорректируйте под
> другого юзера, если узнаете, счас я его передавать буду.
> .."?

Ответ достойный мастера. Спасибо.

Вопрос, похоже решается с помощью функций
InitializeSecurityContext, AcceptSecurityContext

> Вопрос, похоже решается с помощью функций
> InitializeSecurityContext, AcceptSecurityContext

Так и есть.

Ура, я сделал это! Сколько же всего пришлось изучить нового:)

http://msdn.microsoft.com/en-us/library/aa379449(v=VS.85).aspx

> DiamondShark ©   (05.07.11 16:48) [8]

То, что надо, примерно так я и сделал.

Я в Си не очень хорошо разбираюсь, но кажется в клиенте у них ошибка
http://msdn.microsoft.com/en-us/library/aa380536(v=VS.85).aspx
вот тут:


Ошибка, или я что-то не так понял?

> Дмитрий С ©   (05.07.11 19:24) [9]

Ошибка. И не только там.

InitializeSecurityContext вызывается в функции GenClientContext, которая вызывается в DoAuthentication, которая вызывается в ConnectAuthSocket, которая вызывается в main.

Но это какой-то болезненный бред, потому что DoAuthentication ссылается на hCred, которого нет в её области видимости, и на hcText, которого нет вообще нигде, видимо, это hCtxt. Кроме того, эти переменные используются по значению, тогда как GenClientContext, параметрами которой они являются, принимает указатели.

Если описания переменных из main скопировать в глобальную область видимости, допилить напильником перепутанные имена переменных, значки ссылок и разгрести жуткую смесь юникода, ТЧаров и чаров, то этот пример даже скомпилируется.

Запускать это творение укурившихся индусов я уже не решился.

> DiamondShark ©   (05.07.11 20:52) [10]

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